What Is an MX Record?
MX records tell the internet which servers accept mail for your domain. Wrong priority or a missing host means silence, not a bounce warning.
What an MX Record Does (and What It Does Not)
MX is inbound routing only
When someone mails [email protected], their server looks up MX for example.com, sorts by priority, and tries SMTP delivery to those hosts. The From: header you see in the inbox and the SPF record you publish for outbound mail do not participate in that lookup. Fix SPF for deliverability, ignore MX, and inbound mail still breaks.
Not the same as SPF, DKIM, or DMARC
SPF says who may send as your domain. DKIM signs messages. DMARC sets policy on the From: header. MX only answers where inbound SMTP should land. Google Workspace and Microsoft 365 both want MX targets like aspmx.l.google.com or example-com.mail.protection.outlook.com. You still need those rows when outbound auth already passes.
Warning
Priority Numbers: Lower Wins First
Each MX row carries a priority from 0 to 65535. Lower numbers win. Senders try the lowest first; if that host is down, they walk up the list.
| Priority | Host | Role |
|---|---|---|
| 10 | aspmx.l.google.com | Primary Google Workspace |
| 20 | alt1.aspmx.l.google.com | Failover |
| 30 | alt2.aspmx.l.google.com | Failover |
Pro tip
Warning
“SPF is outbound permission. MX is where inbound mail gets delivered. Different jobs.”
Three Ways to Check MX Records
From any terminal, query MX for your domain.
dig +short MX example.comEach result line is priority hostname. Match every hostname to your provider's current doc (Google, Microsoft, Zoho, Proton, etc.). One stray hostname usually means a record left behind from an old hoster.
Want SPF and DKIM in the same view? Run the free check at zerohook.org/dns-health-check before an audit or client handover.
In Cloudflare, GoDaddy, Route 53, or wherever you edit DNS: MX rows must match the provider template. Delete legacy MX from a previous ESP. Two active providers on the same apex zone can split inbound mail in ways nobody intended.
Send a test from a personal Gmail to your domain. Wrong MX often shows up as delayed bounces or 550 text about mail loops or unknown hosts. On a delivered message, open headers and note which MX host accepted the connection.
Common MX mistakes we see in scans
- MX still on GoDaddy forwarding after a move to Google Workspace
- One MX row when the provider documents four (no failover)
- MX hostname set to the bare domain instead of the provider mail server name
- Old marketing-subdomain MX left on the apex zone
Pro tip
Frequently Asked Questions
Key takeaways
MX lists which servers accept inbound SMTP for your domain; it does not authenticate outbound mail.
Lower priority numbers go first; keep every failover row your provider documents.
Check with dig, your DNS panel, and an external test message before you close a migration.
Stale MX after a provider change is why "nothing hits the inbox" while DNS "looks fine."
Plot MX with SPF, DKIM, and DMARC on one diagram so handovers do not miss a layer.
Share this analysis
Help others discover this content
More from our blog
Gmail Spam Filter 2026: 35 Mail Failures
Gmail and Microsoft spam-folder legitimate mail for authentication, DNS, reputation, and list-hygiene reasons most admins never audit. All 35 failure modes and fixes in one guide.
Fix Gmail 550 5.7.26 Auth Errors
The 550 5.7.26 authentication required bounce means Gmail rejected your message before inbox placement. Fix SPF, DKIM, DMARC alignment, and envelope-from settings for M365 and Google Workspace.
SPF Passes but Mail Lands in Spam
When SPF passes but mail lands in spam, DMARC alignment, missing DKIM, or envelope-from mismatch is the usual cause. Diagnosis and fix steps for Gmail, M365, and ESP relay sends.