How long DNS propagation takes, and how to check it
Updated 6 min readBy the DNSPeek team
A DNS record change reaches most visitors within the record’s old TTL, which is often 5 minutes to an hour, while a nameserver change can take up to 48 hours because the registry delegation is cached longer. Nothing actually travels: resolvers keep their cached answer until it expires, then ask again. Check progress by asking many public resolvers for the record and comparing their answers with the new value.
What “propagation” really is
When a browser needs example.com, it asks a recursive resolver: your ISP’s, your company’s, or a public one such as Google or Cloudflare. The resolver asks the authoritative nameservers for the domain and caches the answer for as long as the record’s TTL (time to live) allows. Until that cached copy expires, it keeps handing out the old answer, however recently you changed the record.
So “propagation” is just thousands of caches expiring at different times. A resolver that looked up your domain a second before the change keeps the old answer for a full TTL. One that never looked it up gets the new answer immediately. That is why a friend sees the new site while you still see the old one.
How long each kind of change takes
| Change | What limits it | Typical delay |
|---|---|---|
| A, AAAA or CNAME record | The TTL the record had before the change | Minutes to a few hours; 5 minutes or less if you lowered the TTL in advance |
| MX or TXT record (email, SPF, verification) | The old TTL of that record | Same as above |
| Nameservers at the registrar | The TTL of the delegation in the parent zone, often one to two days | Usually hours, up to 48 hours |
| A brand-new record that never existed | Negative caching: the “no such record” answer is cached for the zone’s negative TTL | Up to that negative TTL for resolvers that asked before it existed |
The “24 to 48 hours” figure you see everywhere comes from nameserver changes and from the days when long TTLs were the norm. For an A record change with a 300-second TTL, almost everyone sees the new server within minutes.
What else can make it slower
- You lowered the TTL too late. Lowering the TTL only helps after the old, long TTL has expired from caches. Lower it a day ahead: see Lower your TTL before a migration.
- Local caches. Your operating system and browser cache DNS too. Flush them before deciding that propagation is stuck.
- A forgotten record.
wwwstill points at the old server, or an old AAAA (IPv6) record keeps sending IPv6 visitors there. - A CDN or proxy in front of the site. If Cloudflare or another proxy sits in front, the DNS answer is the CDN’s address and stays the same. The origin setting in the CDN has to change instead, and Cloudflare applies it within seconds, so there is nothing to propagate: check the new server with a preview link instead.
- Resolvers that keep answers longer than the TTL. A few do. They are a minority, which is why you keep the old server running for a day or two after the switch.
How to check DNS propagation
Step 1: Confirm the change on the authoritative nameservers
Query the domain’s own nameservers. If they still return the old value, the record was not saved, and waiting will not help.
Step 2: Ask public resolvers worldwide
Enter the domain and the expected value in the DNS propagation checker to see which resolvers already return it.
Step 3: Check every hostname and record type
Repeat for
www, other subdomains, and AAAA records. A forgotten record is the most common reason a change looks stuck.Step 4: Flush your own caches
Clear the operating system DNS cache and restart the browser before you test the site yourself.
Step 5: Confirm the site answers from the new server
Use Is my domain switched? to check that the domain resolves to the new IP and the site answers there.
Step 6: Get notified instead of refreshing
Turn on DNS propagation alerts for the preview link so DNSPeek checks every few minutes and emails you when the change is done.
Check it from the command line
Ask specific public resolvers directly. The number in the answer section is the remaining TTL of the cached answer, in seconds:
dig @8.8.8.8 example.com A +short
dig @1.1.1.1 example.com A +short
dig @9.9.9.9 example.com A +noall +answerResolve-DnsName -Name example.com -Type A -Server 8.8.8.8
Resolve-DnsName -Name example.com -Type A -Server 1.1.1.1To see what the authoritative nameservers say, without any cache, query them directly. Find them with dig NS example.com +short or the nameserver checker, then run dig @ns1.your-dns-host.com example.com A. If even the authoritative answer is old, the change was not saved.
# Windows
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponderWhen can you call it done?
There is no global switch that flips, so pick a rule. DNSPeek uses this one: propagation is complete when at least 90% of the public resolvers that answered return the new value, and at least half of all resolvers answered. Resolvers that time out are left out, so one unreachable resolver cannot hold you back. The highest TTL still seen tells you how long a stale cache might last. When the new value is a Cloudflare address, any Cloudflare address counts, because Cloudflare gives each region its own edge IP.
The free DNS propagation checker applies that rule to 20 public resolvers, asked from DNSPeek’s server. In the dashboard, a preview link can check 16 resolvers on demand, and on paid plans DNSPeek can alert you by email or webhook when the domain has propagated, then re-run your QA report on the live domain.
Why answers differ between resolvers
Seeing the old address from one resolver and the new one from another is normal halfway through. Each resolver cached the record at a different moment, so each expires at a different moment. Large public resolvers also run many separate caches behind one address, which is why two queries to the same resolver a minute apart can disagree.
Worry only if the split does not move. If the share of new answers stays the same for longer than the old TTL, look for a record that was not changed, a second set of nameservers that still serves the old zone, or a CDN that answers for the domain. The DNS compare tool shows whether two nameservers return different records.
What to do while you wait
Propagation is only stressful if the new server was not checked first. If you opened the site on the new IP with a preview link before switching, the waiting period just means some visitors see the old copy a little longer. Keep both servers serving the same content, avoid content changes on the old one, and look at its access logs: when real visitors stop arriving, it is safe to switch it off.
Propagation troubleshooting checklist
Propagation troubleshooting
- Authoritative nameservers return the new value
- TTL was lowered at least one old TTL before the change
- www and other hostnames updated
- Old AAAA record updated or removed
- CDN origin updated, if a CDN proxies the site
- Local DNS cache flushed, browser restarted
- Most public resolvers return the new value
- Old server kept running until its traffic stops
Frequently asked questions
Why does DNS propagation take 24 to 48 hours?
Mostly it doesn’t any more. That figure comes from nameserver changes, whose delegation is cached for up to two days, and from long TTLs. A record change with a short TTL reaches almost everyone within minutes.
Can I speed up DNS propagation?
Only in advance. Lower the record’s TTL to 300 seconds a day before the change, so caches hold the old answer for at most five minutes. After the change you cannot force other resolvers to drop their cache, but you can flush your own.
Why do I see the old site when others see the new one?
Your resolver or your computer still has the old answer cached. Flush the local DNS cache and restart the browser, or check from a public resolver. Also check that www and any AAAA record point at the new server.
How do I check DNS propagation for free?
Use a propagation checker that asks many public resolvers at once, such as the free DNSPeek DNS propagation checker, or query a few resolvers yourself with dig or nslookup. Compare each answer with the new value you expect.
Can I test the new server before DNS propagates?
Yes. A preview link or a hosts file entry sends requests for your domain to the new IP regardless of DNS. That lets you check the site before the switch, so the waiting period after it carries no risk.