Why DNS Migrations Go Wrong
Understanding the failure modes makes every phase of this playbook make sense:
Missing records. DNS zones accumulate records over years — legacy subdomains, service verification TXT records, CAA records, SRV records for VoIP or Microsoft 365. A manual export misses the ones you've forgotten about. After cut-over, traffic hits the new nameservers, queries for missing records get NXDOMAIN responses, and services fail silently.
TTL not lowered in advance. If your A record has a 24-hour TTL and you switch nameservers, resolvers that cached the old record within the last 24 hours keep serving the old IP for up to another 24 hours. The cut-over appears instantaneous at your desk (your local cache may have expired) but large portions of users see the old destination for hours.
Nameserver switch before zone is verified. The new provider's nameservers become authoritative the moment the registrar updates the delegation — traffic arrives immediately. If the zone isn't ready, you're serving partially, or responding SERVFAIL.
Email breaks. SPF records, DKIM selector TXT records, DMARC records, and MX priority configurations are easy to miss, especially when they're spread across multiple subdomains or use long record values that look correct at a glance but have subtle differences (like a trailing space, missing ~all, or wrong DKIM selector name).
DNSSEC left enabled. If your current zone has DNSSEC enabled and you switch to a new provider without either disabling DNSSEC first or re-establishing the chain of trust at the new provider, validating resolvers will fail with SERVFAIL for every query to your domain after cut-over.
Phase 1 — Audit and Export Your Existing Records
Before touching anything, build a complete inventory of your current DNS zone.
Export the full zone
If your current DNS provider supports zone file export (BIND-format), download it now. This is the most reliable way to capture every record:
# If you have access to the authoritative nameserver directly
dig @your-auth-ns.example.com example.com AXFR
# If zone transfer is blocked (most hosted providers), use dig for each type
for TYPE in A AAAA CNAME MX TXT NS SOA SRV CAA PTR NAPTR; do
echo "=== $TYPE ==="
dig @your-auth-ns.example.com example.com $TYPE +short
done
Most hosted DNS providers have an "Export zone file" option in their dashboard. Download this before making any changes.
Record types audit checklist
| Record Type | What to Check | Common Misses |
|---|---|---|
| A | All subdomains, including www, mail, ftp, dev, staging | Old/unused subdomains pointing to decommissioned IPs |
| AAAA | IPv6 equivalents for all A records (if in use) | Forgetting to add AAAA at the new provider |
| CNAME | All aliases and CDN/service CNAMEs | Service CNAMEs for Fastly, Cloudflare, SendGrid, etc. |
| MX | All MX records with correct priority values | Priority values getting reordered incorrectly |
| TXT | SPF, DKIM selectors, DMARC, Google/Microsoft verification, BIMI | Multiple TXT records at root; DKIM selectors on subdomains |
| NS | Current authoritative nameservers (for reference) | — |
| SOA | Serial, refresh, retry, expire, minimum TTL | SOA gets auto-generated by new provider — verify values |
| SRV | VoIP, Microsoft 365 Teams/Skype, other SRV-based services | Easy to miss — check carefully if using M365 or SIP |
| CAA | Certificate authority authorisation records | Often forgotten; blocks cert issuance after migration |
| DNSKEY / DS | DNSSEC keys (if DNSSEC is enabled) | Critical — see the DNSSEC section |
Wildcard (*) | Wildcard A or CNAME records | Must be explicitly recreated; don't propagate automatically |
⚠️ Warning: Don't rely on manually browsing your provider's dashboard to find all records. Export the zone file programmatically. Dashboard UIs paginate, filter, and may not display all record types — a zone file export or AXFR transfer is the only reliable method.
Document all records with their current TTLs
Before lowering TTLs in Phase 3, record the original TTL for each record type. You'll restore these after migration is confirmed stable.
# Check current TTL for key records
dig example.com A | grep "^example.com"
dig example.com MX | grep "^example.com"
dig example.com TXT | grep "^example.com"
dig _dmarc.example.com TXT | grep "_dmarc"
Phase 2 — Replicate Records at the New Provider
Create every record from your audit at the new DNS provider before touching the registrar.
Import vs manual entry
If the new provider accepts BIND zone file imports, use that — it's faster and eliminates manual transcription errors. Most major providers (Cloudflare, Route 53, Azure DNS, Google Cloud DNS) accept zone file imports.
If importing manually:
- Copy record values directly from the zone file export — don't retype from memory
- Paste TXT record values character-by-character; SPF and DKIM values are long and a single character error is not visually obvious
- Set all TTLs to 300 seconds initially — you'll adjust to correct values in Phase 7
- Double-check MX priority values — these are easy to transpose
Records that need special handling
DKIM selector TXT records live at <selector>._domainkey.example.com, not at the root. These are frequently missed. Check every selector your mail providers use:
# Check for common DKIM selectors
for sel in google s1 s2 mail default selector1 selector2 pm zendesk1; do
result=$(dig TXT "${sel}._domainkey.example.com" +short 2>/dev/null)
[ -n "$result" ] && echo "${sel}: $result"
done
SPF records must be a single TXT record at the root. If your current zone has multiple SPF TXT records (multiple v=spf1 strings at the same apex), this is already a problem — merge them into one before migrating. See our SPF Record guide for correct syntax.
CAA records (RFC 6844) specify which certificate authorities can issue certificates for your domain. After migration, if your CA (Let's Encrypt, DigiCert, etc.) isn't listed in your CAA records, certificate renewals will fail. Copy CAA records exactly.
Wildcard records (*.example.com) must be explicitly created at the new provider. They don't transfer automatically with zone imports in all systems — verify they appear in the new zone.
Phase 3 — Lower Your TTLs (48 Hours Before Cut-Over)
This is the most time-sensitive phase. Lowering TTLs before switching nameservers ensures that when you do switch, the propagation window is short.
Lower TTLs on your current zone (at the current provider, not the new one):
# Target TTL for pre-migration: 300 seconds (5 minutes)
# Apply to all A, AAAA, CNAME, MX, and TXT records
| Record Type | Pre-Migration Target TTL |
|---|---|
| A, AAAA | 300 seconds |
| CNAME | 300 seconds |
| MX | 300 seconds |
| TXT (SPF, DKIM, DMARC) | 300 seconds |
| NS | Cannot change (controlled by registrar / parent zone) |
| SOA | Lower minimum TTL field to 300 |
⚠️ Warning: NS record TTLs are set in the parent zone (your registrar's nameservers), not in your own zone file. You cannot lower NS TTLs yourself — they are controlled by the registry. Most TLDs have NS TTLs of 24–48 hours. This is why the 48-hour pre-migration window exists: you need to wait for the current NS TTL to expire across resolvers so that when you update the delegation, resolvers pick up the change quickly.
Wait the full TTL before cutting over. If your A records had a 24-hour (86400 second) TTL, you must wait at least 24 hours after lowering them to 300 seconds before switching nameservers. Resolvers that cached the old record with the old TTL will hold it for up to that TTL duration.
TIMELINE EXAMPLE:
Day 1, 10:00 — Lower all TTLs to 300s on current provider
Day 1, 10:00 — Resolvers begin caching new records with 300s TTL
(Old cached records expire within 24 hours max)
Day 2, 10:00 — All resolvers have refreshed; max cached TTL now 300s
Day 2, 10:30 — Safe to update nameserver delegation at registrar
(After cut-over, propagation window is ≤5 minutes)
Phase 4 — Verify the New Zone Is Complete and Correct
Before updating the registrar, query the new provider's nameservers directly to confirm every record is present and correct. Don't wait for cut-over to discover missing records.
# Replace ns1.newprovider.com with your actual new nameserver
NEW_NS="ns1.newprovider.com"
DOMAIN="example.com"
# Check key records at the new nameserver
dig @$NEW_NS $DOMAIN A +short
dig @$NEW_NS $DOMAIN MX +short
dig @$NEW_NS $DOMAIN TXT +short
dig @$NEW_NS www.$DOMAIN A +short
dig @$NEW_NS _dmarc.$DOMAIN TXT +short
dig @$NEW_NS mail.$DOMAIN A +short
# Check a DKIM selector
dig @$NEW_NS google._domainkey.$DOMAIN TXT +short
# Check CAA records
dig @$NEW_NS $DOMAIN CAA +short
# Spot-check SRV records if applicable (example: Microsoft 365 Teams)
dig @$NEW_NS _sip._tls.$DOMAIN SRV +short
Compare the output of each query against your zone file export. Every record should match exactly — same value, same priority (for MX), same flags (for CAA), same DKIM key string.
Full pre-cut-over verification checklist
- A records for root and www match current IP
- All other A/AAAA records match (staging, dev, mail, api, etc.)
- All CNAME records resolve to correct targets
- MX records present with correct priority values
- SPF TXT record present at root (single record, correct syntax)
- All DKIM selector TXT records present at
selector._domainkey.domain - DMARC TXT record present at
_dmarc.domain - CAA records present and correct
- SRV records present if applicable
- Wildcard records present if applicable
- No extra or duplicate records that weren't in the original zone
Phase 5 — Update Nameserver Delegation at the Registrar
This is the actual cut-over. Once you update the NS records at your registrar, traffic begins routing to the new nameservers.
Do this during low-traffic hours. Even with 300-second TTLs and a verified zone, brief inconsistency is possible as resolvers worldwide process the change at different times. Avoid Friday afternoons and peak business hours.
At your registrar
Log in to your domain registrar (not your DNS provider — the registrar is where you bought the domain). Find the nameserver settings — usually under "Domain settings," "Nameservers," or "DNS management." Replace the current nameserver entries with the new provider's nameservers.
Example: Switching from current provider to Cloudflare
Old nameservers:
ns1.currentprovider.com
ns2.currentprovider.com
New nameservers:
roxy.ns.cloudflare.com
sean.ns.cloudflare.com
Save the change. The registrar sends an update to the TLD registry. The new NS records will appear in the parent zone within minutes to a few hours, depending on the TLD.
Verify the delegation update
# Query the TLD nameservers directly to confirm NS records updated
# (Replace .com with your actual TLD)
dig @a.gtld-servers.net example.com NS +short
# Or use dig +trace to see the full delegation chain
dig +trace example.com A | head -30
You should see the new nameservers in the response once the registry has processed the update.
Phase 6 — Monitor Global Propagation
After cut-over, monitor propagation across global resolvers to confirm the new zone is being served correctly worldwide.
Using DNSnexus propagation tools
Use our DNS Propagation Checker to query your domain's A and MX records across 100+ resolvers worldwide. Watch for:
- All locations returning the correct IP/value from the new zone
- No locations still returning the old values from the previous zone
- No locations returning SERVFAIL or NXDOMAIN for records that should exist
Via command line
# Query multiple public resolvers to check propagation
for RESOLVER in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222 64.6.64.6; do
result=$(dig @$RESOLVER example.com A +short 2>/dev/null)
echo "$RESOLVER: $result"
done
Expected output once propagation is complete: all resolvers return the same IP from the new zone.
What to watch for
HEALTHY propagation:
8.8.8.8: 203.0.113.10 ← new IP from new zone ✓
1.1.1.1: 203.0.113.10 ✓
9.9.9.9: 203.0.113.10 ✓
208.67.222.222: 203.0.113.10 ✓
STILL PROPAGATING (some resolvers returning old IP):
8.8.8.8: 203.0.113.10 ← new IP ✓
1.1.1.1: 198.51.100.5 ← old IP (still cached) — wait
9.9.9.9: 203.0.113.10 ✓
With 300-second TTLs, full propagation should complete within 10–30 minutes for most resolvers. Some ISP resolvers with override policies may take longer — up to a few hours in rare cases.
Also verify email is flowing correctly during propagation. Send a test message from an external address and confirm delivery. Check MX record propagation specifically:
# Check MX propagation across resolvers
for RESOLVER in 8.8.8.8 1.1.1.1 9.9.9.9; do
echo -n "$RESOLVER MX: "
dig @$RESOLVER example.com MX +short
done
Phase 7 — Post-Migration Checklist and TTL Restoration
Once propagation is confirmed and all services are operating normally, restore TTLs to production-appropriate values.
Service verification checklist
- Website loads correctly at root domain and www
- HTTPS works with valid certificate (no browser warnings)
- Email sending and receiving tested from external address
- SPF check passes:
dig example.com TXT | grep spf - DKIM check passes: use our DKIM Checker
- DMARC check passes:
dig _dmarc.example.com TXT - Any subdomains with services (api, staging, dev, etc.) verified
- SSL certificate auto-renewal confirmed (check CAA records are correct for your CA)
- Login to web application works (rules out session/cookie domain issues)
- If applicable: VoIP SRV records resolving correctly
TTL restoration
After 24–48 hours of stable operation, restore TTLs to normal production values:
| Record Type | Production TTL |
|---|---|
| A, AAAA (stable, rarely changing) | 3600–86400 seconds |
| CNAME (CDN or service aliases) | 300–3600 seconds |
| MX | 3600 seconds |
| TXT (SPF, DKIM, DMARC) | 3600 seconds |
| NS | Managed by new provider (typically 86400) |
Keep your old DNS provider's zone active and unchanged for at least 7 days after migration — don't delete it or let the subscription lapse immediately. If you discover a problem and need to roll back, the old zone being intact is the difference between a 5-minute rollback and a multi-hour recovery.
Rollback Plan
Document this before starting. A rollback means reverting the nameserver delegation at the registrar back to the original nameservers.
Rollback conditions: Any service failure that cannot be resolved by adding a missing record at the new provider within 15 minutes. Don't attempt to debug complex problems under live traffic — roll back first, then diagnose.
Rollback steps:
1. Log in to registrar immediately
2. Restore original nameservers:
ns1.oldprovider.com
ns2.oldprovider.com
3. Save changes — delegation reverts to old zone
4. Propagation begins immediately (within TTL window)
5. Monitor using DNS Propagation Checker
6. Confirm traffic is returning to old zone (old IP visible in dig queries)
7. Investigate and resolve the issue with the new zone offline
8. Re-attempt migration after issue is resolved
With 300-second TTLs already set, rollback propagation completes within minutes for most resolvers. The original zone at the old provider must remain intact and unchanged for the rollback to be effective.
Special Cases: DNSSEC, Email, and Wildcard Records
DNSSEC
If your current zone has DNSSEC enabled, the migration is significantly more complex. Switching nameservers while DNSSEC is active without re-establishing the chain of trust causes every validating resolver to return SERVFAIL for your domain — effectively taking your site offline for the ~30–50% of users whose resolvers validate DNSSEC.
⚠️ Warning: Never switch DNS providers with DNSSEC enabled without following a deliberate DNSSEC migration sequence. The safe approach: disable DNSSEC at the current provider (delete the DS record from the registrar/parent zone), wait for the DS record's TTL to expire, complete the DNS migration, then re-enable DNSSEC at the new provider. For the full DNSSEC chain of trust and migration sequence, see our DNSSEC guide.
Email records
Email is the most common failure point in DNS migrations because the records involved are spread across multiple subdomains, have long values, and failures aren't always immediately obvious.
Before declaring a migration complete, test:
- Inbound email — send from an external account (Gmail, Outlook) to your domain
- Outbound email — send from your domain and check the
Authentication-Resultsheader in the received message for SPF/DKIM/DMARC pass - Check for DMARC aggregate report ingestion continuing normally after migration
SPF records in particular must be migrated exactly. A common mistake is migrating v=spf1 include:_spf.google.com ~all to the new zone but forgetting the additional include: mechanisms for transactional email senders, support tools, or marketing platforms. See our SPF Record guide for the complete record structure.
Wildcard records
Wildcard DNS records (*.example.com) catch queries for any undefined subdomain. They must be explicitly created at the new provider — they don't "inherit" from the zone apex. After migration, test a few specific subdomains that should be caught by the wildcard:
dig undefined-subdomain.example.com A +short
dig another-nonexistent.example.com A +short
Both should return the wildcard target IP. If they return NXDOMAIN, the wildcard record is missing from the new zone.
Frequently Asked Questions
Q: How long does a DNS migration actually take?
The migration preparation takes most of the elapsed time: audit (1–2 hours for a typical zone), zone replication at the new provider (30 minutes to a few hours), and the 48-hour TTL reduction wait. The actual cut-over (updating the registrar) takes 5 minutes. Post-cut-over propagation with 300-second TTLs completes within 30 minutes for most resolvers. Total calendar time: 2–3 days from start to fully migrated.
Q: Can I do a DNS migration with zero downtime, or is some outage unavoidable?
Done correctly with the TTL reduction and zone verification steps in this guide, a migration is effectively zero-downtime. There is always a theoretical window of inconsistency — different resolvers serving different zones simultaneously during propagation — but with 300-second TTLs and a fully populated new zone, any individual user's cached record expires within 5 minutes. Users who happen to query during the transition may see either the old or new zone, but this window is short and the end state is identical in terms of services available.
Q: What if I can't lower my TTLs 48 hours in advance?
You can still proceed, but the propagation window after cut-over will be longer — up to the current TTL value. If your A records have a 24-hour TTL, some resolvers may serve the old record for up to 24 hours after you switch. This is manageable if both the old and new destination serve the same content (e.g., you've already deployed to the new server), but problematic if the IP change corresponds to a site move where the old server goes away. If you can't lower TTLs, at minimum ensure the old server continues running for at least the full TTL duration after cut-over.
Q: Do I need to notify my new DNS provider before switching?
For most hosted DNS providers (Cloudflare, Route 53, etc.), no — you configure the zone in their dashboard, then update your registrar. The new provider's nameservers start answering for your zone as soon as you update the registrar delegation. Some enterprise DNS providers require account provisioning steps before the zone goes live — check their documentation.
Q: What's the difference between my DNS provider and my registrar?
Your registrar is where you registered the domain name — where you pay the annual fee (GoDaddy, Namecheap, Google Domains, etc.). Your DNS provider is where your zone file lives and where your nameservers run — this can be the same company as your registrar, or a separate provider (Cloudflare, Route 53, etc.). When you "migrate DNS," you're typically changing the DNS provider, which requires updating the nameserver records at your registrar. The registrar doesn't need to change — only the nameservers it points to.
Next Steps
Before starting your migration, audit your current zone with our DNS Check tool — it identifies missing records, misconfigured values, and zone health issues that should be resolved before you replicate the zone at a new provider.
After cut-over, monitor global propagation with our DNS Propagation Checker to confirm your new nameservers are visible worldwide. Use our NS Lookup tool to verify the nameserver delegation has updated at the registrar level.
For the foundational concepts behind why TTL reduction and the 48-hour wait matter — and how resolvers cache and expire DNS records — see our DNS Propagation guide and DNS TTL guide.
Browse all DNS guides on DNSnexus for related topics.