What is an MX record? How mail routing actually resolves

An MX record answers exactly one question: which servers accept inbound email for this domain. When someone writes to anything@yourdomain.com, their mail server looks up your MX records before it can deliver a single byte. Here is a real one, pulled from our own zone today:

nostalgiapost.com.  300  IN  MX  12 route1.mx.cloudflare.net.

That single line routes mail for the domain to Cloudflare's inbound servers. Everything else about email DNS (SPF, DKIM, DMARC) is about trust and authentication; the MX record is the only one about where mail physically goes. This article covers how that resolution really works, the backup-MX myth, and the complete DNS record set for a working email domain, all shown with live records. It is part of our email deliverability handbook.

Anatomy of the record

The format is name, TTL, class, type, then two values that matter: a preference number and a target hostname.

nostalgiapost.com.  300  IN  MX  2  route3.mx.cloudflare.net.
nostalgiapost.com.  300  IN  MX  12 route1.mx.cloudflare.net.
nostalgiapost.com.  300  IN  MX  77 route2.mx.cloudflare.net.

Two rules about the target trip people up. It must be a hostname, never an IP address; the sending server resolves that hostname to an address in a separate lookup. And it must not point at a CNAME. Both restrictions come from the DNS and SMTP standards, and while some servers tolerate violations, "some servers tolerate it" is a terrible foundation for the record that receives your invoices.

The preference number is relative, not absolute. Priorities of 2, 12, and 77 behave identically to 10, 20, and 30; only the ordering counts. Cloudflare assigns those odd-looking values automatically, which is a good reminder that nobody wins points for pretty numbers here.

How resolution actually works

When a mail server has a message for your domain, the sequence is rigid. It queries DNS for your MX records, sorts them by preference ascending, and attempts SMTP delivery to the lowest number first. If that host refuses connections, it tries the next number up. Records sharing the same preference are used in random rotation, which is how large receivers spread load.

Then comes the part most explanations skip: what happens when every host is unreachable. The sender does not bounce the message. It queues it and retries on a backoff schedule, typically for days; RFC 5321's guidance is that senders should keep trying for at least 4 to 5 days before giving up. Your mail server can be down for a full weekend and, with no backup MX at all, you lose nothing. The mail arrives Monday.

Two edge cases complete the picture. A domain with no MX records is still emailable: the standard falls back to the domain's A record, the so-called implicit MX, which is why mail sometimes reaches domains whose owners never configured email. And a domain that wants no mail at all can say so explicitly with a null MX (RFC 7505): a single record with preference 0 and a target of just ., which lets senders fail immediately instead of retrying for days against a domain that will never answer.

The backup MX myth

The traditional advice says to run a secondary MX at a higher preference so mail "has somewhere to go" when your primary is down. For almost everyone, this is solving a problem retry queues already solved while creating two real ones.

The first: spammers noticed decades ago that backup MX hosts usually had weaker filtering and looser recipient checks than the primary, and started delivering straight to the highest preference number. The second: a backup that accepts mail without knowing your valid recipients must accept everything, then bounce the junk later, generating backscatter that damages your reputation on mail you never wanted.

Our position: never run your own backup MX. If you use a managed inbound service you get multiple MX hosts anyway, all with identical filtering, as the three Cloudflare records above show. That is the correct version of redundancy: three equal doors into the same system, not a poorly guarded side entrance.

What our records do all day

Those three records feed a catch-all: every address on the domain, whether it existed five minutes ago or not, routes to the same inbound pipeline, where a Worker parses the message and writes it to a database as the source of truth. An "address" in our system is a routing rule, not a mailbox you pay for, which is what makes unlimited addresses literal rather than a pricing gimmick. The pattern is worth a look even if you build it differently: catch-all email changes how you hand out addresses.

We also monitor the whole path rather than trusting it: every two hours a canary message travels through DNS, those MX records, and the parser, and we get an alert if it fails to arrive. MX records fail rarely, but "rarely" is exactly the failure you want a machine watching for.

The complete DNS set for email

MX gets mail to you. Three more records get your mail trusted by everyone else, and one optional record serves your ESP's tracking. This is the full set, with the live values from our zone (DKIM key truncated):

One nuance from our own zone: your ESP may ask you to add an MX record on a sending subdomain, ours being send.nostalgiapost.com pointing at feedback-smtp.us-east-1.amazonses.com. That is not for your inbound mail; it routes bounce reports back to the relay so your bounce processing works. Add it where they tell you and leave your root MX alone.

How SPF, DKIM, and DMARC interlock is its own subject, covered in SPF, DKIM, and DMARC explained. The short version: MX without them means you can receive but your outbound lands in spam, and since November 2025 Gmail hard-rejects unauthenticated bulk mail outright.

MX is inbound only

The most common MX misconception is that it has anything to do with sending. It does not. Outbound mail goes wherever your sending server or relay connects; your own MX records are never consulted. This split is what makes the modern architecture work: our inbound rides Cloudflare's MX hosts while our outbound goes through a sending relay, and neither system knows the other exists.

It also means changing MX records cannot break your outbound sending, and switching ESPs cannot break your inbound. When you debug a mail problem, first decide which direction is broken; it tells you which records are even relevant.

Check yours with dig

Sixty seconds, four commands, and you know the state of a domain's email DNS:

dig MX yourdomain.com +short
dig TXT yourdomain.com +short
dig TXT selector._domainkey.yourdomain.com +short
dig TXT _dmarc.yourdomain.com +short

The first should return at least one priority-and-hostname pair. The second should include exactly one line starting v=spf1. The third needs your provider's selector name (ours is resend; check your ESP's DNS setup page). The fourth should start v=DMARC1.

Run those four against your own domain now. If the MX answer is empty, your domain is receiving mail by accident through the implicit-MX fallback or not at all; either way, fix that first, because every other email record only matters once mail knows where to go.