DNS propagation: how long it takes and why it varies

DNS propagation takes between a few minutes and 48 hours. For most record changes (A, CNAME), the actual wait is 1 to 4 hours. Nameserver changes take longer, the median is 2 to 6 hours, but the 48-hour ceiling is real for some resolver configurations. Two factors control this: the TTL you configured on your records, and the caching behavior of recursive resolvers you do not control. If your site is not responding 2 hours after a nameserver change, that is still within normal range.

What is DNS propagation?

When you update a DNS record, the change is immediate on your authoritative nameserver, the server that holds the official data for your domain. But DNS resolvers across the internet (Cloudflare's 1.1.1.1, Google's 8.8.8.8, your ISP's resolver) have already cached the old value. They will keep serving that old value until the cache expires, which is controlled by the TTL.

The "propagation" period is the window during which different users in different locations get different answers. Someone whose resolver already refreshed its cache sees the new value. Someone whose resolver still has the old value cached sees the old one. This is not an error, it is how DNS was designed to scale across millions of resolvers worldwide.

The flow looks like this: your browser queries a recursive resolver, which checks its cache first. If the cache is still valid (TTL not yet expired), it returns the cached value without asking your authoritative nameserver. If the TTL has expired, it fetches fresh data from your authoritative server and caches the new value for the duration of the new TTL.

The TTL: the parameter that controls propagation speed

TTL (Time To Live) is the number of seconds a DNS resolver is allowed to cache a record before re-querying the authoritative server. It is set on each individual record in your DNS manager.

Examples:

• TTL = 3600 (1 hour): resolvers can keep the old value for up to 1 hour after you make a change.
• TTL = 300 (5 minutes): the maximum cache age is 5 minutes, propagation is nearly immediate.
• TTL = 86400 (24 hours): resolvers can serve stale data for up to 24 hours after your change.

Professional tip: if you know you are planning a DNS change (nameserver migration, IP address change), lower the TTL to 300–600 seconds 24 hours before making the change. After the change is confirmed, raise it back to 3600. This makes the change visible to virtually all resolvers within minutes, not hours.

Default TTL values by DNS provider

Provider	Default TTL	Minimum configurable
Cloudflare (auto)	300	60
AWS Route 53	300	0
Namecheap	1799	60
GoDaddy	600	600
OVH	3600	60

Namecheap's default of 1799 seconds (~30 minutes) is reasonable. OVH's default of 3600 (1 hour) means changes take at least an hour to propagate even for resolvers that respect TTL exactly.

How long does it actually take?

Record type	Typical delay	Maximum
A or AAAA (IP change)	1–4 hours	1 TTL
CNAME	1–4 hours	1 TTL
MX (email routing)	1–8 hours	2 TTLs
TXT	15 minutes–4 hours	1 TTL
NS (nameserver change)	2–6 hours	48 hours
New domain (first registration)	15 minutes–1 hour	N/A

MX changes deserve extra caution. Mail delivery is sensitive to timing, if a sending server queries your MX during propagation and gets no valid response, it may bounce the email rather than retry. Allow 4–8 hours of buffer for MX changes before announcing a new mail address.

Nameserver changes are the longest because they affect the delegation at the TLD registry level (.com, .org, .fr...). The registry itself has a TTL for NS records (commonly 172800 seconds (48 hours) for .com) which is why the "up to 48 hours" warning is accurate even if the median is much shorter. According to propagation measurement data, approximately 50% of global resolvers see nameserver changes within 2 hours, and 95% within 24 hours.

Why propagation varies by country and ISP

Not all resolvers behave the same. Cloudflare (1.1.1.1) and Google (8.8.8.8) generally respect TTL values accurately. ISP resolvers are another matter, some cache DNS responses well beyond the specified TTL, which is technically a protocol violation but is common. Mobile network resolvers in some regions are known to cache aggressively.

Corporate networks with internal DNS resolvers may have their own caching layers with policies that extend cache lifetime further. The result: the same change can be visible from Paris and not from a mobile user in Southeast Asia for several hours after you made it. This is not something you can fix, it is a product of how the global DNS infrastructure operates.

How to check DNS propagation in real time

Online tools: whatsmydns.net and dnschecker.org let you query a specific record type from 20–30 global locations simultaneously. Enter your domain, select the record type (NS, A, MX), and within seconds you see which locations have the new value and which still have the old one. Green means propagated, red means the old cache is still in place.

Command line with dig:

dig A example.com @1.1.1.1

This queries Cloudflare's resolver directly, bypassing your local cache. The ANSWER SECTION shows the current value as seen by Cloudflare. Compare with:

dig A example.com @8.8.8.8

If both return the same new value, propagation is well underway. If they differ, it is still in progress.

An example of what to look for in the output:

;; ANSWER SECTION:
example.com.    299    IN    A    203.0.113.1

The 299 is the remaining TTL on Cloudflare's cached copy, it will re-fetch from your authoritative server in 299 seconds.

How to flush your local DNS cache

Your own machine has a local DNS cache too. Flushing it lets you test the current state of propagation from your own location without waiting for cache expiry.

• Windows: ipconfig /flushdns
• macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
• Linux (systemd): sudo systemd-resolve --flush-caches

This only affects your machine. It does not force a refresh at any other resolver on the internet, those will refresh on their own schedule based on TTL.

Special case: nameserver propagation

Nameserver changes work differently from other record changes. When you update your NS records at the registrar, the registrar writes the new values to the TLD registry database (.com, .org, etc.). The TLD registry then propagates this change to its own root servers. Root servers have TTLs for NS records that are often 172800 seconds (48 hours) for .com domains.

During this window, some resolvers continue to ask your old nameservers for DNS data, while others have already updated and are asking the new ones. Your old nameservers typically keep responding for a while after the transfer, which is why downtime during nameserver changes is unusual if both old and new nameservers have the same records configured.

For the step-by-step process of changing nameservers at your registrar, see how to change nameservers.

Conclusion

If some users can reach your site and others cannot, 4 hours after a DNS change (that is normal. Do not try to "fix" it by making additional changes, which will only reset the propagation timer. Wait it out, monitor with whatsmydns.net or Domain Sentinel's DNS lookup, and give it 24 hours before concluding something went wrong. If after 48 hours a record still has not propagated anywhere, check that your DNS changes were actually saved correctly at the source) that is almost always where the real problem is.