An MX (mail exchanger) record tells the world where to deliver email for a domain. When a sending server has a message for [email protected], it looks up the MX records for example.com and connects to one of the hosts they name. The record looks deceptively simple — a number and a hostname — but that number, the choice of hostnames, and a few strict rules about what an MX may point at, cause more mail misconfiguration than almost anything else in DNS.
The anatomy of an MX record
Each MX record has two parts: a preference value and a mail-server hostname. A typical set looks like this:
example.com. IN MX 10 mail1.example.com.
example.com. IN MX 20 mail2.example.com.
The number is the preference (often loosely called priority). The hostname is the server to connect to. A domain can have many MX records, and together they describe both where mail should go and in what order senders should try.
Lower preference wins
The single most misremembered fact about MX records is the direction of the ordering: lower numbers are preferred. A sending server sorts the MX records by preference and tries the lowest value first. In the example above, mail1 at preference 10 is tried before mail2 at preference 20. Only if the lower-preference host is unreachable does the sender move on to the next one. The actual numbers are arbitrary and only their relative order matters — 10 and 20 behave identically to 1 and 2. When two records share the same preference value, senders are expected to choose among them at random, which spreads load roughly evenly across equally ranked servers. That is how you build simple load balancing: give several hosts the same preference.
What backup MX really does — and the misconception
A backup MX is a second, higher-preference-number host that only receives mail when the primary is down. In principle it queues messages and forwards them once the primary recovers. In practice, a backup MX is far less useful than people assume, and often actively harmful. Modern sending servers already queue and retry for days when a destination is unreachable, so a domain with a single MX loses no mail during a short outage — the sender simply tries again later. That retry behaviour is the real safety net, and it is built into every compliant mail server.
Meanwhile, a backup MX has to run the same anti-spam, recipient-verification and filtering rules as the primary, or it becomes a soft target: spammers deliberately aim at the higher-numbered host precisely because backups are so often less well defended, then let it forward their junk inward past your best filtering. A backup MX that does not perfectly mirror the primary's recipient list also generates backscatter by accepting mail for non-existent users and later bouncing it. For most domains the honest advice is to skip the backup MX entirely and rely on sender retry, or to use a backup only if it enforces identical policy to the primary.
Null MX: declaring that a domain sends no mail
Some domains never receive email — a domain used only for a website, or one reserved defensively. For these, the null MX record explicitly says so:
example.com. IN MX 0 .
A single MX record with preference 0 and a target of just a dot (the root, an empty hostname) is the standardised way to announce that a domain accepts no mail. A sender that sees a null MX stops immediately and returns a permanent failure, rather than wasting days retrying or, worse, having a spammer forge your domain as a return address to a nonexistent mailbox. Publishing a null MX on your non-mail domains is a small, cheap hardening step that also reduces backscatter aimed at you.
Why an MX host can never be a CNAME
The target of an MX record must be a hostname that resolves directly to an address record — an A or AAAA record — and must not be a CNAME. This is a hard rule in the mail standards, not a preference. A CNAME is an alias that redirects a lookup to another name, and pointing an MX at a CNAME forces the sending server into extra, unspecified resolution steps that the mail RFCs explicitly forbid. Many sending servers will refuse to follow it, and delivery fails intermittently in ways that are maddening to debug. So mail1.example.com in an MX record must have its own A/AAAA record; it cannot be a CNAME pointing at, say, your hosting provider's alias. If you need to point an apex or a mail host at a provider that only gives you a hostname, that is a job for address records or provider-side flattening, not a CNAME behind an MX. Our sibling DKIM Studio covers the signing side of mail, and if you are hardening the transport itself, pair your MX audit with a required-TLS policy checked by MTA-STS Studio.
Reading a record in practice
When you inspect a domain's MX records, read them as a ranked list: sort by preference, lowest first, and that is the order senders will try. Confirm each named host resolves to an A or AAAA record and is not an alias. Watch for a lone 0 ., which means the domain deliberately accepts no mail. And treat any backup MX with suspicion unless you can confirm it enforces the same policy as the primary. Once you know which hosts actually receive your mail, this site's tester connects to each of them and verifies that STARTTLS is offered and the certificate is valid, so you can be sure the servers your MX records point at are also encrypting what they receive.