When someone sends an email to you@yourdomain.com, the sender's mail server does not know your mail server's IP address. It looks it up. The DNS record that answers "which servers accept mail for this domain?" is the MX record. If your MX records are missing, misconfigured, or point at servers that do not answer, mail to your domain bounces or silently goes missing. This is the first thing to check whenever mail stops arriving.
An MX record has two parts: a priority (a number, where lower means "try me first") and an exchange (the hostname of the mail server). A typical setup for a domain on Google Workspace:
yourdomain.com. MX 10 aspmx.l.google.com.
yourdomain.com. MX 20 aspmx2.l.google.com.
yourdomain.com. MX 30 aspmx3.l.google.com.
The sending server tries priority 10 first. If that host does not answer, it moves to 20, then 30. That is why most providers publish several MX records: redundancy. If all of your MX servers are down at the same moment, sending servers have nowhere to deliver, and mail is held, retried, and eventually bounced.
1. No MX records at all. The most common cause of "I can't receive email on my new domain." Without an MX record, senders fall back to the domain's A record, and most providers will not accept mail there. If your domain has no MX records, no one can email you.
2. MX points at a hostname that does not resolve. The MX record names a server, but that server has no A or AAAA record. The sending server cannot find an IP address, so delivery fails. This usually happens when a mail provider's records are copied with a typo, or when a provider's infrastructure changed.
3. The MX host has no PTR (reverse DNS). Receiving servers commonly check that the IP you connect to maps back to a sensible hostname. Missing or mismatched PTR is a classic spam-filter red flag, and some corporate gateways reject outright.
4. Pointing MX at a shared or consumer host. MX records should point at your mail provider's servers, not at your VPS or your office IP. If you run your own mail server on a residential IP, you are also fighting blocklists and port 25 filtering, which is a different problem entirely.
5. A "null MX" when you actually want mail. A record of MX 0 . is a valid DNS record that explicitly says "this domain does not accept mail." It is used by domains that exist only for web or subdomains. If you see it and you do expect to receive email, that is your bug.
From a terminal, dig MX yourdomain.com or nslookup -type=MX yourdomain.com will list them. But the MX record alone only tells you half the story: the exchange hostnames must also resolve to IPs, and those IPs should have PTR records. A record that "exists" but points at nothing is worse than no record, because it looks configured.
The free MX checker does the whole chain in one go: it lists your MX records with priorities, resolves each mail server to its IP, and checks reverse DNS, so you can see exactly which link in the chain is broken.
People mix these up, so here is the one-paragraph version. MX says where mail should be delivered. SPF says which servers are allowed to send as your domain. DKIM signs each message so receivers can verify it really came from you. DMARC tells receivers what to do when SPF or DKIM fails. All four are independent: a domain can have perfect MX and still fail authentication, and it can have perfect authentication and still not receive mail because its MX is broken. When mail is misbehaving, check MX first (can I even receive?), then SPF/DKIM/DMARC (can I even send?).
Related: SPF vs DKIM vs DMARC · Why my email lands in spam · Free MX checker · Free SPF checker
The free audit checks MX, SPF, DKIM, DMARC and more in about 30 seconds, and shows the exact record to add if one is missing.
Run the free auditWant this checked automatically every day? Inboxproof Pro monitors your domain around the clock and alerts you the moment a record breaks or an IP gets listed. See pricing →