You changed nameservers, migrated DNS to Cloudflare, ran a “Quick Scan” import, or clicked a “Use this provider for email” button — and within an hour, inbound mail to you@yourdomain.com stopped arriving. Senders get a delayed bounce such as 554 5.4.4 [internal] no relevant MX records found for domain or 550 5.1.10 RESOLVER.ADR.RecipientNotFound, or nothing at all (silently queued, then dropped). The cause is almost always that your MX records were replaced: blank, a placeholder, the new DNS provider’s defaults, or your registrar’s parking MX.
Fastest fix: run dig MX yourdomain.com +short. If it returns empty or the wrong host, go to whoever dig NS yourdomain.com +short says is authoritative, re-add your email vendor’s exact MX (table below), set TTL to 300 while you verify, and send a test mail in 10–30 minutes. This article walks the diagnosis from “is it really MX?” through restoring records for Google Workspace, Microsoft 365, Zoho, Fastmail, Proton, and self-hosted setups.
First, read the bounce — it tells you the layer
The error string narrows the problem before you touch DNS:
| Bounce text the sender sees | What it means |
|---|---|
554 5.4.4 ... no relevant MX records / Host not found | No MX (or MX host doesn’t resolve) — this article |
550 5.1.1 / 550 5.1.10 RecipientNotFound / “user unknown” | MX is reachable; the mailbox doesn’t exist. Not a DNS problem — check the address/account at your mail vendor. |
421 / “temporarily deferred” / “will retry” | Soft failure; mail is queued and retried. Often what you see in the first hour of an MX outage before it hard-bounces. |
A 550 5.1.1 means your domain still has working mail infrastructure, so MX is probably fine and you’re in the wrong article. A 5.4.x “no route / host not found” is the missing-MX signature.
How to identify which case you’re in
Run one query to confirm MX is the layer that broke:
dig MX yourdomain.com +short
# Good (Google Workspace, single-record style, since Apr 2023):
# 1 smtp.google.com.
# Good (Google Workspace, legacy 5-record set — still valid, do NOT "fix" this):
# 1 aspmx.l.google.com.
# 5 alt1.aspmx.l.google.com.
# 10 alt3.aspmx.l.google.com. ...etc
# Good (Microsoft 365):
# 0 yourdomain-com.mail.protection.outlook.com.
# Bad:
# (empty) → MX wiped
# 10 mail.yourdomain.com. → registrar default to a host that doesn't exist
# 13 route1.mx.cloudflare.net. → Cloudflare Email Routing took overNote the Google legacy set (aspmx.l.google.com plus alt1–alt4) is still fully supported as of June 2026 — if you see it, it is correct and you should leave it alone. Google added the single smtp.google.com record in April 2023 as a simpler alternative, not a replacement.
Case 1: MX wiped during DNS migration
You switched nameservers (e.g., 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, and dig +short NS yourdomain.com shows the new provider while that 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 (table below).
Case 2: “Set defaults / Quick Scan / Use recommended records” overwrote MX
Cloudflare’s “Quick Scan” sometimes imports stale MX from your old DNS, or replaces it the moment you enable Email Routing (which injects route1/route2/route3.mx.cloudflare.net). 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 a clear warning.
How to spot it: MX exists but points to the DNS vendor’s own mail product — *.mx.cloudflare.net, *.improvmx.com, or mx.zoho.com when you don’t use Zoho.
Fix: delete the auto-generated MX, paste the correct records for your real provider, save. If Cloudflare Email Routing grabbed the domain and you don’t want it, disable Email Routing under Email > Email Routing first, or it will re-add its MX on save.
Case 3: Registrar parking MX came back
A domain transfer or renewal flipped the domain into a “parking” state, and the registrar replaced MX with their park MX (mx.park.example.com style) to monetize bounces.
How to spot it: the MX hostname carries the registrar’s branding, not your email vendor’s.
Fix: delete the park MX, re-add the real MX, and disable any “parking” or “premium DNS” toggle so it can’t return.
Case 4: SPF / DKIM / DMARC got wiped in the same migration
Even with correct MX, mail can bounce or land in spam if the TXT records for SPF/DKIM/DMARC vanished alongside it. Recipients see SPF=none and DMARC=fail and quarantine or reject 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 selector per vendorIf all three are empty, the migration nuked them too. (Note the selector differs by vendor — Google uses google, Microsoft uses selector1 / selector2 as CNAMEs, Fastmail uses fm1/fm2/fm3.)
Fix: restore all three from your vendor’s docs or a recent zone export.
Case 5: Wildcard record swallowed mail subdomains
Less common: you added *.yourdomain.com CNAME → your-site.netlify.app. Now mail.yourdomain.com or autodiscover.yourdomain.com resolves to your website host instead of the mail server, so SMTP/autodiscover connects to a web server and the handshake fails.
How to spot it: dig mail.yourdomain.com returns your website IP/host.
Fix: add an explicit record for the mail name (an A/CNAME pointing at the real mail server, or the vendor’s required autodiscover CNAME). An exact-name record always beats the wildcard, so the specific entry wins.
Shortest fix path
In hit-rate order:
- Find your email vendor’s required MX. Google Workspace, Microsoft 365, Zoho, Fastmail, and Proton all publish them in their setup docs / admin console. Copy the exact priority + hostname.
- Add them at the current authoritative DNS provider — whoever
dig NS yourdomain.com +shortreturns, not the registrar unless registrar = DNS. - Delete every other MX row first. Mixing two providers’ MX guarantees lost mail. Microsoft explicitly supports only one MX per domain on Exchange Online.
- Set TTL to 300 (5 min) while you verify, then raise it to 3600 once confirmed.
- Restore SPF / DKIM / DMARC TXT in the same sitting if they were wiped too.
- Test in 10–30 minutes: send a fresh email from a Gmail/Outlook account to
you@yourdomain.com, and confirm global publication with mxtoolbox.com/SuperTool.
Vendor MX reference (verified June 2026)
| Provider | MX records | Notes |
|---|---|---|
| Google Workspace (current) | 1 smtp.google.com. | One record. Don’t keep the legacy set alongside it. |
| Google Workspace (legacy) | 1 aspmx.l.google.com. 5 alt1.aspmx.l.google.com. 5 alt2.aspmx.l.google.com. 10 alt3.aspmx.l.google.com. 10 alt4.aspmx.l.google.com. | Still valid. Use this or the single record, never both. |
| Microsoft 365 | 0 yourdomain-com.mail.protection.outlook.com. | Substitute your real tenant prefix; copy the exact value from the admin center. |
| Zoho Mail | 10 mx.zoho.com. 20 mx2.zoho.com. 50 mx3.zoho.com. | TLD changes per data center — .eu/.in/.com.au etc. Use the value shown in your Zoho Admin Console. |
| Fastmail | 10 in1-smtp.messagingengine.com. 20 in2-smtp.messagingengine.com. | These two only. |
| Proton Mail | 10 mail.protonmail.ch. 20 mailsec.protonmail.ch. | |
| Cloudflare Email Routing | 13 route1.mx.cloudflare.net. 37 route2.mx.cloudflare.net. 61 route3.mx.cloudflare.net. | Cloudflare adds these automatically when you enable Email Routing; SPF needs include:_spf.mx.cloudflare.net. |
For Microsoft 365, the live value lives in the admin center under Settings > Domains > [your domain] > DNS records, shown as the MX “Points to address.” For Zoho it’s under Admin Console > Domains > [domain] > Email Configuration / DNS Mapping.
How to verify the fix worked
# 1. MX is back, on multiple public resolvers
dig MX yourdomain.com @8.8.8.8 +short
dig MX yourdomain.com @1.1.1.1 +short
# 2. The MX target actually answers SMTP
nc -vz smtp.google.com 25
# or, to see the banner + STARTTLS:
openssl s_client -starttls smtp -connect smtp.google.com:25
# 3. End-to-end: send a test mail from a different domain,
# then in Gmail use "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 happened to mail sent during the outage
Mail sent to your domain while MX was broken has one of three fates:
- Hard-bounced: the sender got a non-delivery report and knows to resend.
- Soft-bounced and queued: most reputable mail servers retry for 24–72 hours. Once MX is fixed and the old TTL has expired, the queue flushes and you receive the message late.
- Silently dropped: rare, but possible if MX pointed to a syntactically valid but unreachable host (e.g. a parking MX). That mail is lost.
So: fix MX, wait a day, and most queued mail trickles in. Tell customers and partners that anything sent during the gap may need resending.
Prevention
- Export the full zone before any DNS migration. Most providers have an “Export BIND” / “Export zone” button. Keep the raw text in your team docs.
- Never trust “Quick Scan / Import / Set defaults” without reviewing each row. Cloudflare’s scanner misses records behind WAFs and proxies; a partial import looks complete but isn’t.
- Never proxy MX through Cloudflare (keep the cloud grey, not orange) — proxied MX breaks inbound mail.
- Add a monitor. UptimeRobot, Better Stack, and mxtoolbox all offer free MX monitoring that alerts within minutes of MX going empty or changing.
- Keep MX TTL at 3600+ in steady state, 300 only during migrations. Low TTL on stable MX just adds query load.
- Document the canonical MX values next to SPF/DKIM/DMARC in your ops doc, so anyone can restore from a known-good source.
FAQ
How long until mail flows again after I restore MX? It depends on the previous TTL. If the old (broken) MX had a 3600 TTL, some resolvers may keep returning the stale answer for up to an hour. New inbound usually starts within ~5 minutes once propagated; well-behaved senders retry for 24–72 hours, so the queued long tail catches up over the next day.
My MX matches the vendor docs exactly but mail still bounces.
Check the trailing dot — smtp.google.com without a final dot is read by some DNS UIs as smtp.google.com.yourdomain.com. Confirm priorities are integers, not text. Make sure there are no leftover wrong MX rows hidden under a “Show more” toggle, and that you only have one provider’s MX, not two.
Cloudflare offered to handle my email for free — should I switch?
Cloudflare Email Routing is a forwarder, not a mailbox. It’s great for you@yourdomain.com → you@gmail.com aliases, but you can’t send from your domain through it. If you need a real send-and-receive mailbox, keep Google Workspace / Microsoft 365 / Zoho / Fastmail.
Can I point MX at two mail providers at once? Only the lowest-priority-number host is tried first, and overflow goes to the next, so mixing (say) Google Workspace and Microsoft 365 MX guarantees split, lost mail. Pick one. During a planned migration you may briefly run both sets, then cut over cleanly to a single provider.
dig MX returns the right value but the vendor dashboard still says “MX not verified.”
The vendor’s verification probe caches negative results for 5–30 minutes. Click “Re-check,” or wait. If it still fails after an hour, query the vendor’s own resolver — some run DNS infrastructure that lags public resolvers like 8.8.8.8.
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