Why DNS Migrations Go Wrong
Moving a domain from one DNS provider to another sounds simple — update the nameservers at your registrar and wait. But in practice, DNS migrations are one of the most common causes of preventable outages. Email stops flowing, websites go unreachable, and SSL certificates fail to renew because someone forgot to copy an MX record or left a CAA entry behind.
The problem isn't DNS itself. It's that most migration guides skip the preparation phase and jump straight to "change nameservers." A proper DNS migration is 80% preparation and 20% execution. This checklist walks through every step, from the initial audit to post-cutover verification, so nothing gets left behind.
Phase 1: Audit Your Current DNS Zone
Before touching anything, you need a complete, verified snapshot of every record in your zone. Don't trust the control panel export alone — exports can truncate records, miss hidden entries, or fail to include DNSSEC configuration.
Step 1: Pull the Full Zone from Authoritative Nameservers
# Find your authoritative nameservers
dig +short NS example.com
# Request a zone transfer (if AXFR is allowed)
dig AXFR example.com @ns1.currenthost.com
# If AXFR is blocked (common), query each record type individually
dig ANY example.com @ns1.currenthost.comMost shared hosting and managed DNS providers block zone transfers, so you'll need to query record by record. The OpsCheck DNS Lookup tool pulls all common record types in one request, which is faster than running individual dig commands for A, AAAA, MX, TXT, CNAME, NS, SOA, and SRV records.
Step 2: Build a Record Inventory Spreadsheet
Create a spreadsheet with these columns: Record Type, Name, Value, TTL, Priority (for MX/SRV), and Notes. Every single record goes here. Pay special attention to:
- TXT records for email authentication: SPF, DKIM selector records, DMARC, and any domain verification tokens (Google Workspace, Microsoft 365, Mailgun, SendGrid). Missing a DKIM selector record means your outgoing email fails authentication.
- CAA records: Certificate Authority Authorization records that restrict which CAs can issue SSL certificates for your domain. If you migrate DNS but forget the CAA record, your Let's Encrypt renewals may silently fail.
- SRV records: Service records for VoIP, LDAP, XMPP, or other non-web services that don't show up in a basic DNS scan.
- NS records at the apex: Some providers store NS records inside the zone itself. If your new provider auto-generates these, they may conflict.
Step 3: Check WHOIS for Hidden Dependencies
Run a WHOIS lookup on your domain and note the registrar, current nameservers, expiration date, and registrar-lock status. If your domain is locked, you won't be able to change nameservers until you unlock it. If it expires next week, handle the renewal before starting the migration — expired domains can't have their nameservers changed.
Phase 2: Prepare the Destination Zone
Lower TTLs 24+ Hours Before the Move
This is the single most important step and the one most often skipped. Set the TTL on every record in your current zone to 300 seconds (5 minutes) at least 24 hours before you plan to change nameservers. The 24-hour window ensures that even resolvers that cached your old TTL values will pick up the new, shorter TTL before the cutover.
# Verify current TTLs on a record before lowering them
dig +short A example.com
dig example.com A | grep -E '^[a-zA-Z0-9]' | head -1 # Shows full answer with TTLWhy this matters: Without lowered TTLs, resolvers that queried your zone before the migration will cache old record values for however long the original TTL specifies — sometimes 24 hours or more. Users hitting those resolvers get routed to the old provider's IPs, which may be dead after the cutover.
Pre-populate All Records at the Destination
Copy every record from your audit spreadsheet into the new DNS provider. Don't forget:
- The apex A/AAAA record (often just "@" or "example.com.")
- The www CNAME or A record
- Any wildcard records (*.example.com)
- SPF and DKIM TXT records — check for multiple SPF mechanisms, as some providers split long SPF strings across multiple TXT records (incorrectly)
- MX records with correct priority values
Verify the Destination Zone Independently
Before changing nameservers, query the new provider's nameservers directly to confirm your records are present and correct:
# Query the new nameserver directly for each record type
dig A example.com @ns1.newhost.com
dig MX example.com @ns1.newhost.com
dig TXT example.com @ns1.newhost.com
dig CAA example.com @ns1.newhost.comUse the OpsCheck DNS Propagation Checker to spot-check records from multiple geographic locations. If a resolver in Singapore returns different records than one in Frankfurt, your zone isn't consistent yet.
Phase 3: Execute the Cutover
Choose a Low-Traffic Window
Schedule the nameserver change during your lowest traffic period — typically Sunday morning or late night in your primary user timezone. Even with proper TTL management, there's a brief window where some users may hit cached records.
Change Nameservers at the Registrar
Log into your domain registrar (not your DNS provider), update the nameserver delegation to point to the new provider's nameservers, and save. This change typically takes 10-60 minutes to propagate to the TLD root servers, but can take up to 48 hours in rare cases.
Monitor Both Providers During the Transition
# Watch propagation in real-time from both old and new nameservers
watch -n 30 'dig +short NS example.com'
watch -n 30 'dig +short A example.com @8.8.8.8'
watch -n 30 'dig +short MX example.com @1.1.1.1'During the window when some resolvers still see the old NS records and others see the new ones, both sets of nameservers need to serve identical zone data. This is why you pre-populated the destination zone — if the new provider's zone is empty or incomplete, anyone who switches to it early hits broken records.
Phase 4: Post-Migration Verification
Verify Every Record Type from Public Resolvers
# Check all critical record types against public resolvers
for type in A AAAA MX TXT NS SOA CAA; do
echo "=== $type ==="
dig +short $type example.com
doneTest Email Delivery
Send test emails to and from the domain. Check that MX records resolve correctly and that SPF/DKIM/DMARC authentication passes. Use an email header analyzer or send a test to a Gmail address and inspect the Authentication-Results header.
Test SSL Certificate Renewal
# Simulate a Let's Encrypt dry-run renewal
certbot renew --dry-run --cert-name example.comIf you're using HTTP-01 validation, the webserver must be reachable at the new IP. For DNS-01 validation, the new provider must support the ACME TXT record challenge and your automation must be updated with new API credentials.
Check for Lingering DNSSEC Issues
If your domain had DNSSEC enabled at the old provider, you need to remove the DS records from your registrar before changing nameservers — otherwise resolvers will try to validate new records against old signatures and fail. After the migration, re-enable DNSSEC at the new provider and add the new DS records to the registrar.
# Check DNSSEC status
dig +dnssec example.com SOA
dig DS example.comRaise TTLs Back to Normal
Once you've confirmed everything works — all records resolve, email flows, SSL renews, and no users report issues — raise your TTLs back to reasonable values (3600 seconds for most records, 86400 for stable records like MX and TXT). Lower TTLs mean more DNS queries hitting your provider, which can increase costs on some platforms.
Real-World Scenario: The Missing MX Record
A hosting company migrated 47 client domains to a new DNS platform over a weekend. They used automated zone exports and imports, so most records copied correctly. But for 3 domains, the export tool silently dropped MX records because they had a trailing dot in the mail server hostname — a perfectly valid but uncommon format. By Monday morning, those clients had missed hundreds of emails. The fix was trivial once identified, but the business damage was already done.
Lesson: Never trust automated exports alone. Run the OpsCheck DNS Lookup against both old and new nameservers and diff the results before you call the migration complete.
DNS Migration Checklist Summary
- Export every record from the current zone — all types, all subdomains
- Run a WHOIS lookup to confirm registrar status (unlocked, not expiring soon)
- Lower TTLs to 300 seconds at least 24 hours before cutover
- Pre-populate the destination zone with every record
- Query the new provider's nameservers directly to verify zone contents
- Remove DNSSEC DS records from registrar if previously enabled
- Change nameservers at the registrar during a low-traffic window
- Monitor both old and new nameservers during transition
- Verify all record types from public resolvers
- Test email delivery, SSL renewal, and any custom services
- Re-enable DNSSEC at new provider if needed
- Raise TTLs back to normal levels