MX Records Explained: Priority, Backup Servers and Null MX

An MX (Mail Exchanger) record tells the world which servers accept email for your domain. Get it wrong and inbound mail bounces or vanishes, usually without any warning on your website, which is why many outages from DNS edits go unnoticed for hours. This guide explains how MX records are interpreted, what priority numbers mean, when backup servers help (and hurt), and how to mark a domain as one that does not accept mail.

What an MX record looks like

example.com.   3600  IN  MX  10  mail1.example.com.
example.com.   3600  IN  MX  20  mail2.example.com.

Each record has a priority (also called preference) and a target hostname. When someone emails you@example.com, the sending server:

1. Looks up the MX records for example.com.
2. Sorts them by priority, lowest number first.
3. Tries to deliver to the lowest-numbered host. If it cannot connect or gets a temporary error, it moves to the next.
4. If every server fails temporarily, it queues the message and retries, typically for days, before bouncing it.

Check what is published for any domain with the MX Lookup or from a terminal:

dig +short MX example.com
# 10 mail1.example.com.
# 20 mail2.example.com.

Priority rules

• Lower is preferred. 10 is tried before 20. The absolute numbers do not matter, only the order.
• Equal priority means load sharing. Two records at 10 are chosen between at random, so both must be ready to accept all mail.
• Gaps are conventional. Using 10, 20, 30 leaves room to insert a server later.
• Senders choose, not you. Priority is guidance. Some senders and spam tools deliberately try the highest-numbered server, because backup servers are often less protected.

Google Workspace, Microsoft 365 and similar providers publish their own required values; see the Google Workspace and Microsoft 365 guides. Follow their documentation exactly and never mix their MX hosts with another provider's.

Rules for the target hostname

• The target must be a hostname, never an IP address. 10 203.0.113.25 is invalid.
• The target must have an A or AAAA record. A target that does not resolve means undeliverable mail.
• The target should not be a CNAME. RFC 2181 says an MX target must not be an alias, and although some servers tolerate it, others do not. Point at a name that has address records directly.
• Use a trailing dot in zone files (mail1.example.com.), otherwise the zone's own name is appended. Many control panels add it for you, and a few need the dot typed. Entering a full name in a panel that appends the domain gives you mail1.example.com.example.com.
• The MX records apply to the exact name they are published on. Records on example.com do not cover mail.example.com. If you want mail at user@sub.example.com, publish MX at sub.example.com.

No MX at all: the implicit MX fallback

If a domain has no MX records, RFC 5321 tells senders to fall back to treating the domain's A or AAAA record as the mail server (an "implicit MX"). That means a web server at example.com might receive connection attempts for email. Deliverability systems often treat this unreliably, so do not depend on it. Always publish explicit MX records if you want mail, and publish a null MX if you do not.

Null MX: for domains that do not receive mail

RFC 7505 defines a null MX: a single MX record with priority 0 and a root dot as target.

example.net.   3600  IN  MX  0  .

It means "this domain accepts no mail". Senders get a fast, definitive failure instead of retrying for days or falling back to the A record. Use it on:

• Parked or defensive domains
• Domains used only for web hosting
• Subdomains that send mail but never receive it, such as a mail.example.com used only as a sending identity

Pair it with anti-spoofing records for a domain that neither sends nor receives:

example.net.         IN  MX   0  .
example.net.         IN  TXT  "v=spf1 -all"
_dmarc.example.net.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Do not publish a null MX alongside other MX records. The combination is invalid.

Backup MX servers: usually a bad idea

The classic setup is a primary (priority 10) plus a secondary (priority 20) that holds mail if the primary is down. In the days of unreliable connectivity this made sense. Today it often causes more harm than good:

• Sending servers already retry. If your primary is down for hours, well-behaved senders queue and try again for days. A backup adds little.
• Spammers target backups. Backup servers often lack the primary's spam filtering and recipient validation, so junk is accepted there and forwarded to the primary.
• Backscatter. A backup that accepts mail for nonexistent users, then fails to deliver it to the primary, sends bounce messages to forged senders. That is a known way to land on blocklists. A backup must validate recipients as strictly as the primary.
• Inconsistent security. Policies such as MTA-STS (see MTA-STS and TLS-RPT) require every MX host to be listed and to present a valid certificate.

When a secondary makes sense: if it belongs to the same managed provider and is configured identically, which is how large hosted providers operate. If you run your own servers, a single well-monitored primary, or multiple servers that are equal peers with the same filtering, is usually sounder than a thin backup. Put your own mail host under uptime monitoring with a port check on 25 so you hear about outages quickly.

Common MX mistakes

During a migration lower the TTL on the MX records a day or two beforehand (for example to 300 seconds) so cutover is quick; the propagation guide explains the timing. Remember that some senders cache longer than your TTL.

Troubleshooting inbound mail that does not arrive

1. Run the MX Lookup and confirm the records are what you intend, with no leftovers.
2. Check each target resolves, with the DNS Checker or dig A mail1.example.com.
3. Test that the server answers on port 25: nc -vz mail1.example.com 25, or use the Port Checker.
4. Confirm the authoritative nameservers (via the Nameserver Lookup) are the ones where you edited the zone.
5. Check the mail server's own logs for rejections.
6. Look at the whole domain with the Email DNS Checker.

Next steps

• Look up any domain with the MX Lookup.
• Verify the full mail DNS set with the Email DNS Checker.
• Read DNS explained for website owners for how records resolve.
• Make sure your sending IP is not listed using the Blacklist Checker.
• Add authentication with the SPF, DKIM and DMARC guide.

FAQ

What does MX priority 10 vs 20 mean?

The server with the lower number, 10, is tried first. Priority 20 is tried only if the first is unreachable or returns a temporary error. The numbers themselves have no other meaning.

Can I have just one MX record?

Yes. One MX record is perfectly valid and common for managed email services and simple setups.

Can an MX record point to a CNAME?

It should not. The standard says MX targets must be canonical names with address records. Some mail servers tolerate aliases, others fail, so point to a name with A or AAAA records.

What is a null MX?

A single record 0 . that declares the domain does not accept email. It makes senders fail immediately instead of retrying or falling back to your web server.

How long do MX changes take?

Up to the old record's TTL for most resolvers, and sometimes longer where senders cache. Lower the TTL before a planned migration and keep the old server running for a few days after.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.