MX records: priority, fallbacks, and the mistakes that lose mail
MX records tell the world where to send mail addressed to your domain. Misconfigured priorities, missing TTLs, and CNAME traps cause silent loss every day.
MXDNSMail Routing
MX (Mail Exchanger) records are the most consequential 50 bytes of DNS most people never check. They tell every sending server in the world where to deliver mail addressed to your domain — and a single typo can route weeks of important messages into a black hole.
Anatomy of an MX record
DNS record
| Host | Type | Value | TTL |
|---|---|---|---|
| example.com | MX | 1 smtp.google.com | 3600 |
The 1 is the priority. Lower numbers win. Google Workspace has consolidated to a single MX, but historical setups often have 5-10 records with priorities like 10, 20, 30 etc. Sending servers try the lowest first, then fall back if it's unreachable.
Multi-MX with priority
DNS records
| Host | Type | Value | TTL |
|---|---|---|---|
| example.com | MX | 0 example-com.mail.protection.outlook.com | 3600 |
| example.com | MX | 10 backup-mx.example.com | 3600 |
Common mistakes
- MX pointing to a CNAME. RFC violation. Most receivers handle it but some throw 5xx. Always point MX to an A/AAAA record.
- MX pointing to an IP. Same problem — must be a hostname.
- Same priority on every record. Allowed, but means random selection. Use distinct priorities unless you genuinely want round-robin.
- TTL too long. 86400 (1 day) means a typo takes a day to roll back. 3600 is friendlier.
- Missing trailing dot. In some DNS interfaces,
smtp.google.comwithout a trailing dot becomessmtp.google.com.example.com. Disaster.
Verifying your MX
Quick check from the command linebash
# dig
dig +short MX example.com
# host
host -t MX example.com
# nslookup
nslookup -type=mx example.comFrequently asked questions
Keep reading