What is an MX record? Priority, backup MX and null MX explained

What an MX record does

When someone sends a message to anna@example.com, their mail server needs to know where to deliver it. It asks DNS for the MX (mail exchanger) records of example.com, gets back one or more hostnames, looks up their IP addresses, and connects to them over SMTP. Your website, your A record and the company you bought the domain from play no part in this - only the MX records do.

That also means MX records only affect incoming mail. Whether your outgoing mail is trusted is decided by SPF, DKIM and DMARC, and by the reverse DNS of the sending server (see reverse DNS and PTR records).

MX record syntax

An MX record has two parts in its value: a preference number and the hostname of a mail server.

example.com.  3600  IN  MX  10 mx.mailprovider.example.

The preference is a 16-bit number (0 to 65535). Its absolute value means nothing - only the order matters, so 10 and 20 behave exactly like 1 and 2. With a single MX record the number is irrelevant.

Priority and multiple MX records

SMTP (RFC 5321, section 5.1) defines how senders use several MX records: they sort them by preference, try the lowest number first and move on to the next one only if it can't be reached. Records with the same preference share the load - the sender must pick between them at random.

example.com.  MX  10 mx1.mailprovider.example.
example.com.  MX  10 mx2.mailprovider.example.
example.com.  MX  20 mx3.mailprovider.example.

Large providers often give you several MX hosts like this. Publish all of them, exactly as listed - they are all part of the same service.

Do you need a backup MX?

A "backup MX" is a lower-priority server run by someone else that accepts mail while your main server is down and forwards it later. It used to be common advice; today it usually isn't worth it:

• Sending servers already queue mail they can't deliver and retry it. RFC 5321 says the give-up time should generally be at least 4-5 days, so a few hours of downtime costs you delays, not lost messages.
• A backup MX that doesn't know which mailboxes exist has to accept everything and bounce the invalid ones later - sending bounces to forged sender addresses (backscatter) and getting itself a bad reputation.
• A backup MX needs the same spam filtering as your main server. If it filters less, everything it accepts reaches your mailboxes through the back door.

If your provider gives you several MX hosts, that is their redundancy. Don't add a server from a different provider next to them - mail would be split between two places, and some of it would end up in a mailbox nobody reads.

An MX must point to a hostname, not an IP or a CNAME

Two rules catch people out regularly:

• No IP addresses. The value of an MX record is a domain name. MX 10 192.0.2.25 is not an IP address to DNS - it's a hostname called "192.0.2.25" that doesn't exist. Give the server a name, add an A (and AAAA) record for it, and point the MX at the name.
• No CNAMEs. RFC 2181 (section 10.3) says the name in an MX record must not be an alias, and RFC 5321 puts an MX target that returns a CNAME outside the standard. Some senders follow the alias anyway, others don't - so point the MX directly at a name that has address records.

example.com.       MX     10 192.0.2.25
example.com.       MX     10 mail.example.com.
mail.example.com.  CNAME  mailhost.example.net.

example.com.       MX    10 mail.example.com.
mail.example.com.  A     192.0.2.25
mail.example.com.  AAAA  2001:db8::25

The domain itself (example.com) can't be a CNAME if it has MX records anyway: a name with a CNAME may not carry any other records. Note also the trailing dot in zone-file syntax - without it, many editors append your domain to the target. The guide to adding DNS records covers these panel quirks.

What happens when a domain has no MX record

If a domain has no MX records at all, senders fall back to its A or AAAA record and try to deliver there, as if it were an MX with preference 0 (the "implicit MX" rule in RFC 5321). So a domain whose website runs on a web server will still receive delivery attempts at that web server. If nothing listens on port 25, the sender just keeps retrying for days before bouncing the message.

Null MX: saying "this domain receives no mail"

For domains that should never receive mail - a parked domain, a brand-protection domain, a web-only subdomain - RFC 7505 defines the null MX: a single MX record with preference 0 and a lone dot as the target.

parked.example.  MX  0 .

• Senders see it and fail immediately with a clear error instead of queuing the message for days.
• A domain with a null MX must not publish any other MX record. And don't use it for a domain you send mail from: RFC 7505 warns that receivers may reject mail whose sender domain has a null MX.
• A domain that neither sends nor receives mail usually gets a null MX, the SPF record v=spf1 -all and a DMARC record with p=reject, so nobody can send in its name either.

Switching mail providers: TTL and timing

Resolvers cache your MX records for as long as their TTL says. If the TTL is 86400 (one day), some senders will keep delivering to the old provider for up to a day after you change the records. To make the move smooth:

1. At least one old TTL before the switch, lower the MX records' TTL to something like 300-3600 seconds. The lower value only takes effect once the old, longer one has expired from caches.
2. Create the mailboxes at the new provider first, so mail arriving there has somewhere to go.
3. Replace the MX records - remove the old ones in the same step rather than leaving them next to the new ones.
4. Keep the old mailboxes open for a few days and check them: cached records, and senders that are still retrying, can deliver there for a while.
5. Once everything arrives at the new provider, you can raise the TTL again.

Update your SPF record at the same time if the new provider also sends your outgoing mail - but remember that's a separate record, and changing the MX doesn't change who may send.

How to check your MX records

dig MX example.com +short

nslookup -type=MX example.com

dig prints one line per record, for example 10 mx.mailprovider.example.. Then check that each target resolves: dig A mx.mailprovider.example +short. To ask a particular resolver instead of your own (useful while caches still hold old values), add @1.1.1.1 or @8.8.8.8. The email authentication checker checks your MX records together with SPF, DKIM and DMARC.

With AnyMail, a domain gets a single MX record pointing at anymail.tech; the DNS setup page shows the exact value and checks it for you. If the domain previously used another provider, delete that provider's MX records rather than keeping them alongside.