Domains and DNS

How long does DNS propagation take?

“Allow 24 to 48 hours for propagation” is support-desk boilerplate. DNS does not propagate at all — nothing is pushed anywhere. Resolvers cache, caches expire, and the expiry time is a number you set.

A DNS change takes effect as soon as the previous record’s TTL expires in each resolver’s cache — commonly 5 minutes to 1 hour, and at most the TTL you had set before the change. Nothing is broadcast: a resolver simply keeps serving the old answer until its copy expires, then asks again. If you lowered the TTL to 300 seconds a day before the change, the whole world sees the new value within five minutes. Name-server changes are the slower case, because they go through the TLD zone and often carry a TTL of 24 to 48 hours — which is where the myth came from.

Worked out 2026-09-10 (IST) · Standard recursive resolver behaviour; RFC 1035 caching

How long, by what you changed

Realistic timings
Change	Governed by	Typical wait	Worst case
A or AAAA record	The old record’s TTL	5 min – 1 hour	The old TTL exactly
CNAME	The old record’s TTL	5 min – 1 hour	The old TTL
MX record	The old record’s TTL	5 min – 4 hours	The old TTL; mail retries, so little is lost
TXT (SPF, DKIM, verification)	The old record’s TTL	Minutes	The old TTL
Name servers (NS delegation)	TLD zone TTL, often 24–48 h	1–24 hours	About 48 hours
New domain, first delegation	Registry zone publication	Minutes to a few hours	A few hours
DNSSEC key rollover	DS record TTL at the parent	Hours	Up to the parent TTL

The arithmetic

maximum delay = the TTL that was in force before you made the change

average delay ≈ half of that TTL, across many resolvers

a planned cutover = lower TTL → wait one old TTL → change → verify → restore TTL

The new TTL is irrelevant to how fast the change lands. Only the old one matters, because that is the number resolvers were told to trust when they cached the answer you are replacing.

Choosing a TTL

What each TTL is for
TTL	In words	Use it for
300 s	5 minutes	The window around a planned migration
3600 s	1 hour	A sensible default for records that change occasionally
14400 s	4 hours	Stable web and mail records
86400 s	24 hours	Records that never change; also the usual NS TTL

Low TTLs are not free. Every expiry is another query, which adds latency to a first page load, and if your DNS provider goes down a longer TTL is the only thing keeping your site resolvable while it recovers.

Sources: RFC 1034 and RFC 1035 on caching and TTL semantics; RFC 2308 on negative caching.

Check your own numbers

Query A, AAAA, MX, NS, TXT and CNAME records and see what resolvers are answering now.

DNS LookupA, AAAA, MX, NS, TXT and CNAME records, live from the resolver.

Frequently asked

Why do some people see the new site and others still see the old one?

Because each recursive resolver holds its own cache with its own expiry clock. A visitor whose resolver fetched the record one minute before your change waits the full TTL; one whose resolver had nothing cached gets the new answer immediately. It is not a partial rollout, it is many independent caches expiring at different moments.

How do I make a DNS change take effect fast?

Lower the TTL to 300 seconds at least one full old-TTL period before the change - lower it on Monday for a Wednesday cutover. Make the change. Verify. Then raise the TTL back to 3600 or higher, because a permanently low TTL means more queries, slower first loads and no cached fallback if your DNS provider has an outage.

Why did my change take two days when the TTL was 5 minutes?

Almost always because it was a name-server change rather than a record change. NS delegation records live in the TLD zone with their own long TTL, and some ISP resolvers ignore short TTLs and enforce a floor of their own. Changing an A record inside the same DNS provider is fast; moving the whole zone to a different provider is not.

Does flushing my DNS cache help?

It fixes your machine, not your visitors. ipconfig /flushdns on Windows or dscacheutil -flushcache on macOS clears the local stub cache, but the recursive resolver upstream - your ISP, your office, or 8.8.8.8 - still holds its own copy until the TTL expires. Testing against a resolver you have not queried before is a better check.

Need domain and DNS checks inside your own product?

We build WHOIS, RDAP, DNS and SSL lookups as embeddable widgets or a plain JSON API in your branding, wired to your own lead form. Tell us which checks you need and we will send a working demo.