How long does DNS propagation really take?

// published 2026-04-17

You changed a DNS record, the docs said "propagation takes up to 48 hours", and you've been refreshing for 4. What's actually going on? Short answer: TTL is the biggest lever, but it's not the only thing.

What "propagation" really means

Your authoritative nameservers got the new record the moment you saved it. What takes time is every other resolver in the world noticing. They only check when their cached copy expires.

So "48 hours" isn't a real delay — it's a worst-case assumption. Actual propagation depends on three things:

1. TTL of the old record (before you changed it)
2. Which recursive resolvers users are hitting (Google, Cloudflare, their ISP's resolver, etc.)
3. Whether any DNS software between you and them caches longer than your TTL (some old resolvers do — it's rare now)

TTL dictates worst case

If your old record had TTL = 3600, a resolver that cached it 3599 seconds before your change will hold it for another second. A resolver that cached it 1 second before will hold it for ~60 minutes.

Across the whole population, that's a bell curve peaking around half your TTL. For a 3600s TTL, most users see the change within 30-60 minutes; stragglers take the full hour. For a 86400s TTL, you're looking at up to a day.

Why different regions see changes at different times

Recursive resolvers are per-ISP and per-region. Google's 8.8.8.8 is a cluster spread across multiple edges. Each edge has its own cache. So "Google says the record is updated" depends on which Google edge your lookup hit.

Use a DNS Propagation Checker that queries 12+ resolvers in parallel — you'll literally see the old value in one region and the new value in another.

Pre-change TTL trick

The pros do this: before changing a record, lower its TTL to 300. Wait for the old (high) TTL to pass — worldwide — then make the change. Now rollout is fast, because the ceiling is 300 seconds instead of hours.

1. Day 0, 9am: change current record's TTL from 86400 to 300. (Existing records keep pointing at the same value.)
2. Day 1, 9am: wait 24h so old cached copies with 86400 TTL have expired.
3. Day 1, 9:05am: change the record's value. With TTL=300, everyone picks it up within 5 minutes.
4. After rollout: raise TTL back to something sane (3600+).

"Negative cache" and other traps

If a record doesn't exist and a resolver queries it, the NXDOMAIN reply is also cached — typically for 60-900 seconds (depends on SOA minimum TTL). So if you add a new record, it can take up to 15 minutes for a resolver that previously got NXDOMAIN to ask again.

Fix for this: if you're planning to add a record, don't query the non-existent one first. Sounds silly but it happens — people "test" with dig before publishing, then the resolver caches the NXDOMAIN.

Verify it's really propagating

Run DNS Propagation Checker on the changed record. If you see the new value on >80% of resolvers, you're effectively propagated. The remaining 20% will catch up within the TTL window.

If resolvers are split 50/50 for more than your TTL, something's wrong: usually a split-brain zone (primary and secondary out of sync), or the record was never saved on authoritative servers.