DNS Propagation Explained: How Long It Takes and How to Track It

DNS propagation is the process by which changes to a DNS record spread across recursive resolvers worldwide. It is not a fixed waiting period. The timeline is governed by the TTL value on the record you changed, which means a well-planned change can be visible in minutes while a poorly planned one can take a full day.

What Is DNS Propagation?

DNS propagation is the period between the moment a record is updated on the authoritative nameserver and the moment that change is visible to resolvers everywhere. During that window, some resolvers return the new value, and others still return the old one. Both answers are technically valid, because each resolver is working from its own cached copy.

The reason this window exists is that DNS operates on a pull model. No server pushes an update outward, and there is no global queue of pending changes. 

Each recursive resolver holds a cached copy of a record for the number of seconds specified by its TTL. When that timer expires, the resolver discards its copy and queries the authoritative nameserver again, at which point it picks up the new value. A resolver that cached your record one minute before you made the change will keep serving the old value for almost the entire TTL. A resolver that had nothing cached will get the new value immediately.

How Long Does DNS Propagation Take?

The answer you will get most of the time is 24 to 48 hours. Those numbers were true back when registrar and DNS provider defaults were set to 86,400 seconds, a full 24-hour TTL. 

How long DNS propagation takes now depends mostly on the TTL that was in effect when you made the change. With most modern registrars defaulting to 3,600 seconds, most changes are visible to most resolvers within an hour. If the TTL were 300 seconds, the same change would be effectively complete in under 10 minutes.

Nameserver changes are the exception and typically take 12 to 48 hours. Changing your NS records means updating the delegation at the TLD registry level, not just publishing a record on an authoritative nameserver you already control. Registry updates move on their own schedule, and root and TLD nameserver data is cached aggressively by design.

Some ISPs run aggressive caching policies and will serve stale records past the stated TTL. This happens, but it is the exception rather than the rule, and it affects a minority of end users rather than the global resolver population.

What Controls Propagation Speed

Three factors account for nearly all variation in propagation timelines.

TTL (Time to Live). The TTL on a DNS record tells resolvers how long to cache it before fetching a fresh copy. A TTL of 3,600 means resolvers hold the record for one hour before re-querying. A legacy TTL of 86,400 means a full 24-hour wait. The critical detail: the TTL in effect at the time of the change is what resolvers respect during the transition, not the new TTL you publish alongside it. Lowering the TTL at the same moment you change the record does nothing for that change, because resolvers already hold the old record under the old TTL.

Record type. Different record types behave differently in practice. A and AAAA records are queried constantly and are therefore heavily cached, so they often take the full TTL to turn over. TXT records used for SPF, DKIM, and DMARC follow the same TTL logic but tend to be queried on demand at the time mail is received, rather than sitting pre-cached in every resolver, which often makes them appear to update faster. NS changes involve the TLD registry and take longer regardless of the TTL you set.

ISP caching behavior. Some ISPs and enterprise resolvers ignore the published TTL and hold records longer than specified. This is the single largest source of unpredictability in propagation timelines, and it is entirely outside the domain owner’s control. There is no way to force a third-party resolver to drop its cache.

How to Speed Up DNS Propagation

The most effective technique is lowering the TTL before making a planned change, lower the TTL to 300 seconds at least one full old-TTL period before the change. By the time you publish the new value, every resolver that queries your domain is already refreshing its copy every five minutes, so the new record reaches them almost immediately.

Once you have confirmed the new record is propagated, restore the TTL to a normal operating value. A TTL of 3,600 seconds is standard and gives you a reasonable balance between resolver load and future flexibility.

Flushing your local DNS cache is a separate action and is worth doing when you are testing. On Windows, run ipconfig /flushdns. On macOS, run sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder. On Linux with systemd, run sudo systemd-resolve –flush-caches.

Be clear about what this accomplishes. Flushing a local cache only affects the machine you run it on. It does not speed up propagation at your recursive resolver, at your ISP, or anywhere else on the internet. It is a testing tool, not a propagation tool.

DNS Propagation and Email Authentication Records

Email authentication records follow exactly the same propagation rules as any other DNS record. When you publish or update an SPF, DKIM, or DMARC TXT record, the TTL in effect at the time of the change determines how quickly receiving mail servers see the new value.

In practice, initial effects on email delivery at major providers such as Gmail, Outlook, and Yahoo are typically visible within minutes to a few hours of the TTL expiring. Full stabilization across all receivers, including smaller and regional mail providers with longer cache windows, takes up to 24 hours. If you are making SPF changes on a domain with many sending sources, the record itself is often the harder problem than the propagation, and managed SPF for large domains covers how to keep those records within lookup limits while you make changes.

One mistake comes up repeatedly. An administrator publishes a DMARC record, checks for aggregate reports an hour later, sees nothing, and concludes the record did not propagate. Aggregate report data accumulates over a reporting cycle, which is typically 24 hours, and reports are sent after that cycle closes. The absence of reports in the first few hours tells you nothing about whether your record is live. To confirm publication, query the record directly with a DNS check rather than waiting on report data.

How to Check DNS Propagation

Knowing how to check DNS propagation comes down to two things: confirming the record is published correctly at the source, and confirming resolvers have picked it up.

For the first part, use a DNS checker. The tool queries the record and returns the current published value, indicating whether the record was saved correctly and whether the syntax is what you intended. If the lookup returns the old value or nothing at all, the problem is at the authoritative nameserver, not in propagation, and no amount of waiting will fix it.

For the second part, you need visibility across regions. The most straightforward way to check DNS propagation is to query multiple resolvers across different geographic locations at the same time and compare what they return. A DNS propagation checker does this automatically and shows you which resolvers are serving the new record and which are still returning the cached version. A mixed result set is normal mid-propagation and is exactly what you expect to see partway through a TTL window.

If you prefer command-line tools, dig @8.8.8.8 example.com TXT and dig @1.1.1.1 example.com TXT will query two large public resolvers directly. Add +noall +answer for readable output. This gives you a spot check on two resolvers, but it does not give you the regional spread that a propagation checker provides.

When DNS Changes Take Longer Than Expected

Most delayed propagation traces back to one of four causes. The TTL was high at the time of the change and has not yet expired, which is by far the most common. The ISP or corporate resolver you are testing from is caching beyond the specified TTL. The change was made at the wrong DNS level, for example, editing a hosted zone at a provider that is not the one your NS records actually delegate to. Or a nameserver change is still processing at the TLD registry.

In the first two cases, the fix is to wait for the TTL to expire. There is no override. In the third case, no amount of waiting helps, because the record you edited is not the record the world is querying. Confirm which nameservers your domain delegates to before assuming a propagation problem.

SPF changes have one additional failure mode worth separating. If a record is updated but mail still fails authentication after propagation completes, the issue is often the 10-lookup limit rather than caching, especially on domains with many third-party senders. Best SPF flattening tools cover the options for consolidating those lookups. If a change is still not visible after 48 hours, verify with a DNS check that it is actually saved at the authoritative nameserver before escalating to your provider.

DNS Propagation Takes as Long as Your TTL

Propagation is not a waiting game you are subject to; it is a TTL management problem you control. Set your TTL to 300 seconds two days before any planned change, make the change, verify it, then restore the TTL to 3,600. Use a DNS check to confirm the record is published and a Domain propagation checker to confirm resolvers worldwide have picked it up.

Frequently Asked Questions