MX records explained: priority, backup MX and null MX

An MX record tells the rest of the internet which host accepts mail for your domain. It holds two things: a priority number and the name of a mail server. When someone sends to anna@example.com, their server looks up the MX records for example.com, tries the host with the lowest number first, and falls back to the others in order if it cannot connect. That is the whole mechanism. Everything that goes wrong with MX records comes from four rules most people never read: the target must be a host name, never an IP address; that host name must not be a CNAME; lower numbers win; and a domain with no MX at all still receives mail at its A record unless you say otherwise.

This post covers the syntax, what senders actually do with priorities, whether a backup MX is worth having (usually not), the null MX for domains that should never receive mail, and the dig commands that tell you what the world sees.

The record and its two fields#

example.com.   3600  IN  MX  10 mail.example.com.example.com.   3600  IN  MX  20 mail2.example.com.mail           3600  IN  A   203.0.113.25mail2          3600  IN  A   198.51.100.40

The first number after MX is the preference - commonly called priority. It is a 16-bit value, so anything from 0 to 65535. Lower is preferred. The numbers mean nothing in absolute terms; only their order matters. 10 and 20 behave exactly like 1 and 2 or 100 and 200. Convention leaves gaps so you can slot a host in between later without renumbering.

The second field is the exchange: the host name of a server that accepts SMTP on port 25. In a zone file the trailing dot marks it as a fully qualified name; most web DNS editors add it for you.

The record lives at the name mail is addressed to. Mail for @example.com uses the MX at example.com (the apex, shown as @ in many editors). Mail for @support.example.com uses the MX at support.example.com, which is a separate record - subdomains do not inherit the parent's MX.

The rules that break mail#

These are in the standards, and receivers enforce them to varying degrees, which is worse than consistent enforcement because a broken setup can half-work.

1. The exchange must be a host name, not an IP address. MX 10 203.0.113.25 is invalid. Some senders will try to resolve 203.0.113.25 as a name and fail; some will guess what you meant. Create an A record for the host and point the MX at the name.
2. The exchange must not be a CNAME. RFC 2181 says an MX target must have its own address records. Many senders tolerate a CNAME, some do not, and the ones that do not will bounce your mail with errors you never see. If your mail provider gives you a host name, use it directly.
3. The exchange must resolve. An MX pointing at a name with no A or AAAA record is a black hole. Senders treat it as a temporary failure and retry for days before bouncing.
4. The MX name can hold other records, but a CNAME cannot sit beside them. The apex already cannot be a CNAME; the same rule means you cannot put a CNAME at any name that also needs an MX.

What a sending server actually does#

RFC 5321 section 5.1 describes the lookup, and it is worth knowing step by step because it explains every symptom.

1. The sender queries MX for the recipient's domain.
2. It sorts the answers by preference, lowest first. Hosts with the same preference are tried in random order, which spreads load across them.
3. It resolves each exchange to addresses and connects to port 25, trying the next host if one is unreachable or returns a temporary error.
4. If every host fails temporarily, the message stays in the sender's queue and is retried. RFC 5321 suggests giving up only after four to five days, and most servers follow something close to that, sending the original sender a delay warning after a few hours.
5. A permanent error - a 5xx reply such as "no such user" - ends the attempt at once. The sender does not try the next MX for a permanent rejection.

That last point surprises people: a backup MX is consulted only when the primary is unreachable or temporarily failing, not when it rejects a message.

There is also a fallback when no MX exists at all. If the MX query returns no records but the domain has an A or AAAA record, the sender treats the domain itself as an implicit MX with preference 0 and delivers to that address. This is why a domain that only hosts a website can still receive mail at the web server's IP if anything listens on port 25 there - and why you should publish a null MX for domains that should never receive mail.

Equal priorities, failover and load#

Two records with the same preference share incoming mail randomly:

example.com.  IN  MX  10 mx1.example.com.example.com.  IN  MX  10 mx2.example.com.

That is load balancing, not redundancy in the sense people expect. Both servers must accept mail for every mailbox, which means either they share storage or one forwards to the other. For a single self-hosted server it is not something you need.

Different preferences give ordered failover. The secondary host receives mail only while the primary is unreachable. This is where hosted mail providers list several of their own servers - Google Workspace's current setup is a single smtp.google.com record, while older guidance listed five hosts at preferences 1, 5, 5, 10 and 10. Use exactly what your provider tells you, and remove the old provider's records completely when you move.

Backup MX: why it is usually a bad idea now#

A backup MX was standard advice twenty years ago: if your server was down, a secondary would accept and hold mail until it came back. Today it mostly causes problems, for three reasons.

• Senders already queue. Every mail server retries for days. If your primary is down for an afternoon, mail waits on the senders' side and arrives when you are back. The backup adds nothing a sender does not already do.
• Spammers target backup MX hosts. They deliberately connect to the highest-numbered MX because backups often have weaker filtering and accept mail for any address. The backup then relays the spam to your primary, which trusts it.
• Backscatter. A backup that does not know your valid mailboxes accepts mail for nonexistent addresses, then has to bounce it later - to forged sender addresses. That makes your backup a source of spam to innocent third parties, and gets it listed.

A backup MX is only worth running if it has the same recipient list as the primary (so it rejects unknown users during the SMTP conversation), the same spam filtering, and the same authentication checks. At that point you are running two mail servers. For a small domain, one well-kept server and the senders' own retry queues are the better design.

Null MX for domains that never receive mail#

RFC 7505 defines a way to say "this domain accepts no mail":

example.net.   3600  IN  MX  0 .

A single MX with preference 0 and an exchange of . (the root). A sender that sees it fails immediately with a permanent error instead of trying the domain's A record or queueing for days. Publish one on:

• Domains used only for websites or redirects.
• Parked domains and old brand domains you keep for protection.
• Subdomains that have A records but should never be mail destinations, such as www or api, if you want to be thorough.

Pair it with an SPF record of v=spf1 -all and a DMARC record with p=reject on domains that also never send. Together they say "nothing to or from this domain is genuine", which removes it as a target for spoofing. The null MX must be the only MX record at that name; combining it with real MX records is invalid.

Checking MX records with dig#

# The MX set as your resolver sees it$ dig +short MX example.com10 mail.example.com.20 mail2.example.com.# Ask a public resolver to avoid your own cache$ dig @1.1.1.1 +short MX example.com# Confirm the target is not a CNAME and has an address$ dig +short CNAME mail.example.com$ dig +short A mail.example.com# Then confirm something answers on port 25$ nc -vz mail.example.com 25

On Windows, Resolve-DnsName example.com -Type MX or nslookup -type=MX example.com 1.1.1.1.

An empty CNAME answer and an address for the A query is what you want. If the CNAME query returns something, fix it. If nc times out from outside your network, the DNS is fine and the port is not reachable - a firewall, or on a hosted server, port 25 not yet forwarded. Testing from a network that blocks outbound port 25 (most home connections) will also time out, so run the test from a server, or use a web-based SMTP checker.

What the common MX failures look like

The bounce a sender receives usually names the problem if you know how to read it.

• "Domain not found" or `NXDOMAIN` - the recipient domain does not exist in DNS at all. A typo in the address, or a domain whose registration lapsed.
• "No MX or A records" or "unrouteable address" - the domain exists but has neither an MX nor an address to fall back on. Usually a newly registered domain whose records were never created.
• "Host not found" for the exchange - the MX points at a name with no A record, often because the mail host was renamed and the MX was not updated.
• Delivery delayed, connection timed out - the MX resolves, but nothing answers on port 25. The server is down, firewalled, or the port is not forwarded. The sender keeps retrying, so this shows up as a delay warning first and a bounce days later.
• `550 5.1.1` user unknown - DNS and the server are fine; the mailbox does not exist on the server the MX points at. After a provider move this often means the MX still points at the old provider, where the mailbox was deleted.
• `554 5.7.1` relay access denied - the receiving server does not consider itself responsible for your domain. The domain was never added to the mail server, or the MX points at a server that belongs to someone else.

Reading which of these you have tells you whether to fix DNS, the network, or the mail server itself, which is most of the diagnosis.

For the full picture of how lookups and caching work, see DNS records explained; for the TXT records that sit alongside MX, see SPF, DKIM and DMARC explained.

Changing mail provider without losing mail#

Moving MX is the riskiest DNS change most people make, because mail sent during the switch can land on either side.

1. Lower the MX TTL to 300 at least one old-TTL period in advance - a day before, if it was 86400.
2. Set up the new server completely first: domain, mailboxes, DKIM keys published under new selectors. Test it by sending to it directly before the switch.
3. Change the MX records to the new server. Remove the old ones entirely; leaving the old provider at a higher number means some mail goes there whenever the new one hiccups.
4. Keep the old mailboxes open for at least a few days. Senders with cached MX answers will keep delivering there until their TTL runs out. Check them and move anything that arrives.
5. Update SPF for the new sending path, and only then remove the old provider's include.
6. Copy old mail across over IMAP. Migrating email to your own server covers imapsync and the order of operations.

Note that changing the MX moves only incoming mail. Outgoing mail goes wherever your clients and applications submit it, which is configured separately in each of them.

How this fits a RE:NODE Mail Server#

On a Mail Server plan the MX for your domain points at the host name you give your server, with an A record holding the address shown in the panel. You create those records wherever your DNS is hosted - there is no zone editor on our side - and the Stalwart web admin shows the full set it expects for each domain. The MX only works once port 25 reaches the server, which support sets up on request; it is one mail server per address, since only one server can receive on port 25 at a given IP. Stalwart mail server setup covers the rest of the first hour.

FAQ#

What priority number should I use?

Any. With one mail server, 10 is conventional. With several, only the order matters, so leave gaps (10, 20, 30) to make later changes easy. Use exactly the values a hosted provider gives you.

Can an MX record point to an IP address?

No. It must point to a host name that has its own A or AAAA record. Create mail.example.com with the address and point the MX at that name.

Why is mail still going to my old provider after I changed the MX?

Senders cached the old MX for the length of its TTL. A record that sat at 86400 seconds can keep sending mail to the old server for a day. Keep the old mailboxes open until the TTL has passed and check them.

Do I need an MX record if I only send mail?

Technically no, but bounces and replies go to your domain, so you probably want to receive them. If the domain truly receives nothing, publish a null MX so senders fail fast rather than trying your web server.

Does a subdomain use the parent domain's MX?

No. Mail for user@news.example.com looks up MX at news.example.com. If there is none, it falls back to that subdomain's A record, not the parent's MX.