Most website migration checklists are about the website: redirects, templates, assets, SSL. The step that takes a business offline is usually somewhere else.
When you move a domain's nameservers to a new DNS provider, the new provider starts answering for every record on the domain, not only the one that points at the website. If the mail records were not recreated there first, the new site can launch cleanly while inbound email stops and outbound mail starts failing SPF and DKIM checks.
Here is the inventory to run before you touch the nameservers.
1. Find out who answers today
dig +short NS example.com
That tells you which provider is authoritative right now. If that provider can export the zone as a BIND file, do it first: it is the most complete inventory you will get. Most providers refuse public zone transfers (AXFR), so dig alone cannot list every record. You have to query the names you know about.
2. Pull the records that matter
DOMAIN=example.com
Website
dig +short A $DOMAIN
dig +short AAAA $DOMAIN
dig +short CNAME www.$DOMAIN
Mail routing
dig +short MX $DOMAIN
SPF and most verification records live in TXT
dig +short TXT $DOMAIN
DMARC policy
dig +short TXT _dmarc.$DOMAIN
Which certificate authorities may issue for the domain
dig +short CAA $DOMAIN
If a CAA record exists, make sure it allows the certificate authority your new host uses, or the new SSL certificate will not issue.
3. DKIM needs the selector, and DNS will not tell you
DKIM keys sit at ._domainkey., and there is no way to list selectors from DNS. Two ways to find them:
Check the mail provider's admin console. Google Workspace's default selector is google. Microsoft 365 uses selector1 and selector2, published as CNAMEs.
Open a recent email sent from the domain, view the raw headers, and read the s= value in the DKIM-Signature header.
dig +short TXT google._domainkey.$DOMAIN
dig +short CNAME selector1._domainkey.$DOMAIN
dig +short CNAME selector2._domainkey.$DOMAIN
Repeat for every service that sends mail as the domain. Newsletter platforms, CRMs, help desks and transactional email providers often sign with their own selectors.
4. Do not forget the quiet records
Verification TXT records such as google-site-verification=... or MS=.... If they disappear, those services can stop treating the domain as verified.
Subdomains pointing at third parties: booking tools, help desks, status pages, landing-page builders. Check each tool's custom-domain settings.
autodiscover, a CNAME to autodiscover.outlook.com on domains that use Microsoft 365.
SRV records, if any exist.
5. Lower the TTL before the move, not during it
Resolvers cache each record for its TTL. Lower the TTL on every record you plan to change (300 seconds is common) at least one full old-TTL period before the switch, so caches have picked up the short value by then.
The delegation is cached too. For .com, the NS records at the registry carry a TTL of 172800 seconds, which is two days. Keep the old zone live and identical to the new one until that has passed.
6. Diff before you flip
Build the zone at the new provider, then query its nameservers directly, before you change anything at the registrar:
DOMAIN=example.com
NEW_NS=ns1.newprovider.example
for t in A AAAA MX TXT CAA; do
diff <(dig +short $t $DOMAIN | sort) <(dig +short $t $DOMAIN @$NEW_NS | sort) \
&& echo "$t matches" || echo "$t DIFFERS"
done
diff <(dig +short TXT _dmarc.$DOMAIN | sort) <(dig +short TXT _dmarc.$DOMAIN @$NEW_NS | sort) \
&& echo "DMARC matches" || echo "DMARC DIFFERS"
Run it with bash, since it uses process substitution. Add a line for each DKIM selector you found in step 3. Change the nameservers only when every line says "matches".
7. After the switch
Send a test email from the domain to an outside account and back. In Gmail, "Show original" displays the SPF, DKIM and DMARC results; all three should pass.
Re-run step 2 the next day to confirm the public answers match.
Leave the old zone untouched for at least as long as the longest TTL involved, including the registry's NS TTL.
Redirects protect search traffic. The DNS inventory protects everything else the domain does.
At CoderCorn, DNS and email dependencies are part of the discovery we run before a website migration, and part of the inventory behind our managed web hosting.
Top comments (2)
The email part is what usually bites people—MX records and SPF get forgotten until mail breaks.
Spot on! Had a client launch a new site once and completely forget the MX records the new site looked great, but all incoming emails went missing for two days. Definitely a lesson learned the hard way. Thanks for reading!