Guides · Email
MX Records And Email Routing
MX records tell the world where to send mail for your domain. Here's how senders actually use them and how to read them when delivery breaks.
By Cody · 6 min read · Published
What an MX record is
An MX (Mail eXchanger) record published at a domain tells the world which hostnames will accept SMTP mail for addresses ending in that domain. Each record carries a numeric priority and a target hostname.
MX records can be published at the apex (example.com) or at a subdomain (mail.example.com). The apex MX is what governs mail to user@example.com; a subdomain MX governs mail to user@mail.example.com.
How priority works
Lower numbers are tried first. If a sender cannot connect to the lowest-priority host, or the host returns a temporary failure, the sender moves on to the next priority. Records with equal priority are load-balanced — the sender picks one at random for each delivery attempt.
Pitfall: assuming "higher priority" means "higher number." In MX, lower number = higher preference. Read MX values like a foot race — first place is number one.
Anatomy of a working MX setup
Most domains use a single hosted-email provider, which typically publishes a primary plus several backups. A few examples:
# Google Workspace example.com. IN MX 1 aspmx.l.google.com. example.com. IN MX 5 alt1.aspmx.l.google.com. example.com. IN MX 5 alt2.aspmx.l.google.com. example.com. IN MX 10 alt3.aspmx.l.google.com. example.com. IN MX 10 alt4.aspmx.l.google.com. # Microsoft 365 example.com. IN MX 0 example-com.mail.protection.outlook.com. # Self-hosted with a backup example.com. IN MX 10 mx1.example.com. example.com. IN MX 20 mx2.example.com.
What MX targets must look like
An MX target must be a hostname with A or AAAA records. It must not be an IP address (DNS syntax forbids it) and per RFC must not be a CNAME. Most provider migrations break because the new MX is added but the old MX is left behind, so a fraction of mail still routes to the decommissioned host. Always remove the previous provider's MX records as part of cutover.
Where MX fits with SPF, DKIM, and DMARC
MX governs inbound mail — where senders deliver to you. SPF, DKIM, and DMARC govern how receivers judge outbound mail that claims to be from your domain. They are separate concerns sharing the same DNS zone.
See the SPF, DKIM, and DMARC guide for the authentication side.
Troubleshooting bounces
Quick checklist when mail to your domain is bouncing:
- Does an MX record exist? Run a lookup against a public resolver, not just your own.
- Do the MX targets resolve to A or AAAA addresses?
- Is port 25 reachable from the internet to those hosts?
- Does the receiving server greet with a banner naming the right domain?
- Is the TLS handshake on port 25 clean? Some senders require STARTTLS today.
- Is the bounce a 4xx (transient) or 5xx (permanent)? The text usually names the cause.
If steps 1-3 pass but mail still fails, the problem is on the receiving server, not in DNS.
TTL and cutover planning
Lower the TTL on your MX records 24-48 hours before a provider switch. During cutover, both old and new MX may briefly receive mail; that is normal. Watch the new provider's queue and the old provider's spool until the old TTL window closes.
Example MX query
- Example input
example.com- Example result
MX 1 aspmx.l.google.com. MX 5 alt1.aspmx.l.google.com. MX 5 alt2.aspmx.l.google.com.
Senders try aspmx.l.google.com first. If that host is unreachable, they retry with the priority-5 alternates, picking between them at random.
Related tools
FAQ
Can I use a CNAME as my MX target?
Per RFC 2181 and RFC 5321, MX records must point to hostnames that have A or AAAA records, not to CNAMEs. Some senders tolerate CNAME targets, but many do not, and you will see intermittent delivery failures that are very hard to debug. Always point MX at a real A/AAAA name.
What is the null MX record?
A null MX (RFC 7505) is the record `0 .` published at a domain to declare that the domain does not accept mail. Compliant senders will reject mail to that domain immediately rather than retrying for days. Useful for parked domains and apex names of services that should never receive mail.
Do priorities 10, 20, 30 mean something different from 1, 2, 3?
No. Only the relative order matters. Many providers use multiples of 10 to leave room for inserting an intermediate value later, but the routing behavior is identical. Equal priorities are load-balanced across attempts.
Why does the sender see different MX answers than I do?
Resolver caches and split-DNS configurations both cause this. Senders may have cached the previous MX set during its TTL, or your network may serve different DNS internally than externally. Use a public resolver lookup to see what an external sender sees.
What happens if I have no MX record at all?
Per RFC 5321, senders fall back to the A or AAAA record of the domain itself if no MX exists — the so-called implicit MX. This is fragile and surprising; if you accept mail, publish an explicit MX record. If you do not accept mail, publish a null MX.
Last reviewed: 2026-05-06.