In short
Email keeps working when you move a domain to a new DNS provider if the new zone contains every mail record before the nameservers change: MX, SPF, DKIM and DMARC. Query the new nameservers directly, make the change only after that, and switch the website over in a separate step. Test emails in both directions complete the move.
Key takeaways
- Email follows your domain’s DNS records, wherever your website is hosted. Once the nameservers change, only the new zone counts.
- If the MX record is missing, sending servers try the domain’s own address. After a move, that’s often a web server that won’t accept mail.
- You’ll find the DKIM selector in the s= value of the DKIM-Signature header of a sent email. Then query the new nameservers for it directly.
- For datafalke.de, DENIC publishes the delegation with a one-day TTL. Until it expires, resolvers may still use the old nameservers.
- datafalke.de moved in two steps on November 7, 2026: nameservers first, the website over ten hours later. MX and DKIM were in both zones.
What happens to your email when your domain moves?
Email follows your domain’s DNS records, wherever your website is hosted. If only the website moves, your email isn’t affected. If the nameservers change, only the records in the new zone apply from then on. If the MX record is missing there, new mail no longer reaches your mailbox.
The Domain Name System (DNS) translates names into addresses. The list of all records for a domain is called a zone, and the nameservers serve it to anyone who asks. The MX (mail exchanger) record names the server that accepts mail for your domain. Our guide to technical SEO covers the rest of a website’s technical foundation. The registrar is the company your domain is registered with. The kind of move you’re planning determines the effort:
| What changes | Effect on email | What to do |
|---|---|---|
| Only the website moves; DNS and email stay put | none, as long as MX and TXT stay the same | change the website’s records and check SPF |
| The registrar changes; the nameservers stay | none, as long as the zone keeps being served | find out how long the old provider will keep running the zone |
| The DNS provider and nameservers change; email stays with the same provider | none, if the new zone contains every record | all the steps in this guide |
| The email provider changes too | MX, SPF and DKIM change, and mailboxes have to move | a separate project, see below |
If the domain name itself changes, the steps in the section What else applies when you change domains? of our website migration checklist apply as well.
Short outages: If a DNS lookup fails temporarily, a sending mail server puts the message in its queue and tries again later. The standard RFC 5321 (external site) calls for at least 30 minutes between attempts and generally at least four to five days before giving up. A short outage therefore usually just delays mail.
Missing record: If there’s no MX record, RFC 5321 has the sending server treat the domain’s own address as the mail server. After a move, that’s often a web server or a CDN, a network of servers that delivers websites. Neither usually accepts mail.
Which DNS records should you save before the move?
Save every record in the old zone before you change anything: MX, SPF and other TXT records, DKIM selectors, DMARC, records for email clients, CAA and subdomains. Note the date of the lookup on the list. After the change, the old nameservers may stop answering, and then you’d have nothing to compare against.
SPF (Sender Policy Framework) specifies which servers may send email using your domain. DKIM (DomainKeys Identified Mail) signs each message, and recipients find the key for checking it in DNS. DMARC (Domain-based Message Authentication, Reporting and Conformance) tells recipients what to do with mail that fails these checks for your domain.
| Record | Name in the zone | If it’s missing |
|---|---|---|
| MX | the domain itself | new mail doesn’t reach the mailbox |
| SPF (TXT) | the domain itself | recipients can’t check the sender; if DKIM is missing too, DMARC fails |
| DKIM (TXT or CNAME) | selector._domainkey | recipients can’t check the signature |
| DMARC (TXT) | _dmarc | recipients don’t know your policy, and reports stop |
| MTA-STS, if you use it | _mta-sts and mta-sts | senders that haven’t cached your policy for encrypted delivery can’t find it |
| Email client setup | autoconfig, autodiscover, SRV records | new accounts no longer set themselves up |
| Verifications (TXT) | the domain itself | services such as Search Console lose their verification |
| CAA | the domain itself | any certificate authority may issue; a wrong value blocks certificates |
| Subdomains | for example shop, portal, vpn | that service can no longer be reached |
How to do it:
- Export the zone if your provider offers that. Otherwise, copy the records from the admin interface by hand.
- Also query the old nameservers directly.
dig +short NS example.comshows which ones they are. The dig tool is available on macOS and Linux. On Windows, use PowerShell:Resolve-DnsName example.com -Type MX -Server old-nameserver -DnsOnly. - Find the DKIM selectors. A selector is the part of the name under which the public key is stored in DNS (RFC 6376 (external site)). Send yourself an email and look in the message source for the s= value of the DKIM-Signature header (external site). With Microsoft 365, the selectors are called selector1 and selector2 (external site), and with Google Workspace the default is
google. Check every service that sends on your behalf, such as a newsletter tool, with a separate email sent through it. - Note which services were verified through DNS. Search Console periodically checks that its verification token is still there (external site), and your permissions expire after a grace period if it’s gone.
dig +short NS example.com
dig +short MX example.com @nameserver
dig +short TXT example.com @nameserver
dig +short TXT _dmarc.example.com @nameserver
dig +short TXT selector._domainkey.example.com @nameserver
dig +short CNAME selector._domainkey.example.com @nameserver
dig +short CAA example.com @nameserverCommon mistake: The DKIM selectors are missing from the list. Unlike MX and SPF, they sit under a name of their own, and you only know that name if you’ve examined an email.
Done when you have a dated list of all records, and every service that sends email on your behalf is on it with its selector.
How do you set up the new DNS zone?
Set up the complete zone at the new DNS provider before you change the nameservers. Copy the mail records unchanged and leave the website pointing to its old target for now. The nameserver change then alters nothing for your website or email, and if an error occurs, this step is the only possible cause.
How to do it:
- Create the zone and enter every record from your list. Some providers add default records of their own when you create a zone, so also check for anything you didn’t enter yourself.
- Leave the website’s records pointing to the existing target. That way, visitors won’t notice the nameserver change.
- Copy DKIM the way your mail provider specifies. The German provider STRATO (external site) (in German) and Microsoft list CNAME records for this. Microsoft then rotates the keys itself. STRATO says it may switch to new selectors from time to time. Check the selector in your emails regularly, and add each new one as another CNAME record.
Rules that trip up new zones:
- Exactly one SPF record. According to RFC 7208 (external site), two records with
v=spf1result in a permanent error. The same standard allows at most ten terms per check that trigger DNS lookups, such asinclude,aandmx. - Be careful with
ain SPF. This mechanism authorizes the addresses your domain name points to. If the website moves, that also changes who’s allowed to send. If your web server sends email itself, for example from a contact form, list it explicitly. - No CNAME at the domain itself. A CNAME points one name to another. According to RFC 1034 (external site), no other record may exist alongside it. But the domain always has nameserver records and usually MX and TXT as well. Providers such as Bunny handle this with CNAME flattening (external site) and answer queries with IP addresses.
- MX never points to a CNAME. RFC 2181 (external site) rules this out. If the target is in your own domain, for example
mail.example.com, its A record belongs in the zone too.
About TTL (time to live): It says how long resolvers, the servers that look up names for programs and devices, may cache an answer. Google suggests lowering it at least a week before a move (external site). If the mail records are the same in the old and new zones, delivery doesn’t depend on it. It still matters when you switch the website over later.
Common mistake: A second SPF record gets added for another sender. Together, the two are invalid. Add new senders to the existing record.
Done when the new zone contains every record from your list, has exactly one SPF record and still points the website to its old target.
How do you check the new zone before the change?
Query the new nameservers directly, because public resolvers don’t know the new zone before the change. With dig and the @ option, you get exactly the answer everyone will get later. Compare each answer with your list. The only differences should be the ones you planned.
How to do it:
- Repeat the queries from the section Which DNS records should you save before the move? with
@and the new nameserver. Query each new nameserver separately. - Compare each answer with your list. When there are several answers, their order can change.
- If the output is empty, run the same query without
+short. The output then also shows the response header, including the response code.REFUSEDmeans the server isn’t serving this zone.NXDOMAIN, orNOERRORwith no answer, means the record is missing.
| Query | Expected answer |
|---|---|
| MX | the same targets and priorities as before |
| TXT at the domain | exactly one record with v=spf1, plus your verifications |
| DKIM for each selector | the same key or a CNAME to the same key |
| DMARC | the existing value or your planned change |
| Website records | still the existing target |
Common mistake: The query runs through your own resolver, without @. Then the old zone answers, and the result looks fine even though the new zone still has gaps.
Done when every new nameserver returns the expected answer for every record.
How do you change the nameservers?
Enter the new nameservers at the provider where your domain is registered, ideally on a weekday morning. Your provider’s confirmation only means the request was accepted. For .de domains, only a query to DENIC, the registry, shows whether the new delegation is in effect.
What DENIC requires for .de domains: DENIC is the registry for all .de domains, and the delegation determines which nameservers are responsible for a domain. Before a change, DENIC tests the new nameservers with its Nameserver Predelegation Check (external site). Each one must be reachable and answer authoritatively for the zone, there must be at least two, and their NS records must match the list in the request exactly. The domain itself must not have a CNAME. That’s why the new zone has to be ready before you submit the request.
DNSSEC: This method signs DNS answers. If your domain is signed, the parent zone, which for .de domains is DENIC’s, holds a DS record for it. If it doesn’t match the new zone, validating resolvers treat the answer as invalid, according to RFC 4033 (external site). Agree on the order of steps with both providers beforehand. dig +short DS example.com shows whether your domain is signed. If the output is empty, it isn’t.
How to do it:
- Check your provider’s rules. STRATO’s help page, for example, says the NS record can’t be edited while a custom MX, A or SPF record is set. If you reset those records to make the change, STRATO says you can’t restore them except by entering them again, so your list has to be ready first.
- Enter all the new nameservers.
- Check with the registry whether the delegation has gone through:
dig +noall +authority NS example.de @a.nic.de. On Windows,nslookup -type=NS example.de a.nic.deshows the same thing. For top-level domains other than .de, usedig +trace NS example.com. - Don’t cancel the old DNS service yet. When we queried DENIC, the delegation of datafalke.de had a TTL of one day, and resolvers can cache it for that long. Even so, don’t count on the old nameservers to keep answering: ours refused queries after the change.
Common mistake: The change is treated as done as soon as the provider confirms it. In our case, DENIC was still naming the old nameservers more than an hour and a half after the confirmation.
Done when the registry names the new nameservers.
How do you check that email works after the change?
First check the records through several public resolvers, then check delivery itself: one email from outside to your address and one from your address to the outside. The Authentication-Results header of the received email should show spf=pass, dkim=pass and dmarc=pass. Lookups alone don’t prove delivery.
Why: Gmail requires all senders to use SPF or DKIM (external site), and senders of more than 5,000 messages a day to Gmail accounts to use SPF, DKIM and DMARC. According to RFC 9989 (external site), DMARC passes if one of the two checks succeeds for your domain. Germany’s Federal Office for Information Security (BSI) sets out requirements for email providers in its guideline TR-03182 (external site). The Authentication-Results (external site) header shows the result of the checks at the recipient.
How to do it:
- Query the records through two public resolvers, for example with
@8.8.8.8and@1.1.1.1. Both should return the same values as your list. - Send an email from your address to an account with another provider. Open the message source there and read the Authentication-Results line.
- Reply from that account. The reply must arrive in your mailbox.
- Repeat both tests the next day. Until then, resolvers may still be using the old delegation.
- Read the reports sent to the address in the
ruavalue of your DMARC record. They show which servers send on your behalf.
Plan a rollback: Decide before the change at what point you’ll switch back, for example if email still isn’t working after an hour. A rollback also runs through the delegation, so it takes about as long as the change itself.
Common mistake: The test email goes to a mailbox with the same provider. It may then stay internal, and MX and SPF never come into play.
Records added later: Resolvers also cache the answer that a record doesn’t exist. According to RFC 2308 (external site), the lower of the SOA record’s TTL and its MINIMUM field applies to that answer. For our zone, that’s 15 minutes.
Done when both test emails have arrived and the received email shows pass for SPF, DKIM and DMARC.
When should you switch the website over?
Switch the website over only after the registry names the new nameservers and email has been checked. Then you only change the website’s records. Check https for the domain and for www right afterward, because a certificate often can’t be issued until the new records are publicly visible.
If URLs or the host change in the process, follow the steps for launch day in our website migration checklist. Our guide to technical SEO explains the basics of redirects and status codes.
About CAA: The CAA (Certification Authority Authorization) record specifies who may issue certificates for your domain. If it names only authorities other than your new host’s, RFC 8659 (external site) says your host’s authority may not issue a certificate. Check the value beforehand. Let’s Encrypt’s value (external site) is issue "letsencrypt.org".
Common mistake: The website and the nameservers change in one step. If something then fails, it’s hard to tell whether the zone, the host or the certificate is to blame.
Done when the website leads to the new address over http, https and www, the certificate is valid and email is still arriving.
What changes if you also switch email providers?
If your email provider changes too, plan that as a separate project with its own date. First set up the mailboxes at the new provider, then change the MX record and add SPF and DKIM for the new sender. Existing email stays with the old provider until you transfer it.
Microsoft gives this order for Microsoft 365 (external site): add your users first, then change the MX record. From that point on, new mail arrives at the new provider.
- Set up all mailboxes and forwarding at the new provider.
- Lower the TTL of the MX record in good time. A lowered TTL only takes effect once the old one has expired.
- Add the new sender to the existing SPF record and set up DKIM at the new provider. Remove the old sender once nothing is being sent through it.
- Switch the MX record and test with emails in both directions.
- Transfer existing email and check address books and calendars.
If your DMARC record is set to p=reject, test the new sender with an email before you switch. If it passes neither SPF nor DKIM for your domain, recipients may reject the mail.
From our work: our nameserver change on November 7, 2026
On November 7, 2026, we moved the nameservers of datafalke.de from STRATO to Bunny. Registration and email stayed with STRATO, and MX and DKIM were in both zones. The website followed more than ten hours later in a separate step. The reason was technical. We wanted to keep our address without www, and for a domain without www, Bunny lists only two options (external site): a redirect to www or its own DNS service.
| Time | Step | Result |
|---|---|---|
| Sat, Nov 7, 2026, around 12:16 a.m. | Nameservers set to Bunny at STRATO | STRATO confirms they were saved |
| 1:53 a.m. | Query to DENIC | still the old nameservers |
| 1:59 a.m. | Background monitoring | stops when the computer restarts |
| 10:40 a.m. | Query to DENIC | Bunny’s new nameservers |
| 10:42:32 a.m. | Website records changed | the domain now points to the CDN |
| 10:42:36 a.m. | First attempt at the certificates | error: the domain doesn’t point to the provider yet |
| 10:43:00 to 10:43:22 a.m. | Second attempt | certificates issued for the domain and www |
| 10:43:28 a.m. | Comparison of the records | four checks report errors, see below for why |
| Sun, Nov 8, 2026, 4:22 a.m. | Comparison against the plan repeated | passed, including both DKIM keys |
Four records were deliberately different from before. The old zone had no SPF record, so we added one. DMARC got an address for reports, DKIM now uses CNAMEs pointing to STRATO’s keys, and CAA is new. The TTL at STRATO was already 150 seconds. In the new zone, it’s 300 seconds.
What didn’t go to plan:
- The timing. The plan called for a weekday morning. We made the change in the early hours of Saturday.
- The monitoring. It stopped at 1:59 a.m. when Windows restarted. That’s why we only know that the new delegation took effect between 1:53 and 10:40 a.m.
- The check tool. It also compared the new zone with the old nameservers. At 10:43 a.m. they answered with
REFUSED, and the tool reported MX, email client setup and DKIM as errors. Checked by hand through 8.8.8.8 and 1.1.1.1, all values were correct. The tool now checks against the plan. So make your comparison list before the change, because afterward the old nameservers may no longer give you any information. - The test email. We didn’t log an email showing
spf=pass,dkim=passanddmarc=passin its header after the change. So the records are documented, but delivery isn’t. We also can’t rule out that individual emails arrived late that night. We had planned a rollback but didn’t need it.
You can verify these values yourself. DNS is public, and the queries change nothing.
dig +short NS datafalke.de @8.8.8.8
coco.bunny.net.
kiki.bunny.net.
dig +noall +authority NS datafalke.de @a.nic.de
datafalke.de. 86400 IN NS coco.bunny.net.
datafalke.de. 86400 IN NS kiki.bunny.net.
dig +short MX datafalke.de @kiki.bunny.net
5 smtpin.rzone.de.
dig +short TXT datafalke.de @kiki.bunny.net
"v=spf1 include:_spf.strato.com -all"
"google-site-verification=…"
dig +short CNAME strato-dkim-0002._domainkey.datafalke.de @kiki.bunny.net
strato-dkim-0002._domainkey.rzone.de.
dig +short TXT _dmarc.datafalke.de @kiki.bunny.net
"v=DMARC1; p=reject; rua=mailto:dmarc@datafalke.de; adkim=r; aspf=r"The order of the lines can change, and the verification code is shortened. A domain and its DNS are among the things that should be in your company’s name. Our section Who holds the accounts for your repository, domain and hosting? explains why. On our website projects, the domain and hosting are in your accounts (website development FAQ).