Guides · 20 October 2026 · 6 min read

Email stopped working after changing nameservers

You moved a domain's DNS to a new provider, the website came back fine, and now email is bouncing, silently missing, or landing in spam. This is the most common surprise after a nameserver change, and it's usually quick to fix once you know where to look.

Changing nameservers doesn't move your email. It changes who answers questions about your domain. If the new provider doesn't have exactly the right email records, the rest of the internet is now being told the wrong thing.

Work through these in order. The first three explain most cases.

First: is it receiving, sending, or both?

Keep any bounce message you get. The code in it (for example 550 5.1.1 or "no MX record") tells your email provider exactly what failed.

1. Are the MX records there at all?

MX records tell other servers where to deliver your email. If the new DNS provider's import missed them, or someone set up the zone by hand and forgot them, incoming mail has nowhere to go.

Check: look at the domain in your new DNS provider's dashboard, or run dig yourdomain.com mx +short (or nslookup -type=mx yourdomain.com on Windows). If nothing comes back, recreate them from your email provider's setup page.

2. Do the MX records match your email provider exactly?

Present isn't the same as right. Compare the hostnames and priorities with what your email provider (Google Workspace, Microsoft 365, Zoho, your host) currently tells you to use. Old values copied from the previous DNS provider may point to a mail server the old host no longer runs for you.

3. If you moved to Cloudflare: is the mail hostname orange-clouded?

Cloudflare's proxy (the orange cloud) only handles web traffic. Cloudflare's own docs say mail protocols don't work through it, so any hostname your mail uses, including the target of your MX record (for example mail.yourdomain.com), must be set to DNS only (grey cloud).

Also check that Cloudflare Email Routing isn't switched on unless you actually use it. It adds its own MX records, which conflict with Google Workspace or Microsoft 365.

4. Is SPF still there, and does it include every sender?

SPF is the TXT record starting v=spf1. It lists the services allowed to send email as your domain. If it went missing in the move, or lost an include: for one of your senders (newsletter tool, invoicing app, CRM), messages from that service start failing checks and drift into spam.

There must be exactly one SPF record. Two separate v=spf1 records is an error, and receivers treat it as no SPF at all.

5. Did the DKIM records make the move?

DKIM records live on names like google._domainkey or selector1._domainkey. Automatic imports can't guess these names, so they're often missing after a move. Without them, signed mail fails DKIM.

Your email provider's admin console shows the exact name and value. Some providers (Microsoft 365, for example) use CNAMEs here. Cloudflare's docs note that CNAME flattening can break these, so leave flattening off for those records.

6. Is the DMARC record still at _dmarc?

DMARC is a TXT record at _dmarc.yourdomain.com starting v=DMARC1. If it was set to p=quarantine or p=reject and SPF or DKIM broke in the move, DMARC is now telling receivers to spam-folder or reject your mail. Fix SPF and DKIM first, rather than loosening DMARC.

7. Email apps can't connect: check the mail hostnames

If your email app shows connection errors, check the records it uses: mail., imap., smtp., or autodiscover. (Outlook). They need to exist with the right values and, on Cloudflare, be DNS only.

8. Give it time, but not too long

Other servers cache DNS answers for as long as the record's TTL says, so some will see the fix within minutes and others after a few hours. If mail still fails after a few hours with the right records in place, contact your email provider with the exact bounce message.

Find everything in one go

A Klockie Check looks at MX, SPF and DMARC in about 10 seconds and says in plain language what's missing or wrong. It also covers the website, HTTPS and redirects. If you still have the old provider's records (a zone export or screenshots), Klockie Migrate compares them with the new provider's and lists exactly what didn't come across.

Next time: check before you switch

Almost all of this is preventable with ten minutes before the change. See What to check before moving DNS to Cloudflare. And save a before snapshot in Klockie Check, so after the move you can see exactly what changed.

Email broken right now? Run a free Check on the domain. It shows what's missing in about 10 seconds.

Run a Check Compare old and new DNS

Sources: Cloudflare's Email issues troubleshooting and RFC 7208 (SPF).