Error guide / Email stopped working after a DNS change
Email stopped working after a DNS change
Mail that worked until yesterday and stopped right after a DNS change is one of the most common side effects of moving a site. It shows up as messages that never arrive, bounces for people who write to you, your own outgoing mail suddenly landing in spam or being rejected, or mail apps that can no longer connect. The website itself usually works fine, so the mail provider gets the blame at first. In almost every case the mail service is untouched: the DNS records that pointed to it did not survive the change.
Check your site
What causes it
When you switch nameservers, for example to Cloudflare or to a new host, the whole DNS zone is replaced by the one at the new provider, and anything that was not copied over simply stops existing. Typically that is the MX records, which tell other servers where to deliver your mail, and the TXT records for SPF, DKIM and DMARC. Automatic imports often miss DKIM, because it lives on a name like selector._domainkey that a scan does not find. A subtler case is MX pointing to mail.your-domain, where the A record for mail was changed to the new web server, or proxied through Cloudflare (orange cloud), which only carries web traffic. Even without a nameserver change, a single manual edit can break mail: replacing the MX with the new host's, deleting the old SPF while adding a new one, or publishing a second SPF record, which makes both invalid.
How to fix it
- Run the check on this page for your domain. It shows the MX records, the SPF record with its DNS lookup count, DMARC and the DKIM keys we can find. No MX at all means nobody can deliver mail to you right now, so that is the first thing to restore. If MX is there, note the host it points to for the next steps.
- Get the old records. The previous DNS provider or host usually keeps showing the old zone in its panel for a while, and your mail provider (Google Workspace, Microsoft 365, Zoho or the old hosting) lists the exact MX, SPF and DKIM values in its setup instructions. Copy them exactly as they are, MX priorities included.
- Restore MX and check where it points. If MX points to a name like mail.your-domain.com, that name needs its own A record with the IP of the mail server, not the web server: the DNS check on this site shows which IP it resolves to now. In Cloudflare this record must be DNS only (grey cloud), because the proxy passes only web traffic and mail connections to it fail.
- Restore SPF as a single record. A domain must have exactly one TXT record starting with v=spf1. If both the old and the new host send mail for you, merge them into one record, for example v=spf1 include:old-provider include:new-provider ~all. Two separate SPF records make the check fail for every message.
- Restore DKIM with the exact selector your provider uses, such as google._domainkey or selector1._domainkey, by copying the TXT or CNAME record from the provider's panel. Our check tries the common selectors, so if your provider uses an unusual one it may not show here even when it is correct. The provider's panel has its own verify button for that.
- Then verify and wait. Sending servers keep retrying for several days when delivery fails temporarily, so much of the mail sent during the outage arrives once MX is back, but anything that was bounced permanently is lost and has to be sent again. Rerun the check, send test messages to and from an outside address such as Gmail, and look in that message's headers for spf=pass and dkim=pass.