Why MX records matter
Updated ·5 min read
An MX (Mail Exchange) record is a DNS record type dedicated to a single job: telling the rest of the internet which servers should receive email addressed to a domain. Unlike A or CNAME records, which apply generally, MX exists purely for mail routing, and a domain that sends or receives no email can safely have none at all.
For a domain that does handle mail, though, the MX record is not optional or interchangeable with pointing the domain's web server at the same address; it is a distinct, required piece of configuration, and getting its priority values wrong has real, if often invisible, consequences for deliverability.
Check yours now
What an MX record actually specifies
An MX record has two parts: a priority (also called preference) and a target hostname, which must itself resolve to an A or AAAA record; MX cannot point directly at an IP address. A domain example.test might publish mx.example.test with priority 10, meaning any server sending mail to someone@example.test looks up this record, resolves mx.example.test to an IP, and delivers there.
A domain can list several MX records at once, each with its own priority, describing the order in which a sending server should attempt delivery, not a set of servers to pick from arbitrarily.
How priority and fallback actually work
Lower priority numbers are tried first. A common configuration lists a primary server at priority 10 and a backup at priority 20; a sending server always attempts the priority 10 server first, and only falls back to priority 20 if the first is unreachable or refuses the connection after retries.
Two MX records sharing the same priority value are treated as an even split for basic load distribution rather than a strict order, which is a different pattern than the primary-and-backup setup and is chosen deliberately when a domain wants incoming mail spread evenly across more than one server rather than concentrated on a single primary.
A single MX record is not inherently wrong, but it is a single point of failure: if that one server is down, or its host is having network trouble, sending servers queue the mail and retry for a period, commonly measured in hours to a few days, before giving up and bouncing it, rather than delivering it elsewhere.
What happens with no MX record at all
A domain with an A or AAAA record but genuinely no MX record can, under an older fallback rule some sending servers still honor, receive mail directly at that address instead. This behavior is not guaranteed across every sender, and relying on it means the domain's own web server, or whatever else that A record points to, needs to also be prepared to accept SMTP connections on port 25, which is rarely the intended setup.
A domain with neither an MX record nor any A record at all cannot receive mail through any path; sending servers have nowhere to deliver to, and messages bounce immediately with an address-resolution failure rather than being queued for retry.
MX records and mail authentication
MX records are not themselves part of SPF, DKIM or DMARC evaluation for outbound mail authentication, since those mechanisms govern the domain used in the message's return path and From header, not where a domain's own inbound mail arrives. It is entirely possible, and common, for a domain to send mail through one provider's infrastructure while receiving it through a completely different provider's MX records.
That said, MX records are indirectly relevant to SPF, since the mx mechanism in an SPF record authorizes exactly the hosts listed in the domain's own MX records to send mail, which is a convenient shorthand when a mail server both sends and receives for the domain, but is meaningless for a domain whose sending and receiving infrastructure are entirely separate.
Common MX configuration mistakes
Pointing an MX record directly at an IP address rather than a hostname is invalid; the specification requires a hostname that itself has an A or AAAA record, and most DNS hosts will reject an attempt to enter a raw IP address in the target field, though the error message is not always clear about why.
Forgetting to update MX records after migrating mail providers is another common issue: the old provider's servers stop accepting mail as expected, but if MX records still point there, incoming mail either bounces or, worse, is accepted by a decommissioned server that no longer forwards it anywhere, producing silent mail loss that is far harder to diagnose than an outright bounce.
Setting an unreasonably long TTL on MX records, such as several days, makes any future change to mail provider slower to take effect everywhere, since resolvers that cached the old record keep using it until that long TTL expires. Lowering the TTL a day or two before a planned migration, the same practice used for other record types, keeps the cutover window shorter.
MX records with managed email providers
Most organizations today do not run their own mail server; they point MX records at a managed provider such as Google Workspace or Microsoft 365, which publishes a specific set of hostnames and priorities that must be entered exactly as documented. These providers typically require several MX records at specific priorities working together, not just one, since their infrastructure is itself distributed across multiple servers for redundancy on their end.
A frequent mistake when switching providers is leaving a leftover MX record from the previous provider in place alongside the new ones, rather than replacing them entirely. Depending on the priorities involved, this can cause some mail to route to a provider that is no longer actively monitored, silently losing messages rather than producing an obvious error either party would notice.