An email address can be spelled perfectly and still be impossible to deliver to. If the domain on the right of the @ has no mail server pointing at it, the message stops during a DNS lookup, before a single byte of your subject line goes anywhere. That lookup asks for one thing: the domain's MX records.
This is why two addresses that look equally plausible in a spreadsheet behave completely differently. Before you send to a list, or trust what somebody typed into a signup form, it takes a second to check whether an address can actually receive mail, and the first thing that check does is read the domain's MX records.
What an MX record actually is
MX stands for Mail Exchanger. It is a DNS record type, published in a domain's zone alongside its A, TXT and NS records, and it answers one question: which server handles email for this domain? A single record looks like this:
example.com. 3600 IN MX 10 mail.example.com.
Left to right: the domain the record covers, the TTL in seconds (how long resolvers may cache the answer), the class, the record type, a priority value, and the hostname of the server that accepts mail. The last two fields are the ones that matter day to day.
When a sending server has a message for you@example.com, it takes everything after the @, asks DNS for that domain's MX records, resolves the chosen hostname to an IP address, and opens an SMTP connection to it. No MX records means no connection, which means no delivery.
Priority values and backup MX servers
The number in front of each hostname is a preference value, and lower wins. A domain publishing:
- 10 mx1.provider.net
- 20 mx2.provider.net
- 30 mx3.provider.net
gets tried at mx1 first. Only if that host refuses the connection or times out does the sender fall through to mx2, then mx3. Records sharing a number are picked between at random, which is how large providers spread inbound load across machines.
A higher-numbered host is often called a backup MX: it spools mail while the primary is down, then forwards it afterwards. Many administrators now skip backup MX entirely, because sending servers already retry for hours or days, and a secondary host tends to run weaker filtering, which is exactly why spam aims at it.
How to look up an MX record
- dig MX example.com +short on macOS or Linux, one line per record.
- host -t MX example.com for the same answer as a readable sentence.
- nslookup -type=mx example.com on Windows, in cmd or PowerShell.
- Resolve-DnsName example.com -Type MX for the PowerShell-native version, which returns objects you can sort.
If you would rather not open a terminal, any web-based MX lookup runs the same query, and a validator does it as one step of a broader check. Either way, DNS answers are cached: after a change, the old TTL has to expire before every resolver agrees with you.
When a domain has no MX record
Bounce messages phrase this several ways: domain not found, no mail server for this domain, or a permanent 5.x.x status from your outbound server. The causes are dull and mostly fixable:
- A typo in the domain. Misspelled variants of the big free providers accept no mail.
- A website-only domain. Plenty of domains host a site and never accept mail: the A record exists, the MX does not.
- An expired or parked domain. Registration lapsed and the zone became a parking page.
- A half-finished migration. Nameservers moved and nobody recreated the MX records in the new zone.
In all of those cases mail fails permanently rather than temporarily, which makes the result a hard bounce: an address you should remove from a list rather than retry.
One wrinkle: the SMTP specification lets a sender that finds no MX record fall back to the domain's A or AAAA record and try delivering there, treating the web server as an implicit mail server. Some software still does this, plenty does not, so relying on it is a bad plan. A domain that never receives mail can close the door properly with a null MX, a single record with priority 0 and a lone dot as its target.
Why MX is the first real check any validator runs
A serious validation pipeline works in cost order. Syntax first, because it is free. Then the domain has to resolve at all. Then MX, the first check that says something about mail rather than DNS in general. Only after that does anything attempt an SMTP conversation.
The MX step is popular because it is instant, invisible to the domain owner and carries no reputation risk: you are reading public DNS, not knocking on a mail server's door. It is decisive in one direction, since no MX and no A fallback means no delivery at all. What it cannot tell you is whether one specific mailbox exists, and a domain with flawless MX records will still reject a mailbox closed last year. That boundary is covered in how to check if an email address is real.
Common MX mistakes
- Pointing an MX at a CNAME. The target must be a hostname that resolves directly to an address record. Aliases are not permitted and some senders refuse to follow them.
- Putting an IP address in the record. The field takes a hostname, not a raw address.
- Trailing-dot confusion. Many DNS editors append the zone name, so an entry quietly becomes mail.example.com.example.com. Check the saved record, not what you typed.
- Missing records after a domain move. A registrar or nameserver switch does not carry the zone with it.
- Leaving the old provider's records in place. Two competing sets at the same priority sends half your mail to a mailbox nobody reads.
- Forgetting the TTL. Drop it to 300 seconds a day before a change, raise it once things are stable.
How MX relates to SPF, DKIM and DMARC
MX governs mail coming in. SPF, DKIM and DMARC govern mail going out: they tell receiving servers which hosts may send on your behalf and how to confirm nothing was altered in transit. A domain can have perfect MX records while failing authentication badly enough that everything it sends is filtered, and the full picture is in SPF, DKIM and DMARC explained.
They touch in two places. SPF has an mx mechanism that authorises your inbound servers to send outbound too, which quietly widens your policy every time you add an MX host. And DMARC reports are emailed to whatever address your policy names, so if that domain has no working MX, the reports bounce into nothing. When you need somewhere disposable to watch a test delivery land, a throwaway inbox is faster than creating a mailbox.
FAQ
Can a domain have more than one MX record?
Yes, and most real domains do. Several records give redundancy and load spreading, and the priority numbers set the order senders try them in.
Does a lower priority number mean lower priority?
The opposite, which catches out nearly everyone. The number is a preference cost, so 10 is tried before 20 — first choice, not importance.
How long does an MX change take to work?
As long as the TTL on the previous record, plus however long the slowest resolver takes to expire its cache. Lower the TTL in advance and the switch is nearly immediate.
Does a valid MX record mean the address is valid?
No. It means the domain can receive mail. The mailbox itself can still be closed, misspelled, or a catch-all that accepts everything and is never read.
Next time an address looks fine but the mail never arrives, start at the domain and run it through a validator that reads the MX records for you.
