DNS propagation: what's actually happening, and how long it takes

You changed a DNS record. Your colleague sees the new value; you still see the old one. The registrar's panel says "saved", a checker site shows a mix of green and red, and somewhere a deadline is slipping. "DNS propagation" is the name everyone uses for this limbo — and the name itself is the source of most of the confusion, because nothing is propagating.

There is no broadcast

DNS changes are not pushed anywhere. When you edit a record, exactly one thing happens: your zone's authoritative nameservers start answering with the new value. Every other DNS server on the planet — your ISP's resolver, Google's 8.8.8.8, Cloudflare's 1.1.1.1, the resolver inside your office router — finds out only when it asks again. Until then, each one keeps serving whatever answer it fetched last, for as long as that answer's TTL allows.

So "propagation" is really cache expiry, happening independently in thousands of places at once. Nobody is forwarding your change around the world; the world is just gradually asking again.

TTL is the whole story

Every DNS answer carries a TTL (time to live) — the number of seconds a resolver may keep serving it without re-asking. A record with a TTL of 300 is re-fetched within five minutes everywhere; a record with a TTL of 86400 can keep serving its old value for a full day after you change it.

That leads to the one trick that makes planned changes painless: lower the TTL before the change, not after. If a record you are about to move has a day-long TTL, drop the TTL a day ahead of the migration and wait for the old, long-lived answers to expire. When you then make the real change, the world re-asks within minutes. Raising the TTL back afterward is optional politeness to resolvers.

Changing the TTL at the same time as the value does nothing for that change — the old answers already in caches still carry the old TTL and expire on the old schedule.

Why "24–48 hours" is a myth (and what's real)

The "24 to 48 hours" figure that registrars quote is a worst-case blend of three different waits:

• Record edits at the same nameservers: bounded by the record's own TTL — minutes to hours, not days.
• Nameserver (NS) changes — moving a domain to a different DNS provider: bounded by the TTL of the NS records and the parent zone's glue, commonly up to 24–48 hours, which is where the folklore number comes from.
• Negative caching: if something asked for a name before it existed, the "does not exist" answer is itself cached, for the time named by the zone's SOA record. This is the classic "I just added the record and it's still not found" trap — the absence was cached, and it expires on its own schedule.

A few resolvers also enforce their own floors and ceilings on TTLs, so the tail end of any change is never perfectly uniform. That's normal, and it's why checking from a single machine tells you almost nothing.

Why different places see different answers

Two people asking "the same" resolver often aren't. 8.8.8.8 and 1.1.1.1 are anycast services: the address is announced from hundreds of locations, and each location keeps its own cache. A query from Johannesburg hits a different Google cache than a query from São Paulo — one may have re-fetched your record, the other may serve the old value for another hour. Your laptop adds its own layers on top: the operating system caches, the browser caches, and the office router often runs a forwarding resolver with a cache of its own.

This is why a change can be "done" for half the world and invisible to the other half — and why the only honest answer to "has it propagated?" comes from asking many resolvers from many places, not one resolver from one place.

How to actually verify a change

DNS Doctor's propagation checker does exactly that: it resolves your record from six vantage points on four continents — querying each region's local resolver plus 1.1.1.1 and 8.8.8.8 from within that region, so you see the real per-location cache state — and returns one verdict: propagated, partial, or not yet, with the per-region grid to show which caches still lag.

If you told the checker what value you expect, a partial verdict with a mix of old and new answers is propagation in progress: the regions still showing the old value are serving unexpired cache, and the TTL shown in the grid tells you roughly how long they may keep doing so. Everything old with no sign of the new value usually means the edit didn't take effect at the authoritative servers at all — check it there with the DNS record checker, which queries your authoritative nameservers directly, skipping every cache.

For email records, the fix-then-verify loop matters more than usual: a changed SPF or DMARC record protects nothing until receivers' resolvers actually see it, and an enforcement change made "at the same time" as a policy decision can lag it by hours. Run the change, verify it has reached the world, and only then treat the new policy as live. A free scan reads what a fresh lookup sees right now; the propagation checker tells you whether the rest of the world agrees yet.

The short version

• Nothing pushes DNS changes; caches expire and re-ask. TTL sets the pace.
• Lower TTLs before planned changes; the change itself then lands in minutes.
• "24–48 hours" applies to nameserver moves and unlucky negative caching, not to ordinary record edits.
• One vantage point can't answer "has it propagated" — check from several, or use the propagation checker and read the verdict.