Skip to content

MX record

Walk through SMTP again and one step gets glossed over: Alice's mail server decides to send Bob's message toward another-example.com, but what server does it actually connect to? Not necessarily anything running at another-example.com itself — mail delivery is deliberately decoupled from the domain's own web server, and the record that makes that decoupling possible is the MX record.

What it stores

An MX record maps a domain to a mail server responsible for accepting email on that domain's behalf, plus a preference value — a lower number means a more preferred server:

dig example.com MX +short

10 mail1.example.com.
20 mail2.example.com.

A sending server queries MX records for the recipient's domain, sorts them by preference, and tries the lowest number first — mail1.example.com here — falling back to the next one only if the first is unreachable or refuses the connection. That fallback is the entire point: a domain can list a primary mail server and one or more backups, and any well-behaved sending server tries them in order without any special configuration of its own. Note the RDATA itself is a hostname, not an IP address — the sending server still has to resolve mail1.example.com to an A or AAAA record afterward, exactly one more DNS lookup layered on top of this one.

Why mail routing is separate from the web server

This indirection exists because a website and its mail don't have to run on the same infrastructure, and usually shouldn't. example.com's A record can point at a web-hosting provider while its MX record points at an entirely different company that specializes in running mail servers — Google Workspace, Microsoft 365, or a self-hosted mail stack on different hardware altogether. Nothing about the website's IP address tells a sending mail server anything useful, so SMTP delivery was designed from the start to look up its own dedicated record rather than reuse the domain's address record.

The null MX: explicitly saying "this domain sends no mail"

A domain that genuinely never sends or receives email — a bare marketing domain used only for redirects, say — can publish a null MX, standardized in RFC 7505: an MX record with preference 0 and a target of ., the DNS root itself.

nomail.example.com.    IN  MX  0   .

Without this, a sending server attempting to deliver forged or misdirected mail to nomail.example.com finds no MX record at all, falls back to trying the domain's own A record as a last resort (a legacy behavior some mail software still implements), gets no useful answer, and only gives up after repeated retries spread out over several days — wasted effort on both ends. A null MX lets the sending server reject immediately and definitively, the moment it looks up the record, instead of queuing a message that was never going to be deliverable in the first place.

Practical scenario: mail always goes to the backup, never the primary

A company configures a primary and backup mail server, confirms both work when tested directly, and yet all incoming mail consistently lands on the backup — including under normal conditions, when the primary is healthy and reachable.

dig example.com MX +short

20 mail1.example.com.
10 mail2.example.com.

The preference numbers are reversed from what the team intended. mail2 — meant as the backup — carries the lower number, 10, and lower means more preferred. Every sending server on the internet is doing exactly what the standard tells it to: trying the lowest-preference target first, which is mail2 every single time the record is queried, regardless of mail1's health. There's no fault anywhere in the mail servers themselves, and no fault in any sending server's behavior — the zone file simply says the opposite of what the team meant, and every mail server on the internet believed it.

Intended:  mail1 = primary   (preference 10)
           mail2 = backup    (preference 20)
Actual:    mail2 = preference 10  <- treated as primary
           mail1 = preference 20  <- treated as backup

The fix is swapping the two numbers in the zone file — a one-line change, but one that took real investigation to spot, because both servers "worked" when tested individually and nothing about that testing revealed which one every sender would actually prefer.

Common mistakes

  • Assuming a higher preference number means "more preferred." It's the opposite — lower wins, and this is the single most common point of confusion when hand-editing MX records.
  • Pointing an MX record's target directly at an IP address. RFC 1035's format requires a hostname in the RDATA; an IP address there is simply invalid and most servers will reject it outright.
  • Leaving no MX record, and no null MX either, on a domain that sends no mail. Sending servers fall back to slower, less predictable behavior and take days to definitively fail a delivery attempt that a null MX would have rejected immediately.

Practice exercises

  1. Run dig <a-company-domain> MX +short against a few real domains and note how many list a single mail server versus a primary-and-backup pair.
  2. Using this article's scenario, explain in one sentence why "both servers work when I test them" was consistent with the bug rather than evidence against it.
  3. Explain, using RFC 7505, why a null MX record is preferable to simply leaving a domain's MX record absent entirely.

MX records point at a hostname, and CNAME records are the general-purpose way DNS lets one name point at another. But CNAME can't be used everywhere a shortcut might seem convenient — including, as it turns out, right where an MX record sits — and that restriction is the whole subject of the next article: CNAME record.

Sources