DMARC Analyzer

TL;DR

• An MX (Mail Exchanger) record is a DNS resource record type (RFC 1035 §3.3.9) that maps a domain name to a list of mail-server hostnames willing to accept mail for that domain.
• MX priority semantics: LOWER preference values mean HIGHER priority. An MX with preference 10 is tried BEFORE one with preference 20. RFC 5321 §5.1 mandates random selection among MX records with equal preference values.
• The implicit MX rule (RFC 5321 §5.1) falls back to the A/AAAA records of the domain ONLY if no MX records exist. Publishing any MX record disables the fallback entirely, so a partial MX deployment is worse than no MX at all.
• MX records cannot point at CNAME aliases. RFC 1034 §3.6.2 and RFC 2181 §10.3 require MX targets to resolve directly to A or AAAA records. Pointing an MX at a CNAME produces undefined behaviour across MTAs.
• MX records do NOT affect SPF or DMARC directly. SPF and DMARC apply to OUTBOUND mail (authenticating the sending server); MX applies to INBOUND mail (telling senders where to deliver). The two operate on opposite sides of the SMTP transaction.
• Null MX (RFC 7505: a single MX with preference 0 and target "." — the DNS root name) explicitly tells senders the domain does not accept mail. Use this for parked domains, marketing landing pages, and internal-only domains.
• Backup MX records are usually a liability. Spammers detect the backup and send all their spam there; the backup either accepts everything (backscatter) or rejects forged senders (NDR storm). Either do not publish a backup or configure it with IDENTICAL anti-spam policies as the primary.
• Recommended TTL: 3600 to 86400 seconds. MX records change rarely (typically only when migrating between mail providers), so longer TTLs improve cache efficiency. Lower to 300 to 3600 seconds BEFORE planned migrations and raise back afterwards. See DNS propagation for the pre-emptive-TTL- reduction pattern.

1. Overview: what an MX record is for

Internet email delivery from a sender to a receiver is a multi-hop DNS-mediated process. When a user sends mail to user@example.com, the sending Mail Transfer Agent (MTA) does not directly know which server accepts mail for example.com. It performs a DNS lookup for the MX (Mail Exchanger) record of example.com, receives one or more MX records back, and uses them to identify the SMTP server(s) authoritative for receiving mail addressed to that domain.

The MX record type is one of the original DNS resource record types, defined in RFC 1035 section 3.3.9 (1987) and tightly integrated into the SMTP protocol by RFC 5321 section 5.1. The MX record carries two pieces of data: a 16-bit unsigned integer called the "preference" value (commonly called priority by operators) and a hostname pointing to a mail server. The preference determines the order in which the sending MTA tries the listed servers; the hostname is then resolved to an A or AAAA record to obtain the actual IP address to connect to.

This page is the foundational reference for the help cluster on MX records. For the cryptographic primitives under DKIM signing, see DKIM cryptography basics. For DNS propagation mechanics that apply to MX changes, see DNS propagation. For the transport-security overlay that validates the MX hostname against an HTTPS-published policy, see MTA-STS explained. For per-provider deployment guides whose first step is pointing MX at the provider, see the DMARC for Microsoft 365 and DMARC for Google Workspace guides.

2. MX record syntax (RFC 1035 §3.3.9)

An MX record in standard DNS zone-file format looks like:

example.com.    3600    IN    MX    10    mx.example.com.

The fields, left to right:

• example.com. — the name the record is published under (the domain that wants to receive mail). The trailing dot anchors it as a fully-qualified name.
• 3600 — the TTL (time-to-live) in seconds. See section 11.
• IN — the class (Internet). Universal for all public-internet DNS records.
• MX — the record type.
• 10 — the preference value (priority). See section 3.
• mx.example.com. — the MX target hostname. MUST resolve directly to an A or AAAA record (NOT a CNAME — see section 12).

A typical mail-server deployment publishes multiple MX records for redundancy:

example.com.    3600    IN    MX    10    mx1.example.com.
example.com.    3600    IN    MX    20    mx2.example.com.
example.com.    3600    IN    MX    30    mx3.example.com.

Most cloud-DNS provider UIs (Cloudflare, Route 53, Google Cloud DNS, GoDaddy, Namecheap) ask for the preference and target as separate fields rather than requiring the operator to type the full zone-file syntax. The resulting record is functionally identical.

3. Priority semantics: lower is higher

The MX preference field is a 16-bit unsigned integer (range 0 to 65535) that determines the ORDER in which a sending SMTP server tries the listed MX targets. RFC 5321 section 5.1 specifies the algorithm:

1. Sort the received MX records by preference value, ASCENDING. (Lower preference = higher priority.)
2. Among records with the same preference value, select one randomly. RFC 5321 mandates random selection to spread load across equally-preferred servers; many real-world implementations actually round-robin or use the order in which they were received from DNS.
3. Resolve the selected target to an A or AAAA record. If multiple A/AAAA records are returned, the sender picks one (typically randomly).
4. Attempt SMTP connection on port 25.
5. If the connection fails or the SMTP session ends with a temporary failure (4xx), move to the next MX target in preference order. If the SMTP session ends with a permanent failure (5xx), do not retry to other MX targets — the message is rejected.

The conventional priority spacing (10 / 20 / 30 rather than 1 / 2 / 3) is purely cosmetic: it leaves room to insert a new MX at preference 15 between an existing 10 and 20 without renumbering everything. The relative ordering is what matters, not the absolute values.

Some operators set all MX records to the same preference value as a load-balancing strategy (publishing three MX targets all at preference 10 means senders pick randomly among them). This works but is more brittle than the cluster-aware load balancing that major providers do at the A-record layer (Google Workspace's smtp.google.com resolves to multiple IPs via DNS round-robin, providing load balancing without needing equal-priority MX records).

4. The canonical mail-delivery sequence

From the sender-MTA perspective, delivering mail to user@example.com involves this sequence:

1. Extract the recipient domain. Parse example.com from the RCPT TO envelope address.
2. Query MX records. Send a DNS query for MX example.com to the configured recursive resolver. The resolver returns zero or more MX records.
3. Apply the implicit MX rule if needed. If no MX records are returned (NODATA response, distinct from NXDOMAIN), fall back to the implicit MX rule: treat the A/AAAA records of the domain itself as if they were a single MX target with preference 0. If neither MX nor A/AAAA records exist, bounce with permanent failure (no such domain).
4. Check for null MX. If the only MX record returned is the RFC 7505 null MX (preference 0, target "."), bounce immediately with permanent failure 550.
5. Sort and select. Sort by preference value ascending; select the lowest-preference target. Among ties, select randomly.
6. Resolve the MX target. Query A and AAAA records for the selected MX target hostname. Pick one IP.
7. Connect via SMTP on port 25. Open a TCP connection to the resolved IP on port 25 (or port 587 / 465 for submission, though port 25 is the MX-to-MX standard). Begin the SMTP HELO / MAIL FROM / RCPT TO / DATA exchange.
8. Handle transient failures. If the SMTP session ends with a 4xx response (transient failure: server busy, temporary policy reject), retry the same target later or move to the next-preference MX target on the next retry. Standard retry schedules are exponential-backoff over several days before bouncing as undeliverable.
9. Handle permanent failures. If the SMTP session ends with a 5xx response (permanent failure: no such user, policy reject), bounce the message back to the original sender with the receiver's reason code. Do NOT retry against backup MX targets — the 5xx is a final answer for the message.

Steps 7-9 are the SMTP layer; everything before is the DNS-MX-resolution layer this page covers. The MX-resolution behaviour is identical across all major sending MTAs (Postfix, Exim, Sendmail, Gmail's outbound, Microsoft 365's outbound, Amazon SES) because they all implement RFC 5321 §5.1.

5. Backup MX: usually a liability

The backup MX pattern (publishing multiple MX records at different preference values so senders fall back to a secondary server when the primary is unreachable) made operational sense in the 1990s when primary mail servers had multi-day outages and operators wanted a secondary to queue mail until the primary came back. In modern internet email, backup MX records are frequently a NET LIABILITY rather than a benefit.

The classic bad backup-MX pattern:

• The operator publishes a primary MX (preference 10) at mx1.example.com with production-grade anti-spam filtering, recipient validation, and SPF / DKIM / DMARC enforcement.
• The operator publishes a backup MX (preference 20) at mx2.example.com with weaker or absent anti-spam filtering, often a "catch-all" configuration that accepts mail for unknown recipients and queues it.
• Spammers detect the backup MX (it is in public DNS) and send all their spam directly to the backup, bypassing the primary entirely.
• The backup either accepts everything (creating backscatter and ruining the operator's sending reputation), or generates non-delivery-reports (NDRs) for the forged sender addresses spammers use (creating an NDR storm that floods third parties).

Modern best practice:

• Do not publish a backup MX at all. Major email providers (Gmail, Microsoft 365, ProtonMail, FastMail) operate their own multi-datacenter MX clusters and do not require operator-configured backup MX records. If Google Workspace's MX cluster has an outage, falling back to your home-built secondary is unlikely to improve things.
• If you DO publish a backup MX, configure it with IDENTICAL anti-spam, SPF, DKIM, DMARC, and recipient-validation policies as the primary. The backup must accept the same recipients the primary accepts and reject the same recipients the primary rejects. The simplest way to achieve this is to run the same MTA software with the same configuration file on both servers.
• Consider using cloud-provider MX clusters as your primary. Gmail's primary MX (smtp.google.com) is itself a multi-datacenter cluster with built-in failover. Pointing at it removes the need for backup MX at the operator level.

6. MX records and email authentication

A common operator misconception: changing the MX record affects SPF, DKIM, or DMARC. It does not, except in one narrow case.

SPF (SPF explained) authenticates the SENDING server of an outbound message — when your domain sends mail to a receiver, SPF tells the receiver which IPs are authorised to send on your domain's behalf. SPF is purely an outbound concern. The MX record tells other senders where to deliver mail TO your domain. The two operate on opposite sides of the SMTP transaction.

DKIM (DKIM explained) attaches a cryptographic signature to outbound mail and lets receivers verify the signature via your published DKIM public key in DNS. Like SPF, DKIM is an outbound concern. The MX record is irrelevant to DKIM signing or DKIM verification.

DMARC (DMARC record tags) is the policy layer on top of SPF and DKIM. DMARC alignment is determined by the FROM: header domain matching the SPF MAIL FROM domain (strictly or relaxed per the aspf= tag) or the DKIM signing domain (strictly or relaxed per the adkim= tag). The MX record is not part of any DMARC alignment rule.

The one narrow case where MX and SPF interact: the SPF mx mechanism. An SPF record like v=spf1 mx -all authorises the IPs corresponding to the MX records of the domain. This was useful in early SPF deployments where a single server handled both inbound and outbound mail and the operator wanted "the same server that receives mail for me is the only server that sends mail for me" semantics. In modern deployments where inbound and outbound use completely different infrastructure (Google Workspace for inbound, Mailgun for outbound), the SPF mx mechanism is rarely useful and frequently misleading. Prefer explicit include: or ip4: / ip6: mechanisms that name the actual sending infrastructure.

7. MX patterns by provider

The MX values you publish depend on which mail provider hosts your inbound mail. The canonical patterns for major providers:

• Google Workspace: a single MX record pointing at smtp.google.com at any preference (commonly 1 or 10). Google's DNS round-robin returns multiple IPs behind the single hostname, providing automatic load balancing and failover without needing operator-configured backup MX records. The older multi-target pattern (aspmx.l.google.com / alt1.aspmx.l.google.com / alt2.aspmx.l.google.com / aspmx2.googlemail.com / aspmx3.googlemail.com) was deprecated in favour of the single smtp.google.com entry.
• Microsoft 365: a single MX record pointing at example-com.mail.protection.outlook.com where the prefix is the operator's tenant domain with dots replaced by hyphens. The tenant-specific MX hostname is shown in the Microsoft 365 admin console under the Domains section.
• Amazon SES inbound: a single MX record pointing at inbound-smtp.{region}.amazonaws.com where {region} is the SES receiving region (us-east-1, eu-west-1, etc.).
• Self-hosted Postfix / Exim / Sendmail: an MX record pointing at the operator's mail server hostname, typically mail.example.com or mx.example.com, which itself has an A record at the mail server's public IP. Operators should also publish a matching PTR (reverse DNS) record at the IP pointing back to the same hostname — receivers reject mail from IPs without matching PTR.
• ProtonMail business: two MX records at mail.protonmail.ch (preference 10) and mailsec.protonmail.ch (preference 20). This is one of the few modern cases where operator-configured backup MX is the provider's recommended deployment.
• FastMail: two MX records at in1-smtp.messagingengine.com (preference 10) and in2-smtp.messagingengine.com (preference 20).

For every provider, check the provider's current onboarding documentation to confirm the exact MX values to publish — providers occasionally change their MX hostnames as they restructure their infrastructure.

8. Null MX (RFC 7505): explicitly no mail

RFC 7505 (2015) defines a special MX record that explicitly tells senders the domain does NOT accept mail. The syntax is:

example.com.    3600    IN    MX    0    .

The target field is a literal dot (.) which represents the DNS root name. The preference value MUST be 0. When a sending SMTP server queries MX for the domain and receives this response, RFC 7505 requires it to immediately bounce the message back to the original sender with permanent failure code 550 and a textual reason like "Mail is not accepted at this domain."

The use cases for null MX:

• Parked domains. A domain registered for branding protection or future use that should never accept mail. Without a null MX, mail to user@parked-domain.example either bounces with a confusing "no MX records found" error or falls back to the A/AAAA record (per the implicit MX rule) and attempts SMTP against the web server, which produces additional confusion.
• Marketing landing-page domains. A domain used only for a campaign landing page that the operator does not want operators to send mail to. Null MX produces a clean, immediate bounce rather than a prolonged retry cycle.
• Internal-only domains. A domain used only for internal services (e.g. internal.corp.example) published in public DNS for certificate issuance but not intended to receive mail from the outside internet.
• Subdomains of mail-receiving domains. If your organisational domain example.com receives mail but subdomains like web.example.com or app.example.com do not, publishing null MX records on the subdomains prevents stray mail from reaching your primary mail server.

Null MX is supported by all major sending MTAs in current versions (Postfix since 3.0, Exim since 4.94, Sendmail since 8.16, the proprietary MTAs operated by Google and Microsoft). For older MTAs that do not recognise null MX, the behaviour falls back to "MX target is a literal dot which cannot be resolved", resulting in a permanent failure with a less clean error message but still a bounce.

9. MX records and MTA-STS / DANE transport security

Two modern transport-security overlays operate at the MX-target layer:

• MTA-STS (MTA-STS explained) is an HTTPS-published policy that lists the operator's MX hostnames and instructs sending MTAs to require TLS to those specific hostnames. The MTA-STS policy enumeration of MX hostnames is independent of the DNS MX record and must be kept in sync: if you change your MX target, you must update the MTA-STS policy's mx: list at the same time.
• DANE (MTA-STS vs DANE) publishes TLSA records under the MX target hostname's _25._tcp.{mx-hostname} name that pin the TLS certificate (or certificate authority) the MX server uses. DANE validation requires the receiver's DNS to be DNSSEC-signed.

For both overlays, the MX hostname is the anchor: the operator's MX record points at a hostname; the transport-security policy associates that hostname with a TLS certificate. Changing the MX target requires coordinated updates to whichever transport- security overlay is deployed. See MTA-STS vs DANE for the per-overlay comparison.

10. TTL recommendations for MX records

MX records are the canonical example of a "set once and rarely change" record. The operational change frequency is low (typically only when migrating between mail providers or rebuilding mail infrastructure, perhaps once every several years), and the cache benefit of long TTLs is significant (the millions of recursive resolvers across the internet do not need to re-query the authoritative nameserver every hour for a record that has not changed in three years).

The recommended TTL for stable production MX records is 3600 to 86400 seconds (1 hour to 24 hours). Most major email providers recommend 3600 seconds as a balance between cache efficiency and the time required for a planned migration to complete.

Before a planned MX migration:

1. Two TTL cycles BEFORE the migration, lower the TTL on the existing MX record to 300 seconds (5 minutes). For a current TTL of 86400, this means lowering 48 hours before the migration. The TTL change must propagate BEFORE the actual MX change can take advantage of the shorter window.
2. At the migration moment, publish the new MX record (still at 300- second TTL). Recursive resolvers see the new MX within 5 minutes.
3. After the migration is confirmed stable (typically 24 to 72 hours after the change), raise the TTL back to 3600 or 86400 for cache efficiency.

See the DNS propagation deep dive for the complete pre-emptive-TTL-reduction pattern that applies to MX, DKIM, DMARC, and every other actively-managed DNS record.

11. Common MX-record mistakes

• Pointing MX at a CNAME. Forbidden by RFC 1034 §3.6.2 and RFC 2181 §10.3. The MX target MUST be a hostname that resolves directly to an A or AAAA record, not to another DNS alias. Common accidental occurrence: pointing MX at mail.example.com while mail.example.com is itself a CNAME to smtp.example.com elsewhere. Verify with dig that the MX target has a direct A/AAAA record, not a CNAME chain.
• Forgetting the trailing dot. In zone-file syntax, the MX target must end with a literal dot to anchor it as a fully-qualified name. An MX target without the trailing dot will have the zone's origin appended: mx.example.com (no dot) in a zone file for example.com becomes mx.example.com.example.com — almost certainly not what the operator intended. Cloud DNS provider UIs usually handle this automatically; manual zone-file editing requires care.
• Missing PTR record on the MX target IP. Receivers reject mail from IPs without a matching reverse-DNS record. If your MX is mx.example.com at IP 203.0.113.10, the PTR record at 10.113.0.203.in-addr.arpa should resolve back to mx.example.com. Without matching PTR, your outbound mail will be rejected by Gmail, Microsoft 365, Yahoo, and most other major receivers.
• Partial MX deployment that defeats the implicit MX rule. Publishing any MX record disables the RFC 5321 implicit-MX fallback to A/AAAA. An operator who publishes a single broken MX (typo in the target hostname, target that does not resolve, target that is offline) will not fall back to the A record of the domain; they will bounce. If you cannot deploy MX correctly, do not deploy MX at all and let the implicit-MX fallback to your domain's A record handle mail delivery.
• MX priority direction confusion. Operators sometimes assume HIGHER preference numbers mean higher priority. The opposite is true: LOWER preference numbers are tried FIRST. A backup MX at preference 10 and a "primary" at preference 20 means senders try the backup first.
• Publishing equal-preference MX records and expecting deterministic selection. Per RFC 5321 §5.1, senders MUST select randomly among MX records with equal preference. If you publish two MX records both at preference 10, you cannot predict which one any given message will hit. Use distinct preference values if you need a deterministic primary-vs-backup relationship.
• Forgetting to remove the null MX when starting to accept mail. If you previously published a null MX because the domain was parked and you now want to accept mail, the null MX must be REMOVED and replaced with a real MX before mail flows. Senders see the null MX first and bounce.
• Inconsistent MX between public DNS and internal split-horizon DNS. If your domain uses split-horizon DNS (different views for internal vs external queries), the public-DNS MX records are what other senders use; internal MX records affect only internal queries. Inconsistency causes "mail works from inside but not from outside" or vice versa.

12. Troubleshooting "mail is bouncing"

When MX-based mail delivery fails, work the diagnostic funnel:

1. Confirm the MX record is published. dig +short MX example.com should return one or more lines of the form 10 mx.example.com.. If it returns nothing, the MX is either not published or not propagated yet — see DNS propagation.
2. Confirm the MX target resolves to an A/AAAA record (not a CNAME). dig +short A mx.example.com should return one or more IP addresses directly. If it returns nothing, or returns a CNAME chain, the MX is misconfigured per the no-CNAME rule.
3. Confirm the MX target IP is reachable on port 25. From a host that has outbound port-25 access (not a residential ISP — port 25 is blocked from most residential connections), telnet mx.example.com 25 should produce a 220 SMTP banner. If the connection times out, port 25 is blocked upstream or the server is down.
4. Confirm PTR records on the outbound IP. For outbound mail being rejected by receivers, dig -x <outbound-ip> should return a PTR pointing back to your MX hostname (or a closely-related hostname). Missing or mismatched PTR is the single most common cause of receiver-side rejection.
5. Check sender-side IP reputation. Even with correct MX and PTR, a sending IP with a bad reputation (recently used by spammers, listed on Spamhaus or other RBLs) will be rejected at the SMTP level. The DMARC Analyzer Blacklist Checker queries the major RBLs directly.
6. Inspect the receiver-side bounce message. A clean bounce with a 5xx code and a descriptive reason (e.g. "550 5.7.1 SPF check failed", "550 5.7.26 DMARC alignment failed") tells you exactly what the receiver objected to. Use the Email Header Analyzer to parse the Authentication-Results header for the full receiver-side verdict.
7. Compare against the DMARC RUA aggregate-report stream. The DMARC aggregate reports are the authoritative source for what receivers are observing across all your domain's mail flow. A drop in reported message volume from a specific receiver often indicates a delivery-rejection pattern that is otherwise invisible.

13. FAQ — common questions about MX records

What is an MX record?

An MX (Mail Exchanger) record is a DNS resource record type that maps a domain name to a list of mail-server hostnames willing to accept mail for that domain. Defined in RFC 1035 section 3.3.9 and used by SMTP per RFC 5321 section 5.1. Without an MX record (or a fallback A/AAAA per the implicit MX rule), no mail can be delivered to the domain.

How does MX priority work?

MX priority (technically "preference") is a 16-bit unsigned integer. LOWER values mean HIGHER priority — an MX with preference 10 is tried before one with preference 20. Among MX records sharing the same preference, RFC 5321 mandates random selection. Conventional spacing (10 / 20 / 30) leaves room to insert new records without renumbering.

What is a backup MX and why are they often misconfigured?

A backup MX is a secondary mail-exchanger for fallback when the primary is unreachable. The pattern was operationally useful in the 1990s but is now frequently a liability: spammers detect the backup and send all their spam there, bypassing the primary anti-spam filtering. Modern best practice: either configure the backup with IDENTICAL anti-spam policies as the primary, or do not publish a backup at all.

Does my MX record affect SPF or DMARC?

No, not directly. SPF and DMARC apply to OUTBOUND mail (authenticating the sending server); MX applies to INBOUND mail (telling senders where to deliver). The two operate on opposite sides of the SMTP transaction. The one indirect connection is the SPF "mx" mechanism, which authorises the IPs of your MX records to send on your behalf — useful only when inbound and outbound share IPs.

What is a null MX record?

A null MX (RFC 7505) is a special MX record that explicitly tells senders the domain does NOT accept mail. The syntax is a single MX with preference 0 and target "." (a literal dot — the DNS root name). Senders bounce immediately with permanent failure 550. Use for parked domains, marketing landing pages, and internal-only domains.

What TTL should I set for my MX records?

For stable production MX, use 3600 to 86400 seconds (1 hour to 24 hours). MX records change rarely and longer TTLs improve cache efficiency. Before a planned migration, lower the TTL to 300 to 3600 seconds two TTL cycles in advance, then raise back after the migration is stable.

Can an MX record point to a CNAME?

No. RFC 1034 section 3.6.2 and RFC 2181 section 10.3 prohibit pointing an MX at a CNAME alias. The MX target MUST resolve directly to an A or AAAA record. Violating this rule produces undefined behaviour across MTAs.

Why is my MX record not working — mail is bouncing?

Work the diagnostic funnel: confirm the MX record is published (dig +short MX), confirm the MX target resolves directly to A/AAAA (no CNAME), confirm SMTP connectivity on port 25, check reverse-DNS (PTR) on the IP, check IP reputation against RBLs, inspect the receiver-side bounce code, and compare against the DMARC aggregate-report stream. The most common actual cause is missing or mismatched PTR records.

14. Related guides

• DNS propagation — TTL mechanics, the multi-resolver verification workflow, and the pre-emptive-TTL-reduction pattern that applies to MX migrations.
• Reverse DNS & PTR records — the natural DNS-record sibling. MX defines the inbound mail endpoint; PTR is the reverse-resolution proof for the sending IP that receivers (Gmail, Microsoft 365, Yahoo) check before accepting outbound mail. Missing or mismatched PTR is the single-most-common actual cause of bounces traced back to MX-target IPs (called out in section 13 of this page). Covers IPv4 + IPv6 reverse zones, the canonical forward-confirmed-reverse-DNS (FCrDNS) validation rule receivers apply, the SPF ptr mechanism (RFC 7208 §5.5 — deprecated but still implemented), shared-IP PTR constraints, and per-provider PTR coordination patterns for AWS EC2 / Google Cloud / Azure / dedicated-IP ESPs.
• SPF explained — outbound-side authentication. The SPF "mx" mechanism is the only direct connection between SPF and MX records.
• include vs ip4 vs a vs mx — the four-mechanism decision view — the focused side-by-side comparison of the four IP-providing SPF mechanisms, one of which (mx / mx:<domain>) IS directly coupled to the MX records this page documents. Picking mx in an SPF record creates a structurally- coupled-edit defect class similar to the MTA-STS policy mx: coupling documented above: every host listed in the MX RRset on this domain is automatically promoted to an authorised SPF sender at evaluation time (the SPF evaluator expands mx by looking up the MX RRset then resolving A/AAAA records for each MX target — RFC 7208 §5.4), so adding a new MX target without auditing whether that target's IPs should also be authorised SPF senders silently widens the SPF authority boundary. The reverse coupling is sharper: mx costs 1 + N DNS lookups (one for the MX RRset, then one A/AAAA per MX target — second most common 10-lookup-overrun source per RFC 7208 §4.6.4) so growing the MX list past 9 entries on a domain that ALSO publishes include:<vendor> tokens will push the SPF record over the permerror cliff. Read this decision view when designing the SPF record for a domain whose MX list might grow — the spoke documents when to prefer ip4:<cidr> literals (zero lookups, immune to MX-list growth) over the deceptively simple mx token.
• SPF for Google Workspace — the WORKSPACE-TENANT-5-MX-HOST- INVENTORY-AS-INBOUND-MX-RR-PUBLICATION- SUBSTRATE companion to this MX-record byte-level reference. Where THIS page documents the RFC 1035 §3.3.9 MX-record wire-format and the per-domain MX-list publication semantics in protocol-neutral terms, the SPF-for-Google-Workspace spoke documents FOUR Workspace-tenant-specific MX-vs-SPF-decoupling patterns: (i) the inbound vs outbound surface separation — the MX RRset at the customer-domain DNS zone publishes the 5-host aspmx.l.google.com + alt1..alt4 ascending-priority inventory governing INBOUND Workspace mail flow (Gmail's mailbox receivers), but the OUTBOUND authorisation surface lives at a completely separate include:_spf.google.com SPF record token — pointing at a different DNS zone managed by Google, NOT at the customer-domain MX RRset — so an operator publishing the Workspace MX inventory gains receive-side mail-flow but gains ZERO outbound SPF authorisation until the SPF record is independently published; (ii) the SPF mx mechanism IS NOT what Workspace operators use — although the SPF mx mechanism documented on this page would technically promote the five aspmx.l.google.com-tier hosts to authorised SPF senders, Workspace operators ALMOST NEVER use mx in their SPF record because (a) Workspace-tenant outbound mail egresses from a Google-managed netblock distinct from the inbound MX hosts so promoting the MX hosts to SPF authorisation would NOT authorise the actual outbound IPs, and (b) the include:_spf.google.com token authorises the correct outbound netblocks at ~4 lookups directly — making the SPF-mx-mechanism-vs-include-cascade decision firmly favour include for the Workspace tenant population; (iii) the recursive include expansion the Workspace SPF token unfolds at receiver-side resolution — _spf.google.com → _netblocks.google.com + _netblocks2.google.com + _netblocks3.google.com — consuming ~4 DNS lookups, structurally independent from the 5-host MX inventory the customer-domain DNS zone publishes, and (iv) the Workspace-tenant SMTP-relay and outbound-gateway egress paths — Workspace's SMTP-relay service uses additional outbound IP ranges that may require secondary include tokens beyond _spf.google.com for full coverage, a topology decision documented at the SPF-for-Workspace spoke independent of the inbound MX publication this page documents. Pair this MX-record byte-level reference (governing the INBOUND-side mail flow at the customer-domain DNS zone) with the SPF-for-Google-Workspace spoke (governing the OUTBOUND-side SPF authorisation surface at _spf.google.com + optional extension tokens) when adopting Workspace — the two surfaces are byte-completely-independent at the customer-domain DNS zone and must be published independently for full bidirectional Workspace mail flow plus outbound DMARC alignment.
• SPF mechanisms explained (per-directive RFC 7208 §5 reference) — the MX-RECORD-PUBLICATION-AS- FOUNDATIONAL-INPUT-FOR-SPF-mx-MECHANISM- RESOLUTION companion to this MX-records- explained reference. Where THIS page documents the MX-record publication contract at the customer-domain DNS zone (per-host priority value, host-name canonical-name resolution to A/AAAA records, multi-MX-host fallback ordering, per-receiver cache-aging behaviour), the SPF-mechanisms-explained spoke is the DOWNSTREAM-AUTHORIZATION-CONSUMER companion documenting how the SPF mx: mechanism's receiver- side evaluation algorithm consumes the MX-record publication as its load- bearing DNS substrate. The MX-RR-VS- SPF-mx-MECHANISM-INTERACTION cross- reference establishes FOUR structurally- distinct dimensions where the spoke's per-directive mx: reference is the load-bearing downstream consumer of the MX-record-publication discipline THIS page documents: (i) MX RR publication as the foundational DNS substrate the SPF mx: mechanism resolves against — without correctly-published MX records the mx: mechanism produces spf=permerror — the spoke documents that the SPF mx:<domain> mechanism directs the receiver-side SPF evaluator to resolve the MX-record-host-list at the specified domain and use the resolved MX hosts' A records as the authorization set; if the publisher's MX RR publication is malformed, unpublished, or returns NXDOMAIN, the receiver-side SPF evaluation of the mx: mechanism produces spf=permerror per RFC 7208 §5.4 — making THIS page's MX-record- publication discipline the load-bearing prerequisite for any SPF record that uses the mx: mechanism for self- authorization; (ii) MX-host-list cardinality determines SPF mx: lookup- cost accounting against the §4.6.4 ten- DNS-lookup budget — each resolved MX host adds 1 lookup beyond the initial MX-record-set resolution — the spoke documents the per-directive lookup-cost accounting where the mx: mechanism consumes 1 lookup to retrieve the MX RR set + 1 lookup per resolved MX host's A-record resolution; THIS page's documented multi-MX-host publication topology (5-MX-host Google Workspace inventory, dual-MX failover topology, secondary MX hot-standby topology) directly determines how many lookups the publisher's mx: mechanism consumes against the §4.6.4 budget — informing the publisher's choice between mx: mechanism (DNS-resolved authorization set) and ip4: literal (static-budget- conservation authorization set); (iii) MX-host A-record cohabitation in SPF mx: evaluation — the receiver resolves each MX host's A record adding lookups per MX host beyond the initial MX-set retrieval — the spoke documents that the mx: mechanism's per-MX-host A-record resolution makes the publisher's MX-record-host's A- record stability a load-bearing prerequisite for SPF mx: evaluation — when an MX host's A record is rotated, the receiver-side SPF mx: evaluation may consult a stale recursive-resolver cache of the OLD A-record IP set, producing per- receiver heterogeneous SPF outcomes during the rotation cutover window — THIS page's per-MX-host A-record cohabitation discipline directly informs the receiver-side SPF mx: evaluation stability; (iv) MX-rotation cadence directly affects SPF mx: stability — receiver-cache-staleness vs publisher-rotation timing skew is a load-bearing per-receiver evaluation-stability dimension — the spoke documents that MX-record rotation events (failover-to-secondary, provider-migration, MX-host-IP- rotation) directly affect the receiver- side SPF mx: evaluation outcome through the per-receiver DNS-cache- aging behaviour — THIS page's per- rotation cadence discipline (MX TTL choice, dual-MX overlap window, coordinated-cutover-vs-flash-cutover decision) is the publisher-side instrument the SPF mx: mechanism's per-receiver evaluation stability depends on. Read the SPF-mechanisms- explained spoke alongside this MX- records-explained reference when authoring an SPF record that uses the mx: mechanism for self- authorization or when planning an MX-rotation that may affect downstream SPF evaluation — the spoke is the canonical per-directive RFC 7208 §5 evaluation-contract reference whose mx: mechanism's per-receiver- evaluation behaviour is directly gated by the MX-record-publication discipline THIS page documents.
• Why SPF alone is insufficient — the MX-RR-PUBLICATION-VS-SPF-ALONE- DEFICIENCY companion to this MX-record byte-level reference. Where THIS page documents the per-publisher per-domain RFC 1035 §3.3.9 MX-record wire-format (16-bit preference + RR-name target hostname) and the per-domain MX-list publication discipline governing INBOUND mail delivery, the why-SPF-alone-is-insufficient spoke documents FOUR structural-deficiency axes in the publisher-side SPF authentication pillar that the MX-record-publication topology this page documents intersects with: (i) the second-hop forwarding break — a per-publisher per-domain MX-record-published mail-exchange host accepts mail addressed to the publisher's domain correctly per RFC 5321 §5.1 MX- resolution, but if that receiving MTA forwards the message onward (mailing list, role-mailbox forwarder, alumni address), the second-hop MTA emits from ITS OWN IP, not the publisher's SPF-authorised source IPs; the downstream receiver-side SPF evaluator checks the second-hop forwarder IP against the publisher's SPF record (because the envelope MAIL-FROM still names the publisher), and the check FAILS even when the publisher's MX records and SPF record are byte- correctly published — the canonical forwarding-break SPF deficiency documented in the help_spf_forwarding_issues.php sibling-spoke immediately below; (ii) the header-From vs envelope-From decoupling — SPF authenticates the envelope MAIL-FROM domain, not the visible RFC 5322 From: header domain users see in their MUA; an attacker can craft a message with a benign envelope MAIL-FROM (passing SPF) but a spoofed From: ceo@victim.example header, and the receiver-side SPF verdict says spf=pass for the unspoofed envelope domain while the user sees the spoofed From: header — a deficiency the publisher-side DKIM d=-tag alignment plus DMARC alignment policy were specifically designed to close; (iii) the 10-DNS-lookup permerror cliff — RFC 7208 §4.6.4 caps SPF evaluation at 10 DNS lookups; growing the MX list past 9 entries on a domain that ALSO publishes the SPF mx mechanism plus 1–2 include:<vendor> tokens silently crosses the cliff and produces spf=permerror at receivers, which DMARC treats as fail-with-no-alignment — directly coupled to the MX-list-growth discipline THIS page documents (every new MX target adds 1 A/AAAA lookup against the 10-lookup budget when the mx SPF mechanism is in play); (iv) shared-host source-IP overlap — when the publisher's outbound MTA shares a source-IP range with hundreds or thousands of other tenants on a shared-hosting platform or per-region cloud-egress NAT (a topology commonly co-occurring with shared MX-target inheritance on the same platform), SPF pass provides ZERO per-tenant attribution because the +a and +include tokens authorise the shared range, not the per-tenant sender — only DKIM d=- aligned cryptographic attestation closes this per-tenant attribution gap. The four-axis deficiency taxonomy this spoke documents is the load-bearing rationale for layering DKIM and DMARC on top of SPF in every publisher-side authentication portfolio; pair the spoke with this MX-records reference when designing the publisher-side authentication stack — the MX-record publication this page documents governs INBOUND delivery integrity, while the SPF-alone-deficiency taxonomy governs OUTBOUND authentication-pillar coverage, two structurally-distinct concerns that compose at the per- publisher per-domain DNS-publication boundary.
• SPF forwarding issues (the second-hop break) — the MX-RECORD-OF-FORWARDER-MTA-AS- SPF-AUTH-FAILURE-DOWNSTREAM-CONSUMER companion to this MX-record byte-level reference. Where THIS page documents the RFC 1035 §3.3.9 MX-record wire- format (16-bit preference + RR-name target hostname), the per-domain MX- list publication semantics (multiple equal-preference MXs for round-robin load-balancing, ascending-preference for primary-secondary failover), and the MX-target-host A/AAAA resolution cascade that produces the per-mail- exchange IP-list that the receiver- side delivery path uses, the SPF- forwarding-issues spoke documents the DOWNSTREAM CONSUMER PATTERN where the FORWARDER'S MX-record-published mail- exchange host (typically a mailing- list MTA at lists.example.org MX RR, an .forward-based personal mail forwarder at the original recipient's MX RR, an internal-relay MTA at a corporate intermediary, or a SaaS-platform feedback-loop-relay MTA) re-emits the original message from the FORWARDER'S OWN IP set published in the FORWARDER'S OWN MX-record-A/ AAAA cascade — which is NOT in the publisher's SPF authorised-IP set — producing the receiver-side spf=fail verdict at the forwarder boundary. FIVE structurally- distinct MX-RECORD-VS-FORWARDER-SPF- BREAK operational classes the spoke catalogues that THIS MX-record-byte- level reference cross-references but does not enumerate: (i) mailing- list-MTA second-hop SPF break — the mailing-list infrastructure (Mailman / Listserv / Google Groups / sympa) operates an authoritative MX at lists.<domain> whose A-record IP set is the list- operator's outbound IP-pool, NOT in the original-sender publisher's SPF record; (ii) personal- forwarder .forward-file SPF break at hand-off MTA — when a recipient at user@old-domain.org configures .forward to user@new-domain.org, the OLD-DOMAIN MX-record-target MTA re- emits the message from its own IP to the NEW-DOMAIN MX, producing a per- forwarded-message spf=fail at the new-domain receiver; (iii) corporate-internal-relay MTA chain SPF break — corporate topologies with an internal-MX hierarchy (perimeter MTA → security- scanning MTA → user-mailbox MTA) each publish their own MX-record and re- emit from their own IP — every hop beyond the perimeter SPF-verifying layer produces a per-hop spf=fail at the next layer; (iv) SaaS-platform feedback-loop-relay SPF break — SendGrid / Mailgun / SES / Postmark feedback-loop-relay MTAs forward bounce-and-complaint reports from the ISP-FBL infrastructure to the publisher's RUF / abuse mailbox, producing forwarder-hop spf= fail rows on the publisher's receiver-side authentication-results; (v) SRS / rewritten-MAIL-FROM as forwarder-side structural remediation — RFC 7489- recommended Sender Rewriting Scheme re-writes the envelope MAIL FROM to a forwarder-controlled domain whose SPF record DOES authorise the forwarder's MX-record-target IP, restoring SPF- aligned-pass at the second-hop receiver. Read the SPF-forwarding- issues spoke alongside this MX-record byte-level reference when designing the per-organisation forwarder topology — the MX-record-publication choices the operator makes at every layer of a forwarder-chain directly determine which hop produces the spf=fail verdict and which deployment-tier remediation (SRS rewriting, ARC re-sealing, receiver-side trusted-forwarder allowlist) restores DMARC-aligned- pass.
• ARC (Authenticated Received Chain) explained — the FORWARDER-MX-HOP-AS-ARC-CHAIN- INTERMEDIATE-SIGNER-BOUNDARY-PRESERVING- AUTHENTICATION-VERDICT-ACROSS-MX-ROUTING- HOPS companion to this MX-records DNS-RR reference. Where THIS page documents the RFC 1035 §3.3.9 MX resource-record syntax, the per-domain MX-RR-priority-and-target- host publication discipline, the per- receiver-cohort MX-routing topology determining which receiver-MTA host receives connections from sender-MTA hosts, and the per-receiver MX-hop boundary at which the per-message SPF and DKIM evaluation runs, the ARC spoke documents the RFC 8617 three-header sealing protocol whose per-forwarder-MX-hop intermediate- signer attestation chain preserves the per-message authentication verdicts across the per-MX-hop routing boundary at FOUR per-MX-routing-vs-ARC-chain-of-custody coupling dimensions: (i) per- forwarder-MX-target as ARC-chain intermediate signer boundary — when the receiver-side MX-RR routes inbound mail through a forwarder-MTA (mailing-list-manager MX target, .forward- rewrite MX target, corporate-gateway MX target), the forwarder-MTA acts as an intermediate ARC-chain signer emitting an ARC-Authentication-Results / ARC-Message- Signature / ARC-Seal triplet attesting the per-hop authentication state at the forwarder ingress boundary — the ARC spoke documents the per-intermediate-signer attestation discipline whose per-hop chain the downstream receiver evaluates; (ii) per-MX-hop SPF=pass at original sender vs SPF=fail at forwarder-MX-hop preserved by ARC-AAR — the canonical SPF forwarder-second-hop break documented at the SPF-forwarding-issues spoke above materialises at the forwarder- MX-hop boundary; ARC bridges the verdict gap by attesting the original-MX-hop SPF=pass verdict in the ARC-Authentication- Results header at the forwarder-MX-hop ingress, so the downstream-MX-hop receiver can honour the original-hop verdict despite the forwarder-MX-hop SPF=fail; (iii) per-MX-hop DKIM body-rewrite invalidation vs ARC-AMS attestation preservation — when the forwarder- MX-hop modifies the message body (mailing- list footer injection, body-content rewriting) invalidating the per-message DKIM signature's body-hash bh= or canonicalization c= verification at the downstream-MX-hop, the forwarder-MX-hop's ARC-Message-Signature attests the per-hop authentication state at the forwarder ingress (when DKIM was still valid) so the downstream receiver can honour the original-hop DKIM verdict — the ARC spoke documents the per-hop ARC-AMS attestation discipline that survives the per-MX-hop body-rewrite invalidation; (iv) per-MX-hop receiver-side ARC-chain honour- policy as per-MX-hop deployment-tier remediation — the per-MX-hop receiver-side ARC-chain honour policy (Gmail honours valid ARC chains from trusted ARC-signers; Microsoft EOP honours conditionally per ARC-trust configuration; other receivers vary) determines whether the downstream-MX-hop per-message verdict attributes ARC-honoured forwarder traffic as legitimate OR rejects it as DMARC=fail — the ARC spoke documents the per-receiver ARC-trust-configuration discipline whose per-MX-hop application IS the deployment- tier remediation the spf_forwarding_issues spoke's "ARC re-sealing" recommendation operationalises. Read the ARC spoke when designing the per-publisher per-domain DMARC-aligned-pass-rate floor whose per-forwarder-MX-hop survival depends on the per-hop ARC-chain-of-custody attestation discipline downstream MX-hop receivers honour.
• DKIM explained — outbound-side cryptographic signatures. Independent of MX configuration.
• DKIM cryptography basics — the foundational cryptographic reference for the DKIM cluster.
• DKIM key rotation — the MX-RECORD-DETERMINES-WHICH-RECEIVER- MTAS-VERIFY-DKIM-SIGNATURES companion to this RFC 1035 §3.3.9 MX-record reference. Where THIS page documents the canonical MX-record resolution semantics that gate every inbound SMTP delivery, the DKIM- key-rotation spoke documents FOUR MX-vs-DKIM-rotation interaction dimensions: (i) receiver MX- record determines WHICH resolver infrastructure caches the rotated DKIM TXT-record — Gmail-receive-side resolves DKIM TXT records via Google's recursive resolver fleet (with its own cache-aging posture); Microsoft-receive- side resolves via Microsoft's recursive resolver fleet (with its own posture); enterprise-on-prem MX-target resolves via the operator's own recursive resolver fleet — the rotation spoke documents the per-receiver-population heterogeneous cache-aging-posture operators must model when planning a key rotation across a recipient base that spans multiple mailbox providers each with their own MX-record-driven resolver infrastructure; (ii) per-MX- backup-fallback DKIM-key-resolution coordination when primary MX is unavailable — the per-receiver-side fallback to a secondary MX with a DIFFERENT cache-aging posture during primary-MX outage — the rotation spoke documents the operationally-significant per-receiver edge case where the rotation cutover window coincides with a primary-MX- outage event and secondary MX targets with their own separate resolver caches may serve STALE DKIM key data for the secondary-MX-resolver-cache TTL window; (iii) implicit MX-from-A fallback rule (RFC 5321 §5.1) and its DKIM-rotation implications when the publisher domain has NO published MX record — the rotation spoke documents the per-publisher edge case where the publisher's domain falls back to A/AAAA- of-domain for SMTP delivery and the per-recipient resolver caching of BOTH the implicit-MX-via-A record AND the DKIM TXT record at <selector>._domainkey.<domain> gates the per-receiver DKIM-verification readiness window; (iv) cloud- mailbox MX-target-points-at-provider pattern (Google Workspace aspmx.l.google.com, Microsoft 365 <tenant>.mail.protection.outlook.com) and the per-provider DKIM-TXT-record- resolver-cache-aging-posture interaction during operator-initiated rotations — the rotation spoke documents the canonical pattern where the operator's outbound DKIM-signed mail flows from the operator's own MTA-infrastructure (or a cloud provider's signing infrastructure) but the receiver-side DKIM verification happens at the mailbox-provider's MX target whose resolver-cache posture for the operator's DKIM TXT record gates the receiver-side verification readiness window. Read the rotation spoke when planning a DKIM-key-rotation event on a domain whose recipient base spans multiple mailbox-provider MX targets — the spoke is the authoritative per-rotation operational reference for the MX-record-meets-DKIM-rotation- receiver-side-resolver-cache-aging- posture cross-cluster boundary.
• DMARC record tags explained — every tag in the DMARC DNS record. DMARC alignment is independent of MX configuration.
• DMARC alignment explained — the alignment rules that determine whether SPF or DKIM pass results contribute to DMARC. MX is not part of any alignment rule.
• MTA-STS explained — the HTTPS-published transport-security policy that lists the operator's MX hostnames and requires TLS to them.
• MTA-STS policy file syntax (byte-level reference) — the byte-level reference for the mx: directive that enumerates receiver MX hostnames in the mta-sts.<domain>/.well-known/mta-sts.txt policy file. The MTA-STS policy mx: list MUST stay in lockstep with the actual MX records this page documents — every hostname in the published MX RRset MUST appear in the policy's mx: directive (with * leftmost-label wildcards permitted to compress provider patterns like mx: *.googlemail.com covering the aspmx.l.google.com / alt1-4.aspmx.l.google.com cluster), or sending MTAs will refuse to deliver to MX targets outside the policy list. The MX-record edit and the policy-file mx: edit are coupled changes: adding a new MX target without simultaneously adding the hostname to the mx: directive breaks inbound delivery from MTA-STS-enforcing senders the moment the new MX is preferred. Read this spoke when planning any MX-target migration on a domain that has MTA-STS in mode: enforce.
• MTA-STS vs DANE — the comparison of transport-security standards, both of which operate at the MX-target layer.
• MTA-STS for Google Workspace — the WORKSPACE-TENANT-MX-RECORD- PUBLICATION-AT-aspmx.l.google.com-TIER-d- INVENTORY-AS-PREREQUISITE-FOR-WORKSPACE- MTA-STS-mx-DIRECTIVE-AND-ENFORCE-MODE- STARTTLS-BOUNDARY companion to this MX- records pillar. Where THIS page documents the MX record's RFC 1035 §3.3.9 byte-level encoding (the 16-bit preference + variable- length QNAME-encoded mail-exchange host, the no-CNAME-as-MX-target rule from RFC 2181 §10.3, the per-preference load- balancing semantics receivers consume) — i.e. the AUTHORITATIVE-DNS-RR-PUBLICATION side of the inbound mail-delivery topology — the MTA-STS-for-Google-Workspace spoke is the WORKSPACE-TENANT-SPECIFIC MTA-STS-mx-DIRECTIVE-CONSUMER companion documenting the structural dependency between the MX record publication this page documents and the Workspace tenant's MTA-STS policy file mx: directive: (i) Workspace's Admin-Console-driven MX inventory is the 5-host tier'd aspmx.l.google.com (priority 1) + alt1.aspmx.l.google.com (priority 5) + alt2.aspmx.l.google.com (priority 5) + alt3.aspmx.l.google.com (priority 10) + alt4.aspmx.l.google.com (priority 10) pattern — the Workspace operator publishes these five A-record-terminating MX targets at the customer-vanity-domain DNS zone exactly per the MX-record-publication mechanics this page documents; (ii) the Workspace MTA-STS policy file at https://mta-sts.<workspace- domain>/.well-known/mta-sts.txt publishes a mx: directive listing that MUST stay in lockstep with the published MX RRset — the Workspace spoke documents the operator- discipline pattern that uses mx: *.googlemail.com wildcard OR enumerates all five aspmx / alt1-4.aspmx hostnames explicitly; (iii) an MX-record edit on a Workspace-hosted domain that changes the tier'd MX inventory (e.g., adding a custom inbound smart-host MX, re-pointing to a third-party security gateway) MUST coordinate with the Workspace MTA-STS policy file's mx: directive update — adding an MX target without updating the policy file breaks inbound delivery from MTA-STS-enforcing senders the moment the new MX is preferred (the coupled-changes invariant this page documents in the MTA-STS context fires on Workspace-hosted domains identically); (iv) the Workspace MTA-STS spoke documents the Workspace-specific MX- record-publication-vs-MTA-STS-policy- publication coordination cadence the Workspace operator runs (including the third-party-inbound-security-gateway case where the operator's MX is NOT the Workspace tier'd inventory and the mx: directive must reflect the gateway's inbound MX hostnames instead). Read the MTA-STS-for- Google-Workspace spoke alongside this MX-records pillar when planning MX publication on a Workspace-hosted domain — the Workspace-tenant-specific 5-MX-host tier'd inventory the spoke documents is the load-bearing MX-record-publication consumer whose authoritative DNS publication this page documents enables, and whose MTA-STS mx:- directive lockstep coordination is the operator's coupled-change discipline.
• MTA-STS for Microsoft 365 — the M365-TENANT-MX-RECORD-PUBLICATION- AT-tenant.mail.protection.outlook.com- SINGLE-MX-TARGET-AS-PREREQUISITE-FOR- M365-MTA-STS-mx-DIRECTIVE-AND-ENFORCE- MODE-STARTTLS-BOUNDARY companion to this MX-records pillar. Where THIS page documents the MX record's RFC 1035 §3.3.9 byte-level encoding (the 16-bit preference + variable- length QNAME-encoded mail-exchange host, the no-CNAME-as-MX-target rule from RFC 2181 §10.3, the per- preference load-balancing semantics receivers consume) — i.e. the AUTHORITATIVE-DNS-RR-PUBLICATION side of the inbound mail-delivery topology — the MTA-STS-for-Microsoft- 365 spoke is the M365-TENANT-SPECIFIC MTA-STS-mx-DIRECTIVE-CONSUMER companion documenting the structural dependency between the MX record publication this page documents and the M365 tenant's MTA-STS policy file mx: directive. Concretely, the spoke documents FOUR M365-MX-vs-MTA-STS-coordination dimensions: (i) M365's Microsoft-Admin-Center-driven MX inventory is the single-host <tenant>.mail.protection.outlook.com target (priority 0) pattern — the M365 operator publishes this ONE A-record-terminating MX target at the customer-vanity-domain DNS zone exactly per the MX-record- publication mechanics this page documents, STRUCTURALLY SIMPLER than the Workspace 5-host tier'd inventory the sibling Workspace spoke documents because Microsoft's Exchange Online MX-tier is consolidated to a single tenant- scoped FQDN that internally fans out to Microsoft-managed load-balancers; (ii) the M365 MTA-STS policy file at https://mta-sts.<tenant- domain>/.well-known/mta-sts.txt publishes a mx: directive listing that MUST stay in lockstep with the published MX RRset — the M365 spoke documents the operator-discipline pattern that uses mx: *.mail.protection.outlook.com wildcard to cover the tenant-scoped MX-host AND Microsoft-managed regional MX-fanout-target naming; (iii) an MX-record edit on an M365-hosted domain that changes the single-host MX inventory (e.g., adding a custom inbound smart-host MX in front of Exchange Online, re-pointing to a third-party security gateway like Mimecast / Proofpoint, or coordinating with on-prem Exchange Server in a hybrid topology) MUST coordinate with the M365 MTA-STS policy file's mx: directive update — adding an MX target without updating the policy file breaks inbound delivery from MTA-STS-enforcing senders the moment the new MX is preferred (the coupled-changes invariant this page documents in the MTA-STS context fires on M365-hosted domains identically); and (iv) the M365 MTA-STS spoke documents the M365-specific MX- record-publication-vs-MTA-STS- policy-publication coordination cadence the M365 operator runs (including the third-party-inbound- security-gateway case where the operator's MX is NOT the tenant.mail.protection.outlook.com target and the mx: directive must reflect the gateway's inbound MX hostnames instead, AND the hybrid-Exchange- Server case where the dual-receive topology requires both on-prem MX AND Exchange Online MX in the policy file's mx: directive simultaneously). Read the MTA-STS-for-Microsoft-365 spoke alongside this MX-records pillar when planning MX publication on an M365-hosted domain — the M365-tenant-specific single-MX-host target the spoke documents is the load-bearing MX-record-publication consumer whose authoritative DNS publication this page documents enables, and whose MTA-STS mx:-directive lockstep coordination is the operator's coupled-change discipline.
• DANE for SMTP (RFC 7672) explained — the deployment-pillar deep dive on the DANE half of the transport-security pair above. DANE binds directly to the MX-target hostname layer this page documents: TLSA records are published at _25._tcp.<mx-target> per RFC 7672 §3.1, so the no-CNAME-as- MX-target rule (RFC 2181 §10.3) covered in section 4 of this page is a hard prerequisite — DANE TLSA discovery breaks the moment an MX target resolves via CNAME because the DNSSEC chain cannot anchor at a CNAME alias's TLSA RRset. Read the DANE pillar when adding TLS-enforcement on top of an existing MX layer (the pillar walks through the four TLSA-record fields usage / selector / matching-type / certificate-association-data with the canonical DANE-EE (usage=3) + SPKI-selector (selector=1) + SHA-256-matching (matching-type=1) deployment shape, the end-to-end DNSSEC chain-of-trust requirement that promotes DNSSEC from a nice-to-have to a hard prerequisite, the RFC 7672 §2.2.1 receiver-side TLSA-retrieval-and- validation algorithm, and the certificate / key rotation procedure that aligns with the TTL-reduction pattern this page recommends for MX migrations) OR when investigating delivery failures from German / Dutch / Scandinavian ISP-mailbox senders whose outbound MTAs require DANE for the MX-target hostnames this page enumerates for inbound providers.
• TLS-RPT explained — the operational observability layer for MTA-STS and DANE failures.
• DMARC for Microsoft 365 — provider deployment guide. The first step of any M365 mail deployment is pointing MX at the tenant-specific protection.outlook.com hostname.
• DMARC for Google Workspace — provider deployment guide. Google Workspace's MX cluster is the canonical modern single-MX-record example.
• DMARC for Office 365 hybrid — hybrid Exchange deployment. The MX topology determines whether the on-prem Edge Transport or Exchange Online sees inbound mail first.
• DMARC for shared hosting — the SHARED-HOSTING-PANEL-TENANT-MX-RR- INHERITANCE-AND-PANEL-OVERRIDE companion documenting how the MX-RR topology THIS page documents (the 16-bit priority + target-FQDN RR-set per RFC 1035 §3.3.9, the cluster-MX vs single-MX deployment choice, the RFC 7505 null-MX MX 0 . idiom for domains that accept no mail, the MX-target A/AAAA downstream-dereference requirement, the reverse-DNS PTR alignment requirement for the MX-target hosts) is OPERATIONALLY MANAGED on shared-hosting panels in FOUR structurally-distinct MX-management topology adaptations: (i) panel- default MX RR inheritance — Plesk / DirectAdmin / ISPConfig / WHM-reseller all publish a panel-default MX RR-set pointing at the panel's own inbound MTA cluster when a new tenant domain is provisioned (Plesk default mail.<tenant-domain> with the A-record pointing at the panel- server IP, DirectAdmin similar, ISPConfig similar, WHM-reseller similar with the panel-server-shared-IP pool), so the tenant inherits a single-MX topology by default — adequate for low-volume tenants but the shared-hosting spoke documents when the tenant must override this default; (ii) panel-override to external mail provider — the common shared-hosting topology where the tenant wants to use Google Workspace / Microsoft 365 / Fastmail / ProtonMail for inbound mail requires the tenant to OVERRIDE the panel's default MX RR-set via the panel's DNS-zone-editor UI, a per-panel UI workflow the shared-hosting spoke catalogues (Plesk Hosting Settings → DNS Settings → MX records tab, DirectAdmin Admin Level → DNS Administration → MX records, ISPConfig DNS → MX records tab, WHM-reseller WHM → DNS Functions → Edit DNS Zone); (iii) panel + external DNS delegation MX-publication topology — tenants who delegate DNS to Cloudflare / Route 53 publish the MX RR-set via the external DNS provider's UI, bypassing the panel entirely; the shared-hosting spoke documents the panel-side override (publish a "non-default" placeholder so the panel does not auto-republish its default) the tenant must apply to prevent the panel from silently re-asserting its default MX RR-set; (iv) panel + null-MX adoption — tenants who run a send-only outbound-mail topology (transactional-mail-only domains) publish the RFC 7505 null-MX MX 0 . via the panel's DNS-zone-editor UI to signal the domain accepts no inbound mail, a topology the shared-hosting spoke documents as deployment-pattern guidance for the transactional-mail-only shared-hosting tenant. Read the shared-hosting deployment spoke alongside this page when scoping the MX RR-set topology for a Plesk / DirectAdmin / ISPConfig / WHM-reseller tenant whose panel UI conventions differ from cPanel (sibling spoke) and whose default MX RR-set inheritance behavior is opaque to the tenant operator.
• DMARC for cPanel - the CPANEL-EMAIL-ROUTING-MX-RR- PUBLICATION-AS-DMARC-COORDINATION- SUBSTRATE companion to this MX-records reference. Where the sibling shared- hosting spoke ABOVE documents the UNIVERSAL panel-tenant MX-RR inheritance across Plesk / DirectAdmin / ISPConfig / WHM-reseller hosts, the dedicated cPanel deep-dive documents the structurally- distinct cPanel-Email-Routing-feature MX-RR publication discipline that NO other panel surface mirrors at the same UI granularity. The four-axis MX-RR-VS-CPANEL- EMAIL-ROUTING comparison exposes the structurally-distinct CPANEL-MX-COORDINATION roles: (i) cPanel "Email Routing" feature publishes the per-Addon-Domain MX target as one of four operator-chosen modes (Automatically Detect / Local Mail Exchanger / Backup Mail Exchanger / Remote Mail Exchanger) where each mode publishes a DIFFERENT MX-RR topology in the cPanel- managed DNS zone — Local routes inbound mail to the cPanel-Exim host (MX target = the cPanel host's FQDN), Remote omits the MX RR entirely (delegating inbound mail routing to a third-party provider's MX), Backup publishes the cPanel host as a higher-priority fallback while the operator's chosen primary remains in place — the cPanel deep-dive documents the per-mode MX-RR publication difference and the per-mode DMARC- coordination consequence; (ii) WHM- managed shared-MTA target as the default MX value at cPanel account provisioning — when a hosting provider provisions a new cPanel account, the default MX RR points to the WHM-managed shared-Exim host's FQDN (e.g. mail.<customer-domain> → cpanel-host-12.shared-host- provider.example) and the operator often inherits this default without explicitly choosing it — the cPanel-tenant DMARC operator must audit the as-provisioned MX-RR to confirm it matches the operator's intended inbound routing rather than the hosting provider's account-creation default; the cPanel deep-dive documents the as-provisioned MX-RR audit checklist; (iii) Addon-Domain per- domain MX inheritance where each Addon Domain's MX RR is independently configurable via Email Routing — multi-domain cPanel cohabitation means N Addon Domains each carry their own MX-RR publication independently of the primary account's MX-RR, producing a per-Addon-Domain MX topology the cPanel operator must reconcile against each Addon Domain's DMARC-policy receive- side discipline (the MX-RR target determines which MTA's DMARC-record consultation surface terminates inbound message processing for that Addon Domain); the cPanel deep-dive documents the per-Addon-Domain MX-vs-DMARC reconciliation discipline; and (iv) cPanel "Email Deliverability" feature's DKIM signing pre-requires "Local Mail Exchanger" Email Routing mode — if the operator has chosen "Remote Mail Exchanger" (delegating inbound mail to a third-party provider), the cPanel-Exim host does NOT process outbound mail and the cPanel-generated DKIM key signs NO outbound mail; the operator's DMARC-alignment-passing outbound mail MUST then be signed by the Remote MX provider with the Remote provider's DKIM key — a structurally-distinct DKIM- signing topology where the MX-RR mode choice CASCADES to the DKIM-key custody layer; the cPanel deep-dive documents the Email-Routing-mode→DKIM- key-custody cascade the cPanel operator must model. Read the dedicated cPanel spoke when scoping the MX RR-set topology for a cPanel-hosted account with multiple Addon Domains or with an operator-overridden Email Routing mode — the spoke is the authoritative per- Addon-Domain MX-publication reference whose four cPanel-specific MX-coordination boundaries this MX-records page is the protocol-substrate companion for.
• DMARC troubleshooting — operational diagnostic guide. Most bounce-related issues trace back to a misconfigured MX, missing PTR, or IP reputation problem rather than to DMARC itself.
• Email spoofing taxonomy — the MX-RR-SET-AS-RECEIVER-SIDE-ROUTING- TARGET-FOR-INBOUND-SPOOFED-MESSAGES companion to this MX-records reference. Where THIS page documents the MX RR-set DNS publication discipline (priority ordering, secondary-MX fallback, MX aliasing pitfalls, TTL planning, MX record cardinality), the email-spoofing spoke documents the SEVEN-TECHNIQUE spoofing taxonomy whose RECEIVE-SIDE SPOOFING-DEFENSE-AND-EVIDENCE-CAPTURE intersects with the inbound MX RR-set THIS page documents at FOUR operationally- load-bearing layers: (i) MX RR- set as the SMTP arrival point where receive-side authentication-evaluation engines run — every spoofed message in the seven-technique catalogue ARRIVES at the receiver's MX-listed hosts; the MX RR-set THIS page documents is the structural choke-point where the receiver's SPF / DKIM / DMARC / ARC evaluation engines fire and where the per-spoofing-technique pass/fail verdict is produced; (ii) secondary-MX priority manipulation as evidence-bypass attack-class — attackers can target lower-priority secondary MX hosts whose authentication-evaluation engines are stale or misconfigured (a backup MX running pre-2020 SpamAssassin rules without DMARC enforcement), which is an operationally-load-bearing MX-RR- set hygiene defense the spoofing- taxonomy spoke catalogues as a backup- infrastructure attack-class; (iii) MX RR-set aliasing as look- alike-domain spoofing vector — the look-alike-domain spoofing variant the email-spoofing taxonomy catalogues often involves MX RR-set aliasing (e.g. example-corp.com MX pointing at attacker-controlled mail infrastructure that proxies real example.com mail) — the MX-aliasing-pitfalls section of THIS page is the canonical defensive reference; (iv) inbound-MX receive-side IP reputation as MX- evidence-stream feedback signal — the source_ip column the email- spoofing-taxonomy spoke catalogues as the per-spoofing-technique attribution primitive is reverse-resolved against the receive-side MX-host's PTR record and IP-reputation signals (Spamhaus, SURBL, the MX-host's local reputation ledger) THIS page documents as core MX-operational discipline. Read the email-spoofing spoke WITH this MX- records page when designing the inbound MX RR-set topology: the spoofing- taxonomy catalogue is the canonical operator-facing reference for understanding WHICH attacker techniques the inbound MX RR-set this page documents must structurally defend against.
• Email authentication ecosystem — cluster-intro pillar covering SPF, DKIM, DMARC, BIMI, ARC, MTA-STS, TLS-RPT.
• Email authentication glossary — definitions of MX, MTA, SMTP, PTR, recursive resolver, and the other vocabulary on this page.
• Email security glossary — the MX-RECORD-INFRASTRUCTURE- VOCABULARY-RESOLVES-TO-EMAIL-SECURITY- VOCABULARY-DICTIONARY companion to this MX-RR publication operator reference. Where THIS page introduces the per-RR MX-record-publication vocabulary (MX priority-preference numeric ordering; MX-host A/AAAA-record-cohabitation with TTL discipline; split-MX-topology per-MX-host vendor-attribution; null- MX 0 . RFC 7505 sentinel for non-receiving domains; MX-rotation cadence and per-receiver MX-lookup- caching window), the Email security glossary spoke is the canonical email- security term-dictionary whose entries resolve THIS page's MX-RR-infrastructure vocabulary into cross-cluster terminology. The MX-RR-INFRASTRUCTURE- VOCABULARY-RESOLVES-TO-GLOSSARY cross- reference establishes FOUR structurally- distinct MX-infrastructure-layer cross- cluster resolution dimensions: (i) MX-host-allowlist vocabulary resolves to glossary MTA-STS-policy-host- mx-allowlist dictionary entries — the per-MX-host receive-path attribution that THIS page documents (preferred-MX-host primary delivery target, secondary-MX-host backup delivery target, split-MX-multi-vendor per-receive-path) maps directly to the MTA-STS mx: policy-host allowlist syntax — every MX-host listed in the MX-RR-set must appear in the MTA-STS policy's mx: rule for receiver-side validation to succeed; the glossary spoke documents the canonical cross-cluster vocabulary used uniformly across MTA-STS-policy-syntax / MTA-STS-vs-DANE / MTA-STS-for-Microsoft- 365 / MTA-STS-for-Google-Workspace pages; (ii) per-failing-MX-IP attribution vocabulary resolves to glossary TLS-RPT-per-MX-IP-attribution dictionary entries — the per- MX-host IP-attribution that THIS page documents (per-MX-host A/AAAA-record cohabitation with TTL-discipline, per-MX-host PTR-record reverse-lookup for IP-to-host identity resolution) maps directly to TLS-RPT's per-MX-IP failure-aggregation discipline — every per-MX-host IP that THIS page documents as the MX-RR-publication target appears as the per-failing-MX-IP key in TLS-RPT JSON aggregate reports for per-MX-IP STARTTLS-validation-failure attribution; the glossary spoke documents the canonical cross-cluster vocabulary used uniformly across TLS-RPT-record-syntax / TLS-RPT-report-format / TLS-RPT- explained / reverse-DNS-PTR pages; (iii) SPF-mx-mechanism expansion vocabulary resolves to glossary SPF-mechanism-budget-cost dictionary entries — the per- MX-host A-record-resolution that THIS page documents (MX-host hostname resolves to N A-records; SPF mx mechanism = 1 lookup cost + N-MX-host-A-record-resolution sub-cost; per-receiver MX-lookup- caching window during MX rotation) maps directly to the SPF lookup- budget-accounting vocabulary; the glossary spoke documents the canonical cross-cluster vocabulary used uniformly across SPF-explained / SPF-mechanisms-explained / SPF-DNS- syntax / include-vs-ip4-vs-a-vs-mx pages; (iv) hybrid-topology- dual-MX-pathway vocabulary resolves to glossary DMARC-for-office-365-hybrid / per-receive-path-coverage dictionary entries — the per-pathway receive-path attribution that THIS page documents (split-MX with on-premises Exchange + Exchange Online cloud-relay; per-pathway TLS-policy / DKIM-signing / SPF-IP-authorisation differences; per-pathway DMARC-RUA evidence-stream attribution) maps directly to the hybrid-topology dual- receive-path-evidence vocabulary; the glossary spoke documents the canonical cross-cluster vocabulary used uniformly across DMARC-for-office-365-hybrid / DMARC-for-shared-hosting / DMARC-for- SaaS-senders / DMARC-multi-domain- strategy pages. Pair this page (the MX-RR publication operator reference) with the Email security glossary spoke (the canonical email-security vocabulary dictionary) when introducing MX-record-infrastructure concepts to operators new to email- delivery-routing — the glossary's term-dictionary provides the cross- cluster vocabulary that THIS page's per-RR publication-discipline composes into the broader MTA-STS / TLS-RPT / SPF-mechanism / hybrid-topology terminology landscape.
• SPF PermError vs TempError diagnostic deep dive — the MX-MECHANISM-LOOKUP-LIMIT- CONTRIBUTING-FACTOR companion reference. Where THIS page documents the MX RR-type byte-syntax, MX-target hostname resolution, MX-preference priority semantics, and MX-record migration playbook (single-MX → multi-MX failover, primary-MX cutover from on-prem to M365, adding a sandbox-MX for spam quarantine tier), the SPF-PermError-vs-TempError spoke is the authoritative reference for an OFTEN-MISSED upstream consequence of MX-record edits: the SPF mx mechanism (per RFC 7208 §5.4) counts as ONE DNS lookup against the publisher's 10-lookup cap (RFC 7208 §4.6.4), BUT EXPANDS at receiver-side evaluation time to ENUMERATE EVERY MX target hostname in the publisher's apex MX record set, EACH of which then traverses A and AAAA RR lookups. Publishers running with a TIGHT 10-lookup- budget chain (M365 + SendGrid + Mailgun + Marketo + Salesforce already consumes ~9 lookups) and adding a second-tier fallback MX entry OR migrating to a multi-MX-target hosted-mail configuration can structurally tip the chain OVER the 10-lookup cap, surfacing across the entire sender population as spf=permerror on receiver-side aggregate-report feeds. The PermError-vs-TempError spoke catalogues the seven canonical PermError causes (record-not-found, syntax-error, multiple-records, too-many- lookups, void-lookup-cap, recursive-include, deprecated- mechanism) — the too-many-lookups class is the operationally-dangerous MX-record- edit collateral pattern operators miss when scheduling MX-cutover change-management windows. The canonical pre-deployment audit sequence: (i) enumerate the publisher's apex SPF chain via dig +short TXT <domain> and count the include: + a + mx + ptr + exists: + redirect= lookup-counting mechanisms; (ii) for each mx entry, enumerate the MX-target hostname list via dig MX <domain> and add ONE LOOKUP PER MX TARGET to the budget; (iii) confirm the total stays below 10 BEFORE the MX-record edit ships. Read the SPF-PermError-vs-TempError spoke alongside this MX-records page when planning ANY MX-record topology change — particularly adding fallback MX targets, migrating to multi-MX-target hosted-mail vendors, or adding per-region MX failover — to verify the publisher's SPF chain will not tip over the 10-lookup-cap collaterally.
• SPF DNS-record syntax — the MX-RR-SET-AS-RESOLUTION-INPUT- TO-SPF-mx-MECHANISM-EXPANSION companion to this MX records pillar. Where THIS page documents the per- domain MX RR-set publication discipline (RFC 1035 §3.3.9 MX RR format with 16-bit preference + hostname target, RFC 5321 §5.1 preference-ordering evaluation, RFC 7505 Null MX opt-out, RFC 2181 RR-set unique-set discipline, MX-host A-record co- habitation rule, dangling-MX security surface), the SPF DNS-record syntax spoke is the PER-DOMAIN v=spf1 TXT-RR PUBLICATION BYTE-GRAMMAR consumer of the per- domain MX RR-set this page documents. The four-axis MX-RR-vs-SPF-v=spf1- TXT-RR co-publication comparison exposes the structurally-distinct per-publisher per-domain co- publication discipline roles: (i) per-publisher per-domain MX RR-set publication at the per-zone apex (and per-subdomain scope) is the receiver-side RESOLUTION INPUT to the SPF mx mechanism's per-MX-host A/AAAA RR-set expansion within the RFC 7208 §4.6.4 10-DNS- lookup budget — every additional MX target hostname this page documents adding to the per-domain MX RR-set translates one-to-one into a per-MX- host A/AAAA RR-set expansion the per-domain v=spf1 TXT-RR's mx mechanism consumes at receiver-side evaluation — the SPF DNS- syntax spoke documents the per- domain TXT-record publication- byte-grammar (the 255-octet character-string-fragmentation rule, the "exactly one SPF record per scope" rule, the publication-mode commitment -all vs ~all vs ?all) every per-domain SPF publisher coordinates against the per-domain MX RR-set THIS page documents; (ii) per- publisher per-domain SPF mx mechanism's per-MX- host expansion is bounded by the per-publisher per-domain MX RR-set CARDINALITY — adding a third or fourth backup MX target hostname documented on THIS page commonly tips an include:-heavy SPF chain over the 10-lookup cap producing spf=permerror — the SPF DNS-syntax spoke documents the per-domain v=spf1 TXT-RR publication-byte-grammar within which the per-domain MX RR-set's cardinality directly determines the per-publisher per-domain permerror-vs-not- permerror trip- point — the SPF DNS-syntax spoke documents the per-publisher per-domain v=spf1-TXT-RR-as-load- bearing-policy-publication-primitive every MX-RR-set-publishing operator must coordinate against; (iii) per-publisher per-domain MX RR-set publication at the per- zone apex is the receiver-side ROUTING TARGET for inbound mail, while per-publisher per-domain SPF v=spf1 TXT-RR publication at the per-zone apex is the receiver-side AUTHORIZATION POLICY for outbound mail — making the two publications STRUCTURALLY-PARALLEL per-zone-apex DNS-publication primitives that bind the per- publisher per-domain INBOUND- RECEPTION-INFRASTRUCTURE (MX) and OUTBOUND-AUTHORIZATION-POLICY (SPF) at the SAME per-domain DNS scope — the SPF DNS- record syntax spoke documents the per-domain v=spf1 TXT-RR publication discipline that COMPLEMENTS the per-domain MX RR-set publication this page documents at the receiver-side OUTBOUND-AUTHORIZATION-vs- INBOUND-ROUTING per-zone-apex DNS-publication boundary; and (iv) per-publisher per- domain MX RR-set mx-mechanism-vs- ip4:-mechanism choice (per-publisher operator- choice between MX-RR-set- delegated A/AAAA-RR expansion vs explicit ip4: / ip6: / include: author- ing) is the per-publisher per- domain v=spf1-TXT-RR- authoring decision documented on the SPF-mechanisms-explained spoke and SPF-DNS-syntax spoke — making the SPF DNS-syntax spoke the load-bearing per- publisher per-domain SPF publication-byte-grammar reference every per-domain MX RR-set publisher must consult when choosing whether to consume the per-domain MX RR- set's A/AAAA RR-set expansion through the SPF mx-mechanism bridge — the SPF DNS-syntax spoke documents the per-publisher per-domain v=spf1 TXT-RR authoring discipline that every MX-RR-set publisher must coordinate against when the MX RR-set is deliberately re-consumed through the SPF mx-mechanism's per-MX-host A/AAAA RR-set expansion bridge. Read the SPF DNS-record syntax spoke whenever modifying the per-publisher per-domain MX RR-set documented on this page (audit the per-domain v=spf1 TXT-RR publication-byte-grammar AND the per-publisher per- domain SPF mx-mechanism expansion lookup-count AT THE SAME CHANGE-SET as the MX RR-set publication modification), and when authoring a new per-domain SPF TXT record for a domain whose MX RR-set was recently expanded to add a per-region backup MX target (audit the per- domain v=spf1 TXT- record's 255-octet character-string- fragmentation discipline BEFORE concluding the SPF publication is byte- correct).
• SPF 10-DNS-lookup limit and SPF flattening — the MX-RR-SET-EXPANSION-AS-LOAD- BEARING-SPF-mx-MECHANISM-LOOKUP- BUDGET-CONSUMER companion to this MX record reference. Where THIS page documents the per-publisher per- domain MX RR-set publication discipline (priority preference, target resolution, A/AAAA-only MX- target rule, null-MX publication, per-region backup MX coordination), the SPF-lookup-limit spoke is the per-publisher RFC 7208 §4.6.4 ten- DNS-query-budget operational reference whose four MX-VS-SPF- LOOKUP-BUDGET-COORDINATION dimensions establish how the MX RR-set publication choices THIS page catalogues structurally constrain the per-domain SPF publication choices an operator can safely make: (i) per-domain SPF mx-mechanism expansion budget cost — the SPF mx mechanism counts as 1 DNS lookup against the §4.6.4 cap but recursively expands to ALL MX target hostnames in the per-domain MX RR-set, then performs an A/AAAA lookup on each target hostname per RFC 7208 §5.4; the SPF-lookup-limit spoke documents how a 3-target MX RR-set with per-region backup MX publication discipline THIS page catalogues consumes the SPF mx-mechanism budget far more aggressively than the raw record text suggests, structurally producing spf=permerror on include:-heavy SPF records that previously fit under the cap; (ii) per-domain SPF a-mechanism vs MX RR-set host-name resolution budget coordination — when a publisher's SPF record uses the a-mechanism (the per-domain apex A/AAAA record is treated as a valid sender), the MX RR-set THIS page documents and the per-domain apex A/AAAA RR-set both consume the §4.6.4 budget independently; the SPF-lookup-limit spoke documents the per-domain co-publication discipline (publish either a OR mx but rarely both, because the dual a mx SPF mechanism pair consumes 2 lookups on top of every include:-cascade already present); (iii) per-domain per-region backup-MX expansion as load-bearing budget consumer — when THIS page documents per-region backup MX publication (one primary MX + two regional backup MXs per the per-region failover topology §10 catalogues), a publisher using the SPF mx-mechanism sees their lookup count expand from 1 (the mx token itself) to 1 + 3 (primary + backup-A + backup-B A-record resolutions) = 4 lookups for the single mx mechanism; the SPF-lookup-limit spoke documents the per-domain per- region MX-set publication-vs-SPF- mechanism trade-off (replace mx with explicit ip4: ranges of the outbound relay IPs to cost zero SPF lookups while preserving the per-region inbound MX-RR-set receive-side resilience THIS page documents); and (iv) per-domain MX RR-set host-name as load-bearing input to the SPF mx:<domain> cross-domain expansion primitive — when a publisher's SPF record uses mx:<other-domain> to delegate sender authority to another organisation's MX RR-set (a transactional ESP, a delivered-from-MX-of-partner relationship, etc.), the OTHER domain's MX RR-set publication discipline THIS page documents directly governs the per-source- domain SPF lookup count; the SPF-lookup-limit spoke documents the per-domain mx:<target> usage anti-pattern (delegating SPF authority to a third party's MX RR-set is brittle because the third party can expand their MX RR-set without notice and break the publisher's per-domain SPF lookup budget). Read the SPF- lookup-limit spoke alongside this MX record reference whenever modifying the per-publisher per-domain MX RR-set documented on this page (audit the per- domain v=spf1 SPF record's lookup count BEFORE adding a per-region backup MX target or a delegated mx:<target> mechanism), and when planning a per-domain SPF flattening deployment (resolve the MX RR-set THIS page documents down to its underlying ip4/ip6 ranges as a load-bearing sub-step of the flattening operational discipline the lookup-limit spoke catalogues).
• CAA records explained — the PER-DOMAIN-CA-ISSUANCE- RESTRICTION-DNS-RR-PUBLICATION- DISCIPLINE-INHERITED-BY-EVERY-MX- TARGET-HOST-SUBDOMAIN companion to this MX records reference. Where THIS page documents the per-publisher per-domain MX RR-set publication discipline (the RFC 1035 §3.3.9 MX record format, the per-preference value ordering semantics, the per- MX-target host resolution to A/AAAA records, the null-MX convention per RFC 7505, the no-CNAME-as-MX-target rule per RFC 2181 §10.3) that announces the publisher's inbound mail-flow endpoints, the CAA- records-explained spoke is the STRUCTURALLY-COUPLED per-domain CA-issuance-restriction publication- discipline reference whose RFC 8659 CAA-RR primitive at parent-domain scope is INHERITED by every <mx-target-host>.<domain> subdomain via the RFC 8659 §3 tree-climbing algorithm (the CA- side CAA-record-fetch algorithm walks up the DNS tree from the per-MX-host FQDN to the parent domain looking for the closest ancestor CAA-RR), gating per-MX- host SMTP-STARTTLS-cert procurement at every MX target THIS page announces. The CAA-vs-MX cross- layer publication-discipline coupling establishes four specific per-MX-host-CAA-inheritance-to- per-MX-host-cert-procurement dimensions: (i) per- publisher per-MX-host CAA- inheritance gating per-MX-host STARTTLS-cert procurement — RFC 8659 §3 tree-climbing rule extends the per-domain CAA publication to every <mx-host>.<domain> subdomain, so per-MX-host SMTP- STARTTLS-cert procurement at the MX-target host is gated by the parent-domain's CAA issue tag list; an MX-target host whose TLS-cert renewal requires CA-X but whose parent-domain CAA-RR lists only CA-Y silently fails to renew → per-MX-host STARTTLS cert expires → per-publisher inbound- mail-flow degradation visible in per-receiver TLS-RPT-JSON failure- report streams; (ii) per- MX-host cert-renewal-cadence coupling to per-publisher MX-RR- set publication discipline — adding a new MX target via THIS page's per-publisher MX RR-set publication discipline introduces a new per-MX-host TLS-cert procurement surface gated by the publisher's existing CAA-RR publication; the per-MX-host TLS-cert procurement workflow MUST verify the per-MX-host- issuer is in the per-domain CAA issue list BEFORE the new MX target is announced (otherwise the per-MX-host first- cert-procurement step silently fails at CA-issuance-refusal, leaving the MX target announced but not STARTTLS-capable); (iii) per-publisher multi-CA per-MX-host issuance- coverage discipline — per-publisher per-domain CAA-RR publication can list multiple CAs (0 issue "ca-x.example" + 0 issue "ca-y.example" on separate CAA-RR rows); the per-MX-host TLS-cert procurement workflow MUST audit the per-domain CAA issue list at every MX-target host addition to verify each per-MX-host TLS-cert renewal cadence is supported by at least one CA in the publisher's CAA issuance-coverage matrix; (iv) per-publisher MX + CAA + MTA-STS + TLS-RPT publication- discipline stack coordination discipline — per- publisher per-domain MX RR-set publication (THIS page's primary surface) + per-domain CAA publication discipline + per-publisher per-MX-host STARTTLS-cert + per-publisher mta-sts.<domain> MTA-STS-policy-cert + per- publisher _smtp._tls.<domain> TLS-RPT-JSON failure-report publication compose into the publisher's complete per-domain transport-security publication- discipline stack; per-MX-host cert-procurement is the load- bearing junction point where the per-publisher MX RR-set publication discipline meets the per-publisher CAA-RR publication discipline meets the per-publisher per-MX-host STARTTLS-cert renewal cadence meets the per-publisher per- receiver TLS-RPT-JSON failure- report observability stream. Read the CAA spoke alongside this MX records reference when planning a per-publisher MX RR-set publication change that introduces a new per-MX- target host (audit the per- domain CAA issue tag list BEFORE announcing the new MX target to verify the per-MX-host-issuer is in the per-publisher CAA issuance- coverage matrix), and during per-publisher CA-migration events (sequence the CAA-RR issue tag-list update + the per-MX-host cert- renewal cycle + the per-receiver TLS-RPT-JSON failure-report observability window to avoid the silent per-MX-host cert- renewal-refusal cascade).
• TLS-RPT record syntax — the PER-PUBLISHER-PER-MX-HOST-TRANSPORT- LAYER-FAILURE-OBSERVABILITY-PUBLICATION- PRIMITIVE companion to this MX records reference. Where THIS page documents the per-publisher per-domain MX-RR-set publication discipline (per-domain per-MX-host hostname publication, per-MX- host priority-value publication, per- domain MX-fanout topology, per-receiver per-domain MX-resolution discipline, per- publisher per-MX-host SMTP-receiving infrastructure publication), the TLS-RPT- record-syntax spoke documents the per- publisher per-domain RFC 8460 §3 TLS-RPT DNS TXT-RR publication discipline whose per-publisher per-MX-host SMTP- STARTTLS-failure-observability JSON- report emission is the LOAD-BEARING per- publisher per-MX-host transport-layer failure-observability evidence stream directly coupled to the per-publisher per-domain MX-RR-set publication discipline THIS page documents at FOUR per-publisher per-MX-host transport- layer publication-discipline coupling dimensions: (i) per-publisher per-MX-host SMTP-STARTTLS-failure evidence per RFC 8460 §4.3 failure- type catalogue (starttls-not- supported / certificate- host-mismatch / certificate- expired / certificate-not- trusted / dane-required- tlsa-invalid / sts-policy- invalid) as load-bearing per- MX-host transport-layer failure-class evidence row — per-publisher per-MX-host SMTP-STARTTLS handshake failure at any per-receiver sender-side MTA produces a per-failure-class JSON evidence row in the per-receiver per- publisher per-day TLS-RPT report emitted at the per-publisher per-domain rua mailbox the TLS-RPT-record-syntax spoke documents the per-publisher publication of; per-publisher per-MX-host per-failure- class evidence row directly attributes per-MX-host transport-layer failure to per-publisher per-MX-host cert-expiry / per-MX-host SAN-mismatch / per-MX-host STARTTLS-disabled / per-MX-host TLSA- invalid root-cause class for per- publisher operations team consuming the per-publisher per-domain rua mailbox TLS-RPT evidence stream; (ii) per-publisher per-MX-host cert-renewal- lifecycle drift as load-bearing TLS-RPT-observed per-MX-host transport- layer failure-class — per- publisher per-MX-host TLS-cert renewal- cadence (Let's Encrypt 90-day cycle, public-CA 12-month cycle, per-MX-host cert-rotation discipline) directly determines per-MX-host SMTP-STARTTLS failure-emergence per-publisher per-MX- host cert-expiry boundary the per- publisher per-domain rua mailbox TLS- RPT JSON-report capture the TLS-RPT- record-syntax spoke documents the per- publisher publication of operationally surfaces — per-publisher per-MX-host cert-renewal-refusal cascade (per-MX- host cert expires + new cert procurement fails per CAA constraint or DNS-01 validation refusal) is captured as a per-MX-host per-day per-failure-class certificate-expired JSON evidence row in the per-publisher per- domain rua mailbox TLS-RPT evidence stream the TLS-RPT-record-syntax spoke documents the per-publisher publication of; (iii) per-publisher per-MX- host hostname-SAN-binding consistency discipline as load-bearing per-MX-host TLS-RPT-observed transport-layer failure- class — per-publisher per-MX- host TLS-cert Subject-Alternative-Name (SAN) coverage must include every per- MX-host hostname published in the per- publisher per-domain MX-RR-set THIS page documents — per-MX-host hostname not present in per-MX-host TLS-cert SAN list produces per-receiver per-MX-host certificate-host-mismatch per-failure-class JSON evidence row in the per-publisher per-domain rua mailbox TLS-RPT JSON-report stream the TLS-RPT-record-syntax spoke documents the per-publisher publication of — canonical per-publisher per-MX-host misconfiguration class surfaced directly by the per-publisher per- domain rua mailbox TLS-RPT evidence stream; (iv) per-publisher per- MX-host TLS-pass-rate distribution as load-bearing per-publisher per-domain cross-receiver transport-layer- compliance KPI consumed at per- publisher Bulk-Sender-Requirements-2024 compliance gate — per- publisher per-domain cross-receiver TLS-pass-rate distribution (per-receiver Gmail / Microsoft 365 / Yahoo per-day per-publisher per-MX-host TLS-handshake- success-rate aggregate from per-receiver rua-emitted JSON reports the TLS-RPT- record-syntax spoke documents the per- publisher per-domain rua publication of) operationally IS the per-publisher per-domain transport-layer-compliance KPI consumed by per-receiver Bulk Sender Requirements 2024 gate decisions the per-publisher per-MX-host SMTP-receiving infrastructure THIS page documents the per-publisher per-domain publication of directly determines. Read the TLS-RPT- record-syntax spoke alongside this MX records reference when planning per- publisher per-domain MX-RR-set publication whose per-MX-host SMTP- STARTTLS-handshake observability is the load-bearing transport-layer failure- observability evidence stream the per- publisher per-MX-host TLS-cert lifecycle discipline depends on, and when investigating per-publisher per-MX-host transport-layer failure variance whose upstream root-cause class is per- publisher per-MX-host cert-renewal- cadence drift / per-MX-host SAN- coverage drift / per-MX-host STARTTLS- enablement drift the per-publisher per- domain rua mailbox TLS-RPT JSON-report capture the TLS-RPT-record-syntax spoke documents the per-publisher publication of structurally captures at per-receiver per-day per-failure-class row-level granularity.
• TLS-RPT report format (RFC 8460 §4 JSON-aggregate schema) — the PER-PUBLISHER-MX-RECORD- PUBLICATION-AS-LOAD-BEARING-PER- MX-PATTERN-INPUT-INTO-PER- RECEIVER-PER-PUBLISHER-PER-DAY- RFC-8460-§4-TLS-RPT-JSON- AGGREGATE-PER-MX-PATTERN- AGGREGATION-DIMENSION companion to this MX-records-explained reference. Where THIS page documents the per-publisher MX- record byte-grammar (the preference 16-bit priority value per RFC 1035 §3.3.9, the exchange per-MX hostname field, the per- publisher canonical multi-MX priority-ranked publication pattern), the tls_rpt_report_ format spoke documents the per- receiver per-publisher per-day RFC 8460 §4 JSON-aggregate report format whose policies[].policy.mx- host[] per-mx-pattern array IS the canonical load- bearing per-mx-pattern aggregation-dimension every per-publisher per-mx-pattern TLS-handshake outcome the per-publisher MX-record publication THIS page documents produces resolves to at the per-receiver-emitted aggregate- report consumption boundary. FOUR structurally-distinct PER- MX-RECORD-FIELD-VS-PER-TLS-RPT- REPORT-FIELD-COUPLING- DIMENSIONS the tls_rpt_report_ format spoke operationally documents: (i) per- publisher MX-record exchange-field per-mx-hostname-publication AS LOAD-BEARING-UPSTREAM-PER-MX- PATTERN-INPUT-INTO-PER-TLS- RPT-JSON-AGGREGATE policies[].policy.mx- host[] per-mx-pattern- catalogue-field — every per-publisher MX-record exchange-field publication produces a per- receiver-side per-mx-pattern TLS-handshake-attempt the TLS- RPT JSON-aggregate-report catalogues under policies[].policy.mx- host[]; the tls_rpt_ report_format spoke documents the per-mx-host wildcard pattern grammar (e.g., *.mail.example.com + canonical-MX-hostname mx.example.com) the per-receiver per-publisher per-day per-mx-pattern aggregation-key consumes; (ii) per-publisher MX- record preference- field priority-ranked publication AS LOAD-BEARING- UPSTREAM-PER-MX-PATTERN-INPUT- INTO-PER-TLS-RPT-JSON- AGGREGATE-PER-MX-PATTERN-PER- DAY-SUCCESS-FAILURE-COUNT- DISTRIBUTION — per- publisher MX-record preference-field priority ranking (lowest- numeric-value MX exchanged first per RFC 5321 §5.1) produces a per-receiver-side per-mx-host TLS-handshake- attempt-ordering the TLS-RPT JSON-aggregate per-mx-pattern summary.total- successful-session-count + summary.total-failure- session-count field- pair distributes per-day outcomes across; (iii) per-publisher MX- record-set per-mx-hostname AS LOAD-BEARING-UPSTREAM-PER-MX- ATTRIBUTION-INPUT-INTO-PER- TLS-RPT-JSON-AGGREGATE failure-details[]. receiving-mx-hostname + receiving-mx- helo per-failure-row attribution-fields — per-publisher per-failed-mx- host TLS-handshake-failure rows surface in the TLS-RPT JSON-aggregate per-failure- details receiving-mx- hostname and receiving-mx-helo attribution-fields; the per- publisher MX-record-set per- mx-hostname publication THIS page documents IS the canonical per-mx-hostname-publication input the per-receiver-emitted per-failure-row attribution consumes; (iv) per- publisher MX-record TTL-and- rotation-discipline AS LOAD- BEARING-UPSTREAM-PER-MX-PATTERN- CACHE-COHERENCE-INPUT-INTO-PER- TLS-RPT-JSON-AGGREGATE policies[]-per- day-policy-coverage-window — per-publisher MX- record TTL coordination + per- rotation MX-record cutover- cadence determines the per- receiver-side per-mx-pattern cache-coherence window the TLS- RPT JSON-aggregate per-day policies[].policy.mx- host[] per-mx-pattern- observed window consumes; publishers coordinate per- publisher MX-record TTL-and- rotation discipline with the per-receiver per-publisher per- day TLS-RPT JSON-aggregate per-mx-pattern aggregation cadence the per-mx-pattern- coverage-window the per- receiver report-emitter catalogues against. Read the tls_rpt_report_format spoke ALONGSIDE this MX-records- explained reference whenever the publisher scopes a per- publisher per-mx-pattern TLS- observability-analysis plan — the RFC-8460-§4-JSON-aggregate- report byte-schema THIS comparison spoke documents IS the canonical load-bearing per-receiver-emitted per-mx- pattern aggregation-dimension every per-publisher MX-record- publication outcome THIS page's per-publisher mx- publication discipline depends on at the per-receiver-emitted aggregate-report consumption boundary.
• Domain Security Checker — live DNS lookups for MX, SPF, DKIM, DMARC, BIMI, MTA-STS, TLS-RPT. Verifies the current MX configuration and reports target resolution + TTL.
• Email Header Analyzer — paste a received message and inspect the Received: chain to see exactly which MX target the sender connected to.
• RBL Blacklist Checker — query major RBLs (Spamhaus, SORBS, Barracuda, etc.) for an IP. The canonical second step when MX-based delivery fails.
• DMARC aggregate (RUA) reports — the RFC-7489-§7.2 XML-AGGREGATE- EVIDENCE-STREAM companion to this MX-records reference. Where THIS page documents the receiver-side per-domain MX-record publication discipline (RFC 1035 §3.3.9 priority + target format, the implicit-MX RFC 5321 §5.1 fallback rule, the RFC 7505 null-MX convention for non-mail-receiving domains, the RFC 2181 §10.3 no-CNAME-as-MX-target constraint, per-receiver per-MX- priority load-balancing-and-failover orchestration), the aggregate- reports spoke is the per-publisher per-domain outbound-side daily evidence-stream documenting the TWO per-day per-receiver per-source- IP row-level evidence channels that surface receiver-side MX-publication- topology evidence in the per- publisher per-domain RUA mailbox: (i) the per-report <report_metadata> <org_name> + <email> elements whose per-receiver identity (Google, Yahoo, Microsoft, Mail.ru, AOL, Comcast, plus the long tail of smaller per-receiver aggregators) enumerates the per-publisher per- domain inbound-MTA topology the receiver-side MX publication actually channels traffic to — every per-receiver-aggregator that emits a RUA report MUST first have accepted the per-publisher per- domain outbound message-flow at its own MX-published inbound MTAs, making the per-receiver report- sender catalogue the empirical per-publisher per-domain per- receiver-side MX-reachability proof; (ii) the per-row <source_ip> element whose per-day per-receiver aggregation surfaces the per- publisher per-domain outbound-MTA per-source-IP-vs-per-receiver- inbound-MTA pairing matrix — every per-publisher per-domain outbound source-IP that successfully delivered to a per-receiver inbound MTA via the per-receiver MX-published target surfaces here as a per-day per- receiver per-source-IP row whose message-count quantifies the per- receiver-side MX-published inbound- MTA throughput the per-publisher per-domain operator can use to cross-validate per-receiver MX record changes, per-receiver MX failover events, and per-receiver inbound-MTA rate-limit boundaries. Read THIS page when PUBLISHING the per-domain MX-record set at the authoritative nameserver; read the aggregate-reports spoke when OBSERVING per-receiver inbound-MTA reachability and per-source-IP-to- per-receiver-MX delivery-volume evidence the per-publisher per- domain RUA mailbox accumulates daily across the per-receiver aggregator population.
• DMARC multi-domain strategy — the PER-ORGANISATION-DOMAIN-FAMILY- MX-COORDINATION companion to this per- domain MX-RRSET publication reference. Where THIS page documents the per- domain MX-RRSET publication discipline (per-priority-ordered MX-host publication, RFC 7505 null-MX convention for non-mail-receiving domains, RFC 2181 no-CNAME-as-MX- target rule, per-MX-host A/AAAA resolution chain), the multi-domain- strategy spoke is the PER-ORGANISATION- DOMAIN-FAMILY-MX-COORDINATION companion documenting how the per- domain MX-RRSET publication discipline scales across the organisation's complete domain family at FOUR per- organisation-domain-family-MX- coordination dimensions: (i) per-active-receiving-domain per-priority-MX-host publication is the per-active-domain MX-publication- execution instantiation — the multi-domain-strategy spoke documents how every actively-receiving domain in the organisation's domain family MUST independently publish its per-priority-ordered MX-RRSET following the per-domain MX publication discipline THIS page documents; (ii) per-parked-or- defensive-registered domain RFC 7505 null-MX publication is the per-non- receiving-domain MX-publication- discipline instantiation — the multi-domain-strategy spoke documents how parked domains, defensive registrations, and cousin- domain catalogues MUST publish the per-domain null-MX ("0 .") convention THIS page documents as the per-domain explicit no-mail-receiving signal, which the per-organisation-domain- family DMARC coordination relies on to prevent attacker-side mail delivery to defensive registrations; (iii) per-organisation-wide MX-priority-coordination is the per- domain-family-wide failover-and-load- balancing instantiation — the multi-domain-strategy spoke documents how the per-domain MX- priority-ordering THIS page documents scales when the organisation's domain family includes dozens of actively- receiving domains each requiring independent per-priority-ordered MX-RRSET publication at the per- organisation-wide failover-coordination operational tier; and (iv) per-organisation-domain- family per-domain MX publication is the per-publisher per-domain DMARC publication's per-domain receiver- identity-record-class prerequisite — the multi-domain-strategy spoke documents how the per-domain MX-RRSET publication discipline THIS page documents is the per-publisher per- domain receiver-side structurally- paired identity-record-class to the per-publisher per-domain DMARC publication the multi-domain-strategy spoke catalogues across the organisation's domain family.
• DMARC policy modes (p=none / p=quarantine / p=reject) — the per-publisher per-domain DMARC policy-tier publication-discipline canonical reference (the p=none monitoring-mode tier, the p=quarantine spam-folder-disposition tier, the p=reject SMTP-time- rejection tier; the per-organisational- domain vs per-subdomain sp=-tag override discipline; the pct=-tag percentage-gradual-enforcement ramp discipline) whose per-publisher per- domain DMARC-policy-tier publication IS the per-publisher per-domain OUTBOUND mail-authentication-record- class structurally paired with the per-publisher per-domain INBOUND mail- flow-routing record-class THIS page documents at the per-publisher per- domain DNS-zone-editor publication boundary. The composition operates through FOUR per-publisher per-domain INBOUND-mail-flow-RR-publication- discipline vs OUTBOUND-DMARC-policy- publication-discipline coupling dimensions every per-publisher per- domain operator must reason about jointly: (i) per-publisher per-domain MX-RRSET INBOUND-mail-flow routing publication discipline + per- publisher per-domain DMARC-policy- tier OUTBOUND-mail-flow disposition publication discipline as the per- publisher per-domain COMPLETE BI- DIRECTIONAL MAIL-FLOW publication- discipline pair — both per-publisher per-domain DNS-RR classes are published at the per-publisher per- domain DNS-zone-editor commit boundary, both are per-publisher per- domain RECEIVER-DETERMINED at the per-receiver per-message evaluation boundary, and both are LOAD-BEARING for the per-publisher per-domain complete mail-flow per-publisher per- domain deliverability posture; (ii) per-publisher per-domain null-MX publication (0 . per RFC 7505) for per-non-mail-receiving domains paired with per-publisher per-domain p=reject + sp=reject publication for per-non-mail-sending domains — the per-publisher per-domain CANONICAL per-domain-class CLOSURE pattern for per-publisher per-domain parked-domain and per-publisher per-domain defensive-domain registration protection where BOTH the per-domain INBOUND-mail-flow-routing record AND the per-domain OUTBOUND-mail-flow- disposition record explicitly close all mail-flow vectors at the per- publisher per-domain DNS-publication boundary; (iii) per-publisher per- domain MX-RRSET PRIORITY discipline (the per-RR priority- value selection within the per- publisher per-domain MX-RRSET-class) coordinates with per-publisher per- domain DMARC-policy-tier pct=-percentage ramp discipline at the per-publisher per- domain phased-deployment cadence — per-publisher per-domain MX-RRSET publication of per-RR priorities determines per-publisher per-domain INBOUND-mail-flow per-recipient receiver-selection cascade, and per- publisher per-domain pct=-percentage ramp determines per-publisher per-domain OUTBOUND-mail-flow per-recipient receiver-side disposition cascade; (iv) per-publisher per-domain DMARC-policy-tier publication rua=mailto:<mailbox-at-mx- delivered-domain> RUA- aggregate-report MAILBOX-ADDRESS publication implicitly REQUIRES per- publisher per-domain MX-RRSET publication discipline at the DMARC-RUA-mailbox-receiving domain — the per-publisher per-domain DMARC-RUA-mailbox-receiving domain is INBOUND-mail-flow-receiving at the per-publisher per-domain MX-RRSET publication boundary THIS page documents AND OUTBOUND-mail-flow- disposed at the per-publisher per- domain DMARC-policy-tier publication boundary the DMARC-policy-modes spoke documents; the per-publisher per-domain JOINT INBOUND-MX- publication AND OUTBOUND-DMARC- publication discipline is the per- publisher per-domain DMARC-RUA- ingestion-pipeline observability precondition. Read THIS page when AUTHORING the per-publisher per- domain MX-RRSET INBOUND-mail-flow- routing record-class publication discipline; read the DMARC-policy- modes spoke when AUTHORING the per- publisher per-domain DMARC-policy- tier OUTBOUND-mail-flow-disposition record-class publication discipline that runs as the per-publisher per- domain structurally-paired record- class to the per-publisher per- domain INBOUND-mail-flow-routing record-class THIS page documents.
• SPF for Microsoft 365 — the per-M365-tenant per-domain v=spf1 include:spf.protection.outlook.com -all publication discipline this spoke documents is the per-publisher per- domain OUTBOUND-mail-flow- authorization apex-zone TXT-RR publication primitive that runs as the structurally-paired RR-class companion to the per-M365-tenant per-domain INBOUND-mail-flow MX record publication discipline ( contoso-com.mail.protection.outlook.com ) THIS page documents — together they form the per-tenant per-domain complete bidirectional mail-flow record-class publication discipline every M365 deployment instantiates at the same authoritative DNS zone publication boundary.
• DKIM alignment with DMARC — the PER-RECEIVER-PER-MX-HOST-MAIL- DELIVERY-ROUTING-AS-LOAD-BEARING-PER- RECEIVER-SIDE-DKIM-VERIFIER-BOUNDARY companion to this MX-records DNS RR foundation reference. Where THIS page documents the per-receiver per-MX-host MX-RR publication discipline at the per- publisher per-domain DNS-zone layer (the per-publisher per-domain MX 10 mx1.<publisher> priority-ordered MX-host enumeration, the per-RFC 5321 §5.1 receiver-side MX-RR consultation algorithm, the per-RFC 7505 null-MX defensive-publication for non- receiving domains, the per-RFC 2181 §10.3 no-CNAME-as-MX-target rule), the DKIM-alignment-with-DMARC spoke is the PER-RECEIVER-PER-MX-HOST-DKIM-VERIFIER- BOUNDARY-AS-LOAD-BEARING-DKIM-ALIGNMENT- EVALUATION-LOCUS companion documenting the per-message DKIM-Signature d=-tag vs RFC 5322 From- header organisational-domain alignment evaluation per RFC 7489 §3.1.1 — the per-publisher per-domain application- layer DKIM-aligned-pass evaluation IS evaluated at the per-receiver per-MX- host DKIM-verifier boundary the per- receiver per-MX-host MX-RR routing discipline THIS page documents delivers inbound mail to. Four MX-records-vs- DKIM-alignment coupling dimensions matter at the per-receiver per-MX-host DKIM-verifier-boundary evaluation locus: (i) per-receiver per-MX-host DKIM- verifier-boundary inbound-mail-flow gating — the per-publisher per-domain outbound mail-flow reaches the per- receiver per-MX-host DKIM-verifier only through the per-receiver per-MX-host MX-RR routing discipline THIS page documents; per-receiver per-MX-host MX-RR misconfiguration (no-CNAME-as-MX, null-MX-on-receiving-domain, broken-MX- priority-ordering) breaks per-publisher per-domain inbound delivery BEFORE the per-receiver per-MX-host DKIM-verifier evaluates the per-message DKIM-Signature d=-tag alignment the DKIM- alignment-with-DMARC spoke documents; (ii) per-receiver per-MX-host DKIM- verifier-asymmetric-edge-case handling — per-receiver per-MX-host DKIM-verifiers have per-vendor-asymmetric edge-case handling (Gmail uses RFC-7489-relaxed organisational-domain alignment per Public-Suffix-List walk; Outlook 365 EOP uses a per-tenant-policy-overridable alignment-mode; per-receiver per-vendor edge-case handling at the i= AUID tag, the l= body-length tag, the x= expiry tag) the per- publisher per-domain DKIM-alignment- with-DMARC evaluation produces per- receiver per-MX-host per-message outcome divergence the DKIM-alignment- with-DMARC spoke documents per-receiver- per-MX-host diagnostic decision-tree for; (iii) per-receiver per-MX-host MX-RR- based reputation reception locus — the per-publisher per-domain DKIM-aligned- pass rate is REPORTED back to per- publisher per-domain RUA aggregate-XML- report MAILBOXES via per-publisher per- domain _dmarc.<domain> TXT- RR rua=mailto:<rua-mailbox> publication; the per-rua-mailbox operator's per-receiver per-MX-host MX- RR routing discipline THIS page documents IS the load-bearing per-rua- mailbox receivability-gate the per- publisher per-domain DKIM-alignment- with-DMARC evaluation depends on for per-receiver per-day per-MX-IP forensic- evidence-stream reception; (iv) per- receiver per-MX-host receiver-side ARC- chain-validation locus — when per- publisher per-domain mail is forwarded through ARC-aware mailing-list-expander hops, the per-publisher per-domain ARC chain-validation receiver-side algorithm operates at the per-receiver per-MX-host DKIM-verifier boundary the per-receiver per-MX-host MX-RR routing discipline THIS page documents delivers inbound mail to; the per-publisher per- domain ARC-chain DKIM-alignment- recovery the DKIM-alignment-with-DMARC spoke documents IS the per-publisher per-domain application-layer DKIM- alignment-recovery primitive operating at the per-receiver per-MX-host receiver-side authentication-evaluator boundary the MX-RR routing discipline THIS page documents anchors. Read THIS page when AUTHORING the per-publisher per-domain MX-RR publication discipline; read the DKIM-alignment-with-DMARC spoke when DIAGNOSING per-receiver per- MX-host per-message DKIM-aligned-pass- vs-fail outcome at the per-receiver per-MX-host DKIM-verifier evaluation boundary the per-receiver per-MX-host MX-RR routing discipline THIS page documents delivers inbound mail to.
• DMARC monitoring
• DKIM for Google Workspace
• SPF qualifiers explained
• DKIM failures explained
• DMARC attacker-bypass catalogue
• DMARC forensic (RUF) failure reports
• DKIM replay attacks
• DMARC for SaaS senders — the PER-PUBLISHER-PER-DOMAIN-MX-RR-INBOUND-ROUTING-PIPELINE-AS-LOAD-BEARING-PER-RECEIVER-PER-MX-HOST-AUTHENTICATION-EVALUATOR-EXECUTION-BOUNDARY-WHOSE-MX-RR-RECEIVER-SIDE-EVALUATION-DRIVES-PER-SAAS-TENANT-PER-CUSTOM-DOMAIN-DMARC-AGGREGATE-REPORT-DELIVERY-CADENCE companion at four per-publisher per-domain MX-RR-publication-vs-SaaS-tenant-DMARC coupling dimensions: (i) per-publisher per-domain MX-RR rdata publication-discipline at <domain> per RFC 1035 §3.3.9 IS the load-bearing per-receiver per-MX-host inbound-routing-pipeline whose per-receiver per-MX-host authentication-evaluator execution-boundary evaluates per-SaaS-tenant per-custom-domain SPF + DKIM + DMARC composite-verdict per RFC 7489 §6.6 the SaaS-senders spoke documents the per-tenant per-custom-domain authentication-stack publication-discipline of; (ii) per-publisher per-domain MX-RR rua=mailto: DMARC-aggregate-report destination delivery-cadence per RFC 7489 §7 depends on per-publisher per-domain MX-RR DNS-publication-discipline at the per-publisher per-domain RUA-mailbox-receiving-domain — per-SaaS-tenant per-customer-onboarding-deliverability operator-side ramp-readiness-evaluation materially depends on per-publisher per-domain MX-RR DNS-publication-discipline preserving the per-tenant per-customer per-day per-source-IP per-row attribution-stream the SaaS-senders spoke documents the per-tenant operator-side DMARC RUA evidence-stream consumption of; (iii) per-publisher per-domain MX-RR backup-host lower-preference fallback operational-discipline IS structurally parallel to per-SaaS-tenant per-customer-onboarding per-stream onboarding-cadence resilience-discipline — both per-publisher per-domain publication-discipline references are per-tenant operator-side resilience-and-survivability publication-decisions at the per-tenant per-customer-onboarding composite inbound-routing-and-onboarding-cadence coordination boundary; (iv) per-publisher per-domain MX-RR DNS-publication-discipline TTL-budget engineering IS structurally parallel publication-budget primitive to per-SaaS-tenant per-custom-domain DMARC TXT-RR publication-discipline TTL-budget engineering — both per-tenant per-custom-domain DNS-publication-discipline TTL-budget references drive per-tenant per-customer per-day per-receiver per-source-IP per-row attribution-stream-continuity the SaaS-senders spoke documents the per-tenant per-customer evidence-stream-continuity discipline of at the per-tenant per-customer composite cross-protocol cross-layer per-day per-receiver attribution-stream-continuity coordination boundary.
• Business email compromise (BEC) playbook — the PER-PUBLISHER-PER-DOMAIN-MX-RR- INBOUND-ROUTING-PIPELINE-AS-LOAD-BEARING- PER-RECEIVER-PER-MX-HOST-AUTHENTICATION- EVALUATOR-EXECUTION-BOUNDARY-WHOSE-PER- MESSAGE-AUTHENTICATION-LEG-VERDICT-FEEDS- THE-BEC-INCIDENT-RESPONSE-FORENSIC- EVIDENCE-STREAM companion to this MX-RR DNS-publication-discipline reference. Where THIS page documents the per- publisher per-domain MX-RR DNS-publication- discipline (RFC 1035 §3.3.9 rdata publication, RFC 5321 §5.1 implicit-MX- rule, RFC 7505 null-MX sentinel, RFC 2181 §10.3 no-CNAME-as-MX-target rule), the BEC playbook is the FINANCE-TREASURY-FRAUD- TEAM operational-workflow reference whose per-message authentication-leg verdict- attribution the per-publisher per-domain MX-RR routing-discipline THIS page documents the per-receiver-side inbound- routing-pipeline of delivers inbound mail to FEEDS the BEC IR investigation at FOUR per-publisher per-domain MX-RR-vs-BEC- defense coupling dimensions: (i) per-publisher per-domain MX-RR rdata publication-discipline as load- bearing per-receiver per-MX-host authentication-evaluator execution boundary — per-publisher per-domain MX-RR rdata publication- discipline at <domain> per RFC 1035 §3.3.9 determines the per- receiver per-MX-host receiver-side authentication-verification execution boundary at which the per-message spf=... + dkim=... + DMARC-composite-verdict per RFC 7489 §6.6 is evaluated — the per-message authentication-leg verdict the BEC IR investigation parses for forensic- evidence attribution surfaces in per- receiver per-day per-source-IP per-row DMARC RUA aggregate-XML report row by row at the per-publisher per-domain MX- RR-delivered inbound-evaluation execution boundary; (ii) per-publisher per- domain MX-RR DNS-publication-discipline drift as per-attacker per-target-domain BEC bypass-attack-class anchor — per-publisher per-domain MX-RR rdata publication-discipline drift (zone- takeover via abandoned-subdomain delegation, backup-host operational- fallback exploitation, MX-CNAME- publication-discipline violation per RFC 1034 §3.6.2 + RFC 2181 §10.3, null- MX-vs-missing-MX silent-bypass-via-A- fallback per RFC 5321 §5.1 implicit-MX- rule, STARTTLS-stripping MITM bypass- class) directly opens per-attacker per- target-domain BEC inbound-pipeline- takeover attack-class whose per-message authentication-leg-fail attribution the BEC investigator parses in Stage 4 chronological-reconstruction; (iii) per-publisher per-domain MX-RR receiver-side STARTTLS-vs-opportunistic- TLS-vs-MTA-STS-enforce decision as transport-layer BEC-message-integrity preservation discipline — per-publisher per-domain MX-RR receiver- side transport-pipeline-floor decision (STARTTLS-vs-opportunistic-TLS-vs-MTA- STS-enforce per RFC 8461) preserves per- message DKIM-Signature in-transit integrity that the BEC investigator depends on for per-message DKIM-Signature d= + s= + b= forensic-evidence verification; per-attacker per-message DKIM-Signature in-transit capture-and- replay attack-class exploiting MX-RR- delivered messages relies on transport- layer integrity compromise the per- publisher per-domain MX-RR receive-side transport-layer publication-discipline the MX-records page documents closes; (iv) per-publisher per-domain MX-RR routing-discipline as load-bearing per-receiver-side DMARC RUF forensic- report-emission execution boundary per RFC 7489 §7.3 — per- publisher per-domain MX-RR routing- discipline delivers inbound mail to the per-receiver per-MX-host receiver-side authentication-evaluator the per-message SPF-or-DKIM authentication-leg-fail verdict per RFC 7489 §6.6.1 of which triggers per-publisher per-domain DMARC RUF forensic-report emission per RFC 7489 §7.3 — the per-message AFRF forensic-report-evidence stream the BEC IR investigation consumes alongside per- day DMARC RUA aggregate-XML report attribution per RFC 7489 §7.2 for per- message authentication-leg attribution evidence. Read the BEC playbook WITH this MX-RR DNS-publication-discipline reference when the per-publisher per- domain finance / treasury / fraud team escalates a suspected per-publisher per- domain BEC incident to the per-publisher per-domain security operations team for per-message authentication-leg forensic- evidence reconstruction at the per- publisher per-domain MX-RR-delivered- inbound-routing-pipeline-and-BEC- incident-response coordination boundary.
• DKIM troubleshooting — the per-publisher per-selector DKIM-verdict-class triage reference companion at four per-publisher per-domain DNS-RR-publication-discipline-vs-DKIM-verdict-troubleshooting coupling dimensions: (i) per-publisher per-domain DKIM <selector>._domainkey.<domain> underscore-prefixed TXT-RR DNS-publication discipline IS structurally parallel underscore-prefixed-leaf-vs-canonical-apex-DNS-publication-discipline reference to per-publisher per-domain MX-RR DNS-publication discipline at the <domain> apex this page documents — both per-publisher per-domain operator-side DNS-RR publication-discipline references coordinate at the per-publisher per-domain composite inbound-routing-and-outbound-authentication-leg DNS-publication-discipline boundary; (ii) per-publisher per-domain DKIM <selector>._domainkey.<domain> TXT-RR publication-discipline drift (no-record / multiple-record / malformed-tag-list / truncated p= base64-payload crossing RFC 1035 §3.3.14 255-octet boundary) surfaces in per-receiver per-message dkim=permerror / dkim=none verdict-class per RFC 8601 §2.7.1 — structurally parallel DNS-RR publication-floor defect-class to per-publisher per-domain MX-RR publication-discipline drift (no-MX-record / CNAME-as-MX-target violating RFC 2181 §10.3 / null-MX mis-publication per RFC 7505) the per-publisher per-domain MX-records reference THIS page catalogues at the per-publisher per-domain inbound-routing publication-discipline-floor defect-class taxonomy; (iii) per-publisher per-domain DKIM dkim=temperror verdict-class root-cause attribution (per-receiver-side per-publisher-zone DNS-resolution transient-failure during selector-TXT-RR retrieval) IS structurally parallel per-receiver-side DNS-resolution-transient-failure root-cause attribution to per-publisher per-domain MX-RR per-receiver-side DNS-resolution-transient-failure root-cause attribution — both per-publisher per-domain per-receiver-side DNS-resolution-transient root-cause attribution references jointly underpin per-publisher per-domain composite DNS-publication-discipline observability the per-publisher per-domain DKIM-troubleshooting temperror symptom-flow catalogues the per-receiver-side per-publisher-zone DNS-resolution-transient triage-procedure of; (iv) per-publisher per-domain DKIM-Signature d=<signing-domain> alignment per RFC 7489 §3.1.1 against the RFC 5322 From-header-domain IS structurally orthogonal application-layer per-message-authentication-leg-alignment-publication-discipline to per-publisher per-domain MX-RR inbound-routing publication-discipline THIS page documents — yet jointly compose the per-publisher per-domain composite inbound-routing-and-outbound-authentication-leg DNS-publication-discipline floor whose per-receiver per-day DMARC RUA aggregate-report per-row attribution stream the per-publisher per-domain DKIM-troubleshooting decision-tree documents the per-publisher per-selector verdict-class triage of, and whose per-receiver per-day per-source-IP MX-host-attribution stream the per-publisher per-domain MX-records page documents the per-publisher per-domain inbound-routing publication-discipline observability of, jointly underpin per-publisher per-domain composite cross-publication-discipline observability coordination floor.
• Email deliverability — the inbox-placement companion to this MX-records page. Deliverability is usually framed as an outbound concern, but the inbound MX-record set is its mirror image: a misordered, stale, or CNAME-violating MX-RR (RFC 2181 §10.3) silently routes mail to an unintended or unreachable exchanger, producing bounces and retry-storms that mailbox providers read as a sending-domain health signal. The deliverability spoke explains how reliable bidirectional mail flow — receiving at correctly-published MX hosts and the reputation that depends on it — feeds inbox placement. Read it when an MX-RR publication issue surfaces as a deliverability or bounce-rate complaint.
• DMARC reporting pipeline — the MX record this page documents is the load-bearing prerequisite for the entire report-ingestion path. DMARC aggregate (RUA) and forensic (RUF) reports are delivered by email to the rua=mailto: / ruf=mailto: mailbox the domain publishes, so a receiver can only deliver those reports if the report-mailbox domain publishes a reachable MX RR (RFC 5321 §5.1 MX resolution, or the implicit-MX-from-A fallback when no MX exists). The reporting-pipeline spoke documents what happens after delivery — IMAP/Graph fetch, XML/ZIP/GZ parsing, per-source-IP aggregation, dashboard storage — but that pipeline starves if the rua-mailbox MX is misconfigured. Read the pipeline spoke to see why an MX-RR publication mistake on the report-collection domain silently breaks DMARC visibility even when the monitored domain's own MX is perfect.
• BIMI explained — the brand-logo program published through the same DNS substrate this MX-record reference covers. A BIMI logo is declared in a default._bimi.<domain> TXT-RR (alongside the VMC), an operator-controlled DNS resource record published from the same zone editor as the MX RR — and it only takes effect once the domain’s mail authenticates and reaches DMARC enforcement, which in turn presupposes correct MX routing for delivery and for the DMARC report mailbox. Read the BIMI explained spoke to see how the verified-logo record fits the broader per-domain DNS publication discipline this MX guide anchors.
• DKIM DNS record syntax — the DKIM public key is published as a TXT resource record at <selector>._domainkey.<domain> in the same zone editor as the MX records this page documents; read the DKIM DNS syntax reference for the v=DKIM1; k=rsa; p=<base64-pubkey> key-record format so the signing keys resolve from the same per-domain DNS substrate that carries your mail routing.
• DKIM best practices (the deployment-rules catalogue) — the operational hygiene companion to the DKIM DNS-syntax reference: once the <selector>._domainkey.<domain> key-record is published in the same zone editor as your MX records, the best-practices catalogue (2048-bit RSA keys, scheduled selector rotation, retirement of stale public-key records) is what keeps that DKIM leg durably correct. Read it so the per-domain DNS substrate that carries your mail routing also carries a well-maintained signing key.
• DMARC deployment checklist — the MX inventory this page teaches is an early step of that checklist. Before you can ramp a domain to p=reject you must enumerate every system that sends and receives mail for it, and the MX records here are where the receiving side of that inventory starts. Read the deployment checklist for the full phased path — inventory, monitor, fix the failing legs, then enforce — that the MX-records step feeds into.
• DKIM canonicalization (relaxed vs simple c=) — the MX records THIS page documents define the receiving servers and any forwarding or relay intermediaries a message traverses; DKIM canonicalization decides whether the signature survives that path. A strict simple body canonicalization breaks the instant a relay re-wraps a line or appends a footer, whereas relaxed tolerates the whitespace and header-folding changes those hops routinely introduce. Read it to understand why the routing topology your MX records describe is exactly what the canonicalization choice must survive for a DKIM signature to still verify on arrival.
• RFC 1035 — Domain Names (Implementation and Specification) — the foundational DNS specification. Section 3.3.9 defines the MX record format.
• RFC 5321 — Simple Mail Transfer Protocol — the SMTP specification. Section 5.1 defines the canonical mail-delivery sequence and the implicit MX rule.
• RFC 7505 — A "Null MX" No Service Resource Record for Domains That Accept No Mail — defines the null-MX convention.
• RFC 2181 — Clarifications to the DNS Specification — section 10.3 confirms the no-CNAME-as- MX-target rule from RFC 1034.
• Microsoft SNDS + JMRP monitoring — Microsoft grades the sending IP itself, not just the domain: SNDS per-IP GREEN/YELLOW/RED verdicts and JMRP complaints are the reputation companion to getting the DNS foundation right.

15. Audit your MX configuration now

DMARC Analyzer's Domain Security Checker performs a live MX lookup against your domain (via includes/DnsChecker.php) and reports the published MX records with their preference values, target hostnames, resolved A/AAAA records, DNS TTLs, and matching PTR records on the resolved IPs. Use it to confirm your MX is correctly configured, that the target is not a CNAME, that reverse-DNS is in place, and that the TTL matches operational expectations. The Email Header Analyzer parses Received: chains from captured messages (via includes/EmailHeaderParser.php) so you can see exactly which MX target inbound mail traversed and whether the SMTP handshake completed over TLS — useful for diagnosing MTA-STS / DANE transport-security issues alongside basic MX correctness.

Audit my domain MX configuration Sign up — Free plan