Check whether your change has propagated
Free, no sign-up — results in seconds.
Propagation is really cache expiry
When you edit a record, the change is live on your authoritative nameservers almost immediately. What takes time is everybody else noticing. Recursive resolvers around the world — at ISPs, mobile networks, offices and public DNS services — keep a copy of each answer for the length of its TTL (time to live). Until that copy expires, they keep handing out the old value.
So “propagation” is not a wave spreading across the internet; it's thousands of independent caches timing out at different moments. That is why one person sees your new website while a colleague in another city still sees the old one.
The three things that control how long it takes
1. The TTL that was on the old record
Resolvers honour the TTL they received with the old answer. If your A record had a TTL of 86,400 seconds (24 hours), some resolvers may serve the old IP for up to a day after you change it — lowering the TTL at the same moment as the change doesn't help resolvers that already cached the old answer.
2. Negative caching
If someone looked up a record before it existed, resolvers cache the “does not exist” answer too. How long they keep it is set by the zone's SOA record (the minimum/negative TTL field). A brand-new subdomain can appear “missing” for a while for this reason.
3. Nameserver changes at the registry
Changing nameservers is a bigger change than editing a record. The registry publishes the new delegation, but the NS records in the parent zone carry their own TTL — often a day or two for generic TLDs such as .com — and resolvers that cached the old delegation keep asking the old nameservers until it expires. This is why nameserver changes are the slowest kind of DNS change.
Why results differ between locations
- Different resolvers cached the old record at different times, so they expire at different times.
- Some resolvers and ISPs enforce a minimum cache time regardless of your TTL.
- Large public resolvers run many separate caches across their data centres.
- Some domains intentionally return different answers by location (geo-DNS, CDNs, load balancers). That looks like “not propagated” but is normal.
How to make future changes propagate faster
- A day or two before a planned move, lower the TTL on the records you will change to something like 300 seconds (5 minutes).
- Wait at least as long as the old TTL so caches pick up the short TTL.
- Make the change. Most resolvers will now refresh within minutes.
- Once everything is confirmed, raise the TTL again (for example to 3,600 seconds) to reduce lookup load.
Checking propagation
A propagation checker asks several large public resolvers for the record and compares the answers. If they all return the new value, most of the internet is likely seeing it too. Our DNS propagation checker queries Google Public DNS, Cloudflare and DNS.SB directly from your browser. See how to check DNS propagation for a step-by-step walkthrough, including command-line methods.
Frequently asked questions
Can I force DNS propagation?
Not across the internet. You can only flush caches you control — your own computer, browser or router. Planning ahead with a low TTL is the only reliable way to speed it up.
Why can I see the new site but my client can't?
Your resolver has already refreshed its cache and theirs hasn't. Ask them to try mobile data, a different network, or flush their local DNS cache.
Does propagation affect email?
Yes. Changes to MX, SPF, DKIM or DMARC records are cached the same way, so some senders may deliver to the old mail server or use the old policy until caches expire.
Planning a move to new hosting? HostFaddy web hosting is backed by South African support — talk to the team before you switch.