Changing DNS Provider Without Breaking Your Email

Short answer: When you move DNS hosting, for example to a new registrar, a CDN or your web host, your e-mail depends on records that the new provider does not know about: MX, SPF, DKIM, DMARC and often verification, autodiscover and MTA-STS records. Export or list every record at the old provider, recreate them at the new one, compare the two zones record by record, especially long DKIM keys, and only then switch nameservers. Afterwards, test incoming and outgoing mail and check authentication headers.

Why DNS moves break e-mail so often

DNS moves usually happen for reasons that have nothing to do with e-mail: a website redesign, a new hosting company, a switch to a CDN for speed or security, or consolidating domains at one registrar. The person doing the move focuses on the website records, sees the new site working and considers the job done.

E-mail breaks quietly. Incoming mail may keep working for hours because senders cached the old MX records, and outgoing mail may be delivered to spam rather than bouncing. By the time someone notices that invoices are not arriving or DMARC reports have stopped, the old DNS provider may already have deleted the zone.

Some migration tools and providers import existing records automatically by scanning the old zone. That helps, but scans can miss records, especially those on unusual names such as DKIM selectors, and they cannot import what they do not know exists. Always verify manually.

The records e-mail depends on

Remember subdomains as well. A marketing subdomain may have its own SPF record, DKIM keys and even MX records for bounce handling, and these are easy to overlook when the focus is on the root domain.

The four core records are MX, SPF, DKIM and DMARC. The others depend on your setup, but each one is there for a reason.

Step 1: take a complete inventory of the old zone

1. Export the zone file if the old provider offers it. A zone file is the most complete record of what exists.
2. If export is not available, take screenshots or copy every record from the DNS panel, including those on subdomains.
3. Collect DKIM selectors from your mailbox provider’s admin console and every sending platform, then look up each selector._domainkey name with dig. DKIM names cannot be discovered without knowing the selector, so this step catches records a scan would miss.
4. Check DMARC reports and sending platforms for any service you forgot.
5. Note TTL values of the current records.

Step 2: recreate the records at the new provider

Add every record to the new DNS zone before switching nameservers. The new provider serves nothing to the public until the nameservers change, so you can build the zone at leisure.

Watch the usual traps:

• Host name formats. Some panels expect @ for the root, others an empty field or the full domain. Entering the full name in a panel that appends the domain creates _dmarc.yourdomain.com.yourdomain.com.
• Long DKIM keys. 2048-bit keys exceed 255 characters and must be stored as multiple strings within one TXT record. Some panels truncate silently. Compare the full value.
• Quotes. Some panels add quotes automatically; adding your own creates doubled quotes inside the value.
• Proxy settings on CDNs. CDN-style DNS providers may offer to proxy records through their network. Mail-related host names, such as the target of MX records, must not be proxied, or mail delivery to them fails.
• MX priorities. Copy them exactly.

Step 3: compare the zones before switching

You can query the new provider’s nameservers directly before they are live, for example dig TXT _dmarc.yourdomain.com @ns1.newprovider.example. Do this for every mail-related record and compare the answers with the same queries against the old nameservers. Pay particular attention to:

• the complete DKIM value for each selector;
• exactly one SPF record, identical to the old one;
• MX host names and priorities;
• the DMARC record, including the report address.

Step 4: switch nameservers and test

1. Lower TTLs in advance at the old provider if you plan to change any values during the move; if values stay the same, this matters less.
2. Change the nameservers at the registrar. Nameserver changes can take up to a day or two to be seen everywhere, because the parent zone’s NS records have their own caching.
3. Keep the old zone active at the old provider until the change has fully propagated. Some resolvers will keep asking the old nameservers for a while.
4. Test incoming mail from an external account.
5. Test outgoing mail from each sending system to Gmail and Outlook.com, and check that SPF, DKIM and DMARC pass.
6. Check DMARC reports over the next days for sudden failures.
7. Check provider dashboards for domain verification status.

Moves that happen without anyone planning them

Not every DNS move is a deliberate project. Several everyday actions change DNS hosting as a side effect:

• Transferring the domain to another registrar can reset nameservers to the new registrar’s defaults if the transfer is done carelessly.
• Connecting the domain to a website builder or hosting plan that asks you to “point your nameservers to us” moves the whole zone, not just the website.
• Activating a CDN or security service for the website often involves moving nameservers to that service.
• Letting a hosting contract expire can remove a DNS zone that the host was serving, even if the registration continues elsewhere.

In each case, the person making the change may not realise that e-mail depends on the same zone. A simple rule helps: any change to nameservers requires a check of the mail records the same day. Put it in the handover notes for whoever manages the website, and in the agency brief if an agency is involved.

A note on DNSSEC

If DNSSEC is enabled for your domain, moving DNS providers requires extra care, because the signing keys and the DS record at the registrar must match the new provider. A mismatch can make the whole domain, including mail records, fail to resolve for validating resolvers. Follow both providers’ DNSSEC migration guidance, or temporarily disable DNSSEC in a controlled way before the move and re-enable it afterwards. Our guide DNSSEC Explained for Website Owners covers how the chain of trust works and why a mismatched DS record is so disruptive.

If something breaks after the switch

Most problems after a DNS move have a simple cause: a missing or mangled record. Compare the failing record at the new provider with your inventory, fix it, and wait for the negative-caching period of the zone to pass. If mail is critical and you cannot find the problem quickly, switching the nameservers back to the old provider is a valid emergency option, provided you kept the old zone intact.

An outside check helps here, because it shows what the rest of the world sees rather than what the panel displays. Site AI Audit checks MX, SPF (including the lookup limit), DKIM and DMARC for your domain, together with the website’s SSL and security basics, and explains each finding in plain words. Run a free check before and after the move and compare. Paid plans on the pricing page repeat the checks and alert you if a record disappears later.

Related reading

• Switching Email Providers: A Checklist to Avoid Lost Mail
• MX Records Explained: How Email Finds Your Mail Server
• DKIM Failing? How to Troubleshoot dkim=fail and dkim=none
• Website Migration SEO: How to Move a Site Without Losing Traffic

The bottom line

A DNS move is an e-mail change whether you intend it or not. Inventory every record, including DKIM selectors that scans miss, recreate them carefully at the new provider, compare the zones by querying both sets of nameservers, and only then switch. Test mail flow and authentication afterwards, and keep the old zone until propagation is complete.

SSS

Will changing DNS provider affect my e-mail?

Only if records are missing or wrong at the new provider. E-mail itself stays with your mail provider, but the MX, SPF, DKIM and DMARC records must be recreated exactly.

How do I find all my DKIM records?

Get the selector names from your mail provider and every sending platform, then look up each selector._domainkey name. DKIM records cannot be listed without knowing the selectors.

How long does a nameserver change take?

Often a few hours, but it can take up to a day or two for all resolvers to use the new nameservers. Keep the old zone active during that time.

Can I proxy MX records through a CDN?

No. Mail servers must be reachable directly. Host names used for mail should be DNS-only, not proxied through a web CDN.

Why did my DKIM break after moving DNS?

Usually because the record was not copied, or the long key was truncated or quoted incorrectly by the new DNS panel. Compare the full value with the one in your mail provider’s console.

Should I lower TTLs before moving DNS?

It helps if you plan to change record values. If you only move the same records to a new provider, the nameserver change is what matters, and TTLs play a smaller role.