When someone sends mail to [email protected], their server has no idea where your inbox lives. It asks DNS, and the answer comes from your MX records. Get them wrong and mail doesn't always bounce cleanly. Sometimes it just goes somewhere you never check, or sits in a queue for days before failing.
An MX (mail exchanger) record maps a domain to the hostname of a server that accepts mail for it, plus a number called the preference.
example.com. 3600 IN MX 10 mx1.example.net.
example.com. 3600 IN MX 20 mx2.example.net.That's the whole record: a domain, a number, a hostname. Notice what isn't there. There's no IP address, no port and no mention of the mailbox. The sending server takes the hostname, looks up its A or AAAA record to get an address, and connects on port 25.
You can check any domain's MX records with dig:
dig MX example.com +short
dig MX gmail.com +shortThe first one is a fun surprise, and I'll come back to it. For Gmail you get five lines, each a number and a hostname. Don't read anything into the order they print in. dig doesn't sort by preference, so you have to look at the numbers yourself.
If you'd rather not use a terminal, our DNS lookup shows MX records alongside the rest of a domain's zone.
The preference number is a ranking, and lower wins. RFC 5321, the SMTP standard, says a sender must try the lowest-numbered server first and only move up the list if it can't deliver there.
If two records share the same number, the sender is supposed to pick between them at random.
The actual values don't matter, only their order. 10 and 20 behave exactly like 1 and 2.
A higher-numbered "backup MX" is less useful than it sounds. Senders already queue and retry on their own. RFC 5321 says the give-up time generally needs to be at least four to five days, so a short outage on your main server rarely loses anything. Meanwhile a backup MX that doesn't know which mailboxes exist will happily accept mail for made-up addresses, then have to bounce it later. Spammers know this and sometimes aim straight at the backup. If you run one, it needs the same recipient checks and spam filtering as the primary.
This catches people out. If a domain has no MX records, mail doesn't simply fail. RFC 5321 section 5.1 says the sender treats the domain as if it had an "implicit MX" with preference 0 pointing at the domain itself. In practice, the sender looks up the domain's A or AAAA record and tries to deliver there.
So a domain with only a website record may still receive delivery attempts on port 25 of the web server. Usually nothing is listening and mail eventually bounces after the retry period.
The fallback only applies when there are no MX records at all. If even one MX exists, senders must not fall back to the A record, even if every MX is unreachable.
For domains that should never receive mail, like parked domains, short-link domains or a static site, RFC 7505 defines a null MX. It's a single MX record with preference 0 and a target of just a dot:
example.com. 3600 IN MX 0 .That's what you saw earlier when you ran dig MX example.com +short. The documentation domain publishes a null MX, because nobody should be sending mail to it.
When a sender sees this, RFC 7505 says it should fail the message straight away, using reply code 556 and enhanced status code 5.1.10, instead of queuing and retrying. The sender learns immediately that the address is dead. A null MX has to be the only MX record on the domain, so don't add one alongside real ones.
Pair it with an SPF record of v=spf1 -all and a DMARC policy of p=reject and you've told the world the domain neither sends nor receives mail, which makes it much less attractive to spoofers. Our SPF, DKIM and DMARC guide covers both.
Pointing the MX at a CNAME. RFC 2181 section 10.3 says the name in an MX record must not be an alias. Many senders will follow the CNAME anyway, but you're relying on goodwill. Point the MX at a hostname that has its own A or AAAA records. The related rule about CNAMEs at the bare domain is covered in why you can't put a CNAME on your root domain.
Putting an IP address in the MX field. The target must be a hostname. Some DNS control panels accept 203.0.113.25 in the box and publish it anyway. Senders expect a name there, and plenty will refuse to deliver. Create an A record like mail.example.com and point the MX at that.
The missing trailing dot. In a BIND-style zone file, mx1.example.net without a final dot gets your zone name appended, becoming mx1.example.net.example.com..
Old records left behind after a migration. Moving from one mail provider to another, people add the new MX records and forget to delete the old ones. Senders then split mail between two systems depending on the numbers, and some messages land in a mailbox nobody reads any more.
Start with the records themselves, then confirm each target resolves and answers.
dig MX example.com +short
dig A mx1.example.net +short
nc -v mx1.example.net 25The last command should show a banner starting with 220. If it hangs, either the server is down or port 25 is blocked on your side. Many home ISPs block outbound 25, so test from a server, or use our port scanner to check from outside your network.
Our email security checker looks at the domain's mail setup as a whole, including SPF, DKIM and DMARC, which is where the next layer of problems usually hides. If the MX records are right and mail still goes to spam, why emails go to spam is the next place to look.
As long as the old record's TTL. Resolvers that cached the previous MX keep using it until the cached copy expires. Lower the TTL a day before a mail migration, then switch.
Not strictly. MX records control where mail to your domain is delivered, not where it's sent from. But some receiving servers reject mail from domains that have neither an MX nor an A record, since there's nowhere to send a reply. Postfix's reject_unknown_sender_domain setting works this way. A domain that can receive mail simply looks more legitimate.
Yes, and that's normal. If Google Workspace or Microsoft 365 hosts your mail, your MX records point at their hostnames. The MX just needs to name a server that's configured to accept mail for your domain.
Only for records that share the same number. Senders randomise between equal-preference servers, which spreads the load. Different numbers are a strict order: the higher one only gets mail when the lower ones can't take it.
0 comments
No comments yet. Be the first.