You change a DNS record, open the domain on your laptop, and it works. Ten minutes later a client messages you: they still see the old site.
Nothing is broken. You’re both looking at the same change at different stages of DNS propagation. Once you know what decides the timing, the wait stops being a mystery and becomes something you can plan around.
What “propagation” actually means
Nothing is pushed around the internet when you save a record. Your DNS provider updates its own nameservers, and that happens almost instantly.
The delay comes from caching. When a visitor opens example.com, their device asks a resolver, usually run by their internet provider or a public service like 1.1.1.1 or 8.8.8.8. The resolver looks up the answer once, then keeps it for a while so it doesn’t have to ask again.
Until that cached copy expires, the resolver keeps handing out the old answer. DNS propagation is simply the time it takes for all those caches around the world to expire and fetch the new record.
TTL decides how long the old answer lives
Every DNS record has a TTL, or time to live, measured in seconds. It tells resolvers how long they may cache the answer.
300 means five minutes. Most caches pick up a change within that window.
3600 means one hour, a common default.
86400 means a full day. A change can take that long to reach everyone.
The important detail: the TTL that matters is the one on the old record, the one already sitting in caches. Lowering the TTL at the same moment you change the record doesn’t help visitors whose resolver cached the old answer an hour ago. As Cloudflare’s TTL docs put it, a longer TTL speeds up lookups but makes updates take longer to go into effect.
So, how long does it take?
It depends on what you changed.
A, CNAME or TXT record at your current DNS provider: usually minutes to a few hours, roughly the old record’s TTL.
A brand-new record that didn’t exist before: often within minutes, since there’s nothing old to expire. Resolvers do cache “not found” answers too, though, so a lookup made just before you added it can linger briefly.
Nameserver change, or moving DNS to a new provider: the slowest kind. Nameserver records are typically cached for much longer, so plan for up to a day or two.
That’s where the familiar “up to 48 hours” comes from. Google’s own Workspace help says DNS changes are generally processed within 48 hours, and sometimes up to 72. In practice, a simple record change is usually done long before that.
Why it’s fast for you and slow for someone else
Two people can get different answers at the same moment because they use different resolvers, and each resolver cached the old record at a different time.
Your phone on mobile data, your laptop on office Wi‑Fi and a client in another country may each ask a different resolver. One might fetch the new record right away, another might still have 50 minutes left on its cache.
There’s also caching closer to home. Browsers and operating systems keep their own short-lived DNS cache, which is why a private window or a different device sometimes shows the new result first.
What you can and can’t speed up
You can’t force every resolver in the world to drop its cache. But you can shorten the wait.
Lower the TTL in advance. A day before a planned change, set the record’s TTL to 300. Once the old, longer TTL has expired, your actual change will spread within minutes.
Flush the public resolvers you can. Google Public DNS has a Flush Cache page that refreshes its cached answer for a domain.
Clear your own caches. Restart the browser, try a private window, or test from your phone on mobile data.
Raise the TTL again afterwards. Once everything works, a longer TTL means fewer lookups and fewer surprises.
What doesn’t help: saving the record again, deleting and re-adding it, or changing it back and forth. Each edit can restart the wait for anyone who caught the in-between value.
How to check where propagation stands
Guessing is the slow part. Our free DNS checker shows what resolvers in different locations return for your domain and compares it with the nameserver that holds the real answer. If most locations show the new value, you’re nearly there.
If none of them do after an hour, propagation probably isn’t the problem. The record may be on the wrong host, or your domain’s nameservers may point at a different provider than the one you edited. Our guide on why a domain redirect isn’t working covers the usual suspects.
What this means when you connect a domain to Redirect Supply
When you connect a domain, you add a few records at your DNS provider: two A records and a www CNAME for a root domain, plus a TXT record that verifies ownership. TTL doesn’t matter here, the default your provider suggests is fine.
Most domains move from Pending to Connected within minutes of adding the correct records. Your rules can be created while you wait and go live as soon as DNS checks out. The HTTPS certificate follows automatically, typically a few minutes later. If a domain stays on Pending, the stuck on Pending guide shows which record is still missing.
The best time to lower a TTL is the day before you need it.
