Here’s a nasty surprise that catches a lot of self-hosters. You move your domain’s nameservers from your registrar over to Cloudflare — for the free CDN, the tunnel, better DNS management, whatever the reason. The website comes back up fine, everything looks healthy… and then you notice that email to addresses on your domain has quietly stopped arriving. Messages bounce, or just vanish. The good news: nothing is broken, and the fix is a few DNS records. Here’s what happened and how to put it right.
Why moving nameservers breaks email
Changing your nameservers hands the entire job of answering DNS questions for your domain to Cloudflare. From that moment, Cloudflare is the authoritative source — and it only knows about the records it holds. When you switch, Cloudflare tries to auto-import your existing records, but it frequently misses MX records (the ones that say “mail for this domain goes to this server”), and often the accompanying SPF and DKIM records too.
Your web records (the A and CNAME entries) usually come across because Cloudflare can see the site responding, so the website keeps working and hides the problem. But with no MX record at the authoritative nameserver, the rest of the internet has no idea where to deliver your mail — so it bounces. The mail server itself is untouched; the signpost pointing to it just went missing.
1. Work out which MX records you need
You’re putting back exactly what your registrar had before the move. Where those values come from depends on who actually handles your mail:
- A hosted provider (Google Workspace, Microsoft 365, Zoho, etc.) — they publish a fixed set of MX values; grab them from the provider’s setup docs.
- Your registrar’s or web host’s email service — ask them, or check their control panel, for the mail server hostname and priority.
- A mail server you run yourself — the MX points at your own mail hostname.
If you’re not sure what you had, three ways to recover it: ask your registrar what MX records were set before the switch, look up your provider’s standard records in their docs, or open the headers of an email you sent from that address before the change — the receiving mail server is listed there.
2. Add the MX records in Cloudflare
In the Cloudflare dashboard, select your domain and go to DNS → Records → Add record. Set the type to MX and fill in the values for your provider. A few common shapes:
- Self-hosted / registrar mail: Type
MX, Name@, Mail servermail.yourdomain.net, Priority10. - Google Workspace: Type
MX, Name@, Mail serverASPMX.L.GOOGLE.COM, Priority1— plus Google’s four backup MX hosts at their listed priorities (5, 5, 10, 10). - Microsoft 365: Type
MX, Name@, Mail serveryourdomain-net.mail.protection.outlook.com, Priority0.
One Cloudflare-specific gotcha: MX records can’t be proxied. If you see the orange cloud, set the record to DNS only (grey cloud) — Cloudflare only proxies web traffic, and a proxied mail record won’t route. New MX records default to DNS-only, but it’s worth a glance.
3. Add an SPF record so your mail isn’t flagged as spam
MX gets mail delivered to you; SPF helps mail from you land in inboxes instead of spam folders. Add a TXT record at Name @ with a value that authorises your provider to send for the domain — for example v=spf1 include:_spf.google.com ~all for Google Workspace, or your own server’s IP for a self-hosted setup. While you’re there, re-add any DKIM and DMARC records your provider gave you; like the MX, they may not have survived the move.
4. Your reverse proxy and tunnel are completely safe
If you’re running something like a SWAG reverse proxy, a Cloudflare Tunnel, or services behind them on a home server, none of this touches them. MX, SPF and DKIM are mail records; your proxy and tunnel run on the web records (A / CNAME) and the tunnel config. Adding mail records back changes nothing about how your web traffic is routed — your self-hosted services, dashboards and web interfaces keep working exactly as they did.
5. Verify and wait for propagation
After saving, give DNS a little time — usually minutes on Cloudflare, but allow up to an hour. Confirm the records are live with an MX lookup tool, then send a test message to an address on your domain from an outside account (a phone on mobile data works well). Once a test lands, you’re back in business.
The short version
Moving nameservers to Cloudflare makes Cloudflare authoritative, and your MX (and often SPF/DKIM) records don’t always come along — so mail stops. Re-add the MX records under DNS → Records, matching whatever your email provider uses, keep them DNS only rather than proxied, add SPF (and DKIM/DMARC) back for deliverability, and rest easy that your reverse proxy, tunnel and self-hosted services are entirely unaffected.