How long does DNS propagation take after a migration?

It is bounded by the record's TTL as it was cached before the change. With a default TTL like 3600 seconds, expect up to an hour; some resolvers ignore short TTLs and cache longer. Lowering the TTL well before cutover, and waiting for the old TTL to expire, cuts real-world propagation to minutes.

Why does the site work for me but not for others after a migration?

Your resolver has already fetched the new record while others are still inside their cache window serving the old answer. Propagation is thousands of independent caches expiring at different times, not a single synchronized update, so different people see the switch at different moments.

When is it safe to shut down the old server?

Only after every resolver you care about returns the new value and at least one full (pre-change) TTL has passed since cutover. Query multiple public resolvers directly to confirm convergence; shutting down while stragglers still point at the old address causes intermittent outages.

How to Monitor DNS Propagation After a Migration

VigilDog Team · October 19, 2026 · 5 min read

You cut over to a new host, updated the records, and the site loads for you, but a colleague across the country still sees the old server, and a few emails are landing in the wrong place. This is the anxious middle of every migration. Good DNS propagation monitoring turns that guesswork into something you can actually watch: knowing which resolvers have picked up the change, which are still serving stale answers, and exactly when it is safe to decommission the old infrastructure.

'Propagation' is really cache expiry

The word 'propagation' is misleading. DNS changes do not slowly spread across the internet like a wave. Your authoritative nameserver is updated instantly. What takes time is that resolvers around the world cached the old answer, and they keep serving it until that cached copy expires. Propagation is not replication, it is thousands of independent caches timing out.

How long each cache holds is set by the record's TTL (time to live). A record with a 3600-second TTL can be served from cache for up to an hour after you change it. That is why the change is instant for you (you queried fresh) but lingers for others (they are inside their cache window). The diagram below shows the resolution path where that caching happens.

How a domain name resolves to a server

Before you migrate: lower the TTL

The single most effective propagation control happens before the cutover, not after. Well ahead of the migration, at least one full TTL interval, ideally 24 to 48 hours, lower the TTL on the records you are about to change to something short like 300 seconds (five minutes).

Here is the timing that trips people up: the TTL that governs how long the old value is cached is the TTL that was in effect when resolvers last fetched it. If you lower the TTL only an hour before cutover, resolvers that cached the record yesterday are still holding the old, long TTL. You must lower it, then wait for the old TTL to fully expire everywhere, so that the new short TTL is the one in every cache. Do that, and the actual cutover propagates in minutes instead of hours. Raise the TTL back up once the migration is confirmed stable.

Check from multiple resolvers, not just your own

Loading the site in your browser tells you almost nothing, your machine and your ISP are one data point out of thousands. To see propagation honestly, query several independent public resolvers directly and compare their answers. From the command line with dig:

Query your authoritative server first (dig @ns1.yourhost.com yourdomain.com A) to confirm the source of truth is correct, then query the big public resolvers and watch them converge. When Google, Cloudflare, Quad9, and your own ISP all return the new value, propagation is effectively complete for the audience that matters. A quick browser-free way to sample many resolvers at once is our DNS checker, which queries multiple vantage points and shows you where answers still disagree.

dig @8.8.8.8 yourdomain.com A, Google Public DNS
dig @1.1.1.1 yourdomain.com A, Cloudflare
dig @9.9.9.9 yourdomain.com A, Quad9
dig @ns1.yourhost.com yourdomain.com A, your authoritative source of truth

What to actually watch for

Do not watch only the A record. A migration usually touches several record types, and the ones people forget are the ones that cause silent damage. Check each type that changed, from every resolver, until they all agree.

Also watch for the reverse problem, records that should not have changed but did. Migrations are a classic source of DNS drift: a control-panel default overwrites your SPF TXT record, or the new host injects its own MX. If you baselined the zone before the move, compare against it now. Getting mail records wrong during a migration is how you end up with SPF or DMARC failures that bounce legitimate email for days. Our guide to DNS records explained is a quick refresher on which record does what if you are unsure.

A / AAAA, the site itself, IPv4 and IPv6
MX plus SPF/DKIM/DMARC TXT, email routing and authentication
CNAME, subdomains and third-party services pointing at the old host
NS, if you also changed DNS providers, the delegation itself

Monitor continuously, not just at cutover

The riskiest assumption in a migration is that propagation completing means you are done. The old server is still running, and until every resolver has moved on you cannot safely shut it down, pull it too early and the stragglers hit a dead address. And weeks later, an unrelated DNS change or a provider glitch can quietly undo part of your work. A one-time check at cutover catches neither.

VigilDog monitoring watches your DNS records continuously from multiple vantage points and alerts you the moment a record drifts from what you expect, so you know exactly when a migration has fully landed, and you find out immediately if anything changes back afterward.