Webmaster & Network·4 min read

Checking DNS Records During a Site Migration

A site migration is not finished when the files land on the new server. It is finished when resolvers around the world agree about where your domain lives, and the only way to know is to check the records at each step. Done right, verification turns a nervous DNS switch into a series of small confirmations: the new record is published, the old one has aged out, mail still routes. This guide walks through that sequence, TTL planning included.

Open the free DNS Lookup All insights

What to check at each phase of a cutover

Verify the records, not the symptom.

Migrations bring a specific worry: you changed a record at your DNS provider, and now you keep refreshing the site to see whether anything happened. Check the records themselves instead. Run DNS Lookup before touching anything to capture the current state, again right after saving your changes, and once more later to confirm caches have moved on.

The tool queries A, AAAA, CNAME, MX, TXT, NS, SOA, SRV and CAA in parallel, so you catch collateral damage early. Plenty of migrations break email because someone rebuilt the zone on a new provider and forgot the MX and TXT records. The Email authentication panel at the top shows whether SPF and DMARC are still published, and it warns when a domain has more than one SPF record, which makes SPF fail.

One thing to keep in mind: the lookup runs through the resolver you pick, Google by default, and any resolver can hold a cached answer until the record's TTL runs out. Switching the resolver list between Google, Cloudflare and Quad9 shows quickly whether they agree, and DNS Propagation Checker asks a dozen of them at once. To see the value straight from the source, query one of the domain's own nameservers, for example dig @ns1.example-dns.com www.example.com A.

One DNS record watched through a migration

A worked example.

Suppose www.example.com has one A record pointing at 203.0.113.10 with a TTL of 3600. The day before the move, you lower the TTL to 300 in your DNS provider's panel. A lookup at that point still shows 203.0.113.10, which is correct. Only the TTL changed.

At cutover you edit the record to 198.51.100.7. A query against the authoritative nameserver returns the new address within seconds, while your ISP's resolver may keep serving 203.0.113.10 for up to five more minutes until its cached copy expires. When DNS Lookup and a couple of public resolvers such as 1.1.1.1 and 8.8.8.8 all return 198.51.100.7, the cutover is done, and you can raise the TTL back to something like 3600.

TTL values decide how fast DNS changes land

The throttle on every change.

Every record carries a time to live, the number of seconds a resolver may reuse the answer without asking again. Long TTLs mean fewer queries and more caching, which is good for stability and bad for cutovers. A record cached with 86400 can keep sending visitors to the old server a full day after you changed it.

The usual approach is to lower the TTL well before the migration, at least one old-TTL length in advance. If the record sat at 86400, drop it to 300 a day or more ahead, because resolvers holding the old answer will not see your new TTL until their cached copy expires. DNS Lookup shows the TTL next to every record, as does Domain to IP Lookup for each address. In a cached answer the number counts down, so the value in your provider's panel is the ceiling.

Why DNS propagation takes as long as it does

It is caching, not broadcasting.

You will read that DNS changes take 24 to 48 hours to propagate, which suggests your update slowly ripples across the planet. That is not how it works. Nothing is pushed anywhere. Each resolver keeps its cached answer until the TTL runs out, then fetches the new one on the next query.

So the wait is really the old TTL plus a little jitter. If lookups still show stale data long past that window, stop waiting and start debugging. The usual causes are editing the zone at the wrong provider, a typo in the record name, or old nameservers still listed at the registrar.

DNS verification mistakes that stretch a migration

A few habits reliably turn a two-hour cutover into a two-day incident:

Testing in the browser instead of checking the records. Browser and operating system caches can hold old answers for minutes after DNS has updated, so you conclude the change failed when it did not.
Forgetting to lower the TTL beforehand, then finding the old 86400 value has locked yesterday's address into caches.
Rebuilding only the A records on the new provider and losing the TXT records that carried SPF, DMARC and site verification.
Adding a second SPF record instead of editing the first. Two v=spf1 records make SPF fail, and the lookup flags it.
Editing the zone at a provider the domain no longer uses. Check the NS records first, because they name the servers the internet actually asks.

Two habits that make DNS checks trustworthy

Save a baseline before you change anything. Run the full lookup, press Copy all records and paste the result into your migration ticket. When something misbehaves late at night, that snapshot is the difference between restoring a value and rebuilding it from memory.

And check the quiet record types, not just the A record you changed. Confirming NS, MX and TXT after any zone work takes half a minute and catches the breakage that otherwise shows up as bounced email days later.

DNS Lookup, DNS Record Types and Domain to IP Lookup

Pick the right tool per question.

This article is about running lookups and verifying changes. If you are looking at an SOA or CAA entry and wondering what the fields mean, the DNS Record Types reference explains each type and its syntax.

When your question narrows to which address answers for this name right now, Domain to IP Lookup gives the tighter answer: IPv4 and IPv6 addresses with TTL, network owner and a note when a CDN sits in front. For registration questions such as nameserver ownership and expiry, use WHOIS Lookup.