MX records: what they are and how to check yours

SPF, DKIM and DMARC get most of the attention, but none of them matter if your MX records are broken. MX is the record a sending server reads before it even attempts a connection. If it is missing, pointing at the wrong host, or chained through a CNAME, your mail will bounce — and in some cases bounce silently.

What an MX record actually is

MX stands for Mail eXchanger. It is a DNS record type that lives at the domain level and publishes a list of hostnames that accept mail for that domain. When a sending server wants to deliver to you@example.com, it looks up the MX records for example.com, sorts them by priority, and connects to the lowest-priority host on port 25.

No MX record = the sender falls back to an A record lookup on the domain root. That used to be normal. Today it is a bad sign and plenty of receivers will refuse mail that only resolves this way.

Reading an MX record

An MX record has two fields: a numeric priority and a target hostname. Here is what Gmail's MX set looks like for a Google Workspace domain:

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

And a Microsoft 365 domain:

example.com.    IN  MX  0  example-com.mail.protection.outlook.com.

The priority number is a preference value. Lower wins. A receiver tries priority 1 first, falls back to priority 5 if that fails, then priority 10, and so on. There is no technical upper bound, but in practice everyone uses values between 0 and 50.

The target hostname must itself resolve to an A or AAAA record. It cannot be an IP address and it cannot be a CNAME — more on both below.

Multiple MX records and failover

You can publish several MX records for the same domain. Receivers sort them by priority ascending. If two records share the same priority, the sender picks one at random — useful for load balancing across a cluster of inbound relays.

example.com.    IN  MX  10  mx1.example.com.
example.com.    IN  MX  10  mx2.example.com.
example.com.    IN  MX  20  mx-backup.example.com.

In this setup, mx1 and mx2 share load. If both are unreachable, mail rolls over to mx-backup. Failover takes effect only after the sender's SMTP connection to the primary times out, which can be anywhere from 30 seconds to several minutes depending on the sending MTA.

MX vs A record — why you cannot point MX at an IP

This is one of the most common mistakes in DNS for small domains. An MX record's right-hand side must be a hostname. It cannot be an IPv4 or IPv6 literal. RFC 1035 and its successors have been explicit about this for decades. Putting MX 10 192.0.2.1 in your zone is a syntax error — most DNS hosts will reject it, but some will accept it silently and publish a broken zone.

The correct shape: publish an A or AAAA record for your mail host, then point the MX at that hostname.

mail.example.com.   IN  A   192.0.2.1
example.com.        IN  MX  10  mail.example.com.

How to check your MX records

With dig (Linux, macOS, WSL)

$ dig MX example.com +short
1 smtp.google.com.
5 smtp2.google.com.
10 smtp3.google.com.

With nslookup (Windows, anywhere)

> nslookup -type=MX example.com
example.com  MX preference = 1,  mail exchanger = smtp.google.com

With a browser

• MXToolbox — mxtoolbox.com/MXLookup.aspx, shows priority, response time, and SMTP banner.
• Google Admin Toolbox / DNS Checker — cross-resolver view, useful for catching propagation lag.
• Our own inbox placement test — the DNS section flags missing or malformed MX records as part of a full deliverability check.

Whichever tool you use, verify the target resolves and a mail server answers on port 25. A published MX that refuses connections is worse than no MX at all because senders will retry it for days.

Three silent MX misconfigurations

1. A CNAME at the MX target

RFC 2181 forbids MX records from pointing at a CNAME. Receivers that follow the spec will reject the zone. Those that don't may still resolve it but flag your mail as suspicious. Symptom: Gmail delivery works fine, a handful of Exchange recipients bounce with DNS error, and you spend a day not seeing why.

Fix: replace the CNAME with a direct A/AAAA record and point the MX at it.

2. Null MX with a typo

A correctly formatted "null MX" (MX 0 .) explicitly says the domain does not receive mail — useful for no-reply domains and helps reduce backscatter. A typo'd null MX (e.g. MX 0 null or MX 0 disabled.) looks almost identical in a text editor but publishes a hostname that doesn't exist. Senders then retry for five days before giving up.

Fix: the null MX is literally a single dot as the target — example.com. IN MX 0 ..

3. MX pointing to a dead secondary

Common after an ESP migration. You add the new provider at priority 1, forget to remove the old one at priority 10, and the old host eventually gets repurposed or shut down. Mail keeps arriving because priority 1 works. Then one day the primary has a brief outage, mail rolls over to the dead secondary, and messages disappear for hours.

Fix: audit your zone after every migration. If you are not running a secondary mail relay, delete the secondary MX.

Fixing a broken MX

• Publish at the domain apex. MX records live on the root, not on a subdomain — unless you deliberately run mail for a subdomain. example.com and mail.example.com are different mail domains.
• Keep TTLs low during changes. Drop TTL to 300 seconds 24 hours before the change, make the change, verify, then raise TTL back to 3600 or higher. Without the pre-drop, old records linger in resolver caches for the full TTL.
• Always test from outside your network. Cached answers on your corporate resolver can hide a broken public zone. Use an external resolver (dig @8.8.8.8) or a third-party tool.
• Coordinate with SPF. A new MX usually means a new sending IP range. If you forget to add the new ESP to SPF, authentication will fail even though mail is routing correctly.

Frequently asked questions