MX records: priorities, backups and three myths

23 September 2026 · Grace

An MX record says where mail for a domain should go. There is not much to it — a priority and a hostname — and yet it is the record people most often get subtly wrong, in ways that do not fail loudly.

What an MX record is

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

Two parts: the priority (10) and the hostname of a mail server. A domain usually has several.

A sending server collects every MX record for the domain, sorts them by priority, and tries them in order.

Lower wins, and that surprises people

The lower number is tried first. It is a preference, not a rank — 10 is preferred over 20, and the intuition that "higher must be better" is exactly backwards.

example.com.  IN  MX  10 primary.example.com.
example.com.  IN  MX  20 backup.example.com.

Mail goes to primary while it is reachable. If it is not, the sender falls back to backup.

Equal priorities share the load. Two records at 10 means senders pick between them, roughly evenly. That is how most hosted mail providers arrange things — several servers at the same preference, and the distribution is a happy side effect of redundancy rather than real load balancing.

The actual numbers are meaningless in themselves. Only the order matters. 10/20 and 1/2 behave identically; the convention of spacing by tens exists only so you can insert something between later.

Three myths

"A backup MX makes mail more reliable"

Usually the opposite. A backup MX at a different provider accepts mail when your primary is down, then tries to deliver it onwards. That sounds helpful, and it means:

• Spam filtering is weaker, because the backup often does not know which addresses exist and accepts everything, including for addresses that do not exist.
• Backscatter, when it later fails to deliver and bounces to a forged sender.
• Delay is hidden. A sending server that cannot reach you will queue and retry for days anyway — that is the backup, and it is built into SMTP.

Modern hosted mail already runs several servers at equal priority. A secondary MX pointing somewhere else is usually a decision from a decade ago that nobody revisited.

"An MX record can point at an IP address"

It cannot. The value must be a hostname, which then has its own A or AAAA record. An IP there is invalid; some DNS providers accept it and the mail simply fails, with the error appearing on the sending side where you will never see it.

The same rule catches people with CNAMEs: an MX must not point at a CNAME either. Point it at a name with an address record.

"No MX record means no mail"

Not quite. With no MX at all, senders fall back to the domain's A record — the implicit MX rule. So a domain with a website and no MX may deliver mail to the web server, which is almost never what anyone wanted, and which fails in a way that looks like the mail vanished.

If a domain should receive no mail, say so explicitly with a null MX:

example.com.  IN  MX  0 .

A single dot at priority zero means this domain accepts no mail. Senders reject immediately with a clear error instead of queueing for days.

The mistakes that do not announce themselves

A trailing dot missing. In a zone file, mail.example.com without the trailing dot is relative and becomes mail.example.com.example.com. Most panels handle this for you; hand-edited zone files do not.

Changing MX without checking SPF. Your new provider's servers are not in your old SPF record, so mail you send starts failing authentication the moment you cut over. MX governs inbound; SPF governs outbound. They change together.

Leaving the old provider's MX in place. Two providers at different priorities means some mail lands in a mailbox nobody reads. This is the one that goes unnoticed longest, because most mail arrives correctly.

Checking

dig +short MX example.com

Then confirm each hostname resolves:

dig +short mail.example.com

A hostname that returns nothing is an MX record that cannot be used, and the failure will be invisible to you — it happens on someone else's server, trying to reach you.

KumoDNS supports MX on every plan including Free, and refuses an MX pointing at an IP address rather than accepting one that cannot work.