MX Records Explained: Priority, Backup MX and Null MX

An MX (mail exchanger) record tells other mail servers where to deliver email for your domain. Each record has a priority number and a hostname. Senders try the lowest number first, fall back to higher numbers if it fails, and share mail out between records with the same number. A domain with no email at all should publish a null MX.

You can see your current records in a couple of seconds with our free MX lookup, which also resolves each host's IP addresses, checks reverse DNS and recognises the common providers. This guide goes deeper than our general DNS records explained overview: how priority behaves in practice, when backup MX helps or hurts, null MX, and the setups and mistakes we see most often on small business domains.

Anatomy of an MX record

example.com.   3600   IN   MX   10   mx1.mailhost.example.
;  name          TTL  class type pri   target hostname

• Name: the domain that receives the mail. Usually the root (@ in most DNS panels), but subdomains can have their own MX.
• TTL: how long resolvers may cache the answer.
• Priority (also called preference): a number from 0 to 65535. Lower means preferred.
• Target: the hostname of the server that accepts mail. The trailing dot means it's a full name. Many DNS panels add it for you; others need it typed.

The address on the right of an @ in an email address is the only thing a sending server looks at. For sales@example.com it looks up the MX records for example.com, nothing else.

How priority actually works

RFC 5321, section 5.1 describes what a sending server does:

1. Look up all MX records for the domain.
2. Sort them by priority, lowest number first.
3. Where several records share the same priority, put them in random order, which spreads the load.
4. Try each in turn until one accepts the message.

So with this setup:

example.com.   MX   10   mx1.mailhost.example.
example.com.   MX   10   mx2.mailhost.example.
example.com.   MX   20   backup.otherhost.example.

Roughly half the mail goes to mx1 and half to mx2. Only if both are unreachable, or both return a temporary error, does a sender try backup.

The numbers themselves don't matter, only their order. 0, 5, 10 behaves exactly like 10, 20, 30. The gaps are just there so you can slot a new record in later.

What happens if every MX is down?

Email is more patient than the web. If no MX accepts the message, the sending server queues it and retries. RFC 5321 suggests senders keep trying for at least four to five days before giving up, and most mail systems retry for a period on that order. The sender usually gets a "delayed" warning after a few hours.

That means a short outage at your mail provider rarely loses mail. A wrong MX record is far worse: if it points to a server that answers and rejects the mail, the sender gets a permanent bounce straight away.

Backup MX: helpful or harmful?

A backup (secondary) MX is a server at a higher priority number that accepts mail when your main server can't, then holds it and forwards it later.

It made sense when businesses ran their own mail server on a single office line. Today it's rarely worth it, for three reasons:

• Major providers are already redundant. Google Workspace and Microsoft 365 run huge, multi-site mail clusters. Their single MX hostname already points to many servers.
• Spammers target backup MX hosts, because backups often have weaker filtering and don't know which mailboxes exist. They accept junk, then generate bounces to forged senders (backscatter).
• Sending servers already queue. As above, legitimate senders retry for days, so you don't lose mail during a short outage anyway.

If you're on Google Workspace or Microsoft 365, use only the MX records they give you. Don't add your old host's mail server at a lower priority "just in case". Mail sent there will sit in a mailbox nobody reads.

Null MX: for domains that never receive mail

Many businesses own domains that never handle email: old brand names, typo domains, campaign microsites. Without an MX record, senders fall back to the domain's A or AAAA record and try to deliver there (the "implicit MX" rule in RFC 5321). That leads to mail queuing for days against a web server that doesn't run SMTP.

RFC 7505 fixes this with the null MX: a single MX record with priority 0 and a target of just a dot.

old-brand.com.   3600   IN   MX   0   .

It tells sending servers "this domain doesn't accept mail", so they bounce immediately with a clear error instead of retrying. Rules:

• It must be the only MX record for that name.
• Combine it with an SPF record of v=spf1 -all and a DMARC record of p=reject so nobody can send as the domain either. Our guide on stopping email spoofing covers locking down parked domains in full.
• Some DNS panels won't accept . as a target. If yours refuses, raise a ticket with the provider. Don't point the MX at a made-up hostname, which just recreates the retry problem.

Our MX lookup reports a null MX as correct, rather than flagging it as missing.

Common setups for small businesses

Google Workspace

Google's current instructions use a single record:

Domains set up before 2023 often have the older five-record set instead: aspmx.l.google.com at 1, alt1.aspmx.l.google.com and alt2.aspmx.l.google.com at 5, and alt3 and alt4 at 10. Google says the legacy values are still supported, so if mail works you don't need to change them. Just don't mix the two sets with anything that isn't Google.

Microsoft 365

Microsoft gives every domain its own MX hostname. For existing domains it usually looks like this, with the dots in your domain replaced by hyphens:

Microsoft announced that new domains added from July 2026 would get an MX under mx.microsoft instead, to make DNSSEC easier to adopt. The exact hostname is unique to your tenant, so don't build it by hand from a pattern. Copy the value shown in the Microsoft 365 admin centre under Settings > Domains.

cPanel and other shared web hosts

Hosting packages from shared web hosts usually set the MX to the host's own mail server, often as mail.yourdomain.com at priority 0, which then points at the shared server. That's fine if you use the host's mailboxes. When you move to Google or Microsoft, you must also change the cPanel Email Routing setting to "Remote Mail Exchanger". Otherwise the server keeps delivering mail from other sites on the same server locally, and those messages never reach your new mailboxes.

For a full new-domain walkthrough including SPF, DKIM and DMARC, see how to set up email for a new domain.

The rules MX targets must follow

• Point to a hostname, never an IP address. MX 10 203.0.113.5 is invalid. Create an A record such as mail.example.com and point the MX at that.
• The hostname must have an A or AAAA record. If it doesn't resolve, mail can't be delivered.
• Don't point MX at a CNAME. RFC 2181, section 10.3 says MX targets must not be aliases. Many senders cope anyway, but some don't, and it's an easy source of intermittent failures. Our guide to CNAME vs A records explains the difference.
• Reverse DNS helps if you run your own server. The IP behind the MX should have a PTR record that resolves back to a matching hostname. Big providers handle this for you. Our MX lookup shows the PTR for each host.

Common MX mistakes

1. Leftover records from the old provider. You moved to Google Workspace but the host's mail.example.com record is still there at priority 0. Some mail goes to the old server.
2. Typing the host into the name field. Entering smtp.google.com as the record name creates an MX for smtp.google.com.example.com. The name should be @ or blank.
3. Missing trailing dot. Some panels treat a target without a trailing dot as relative, producing smtp.google.com.example.com. Check the published result, not what you typed.
4. MX on the www subdomain only. Records belong on the name that appears after the @, usually the root domain.
5. Proxying the mail host through Cloudflare. Cloudflare's proxy doesn't carry mail. The A record your MX points at must be set to "DNS only" (grey cloud), or mail will fail.
6. Forgetting SPF after switching. Changing MX controls where mail arrives. It doesn't change who may send. Update your SPF record too, and check it with our SPF checker.

How to check your MX records

From a terminal:

# macOS / Linux
dig example.com MX +short

# Windows
nslookup -type=MX example.com

Or use the MX lookup tool, which adds the IP addresses, PTR records and provider for each host and flags missing or unresolvable targets. If you've just changed your MX, run the DNS propagation checker with the MX type to see which public resolvers have the new value. Our guide on how long DNS propagation takes explains why some still show the old one.

Once mail is flowing, consider MTA-STS and TLS-RPT, which tell senders to require encrypted delivery to the MX hosts you list.

FAQ

What does MX priority 0 mean?

It's simply the most preferred value possible. Senders try the record with the lowest number first, and 0 is the lowest. Microsoft 365 uses 0 for its single MX record, but any number works if it's the only record.

Can I have two MX records with the same priority?

Yes. Senders pick between them at random, which spreads mail across both servers. Both must deliver to the same mailboxes, or mail will seem to go missing.

Do I need a backup MX?

Usually not. Sending servers queue and retry for days if your MX is down, and Google Workspace and Microsoft 365 are already redundant behind their MX hostnames. Backup MX hosts also attract spam because their filtering is often weaker.

What happens if a domain has no MX record?

Senders fall back to the domain's A or AAAA record and try to deliver there. If that's a web server with no mail service, messages queue and eventually bounce days later. Publish a null MX (0 .) if the domain never receives mail.

Can an MX record point to an IP address?

No. The target must be a hostname with its own A or AAAA record. Create something like mail.example.com pointing to the IP and use that as the MX target.

Does changing MX records affect my website?

No. MX records only control where email is delivered. Your website uses A, AAAA or CNAME records, so you can switch email providers without touching the site.