DNS Propagation Time: How Long Does It Take?

The most common question after making a DNS change is: "How long until everyone sees the new record?" The honest answer is "it depends" — but understanding the factors involved lets you predict and control the propagation window with confidence.

Why DNS Propagation Takes Time

The DNS system is a distributed, hierarchical cache. When you update a record in your DNS control panel, the change appears immediately on your authoritative nameserver — the server that holds the official copy of your zone. However, the rest of the internet does not query your authoritative server for every request. Instead, billions of client devices send queries to their nearest recursive resolver (run by ISPs, companies, or public providers like Google and Cloudflare), which caches answers locally to reduce latency and load.

Each cached answer has a TTL — a countdown in seconds after which the resolver must discard the cached copy and fetch a fresh answer from the authoritative server. Until that countdown reaches zero, the resolver serves the cached (potentially old) value to every client that asks. This is why propagation takes time: each resolver around the world operates on its own independent TTL clock.

TTL is set by the zone owner

TTL values are defined in your DNS zone records — you control them. A record with a TTL of 86400 (24 hours) will take up to 24 hours to propagate to all resolvers. A record with a TTL of 300 (5 minutes) will propagate in minutes.

The Role of TTL in Propagation Speed

TTL is the single biggest factor in propagation time. When a resolver caches a record, it stores the TTL at the time of the query. Each second that passes, the resolver decrements the TTL. When the TTL reaches zero, the next query for that record causes the resolver to fetch a fresh copy from the authoritative server.

This means the effective propagation time for any change equals the TTL that was set on the record at the time resolvers last cached it, not the TTL you set after the change. If your record had a TTL of 86400 and a resolver cached it one minute before you made the change, that resolver will continue to serve the old value for up to 86399 more seconds.

bash

# Check the current TTL on a record at Google's resolver
# The number before "IN A" is the remaining TTL in seconds
dig example.com A @8.8.8.8 +noall +answer

# Example output:
# example.com.   3541  IN  A  192.0.2.1
# This resolver will serve the cached record for ~59 more minutes

Typical Propagation Times by Record Type

The table below shows typical propagation windows assuming no pre-change TTL reduction. With a pre-change TTL reduction to 300 seconds, all types propagate in minutes.

Record Type	Typical Default TTL	Propagation Window	Notes
A / AAAA	1–24 hours	1–24 hours	Most common; governs website IP resolution
CNAME	1–24 hours	1–24 hours	Subdomain aliases; same TTL dynamics as A
MX	1–24 hours	1–24 hours	Email routing; test carefully before changing
TXT	1 hour (common)	1–4 hours	SPF, DKIM, domain verification records
NS (within zone)	24–48 hours	Up to 48 hours	Nameserver records; also requires registry delegation
NS (registrar delegation)	Set by TLD registry	24–48 hours	Registry TTL is outside your control
SOA	Varies	Follows NS propagation	Zone authority record; rarely changed directly

The Fastest Propagation Scenario: Minutes

In the best case, propagation completes in under 15 minutes. This happens when:

The TTL was already lowered to 300 seconds or less before the change.
The resolver's cached TTL has recently expired so it fetches a fresh copy immediately.
The change is an A or CNAME record (not an NS change, which involves additional registry propagation).

The Slowest Scenario: Up to 48 Hours

The worst-case propagation window applies to nameserver changes at the registrar. Unlike regular DNS records, NS delegation is stored in the parent zone managed by the TLD registry (.com, .net, .org, etc.), which has its own TTL — often 172800 seconds (48 hours). This TTL is not under your control, so even if you reduce your zone's NS TTL, the registry's delegation TTL governs how long resolvers cache the old nameserver pointers.

Nameserver changes are the slowest

Switching nameservers at your registrar triggers a dual propagation: the registry must update its delegation (up to 48 hours), and then each resolver must flush its cached NS record. Keep both old and new nameservers serving correct records throughout the entire window to avoid downtime.

How to Speed Up DNS Propagation

While you cannot bypass the TTL mechanism itself, you can take steps to reduce the window:

Lower the TTL in advance. At least one full TTL period before the planned change, lower the record's TTL to 300 seconds. Resolvers will adopt the shorter TTL and re-query frequently after the change.
Make the change cleanly. A single correct change propagates faster than multiple corrections. Verify the authoritative answer before declaring the change complete.
Flush your local DNS cache after the change to confirm the new record locally. See the DNS cache flush guide for platform-specific commands.
Use public resolver flush tools. Google and Cloudflare each provide cache-purge tools for their resolvers that can accelerate propagation for users on those services specifically.
Raise the TTL after propagation is confirmed. Once the new record is stable, raise the TTL back to a higher value (3600–86400 seconds) to reduce query load on your nameserver.

bash

# Monitor propagation in real time by watching the TTL decrement
# Run this repeatedly at a public resolver to track progress
dig example.com A @8.8.8.8 +noall +answer

# When the TTL reaches zero, the next query fetches the new record
# Confirm the new value has been picked up:
dig example.com A @8.8.8.8 +short

Geographic Variations in Propagation

Propagation does not happen uniformly around the world. A resolver in one country may have cached your old record at a different time than a resolver in another country, so their TTL clocks are offset. Factors that cause geographic variation include:

Query frequency: High-traffic domains are queried more often, so resolvers refresh their cache more regularly. Low-traffic domains may have longer gaps between cache refreshes.
Resolver minimum TTL floors: Some ISP resolvers enforce a minimum TTL of 300–600 seconds regardless of the value in the record, which can extend propagation slightly beyond what you set.
Anycast routing: Public resolvers like 8.8.8.8 and 1.1.1.1 use anycast, meaning a query from Europe goes to a different physical server than a query from Asia. Each anycast node has its own cache, so different geographic nodes may update at different times.

Use the ShowDNS DNS Propagation Checker to get a real-time view of propagation status across multiple global locations. The DNS Lookup tool lets you query a specific resolver by IP to check regional propagation manually.

What a Healthy Propagation Looks Like

A typical A record change with a pre-reduced TTL of 300 seconds will show the following pattern:

0–5 minutes: Authoritative server returns new value; most public resolvers still serve old value (TTL not yet expired).
5–15 minutes: Public resolvers with recently expired caches start serving new value. Propagation reaches ~50–70% of tested locations.
15–30 minutes: Propagation reaches ~90% of locations. Remaining resolvers are those that cached the record near the start of the TTL window.
30–60 minutes: Full propagation for most resolvers. ISPs with minimum TTL floors may take slightly longer.

Frequently Asked Questions

Why do people say "24–48 hours" for DNS propagation?

The 24–48 hour figure comes from the typical default TTL of 86400 seconds (24 hours) used by many DNS providers, combined with the up-to-48-hour TTL used by TLD registries for NS delegation records. In practice, most record changes propagate far faster if the TTL was already low or was reduced before the change.

Does a higher TTL mean slower propagation?

Yes. A higher TTL means resolvers cache the record for longer, so they will take longer to fetch the updated value after a change. A higher TTL does reduce the number of queries your authoritative server receives, which is a useful trade-off for stable records that rarely change.

If I check propagation immediately after making a change, should I see the new record everywhere?

No. Immediately after a change, only the authoritative nameserver has the new value. Public resolvers will continue to serve their cached copies until the TTL expires. The propagation checker will show a mixed picture for a while, which is normal.

What TTL should I use for records that change often?

For records that change frequently (during migrations, load balancer swaps, etc.), use a TTL of 300–600 seconds. For stable records that rarely change, use 3600–86400 seconds to reduce resolver query load and improve reliability.

Can the same domain propagate at different speeds in different countries?

Yes, because resolvers in different countries cached the old record at different times and their TTL clocks are offset. The DNS Propagation Checker shows exactly which locations have the new value and which are still serving the old one.