The dashboard said Enabled, DNS records said Locked, and all 49 routing rules were still there. When Cloudflare Email Routing stopped working for someone I was helping in September, the only honest signal was the Activity log. Its last row was three days old, and there was nothing after it.
That's not a rejection. Cloudflare wasn't receiving any mail at all. The registrar had reset the domain's nameservers, so the Cloudflare zone was no longer the one the internet was asking. Two dig commands show this in under a minute.
What does a blank Email Routing Activity log mean?
It means no sender reached Cloudflare's MX for that period. Every message Cloudflare does receive leaves a row with a status, even when it fails. The Email Service logs page lists them: Forwarded, Handled, Dropped, Rejected, Delivery failed and Error. No row at all means no delivery attempt arrived.
That splits the problem in two before you touch anything:
| Activity log shows | What happened | Where to look |
|---|---|---|
| Rows with Rejected or Delivery failed | Cloudflare got it, the next hop failed | Destination mailbox, SPF / DKIM / DMARC |
| Rows with Forwarded, but mail is missing | Delivered | Spam folder and filters at the destination |
| Nothing after a certain day | Cloudflare got nothing | Nameservers, MX, domain status |
One caveat from my own zone. It routes 1 to 4 messages a day, and in September three days had zero rows in the emailRoutingAdaptiveGroups GraphQL dataset, which the Activity log reads from. They were just quiet days. A gap only means something if the address normally gets mail every day, so send yourself a test message before reading anything into it.
Two dig commands that show a nameserver change
Ask a public resolver, not the one on your laptop:
dig +short NS yourdomain.com @1.1.1.1
dig +short MX yourdomain.com @1.1.1.1A healthy Email Routing zone looks like this. It's my own zone, run on 2026-09-30:
craig.ns.cloudflare.com.
priscilla.ns.cloudflare.com.
22 route3.mx.cloudflare.net.
84 route1.mx.cloudflare.net.
98 route2.mx.cloudflare.net.The @1.1.1.1 isn't decoration. When I first ran both commands for this note, my Mac's resolver returned nothing for NS and MX while it answered SOA fine. A public resolver gave the right answer straight away. An empty result from a local resolver proves nothing.
If the NS line shows anything other than two *.ns.cloudflare.com hosts, and MX comes back empty, the nameservers were changed at the registrar. Cloudflare's copy of your records is intact. Nobody is reading it.
Find the day it changed in WHOIS
whois yourdomain.com | grep -iE "updated date|name server|status"If the Updated Date matches the day mail stopped, that's your change. In the case I looked at, it matched to the day. The new nameservers were ns-cloud-a*.googledomains.com hosts, and their SOA serial was 1, which is what a zone that was created moments ago looks like.
A Domain Status of clientHold or serverHold is a different problem with the same symptom. The registry has suspended the domain, so nothing resolves at all. That one gets fixed at the registrar, not in Cloudflare.
Why the dashboard still says Enabled and Locked
The Email Routing overview reads Cloudflare's copy of the zone. As far as I can tell, Locked means the MX and SPF records in that copy match what Email Routing needs. It can't know that resolvers stopped asking that copy.
Cloudflare does notice eventually, on its own schedule. Its domain status page says a zone that fails repeated nameserver checks moves to Moved. On the Free plan, a Moved zone is deleted 7 days later. Your DNS records go with it, and Email Routing rules live in that zone too.
So there's a deadline. Check the zone status right away:
curl -s "https://api.cloudflare.com/client/v4/zones?name=yourdomain.com" \
-H "Authorization: Bearer $CF_TOKEN" | jq '.result[0].status'"active" is fine. "moved" means the week has started.
Who changes nameservers when you didn't?
Usually the registrar, or a site builder acting through it. The user in my case had a Squarespace notification from around the same day, and the domain's A record pointed at a Shopify IP. Squarespace's help page on domain nameservers says custom nameservers disconnect the domain from the site. Reconnecting a site from that dashboard, or the Use Squarespace nameservers button, puts Squarespace's defaults back.
Other registrars have their own versions of this: a domain transfer that lands on default DNS, a "connect to website" wizard, an expired-then-renewed domain. The common thread is a change made outside Cloudflare, which Cloudflare's dashboard can't show you.
The fix, in order
- At the registrar, set the nameservers back to the two shown on your Cloudflare zone's Overview page.
- Re-run
dig +short NS yourdomain.com @1.1.1.1until it shows Cloudflare. Squarespace quotes up to 48 hours, and it's usually much faster. - Confirm the zone status is
active, then open Email Routing settings. If it flags MX or TXT records as missing, re-add them from there. - If a site builder needs the domain, add its A or CNAME records in Cloudflare DNS instead of connecting from the builder's side. That path is what reset the nameservers in the first place.
What happens to mail sent during the outage?
Most of it is still in retry queues. With no MX record, a sender falls back to the domain's A record and tries to deliver there. If that host doesn't take mail, the sender keeps retrying. RFC 5321 says the give-up time generally needs to be at least 4 to 5 days.
So mail from the last few days may arrive on its own once MX is back. Anything older than the sender's retry window already bounced to the sender. Nothing you do on the Cloudflare side brings that back, so it's worth telling the people who were likely to write.
Nameservers and MX aren't in my Cloudflare zone security checklist yet, and after this case they should be. The two dig lines above are the whole check. If you run a Cloudflare Email Routing support address, they're the first thing to try when it goes quiet.