All tools

Guides Domains

Email stopped after changing nameservers

Updated 7 min read

Short answer

Your new nameservers don’t have your email records. Changing nameservers moves your whole DNS zone to the new provider, and only the records you recreated there exist. Mail needs its MX records first, then SPF, DKIM and DMARC.

What to do: ask the old and new nameservers for each mail record, add what’s missing at the new provider, and keep the old zone unchanged for two days.

After a nameserver change, the domain expiration checker shows when the registry last updated the domain, with its registrar and statuses. Free, no account. Check a domain

Compare the old and new nameservers

Each nameserver answers from its own copy of your zone, so ask them directly instead of asking your usual resolver. First, see which nameservers the registry hands out now. For .com and .net, ask one of Verisign’s servers:

dig +norecurse +noall +authority @a.gtld-servers.net NS example.com
example.com.		172800	IN	NS	hera.ns.cloudflare.com.
example.com.		172800	IN	NS	elliott.ns.cloudflare.com.

For another ending, use one of the servers that dig +short NS org. lists, with your own ending in place of org.

Then put the same mail questions to the old nameserver and the new one. example.com is a real case: the registry sends resolvers to Cloudflare, while IANA’s nameservers, which its old zone still names, keep answering from their own copy.

for ns in a.iana-servers.net hera.ns.cloudflare.com; do
  echo "== $ns"
  dig +norecurse +short @"$ns" MX example.com
  dig +norecurse +short @"$ns" TXT example.com
  dig +norecurse +short @"$ns" TXT _dmarc.example.com
done
== a.iana-servers.net
0 .
"v=spf1 -all"
"_k2n1y4vw3qtb4skdx9e7dxt97qrmmq9"
"v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s"
== hera.ns.cloudflare.com
0 .
"_k2n1y4vw3qtb4skdx9e7dxt97qrmmq9"
"v=spf1 -all"
"v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s"

Captured on October 24, 2026 with dig 9.10.6. Both copies match, which is what a careful move looks like. (0 . is a “null MX”, which says the domain accepts no mail at all, as defined in RFC 7505.) On your domain, every line that the old nameserver prints and the new one doesn’t is a record to add at the new provider.

A nameserver that doesn’t host the zone at all refuses to answer for it:

dig +norecurse @ns1.google.com MX example.com | grep status
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 15430

If your new provider’s nameserver says REFUSED, the zone isn’t set up or active there yet.

The records email needs

Recreate them in this order: MX, SPF, DKIM, DMARC. Take the values from the old nameserver, or from your email provider’s setup page.

Record Name Without it
MX The domain itself, such as example.com Mail to your addresses doesn’t reach your email provider.
SPF: a TXT record starting v=spf1 The domain itself Receivers can’t confirm which servers may send as you: the check returns “none”, which means “no SPF records were retrieved from the DNS” (RFC 7208, section 2.6.1).
DKIM: a TXT or CNAME record <selector>._domainkey.example.com Receivers can’t verify your messages’ signatures. A missing key means “PERMFAIL (no key for signature)” (RFC 6376, section 6.1.2).
DMARC: a TXT record starting v=DMARC1 _dmarc.example.com Receivers find no DMARC policy for the domain, and your reports stop (RFC 9989).
Anything else your provider asked for Varies Verification TXT records and CNAMEs such as autodiscover may matter to your provider. Copy every record the old zone has.

SPF records are TXT records on the domain: they “MUST be published as a DNS TXT (type 16) Resource Record” (RFC 7208, section 3.1). A domain may have only one (section 3.2), so add your provider’s entries to the existing record rather than creating a second.

Find your DKIM selectors

DKIM records are the easiest to lose, because their names include a selector that you can’t list with DNS queries. Find it in a message you sent before the change: open its full headers or source and look for DKIM-Signature. RFC 6376 gives this example:

DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane;

d= is the domain and s= the selector. The key lives under _domainkey: for d=example.com and s=foo.bar, the RFC’s own example, the query is for foo.bar._domainkey.example.com (section 3.6.2.1). Ask the old nameserver for that name and copy the value exactly. This is the DKIM record of mail.boringutils.com, the domain our own emails come from:

dig +short TXT resend._domainkey.mail.boringutils.com | cut -c1-60
"p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDMuLeucjuqzJmHfpZFk

The key is long, so the command shows only its start. A message can carry more than one signature, and each selector needs its record.

Automatic imports miss these too. Cloudflare’s documentation expects its records scan to miss “a DKIM record that uses a more custom name”, and advises: “You should always review your DNS records and manually add any missing ones before changing your nameservers” (Records quick scan).

What happened to mail sent in the meantime

It depends on what the new nameservers answered.

  • No MX records at all. A sender then treats the domain as its own mail server: “If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host” (RFC 5321, section 5.1). That host is often your website, which isn’t a mail server.
  • A temporary failure. Senders keep the message and try again. RFC 5321 says “the give-up time generally needs to be at least 4-5 days” (section 4.5.4.1), so mail that was only delayed usually arrives once the MX records are back.
  • A permanent rejection. The sender’s server returns the message to its sender as a bounce. Ask people to send those again.

Why the records didn’t come along

Your registrar holds the list of nameservers; the records themselves live in the zone that those nameservers serve. When you point the domain at new nameservers, the internet starts asking the new provider’s copy, and the old provider’s copy stops mattering. In the DNS standard’s words, once an organization controls its own zone, it “can unilaterally change the data in the zone” (RFC 1034, section 4.2). Nothing copies it for you, unless the new provider imports what it can find.

If nothing resolves at all: DNSSEC

If the website stopped too, check DNSSEC. A signed domain has a DS record at the registry that matches the old provider’s keys:

dig +short DS example.com
2371 13 2 C988EC423E3880EB8DD8A46FE06CA230EE23F35B578D64E78B29C3E1 C83D245A

Any output means the domain is signed. After a switch to a provider that signs with other keys, or doesn’t sign, validating resolvers can’t verify the new answers and return a server failure instead (RFC 4035, section 5.5), so the website and email fail together for everyone behind those resolvers. Cloudflare’s setup guide puts it directly: “If your domain has DNSSEC active, you must turn it off at your registrar before replacing nameservers. Changing nameservers while DNSSEC is active can cause your domain to become unreachable” (Primary setup).

To fix it, remove the old DS record at your registrar, or replace it with the one your new provider gives you.

Before the next nameserver change

  1. Copy every record from the old provider, ideally as an exported zone file, and recreate it at the new one.
  2. Compare both sets of nameservers with the commands above before you switch.
  3. Turn off DNSSEC at the registrar first, and turn it on again with the new provider afterwards.
  4. Switch at the registrar, and leave the old zone unchanged for at least two days: resolvers can keep using the old nameservers for up to 48 hours. How long DNS changes take explains why.

Sources

All sources were checked on October 24, 2026. The command output comes from our own runs on that date.

Keep reading