You changed nameservers, migrated DNS to Cloudflare, ran a “Quick Setup” import, or clicked a “Use this provider for email” button — and within an hour, inbound mail to you@yourdomain.com stopped arriving. Senders may get bounces like 550 5.1.1 No such user or 554 5.4.4 Host not found, or nothing at all (silently dropped). The cause is almost always that your MX records were replaced with something else: blank, a placeholder, the new DNS provider’s defaults, or your registrar’s parking-page MX. This article walks the diagnosis from “is it really MX?” to restoring the correct records for Google Workspace, Microsoft 365, Zoho, Fastmail, and self-hosted setups.
How to identify which case you’re in
Run one query first to confirm MX is the layer that broke:
dig MX yourdomain.com +short
# Good (Google Workspace):
# 1 smtp.google.com.
# Good (Microsoft 365):
# 0 yourdomain-com.mail.protection.outlook.com.
# Bad:
# (empty) → MX wiped
# 10 mail.yourdomain.com. → registrar default that doesn't exist
# 1 mx.cloudflare-email.com. → Cloudflare Email Routing took overCase 1: MX wiped during DNS migration
You switched nameservers (e.g., from Namecheap to Cloudflare) and forgot to copy MX into the new zone. The new authoritative DNS has no MX, so the world sees no MX, so mail is rejected.
How to spot it: dig MX yourdomain.com +short returns empty, or dig +short NS yourdomain.com shows the new provider but the new provider’s dashboard has no MX rows.
Fix: re-add MX at the current authoritative DNS provider (whichever NS dig returns). Values come from your email vendor’s setup doc.
Case 2: “Set defaults / Quick scan / Use recommended records” overwrote MX
Cloudflare’s “Quick Scan” sometimes imports stale MX from your old DNS. Vercel DNS, Hover, and Namecheap have “Set up email with us” buttons that replace MX. GoDaddy’s “Domain connect” wizard for Microsoft 365 will overwrite your existing Google Workspace MX without warning.
How to spot it: MX exists but points to the new DNS vendor’s mail product (*.cloudflare-email.com, *.improvmx.com, mx.zoho.com when you don’t use Zoho).
Fix: delete the auto-generated MX, paste the correct ones for your real provider, save.
Case 3: Registrar parking-page MX came back
You let the domain transfer or renewal trigger a “domain parking” state. The registrar replaces MX with their park MX (mx.park.example.com style) to monetize bounces.
How to spot it: MX hostname matches the registrar’s branding, not your email vendor.
Fix: delete park MX, re-add real MX. Disable any “parking” or “premium DNS” feature.
Case 4: SPF / DKIM / DMARC got wiped at the same time
Even if MX is correct, mail may still bounce or land in spam if the TXT records for SPF/DKIM/DMARC vanished in the same migration. Recipients see SPF=none, DMARC=fail, and quarantine the message.
How to spot it:
dig TXT yourdomain.com +short | grep -i spf
dig TXT _dmarc.yourdomain.com +short
dig TXT google._domainkey.yourdomain.com +short # adjust selectorIf all three are empty, the migration nuked them too.
Fix: restore all three TXT records from your vendor’s docs (or a recent zone export).
Case 5: Wildcard CNAME swallowed mail subdomains
Less common: you added *.yourdomain.com CNAME → your-site.netlify.app. This makes mail.yourdomain.com (used by some MX hostnames or autodiscover) resolve to your website host instead of the mail server.
How to spot it: dig mail.yourdomain.com returns your website IP. SMTP connects to a web server, fails handshake.
Fix: explicitly add mail.yourdomain.com as an A record to the real mail server before the wildcard takes precedence.
Shortest fix path
In hit-rate order:
- Find your email vendor’s required MX records: Google Workspace, Microsoft 365, Zoho, Fastmail, ProtonMail all publish them in their setup docs. Copy exact priority + hostname.
- Add them at the current authoritative DNS provider: whoever
dig NS yourdomain.com +shortreturns. Not the registrar unless registrar = DNS. - Set TTL to 300 (5 min) while you verify, then raise to 3600 after it’s confirmed working.
- Restore SPF / DKIM / DMARC TXT records in the same sitting if they were also wiped.
- Test in 10–30 minutes: send a fresh email from a Gmail/Outlook account to
you@yourdomain.com. Use mxtoolbox.com/SuperTool to confirm MX is published globally.
Vendor MX reference
| Provider | MX records |
|---|---|
| Google Workspace | 1 smtp.google.com. |
| Microsoft 365 | 0 yourdomain-com.mail.protection.outlook.com. |
| Zoho Mail | 10 mx.zoho.com. 20 mx2.zoho.com. 50 mx3.zoho.com. |
| Fastmail | 10 in1-smtp.messagingengine.com. 20 in2-smtp.messagingengine.com. |
| ProtonMail | 10 mail.protonmail.ch. 20 mailsec.protonmail.ch. |
| Cloudflare Email Routing | values shown in the Email Routing dashboard (do not paste literally — they’re per-zone) |
For Microsoft 365 substitute your actual tenant prefix (e.g., mycompany-com.mail.protection.outlook.com.).
How to verify the fix worked
# 1. MX is back, globally
dig MX yourdomain.com @8.8.8.8 +short
dig MX yourdomain.com @1.1.1.1 +short
# 2. SMTP handshake works on the MX target
nc -vz smtp.google.com 25
# or
openssl s_client -starttls smtp -connect smtp.google.com:25
# 3. End-to-end: send a test mail from a different domain
# Then check spam folder + Gmail's "Show original" → SPF/DKIM/DMARC = passIf MX is correct but mail still lands in spam, the SPF/DKIM/DMARC TXTs are the next layer to check.
What to tell users during downtime
Mail sent to your domain while MX was broken can have one of three fates:
- Hard-bounced: the sender got a non-delivery report. They know. They’ll resend if they care.
- Soft-bounced and queued: most reputable mail servers retry for 24–72 hours. Once MX is fixed and TTL has expired, the queue flushes and you receive the message late.
- Silently dropped: rare, but possible if MX returned a syntactically valid but unreachable host. Lost mail.
So: fix MX → wait a day → most of the queued mail trickles in. Notify customers and partners that anything they sent in the gap may need resending.
Prevention
- Always export the full zone file before any DNS migration. Most providers have an “Export BIND” or “Export zone” button. Keep a copy of the raw text in your team docs.
- Never use “Quick scan / Import / Set defaults” buttons without reviewing each row first. Cloudflare’s scanner misses records hidden behind WAFs; partial imports look complete but aren’t.
- Add a monitor. UptimeRobot / Better Stack /
mxtoolboxall have free MX-monitoring that alerts within 5 minutes of MX going empty or changing. - Keep TTL on MX at 3600 or higher in steady state, 300 only during migrations. Low TTL on MX increases query load for no benefit once values are stable.
- Document the canonical MX values in your team ops doc alongside SPF / DKIM / DMARC, so anyone restoring can do it from a known-good source.
FAQ
Q: How long until mail starts flowing again after I restore MX? A: Depends on the previous TTL. If old MX TTL was 3600, recipients’ resolvers may keep returning the empty/wrong answer for up to an hour. Most well-behaved sending servers retry for 24–72 hours, so queued mail will catch up. Expect 5 minutes to flow for new inbound, up to a day for the long tail.
Q: My MX records look identical to the vendor docs but mail still bounces. What now?
A: Check the trailing dot. smtp.google.com without a final dot can be interpreted as smtp.google.com.yourdomain.com by some DNS UIs. Also check priority numbers are integers, not text. And confirm there are no leftover wrong MX rows hidden below a “Show more” toggle.
Q: Cloudflare offered to handle my email for free. Should I switch?
A: Cloudflare Email Routing is a forwarder, not a full mailbox. It works for you@yourdomain.com → you@gmail.com style aliases. If you need a real mailbox at your domain (send + receive), keep Google Workspace / M365 / Zoho.
Q: Can I have MX records pointing to two different mail providers at once? A: Technically yes, but only one will be tried first (lowest priority number wins). Mixing Google Workspace MX with Microsoft 365 MX guarantees mail loss. Pick one. Migrations should be a clean cutover with both sets present only during the planned overlap window.
Q: I see dig MX returns the right value but the email vendor’s dashboard still says “MX not verified.”
A: The vendor’s verification probe caches negative results for 5–30 minutes. Click “Re-check” in their dashboard, or wait. If still failing after an hour, query the vendor’s own resolver (some use their own DNS infrastructure that lags behind public resolvers).
Related articles
- DNS propagation confusion
- DNS changed site still down
- Name server vs DNS records confusion
- TTL too high after DNS change
- Domain points to wrong hosting provider
Tags: #Troubleshooting #DNS #Debug #MX record