Ask almost anyone who has ever moved a website or changed a mail provider how long it takes for the new settings to “propagate,” and you will get the same answer: 24 to 48 hours. It is repeated in support tickets, hosting control panels, and even some documentation. It is also, for the most part, wrong.
DNS does not propagate — caches expire
DNS is a pull-based system. There is no central push of your new records out to the world. When a resolver asks your authoritative name server for a record, the answer includes a TTL (time-to-live) that tells the resolver how long it may keep that answer in its cache. The “propagation” you are waiting for is really just the time it takes for those cached answers to expire.
If your old record had a TTL of 3600 seconds, then any resolver that looked it up in the last hour will keep serving the old value until that hour elapses. After that, the next query goes back to your authoritative server and picks up the new value. The clock starts when each resolver last fetched the record, not when you made the change.
Lower the TTL before you change
The single most effective thing you can do to make a cutover feel instant is to lower the TTL well in advance. If your current TTL is 86400 (one day), drop it to 300 (five minutes) at least one full day before the change. That way, by the time you swap the record, every resolver is already re-querying you every five minutes, and the new value appears almost everywhere within minutes.
Forgetting this step is why people still believe in the 48-hour rule. With a high TTL and no pre-flush, yes — some resolvers will hold the old answer for up to the original TTL. The fix is operational discipline, not waiting.
Some caches ignore your TTL
A wrinkle: not every cache honors the TTL faithfully. Some ISPs and corporate resolvers override short TTLs with a minimum of their own, partly to reduce load and partly as a defence against fast-flux abuse. That is why a propagation checker that queries many resolvers in parallel is useful — it shows you the real distribution of answers, not the theoretical one.
Run a propagation check from multiple global resolvers right after a change. If 18 of 20 already return the new value, you are effectively done regardless of what the remaining two say.
Negative caching matters too
When a record does not exist, resolvers cache the negative answer (the NXDOMAIN or NODATA) for the SOA minimum TTL. If you are creating a new subdomain that previously returned NXDOMAIN, the old negative answer can linger just like a stale positive one. Check your SOA record’s minimum value — it controls how long “does not exist” is remembered.
The takeaway: propagation is not a mystery timer. It is the sum of TTLs you set, the caches that respect them, and the ones that do not. Plan your TTLs, verify with a multi-resolver check, and the myth stops applying to you.