MX records: routing mail, and when to use a null MX

How MX records route a domain’s mail, what happens without one, and when to publish a null MX instead.

MX records tell other mail servers where to deliver mail for your domain. Each one names a mail server and gives it a preference number, and senders try the lowest number first.

If the records are missing, or name a server that doesn’t exist, mail to your addresses is delayed or bounces. Your email provider gives you the exact records to publish.

What SignalDNS checks

We ask Cloudflare’s resolver (1.1.1.1) for the domain’s MX records and list the mail servers in priority order. For the first five, we look up their A and AAAA records to see whether each one has an address. We name common providers, such as Google Workspace and Microsoft 365, from their mail server names.

A single 0 . record is a null MX, which we read as “this domain accepts no mail”. We don’t connect to the mail servers or send test mail.

What MX records look like

example.com.  3600  MX  10  mx1.example.net.
example.com.  3600  MX  20  mx2.example.net.
  • The number is the preference. Lower numbers are tried first.
  • The host is the mail server’s name. It must be a name with its own A or AAAA record, not an IP address. RFC 5321 also leaves a name that’s a CNAME outside the standard, so point MX at the server’s real name.
  • DNS providers format MX records differently. Some have a separate priority field, and some want a dot at the end of the host name. Follow your provider’s format.

There’s no MX record

The domain has no MX records. Under RFC 5321 section 5.1, senders then deliver to the domain’s own A or AAAA address, as if it had an MX record pointing at itself. If that address is a web server that doesn’t accept mail, messages are retried and then returned to the sender. If the domain has no address at all, mail bounces straight away.

SignalDNS marks this as needing attention.

How to fix it: if the domain should receive mail, add the MX records your email provider gives you. For Google Workspace, that’s one record:

example.com.  MX  1  smtp.google.com.

If the domain shouldn’t receive mail, publish a null MX so senders stop trying.

The domain accepts no mail (null MX)

An MX record of 0 . is a null MX, defined in RFC 7505. It says the domain accepts no mail, so senders report a failure at once instead of queuing the message and retrying. It must be the only MX record on the name. SignalDNS marks it OK.

A null MX only covers receiving. RFC 7505 says not to use a domain with a null MX as a sender address, because receivers often reject mail they can’t reply to. If the domain never sends mail either, close it off completely:

example.com.         MX   0 .
example.com.         TXT  "v=spf1 -all"
_dmarc.example.com.  TXT  "v=DMARC1; p=reject"

v=spf1 -all says no server may send as the domain (see SPF), and p=reject asks receivers to refuse mail that claims to come from it (see DMARC).

A mail server has no address

An MX record names a server whose name has no A or AAAA record. Senders can’t connect to it.

  • None of the mail servers has an address. Senders have nowhere to deliver, so mail to the domain bounces. SignalDNS marks this as a problem.
  • Some don’t. Senders skip those and use the others, so mail still arrives, but the dead entries can delay it. This needs attention.

The usual causes are a typo in the host name, a server that was retired but left in DNS, or records from an old email provider left behind after a move.

How to fix it: compare your MX records with the ones your email provider lists now. Fix typos, and remove any host that no longer exists or belongs to a provider you’ve left. We check only the first five servers, so tidy up any beyond that too.

Priority and more than one mail server

Senders sort MX records by preference and try the lowest number first. They move to the next only when a server can’t take the message. When two records share a number, RFC 5321 asks senders to pick between them at random, which spreads the load.

  • Only the order matters. 10 and 20 work the same as 1 and 2. Use the values your provider gives you.
  • Every server listed has to accept mail for your domain. If you mix records from two providers, some mail goes to each, so only do that while you’re moving between them, and only if both are set up for your addresses.
  • If you use MTA-STS, each MX host must also be listed in its policy. A host it leaves out can block delivery.

Your provider’s guides

What we can’t tell from outside

We read the MX records from one resolver and check that the first five mail servers have an address. We don’t connect to them or send test mail, so we can’t tell whether a server accepts mail for your addresses, filters it, or passes it on. A change you just made can take up to the old record’s TTL to reach every resolver; see DNS resolvers and propagation.

Sources

Last reviewed .