How to Verify a DNS Migration Before and After Cutover

Migrating DNS -- switching providers, moving to a new nameserver setup, or restructuring a large set of records -- carries more risk than most infrastructure changes, precisely because a mistake doesn't fail loudly. A broken record just quietly stops resolving, or resolves to the wrong thing, and the first sign is often a support ticket rather than an alert.

Before the migration

• Export every existing record from the current provider -- a complete zone file or equivalent, not just the ones you remember configuring.
• Lower TTLs on records that will change, at least one full TTL cycle ahead of time.
• Note down current values for everything: A/AAAA, CNAME, MX, TXT (including SPF/DKIM/DMARC), and any less common record types in use.

After the migration

1. Query the new authoritative nameservers directly for every migrated record, and compare each answer against your pre-migration export.
2. Check both A and AAAA independently for every hostname that previously had either -- it's easy to migrate one address family and forget the other.
3. Verify MX and the surrounding email-authentication records specifically -- email breakage from a DNS migration is disproportionately common and disproportionately disruptive.
4. Re-check from more than one resolver, and ideally more than one network location, before declaring the migration complete.
5. Wait out the old TTL window, then check again -- a clean result immediately after cutover doesn't guarantee every cached resolver worldwide has caught up yet.

A bulk lookup covering the full list of hostnames, run once right after cutover and again after the old TTL window has passed, turns this from a manual per-record check into a single repeatable step -- and gives you an exportable record of exactly what was verified and when.

Don't tear down the old side too early

The most common regret after a migration isn't a record that was missed -- it's the old provider's account or nameservers being canceled or decommissioned the same day the new ones go live. Because some fraction of resolvers worldwide are still working off cached answers pointing at the old setup until their TTL expires, keeping the previous provider active (even if nothing new points at it) for at least one full old-TTL window after cutover is cheap insurance. If something does need a fast rollback, having the old side still answering is the difference between flipping the nameservers back in minutes and reconstructing a zone file from memory under pressure.

A dry run catches most problems before they're real

Where the new DNS provider allows it, standing up the full new zone ahead of time -- fully configured, but not yet delegated to -- and querying it directly (bypassing normal delegation, either by pointing a test tool at its nameservers explicitly or using the provider's own preview feature) turns migration verification from a post-cutover scramble into a pre-cutover check with zero user impact if something's wrong. Any record that's missing, misconfigured, or simply different from what was intended shows up before a single real resolver has ever seen it, which is a meaningfully lower-stress place to catch a mistake than after the cutover has already gone live.