MX Records Explained: How Mail Finds Your Domain

Send a message to someone@example.com and nothing in that address names a machine. The part after the @ is a domain, and a domain is not a server. Something has to turn one into the other: a single DNS record type called MX, for mail exchange.

MX records are small: each one holds a number and a hostname. Yet most odd mail-delivery problems trace back to how those two fields were filled in, or to a rule about them that someone did not know existed. Our DNS lookup returns a domain's MX records alongside its other record types, sorted the way a sending mail server would read them.

What an MX record actually contains#

The format comes from RFC 1035, and it has exactly two fields. PREFERENCE is a 16-bit integer, so anything from 0 to 65535. EXCHANGE is a domain name that, in the RFC's words, specifies a host willing to act as a mail exchange for the owner name.

In a zone file it looks like this:

example.com.  3600  IN  MX  10 mail.example.com.

Mail for example.com goes to the host mail.example.com, at preference 10.

The exchange field must be a hostname, never an IP address. RFC 5321, the current SMTP standard, requires that the name in an MX record must itself return at least one address record, an A or AAAA, giving the IP of the server to hand the message to. An IP literal in that field is not a valid MX, however many DNS panels let you save it.

Most domains that handle real mail publish several MX records. What happens with more than one is where this gets interesting.

Lower numbers win#

This trips people up because the field is called preference and the intuition runs backwards. RFC 1035 is blunt about it: lower values are preferred. RFC 5321 says the same thing again, that lower numbers are more preferred than higher ones.

Take a typical set:

• 10 mx1.example.net
• 10 mx2.example.net
• 20 mx-fallback.example.net

A sending server sorts by preference and starts at the lowest number it can reach. Both hosts at 10 are equally preferred, and RFC 5321 does not leave that tie to chance: when several destinations share a preference and there is no clear reason to favour one, the sender is required to randomise them, to spread load across the organisation's mail exchangers. Equal preference values are a load-distribution mechanism, and the order records happen to appear in your zone file means nothing.

Only the relative order matters, never the absolute values. The 10 / 20 / 30 convention is habit; 1 / 2 / 3 behaves identically. Leaving gaps is still worth doing, because it lets you slot a new host between two existing ones without renumbering anything.

The backup MX question#

Older guides tell you to publish a high-numbered MX pointing at a spare machine so mail has somewhere to go when the primary is down. That advice has aged badly.

Nothing physically enforces preference order. It is a requirement on well-behaved senders, and software that would rather not meet a well-configured filter can simply connect to the highest-numbered host instead of the lowest. If that fallback filters more loosely than the primary, publishing it hands attackers a quieter door into the same mailbox.

Recipient validation is the second problem. A backup that does not know which addresses exist has to accept everything, then bounce what it cannot deliver to a sender address that is often forged, turning a clean rejection into outbound backscatter from your own infrastructure.

Meanwhile the disaster the backup was meant to prevent mostly does not happen: when no MX host answers, a compliant sender queues the message and retries for days before giving up, so a short outage costs you delayed mail rather than lost mail. A backup MX earns its place only when it enforces the same filtering and the same recipient list as the primary.

When there is no MX record#

A domain with no MX at all still receives mail, which surprises people. RFC 5321 specifies that when the MX lookup returns an empty list, the address is treated as though it carried an implicit MX record with a preference of 0, pointing at that host. The sender falls back to the domain's own A or AAAA record and delivers there.

The corollary is stricter and matters more. Once one or more MX records exist for a name, a sender must not use address records for that name unless the MX records led it to them. Publish a single MX and your A record instantly stops being a mail destination, which is exactly what you want, and exactly what catches people out mid-migration when they add an MX for a new provider and expect the old box to keep catching stragglers.

Our email validator models both paths: it looks for MX records first, falls back to A or AAAA as an implicit MX, and reports which of the two it found. How to validate an email address covers the rest of what that check can and cannot prove.

Leaning on implicit MX is fragile for a reason that has nothing to do with the spec. It means your web server and your mail destination are the same machine by coincidence rather than intent, so the day someone repoints the A record at a CDN, inbound mail follows it.

Never point an MX at a CNAME#

This is the rule most often broken, because DNS panels rarely stop you. RFC 2181 states that the domain name used as part of the value of an MX record must not be an alias, and that it must have one or more address records as its value. RFC 5321 reinforces it, putting a value that resolves to a CNAME outside the scope of the standard entirely.

The reason is a piece of DNS plumbing called additional section processing. When a resolver answers an MX query it appends the address records for the exchange host to the same response, sparing the sender a second round trip. RFC 2181 notes that this processing does not include CNAME records. Point an MX at an alias and no address comes back with the answer, every delivery pays for extra queries, and in some cases the lookup fails outright.

The same rule bites at the apex of a domain, where a CNAME cannot coexist with MX records at all. Providers work around that with ALIAS, ANAME, or CNAME flattening, which resolve the target on their side and publish real address records, so the MX target stays a plain hostname.

Null MX: declaring that you accept no mail#

Plenty of domains never receive mail: parked names, marketing domains that only send, registrations bought to keep a lookalike out of someone else's hands. RFC 7505 gives all of them a way to say so out loud.

A null MX is a single record with preference 0 and a zero-length label, written as a bare dot:

example.com.  3600  IN  MX  0 .

Because . is not a valid hostname, nothing can mistake it for a real route. The RFC is explicit that a domain advertising a null MX must not advertise any other MX record, so this is all-or-nothing rather than a flag you add alongside a working setup.

The payoff is speed of failure. A sender that hits a null MX knows immediately that the address is undeliverable instead of queueing for days, so whoever mistyped the domain finds out while they still remember sending the message. RFC 7505 asks rejecting servers to use a 556 reply code, meaning the domain does not accept mail, with the enhanced status code 5.1.10.

Null MX speaks only to inbound mail. A domain that neither sends nor receives should also publish an SPF record that authorises nothing and a DMARC policy set to reject, so the name is unattractive to forge as well as impossible to deliver to. Our SPF generator and DMARC generator build those records in the browser.

MX records do not authorise sending#

An MX record answers one question: where does mail addressed to this domain get delivered. It says nothing about which machines may send mail claiming to be from the domain. That job belongs to SPF, DKIM, and DMARC, and SPF, DKIM, and DMARC explained walks through how the three fit together.

There is one place the two worlds meet, and it has a sharp edge. SPF offers an mx mechanism that matches when the connecting IP belongs to one of the domain's MX hosts, convenient if the same servers both send and receive. RFC 7208 then adds a rule that catches people: if the domain has no MX record, the mx mechanism must not fall back to the implicit MX rules from RFC 5321. Delivery would use your A record there; SPF evaluation will not, and the mechanism simply matches nothing.

It also costs you. The mx mechanism counts against SPF's overall limit of ten DNS-querying terms, and evaluating a single one must not query more than ten address records or the whole check returns permerror. Our SPF checker walks the include chain and counts those lookups for you.

Where MX touches the rest of email#

Your MX hosts are the servers other organisations connect to on port 25, the port used for server-to-server SMTP relay. That is a separate job from port 587, where your own mail client submits outgoing messages with a username and password.

If you publish an MTA-STS policy to require encrypted inbound delivery, the policy file lists the MX hostnames it covers. Any MX host missing from that list falls outside the policy, so a sender has no instruction to enforce TLS when talking to it. Our MTA-STS checker fetches the policy and reports which of your MX hosts each pattern actually covers, and MTA-STS and TLS-RPT explained covers the rollout.

Reading your own setup#

Three checks will surface almost every problem described above.

Start with the records themselves. Run your domain through the DNS lookup and read the MX section: it shows each preference value beside its exchange host, sorted lowest first, the same way a sender would. Confirm the hosts are the ones you expect, and that a departed provider is not still sitting in the list.

Then look up each exchange host on its own. It needs an A or AAAA record, and it must not be a CNAME. This one check catches the most common silent misconfiguration on the list.

For the wider picture, the domain health report runs the mail-related checks in one pass, showing the MX records alongside SPF, DKIM, DMARC, DNSSEC, and certificate status, and saying plainly when a domain has no MX and therefore no mail receivers. Domain health checks explained describes what each section means, and what is a DNS record puts MX in context with everything else a domain publishes.