DNS propagation and TTL: why your change isn't live yet

The one-sentence version

“Propagation” is the wrong word. DNS changes are not pushed out across the internet in a wave. Your authoritative nameservers serve the new value immediately; the delay is that other resolvers are still holding an older copy they cached earlier, and they will not ask again until that copy's timer runs out.

Why “propagation” is misleading

When you save a record, the servers that are authoritative for your domain have the new value right away. But most of the world does not ask your servers directly. They ask a recursive resolver (their ISP's, or a public one), and that resolver caches whatever it last fetched. Until its cached copy expires, it keeps handing out the old answer without re-checking. There is no central push and no geographic front moving across the map, only a lot of independent caches counting down on their own schedules.

TTL: the cache timer you control

Every record carries a TTL (time to live), a number of seconds. It is the maximum time a resolver may cache that record before discarding it and asking again. It is a ceiling, not a promise: a resolver may drop the record sooner, but never holds it longer.

_dmarc.example.com.   3600   IN   TXT   "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
                      ^^^^
                      TTL in seconds (here, up to 1 hour of caching)

A high TTL (a day) means fewer lookups but slow changes. A low TTL (a few minutes) means changes take hold quickly at the cost of more queries. That trade-off is the whole game.

The trick: lower the TTL before you change anything

If you have a planned change (cutting over to a new mail provider, tightening DMARC), lower the record's TTL ahead of time so resolvers re-fetch sooner once you flip it. The catch trips people up:

• The old record, carrying its old long TTL, is itself already cached. Lowering the TTL today does nothing for a resolver that grabbed the record yesterday at a 24-hour TTL.
• So lower the TTL at least one old-TTL period before the change. Drop it from 86400 to 300, wait up to the old 24 hours for every cache to pick up the lower value, then make the change. Now the cutover clears in five minutes, not a day.

The negative-cache gotcha that bites email setup

There is a second, sneakier delay that hits exactly when you publish a new email-auth record. If a resolver looked up _dmarc.example.com (or a DKIM selector) before you created it, it cached a “does not exist” answer. That negative is cached too, for a duration your SOA record sets, so your live, correct record can read as missing for a while. The fix is patience, or querying your authoritative nameserver directly, which never saw the negative.

Why “propagation checkers” disagree by location

Those tools that show your record live in some cities and not others are not watching a wave cross the planet. Each location queries a different resolver, and those resolvers cached your old record at different moments, so they expire at different moments. A resolver with a cold cache shows the new value instantly. (Genuinely location-aware setups using anycast or geo-routing can also return different answers by design, which is a separate thing entirely.)

Changing a record is fast. Changing nameservers is not.

One important distinction, because they get conflated. Editing a record is bounded by that record's TTL: minutes to a day. Changing your nameservers is a different, slower mechanism, because it edits the delegation up in your TLD's zone (the NS records at the registry), and that delegation carries a TTL the registry sets, commonly 48 hours, which you cannot lower. That is the one change where the multi-day wait is real.

How to check a change is actually live

Do not assume, verify. Query the major public resolvers directly and watch the countdown:

• dig TXT _dmarc.example.com @1.1.1.1 and the same against @8.8.8.8. The TTL in the answer counts down toward zero as the cache ages, then resets to your full value the moment that resolver re-fetches the new record. The reset is your “it is live here” signal.
• Two resolvers agreeing is necessary, not sufficient. Every receiver has its own cache, so a clean read on 1.1.1.1 does not prove a corporate or ISP resolver has caught up.
• For a brand-new record, also query your authoritative nameserver (dig ... @your-ns) to rule out the negative-cache delay above.

Why this matters for your email

A DMARC, SPF, or DKIM change is not live for a given mailbox provider until that provider's resolver cache expires. So do not tighten enforcement and assume it took effect instantly, and do not panic if a change looks like it did nothing for an hour. Lower the TTL first when you can, then confirm with dig before you rely on it.

Common questions

How long does DNS propagation take?

For a record change, up to that record's TTL, usually minutes to a few hours, occasionally a day. For a nameserver change, up to about 48 hours because of the registry's delegation TTL. There is no fixed “propagation time”; it is whatever your TTLs say.

Why does my DNS change show up in some places but not others?

Because different resolvers cached your old record at different times and expire independently. It is not a geographic rollout. A resolver that never cached the old value shows the new one at once.

How do I make DNS changes faster?

Lower the record's TTL at least one old-TTL period before you make the change, so caches re-fetch quickly once you flip it. You cannot speed up a nameserver change the same way; its TTL belongs to the registry.