How long does a DNS change take to take effect?

For any cache that already holds the old record, up to that record's TTL — the number of seconds it was allowed to be cached. A resolver that had never looked the name up gets your new answer immediately; one that cached the old answer keeps serving it until its countdown ends. So the honest answer is 'somewhere between instant and the old TTL', which is why a change with a one-hour TTL can look done for some people and stale for others for up to an hour.

Why does my site work for me but not for other people (or the reverse)?

Because you and they are almost certainly using different resolvers, and each resolver has its own independent copy of the record on its own countdown. Yours may have already expired and fetched the new answer while theirs is still holding the old one — or vice versa. Your own computer and browser also keep short-lived DNS caches on top of that, so even two people 'on the same change' routinely see different things at the same moment. Nothing is broken; the caches are just out of step.

Is DNS propagation real — does my change spread around the world?

Not in the way the word suggests. Nothing is pushed outward from your provider. Your authoritative server has the new record the instant you save it. What you're waiting for is the opposite of spreading: thousands of independent caches that grabbed the old answer forgetting it, each when its own TTL expires. 'Propagation' is really just a lot of separate cache timers reaching zero at different moments — not a wave travelling across the globe.

I lowered my TTL but the change still isn't fast — why?

Because lowering the TTL only affects copies fetched after you lowered it. Any resolver that cached the record under the old, higher TTL will keep honoring that old value until it expires — your new low TTL is invisible to it. That's why the trick is to lower the TTL well in advance, wait out the old value, and only then make the change. Done in the wrong order, lowering the TTL does almost nothing.

How do I check whether my DNS change has gone through?

Ask several independent resolvers the same question and compare their answers. If they all return your new record, the change is effectively live everywhere that matters; if some still show the old one, it's still in flight. That's exactly what the checker on this page does — it queries three separate public resolvers at once and shows you whether they agree.

Why your DNS change hasn't taken effect yet — and how to check

You updated an A record or switched nameservers, refreshed the site, and nothing changed — or worse, it works for you but a colleague still sees the old version. This is normal, and it isn't broken. A DNS change isn't instant because the old answer is cached in countless places across the internet, and each cached copy sticks around until its own timer runs out. Nothing "spreads"; caches simply expire on independent schedules. That single idea explains every confusing thing about DNS changes, including why two people can get different answers at the very same moment.

Why a change isn't instant: TTL is the lever

DNS is built on caching, because the alternative — every device asking an authoritative server every single time — wouldn't scale for a second. So when a resolver (your ISP's, or a public one like 1.1.1.1) looks up your domain, it keeps the answer and reuses it for everyone behind it. How long it's allowed to keep it is set by you, on the record itself, as the TTL — Time To Live, a number of seconds. A record with a TTL of 3600 is telling every resolver, "you may reuse this for an hour before checking again."

That's the whole mechanism behind the delay. When you change the record, your authoritative server updates immediately — but every resolver that already fetched the old value is still inside its TTL window and will keep handing out the old answer until that countdown reaches zero. Only then does it come back to your server and pick up the new record. The TTL isn't a description of how long changes take; it's the actual dial that controls it. A low TTL means caches forget quickly and changes show up fast; a high TTL means they cling to the old answer for longer. Nothing about a DNS change is slow except the caches you told to hold on.

Why "propagation" is the wrong word

Almost everyone calls this "waiting for DNS to propagate," and the word quietly installs the wrong picture in your head. It makes you imagine your change rippling outward from your provider, reaching servers in one region, then the next, like a wave crossing a map. That is not what happens, and believing it leads to fruitless worrying about whether the wave has "reached" a particular country yet.

Nothing is pushed anywhere. Your authoritative server holds the new record the instant you save it — there is no outbound broadcast, no queue of servers being updated one by one. What you're actually waiting on is the exact opposite of spreading: you're waiting for a large number of independent caches that grabbed the old answer to forget it. Each one forgets on its own clock, when its own TTL hits zero, with no coordination between them and no order to it. So "propagation" isn't a process moving steadily toward done; it's a pile of separate deadlines arriving at different times in different places. Once you see it that way, the rest stops being mysterious — including the part that drives people to refresh in two browsers and panic.

Why different people see different answers right now

If caches expire independently, then at any given moment some have already expired and refetched your new record while others are still mid-countdown on the old one. Two people looking at the same instant are really just two caches at different points in their timers. Your resolver might have expired ten minutes ago and shows the new address; your colleague's ISP cached it fresh an hour ago and won't recheck for another fifty minutes. Neither is wrong, and nothing needs fixing — they're simply out of step, which is the natural state of a system with no central clock.

There's an extra layer close to home, too: your own operating system keeps a small DNS cache, and your browser often keeps its own on top of that. So "it works for me" can even mean your laptop is holding an answer your resolver has already moved past. This is why testing a DNS change from a single machine tells you almost nothing — you're sampling one cache out of millions, and it's the one most contaminated by your own previous visits.

Why it sometimes takes far longer than your TTL says

Here's where people get genuinely stuck: they set a 300-second TTL, change the record, and an hour later some resolvers still serve the old one. The usual culprit is the old TTL, not the new one. Lowering a TTL only governs copies fetched after the change; any resolver that cached the record under the previous, higher value keeps honoring that until it expires — your shiny new low TTL is simply invisible to a cache that hasn't rechecked yet. This is the single most common DNS-migration mistake, and it's why the correct sequence is to lower the TTL well in advance, wait out the old value entirely, and only then make the real change. Do it in the other order and the lowered TTL accomplishes almost nothing.

Concretely: say your record has a TTL of 86,400 seconds — a full day. If you want a smooth switch, you drop the TTL to, say, 300 seconds first, then wait at least a full day. That wait is the point: it lets every cache still holding the day-long copy expire and refetch, this time picking up the 300-second value. Only once the whole world is on the short TTL do you make the actual change — and now caches forget it within five minutes instead of a day. Skip the wait, and the resolvers that cached the day-long version sail right past your edit for up to 24 more hours, serving the old answer to everyone behind them. The lowered TTL is a favour you do your future self; it can't reach back and shorten a countdown already running.

Two more reasons a change can outlast your TTL. First, resolvers don't always take your TTL at face value. Many enforce their own caps and floors — a resolver can be configured with a minimum cache time that holds records longer than you intended, or a maximum that refetches sooner, and some networks override TTLs outright. Your TTL is a request, not a command, and a busy resolver optimising its own load may not grant it exactly. Second, if you're creating a name rather than changing one — a new domain or a new subdomain — there's negative caching to contend with: when something looked the name up before it existed, the "this name doesn't exist" answer gets cached too, for a duration the zone itself sets. So a brand-new record can keep coming back as missing for a while after you add it, for precisely the same reason an old record lingers — a cache is holding a now-wrong answer until its timer runs out.

How to actually check propagation

Since the whole problem is that any one cache is unrepresentative, the answer is not to check one — it's to ask several independent resolvers the same question at once and compare. If they all return your new record, the change is effectively live everywhere that counts. If some still show the old answer, it's still in flight, and you now know it's a caching delay rather than a mistake in your settings. That comparison is the only thing that actually tells you where a change stands.

That's what the check below does. It queries three separate public resolvers — on three different networks — in parallel, and shows you whether they agree. All agreeing on your new record is as close to "done" as DNS offers. One honest caveat: if your domain uses a CDN or geographically balanced DNS, different resolvers can legitimately return different addresses at the same time by design — so the check treats "resolves everywhere" as healthy even when the answers vary, and flags only the case where some resolvers can't resolve it at all. For a plain record change, though, the signal is simple: watch them line up.

So when a DNS change seems stuck, don't refresh harder — and don't trust a single device. The change left your provider the moment you saved it; everything after that is just caches counting down. Check across several resolvers, confirm your new record is the one they're converging on, and if it's still mixed, the fix is usually the most unsatisfying one in computing: wait for the old TTL you set earlier to run out. If a check still reports the domain as not resolving anywhere, that's a different problem — our guide on when a site looks fine to you but a check says otherwise covers why a result can disagree with what you see.