"It hasn't propagated yet" is the single most repeated, least accurate explanation in DNS troubleshooting. There's no global process called propagation quietly pushing your new record out to the internet on some fixed schedule — there's only caching, and caching has a knob with your name on it that most people never touch. A record you just changed can be live for one visitor and stale for another in the same city, on the same ISP, at the same moment, and the reason is almost always TTL, not distance.

There's no propagation — there's caching, everywhere, independently

DNS is a hierarchy of caches, not a broadcast network. When you update an A record at your registrar or DNS host, that change is authoritative and immediate the moment it saves — the authoritative nameserver will answer with the new value on the very next query it receives. What takes time isn't the change reaching the authoritative server; it's every resolver, browser and operating system on earth that already cached the old answer deciding to ask again. Each of those caches expires independently, on its own clock, set by the TTL (Time To Live) value that was attached to the record before you changed it — not the new TTL you might have just set.

That last detail catches almost everyone: if your A record had a 24-hour TTL and you change both the IP and the TTL at the same moment, resolvers that cached the old record are holding onto it for up to 24 hours from when they cached it, regardless of what the new TTL says. The new, shorter TTL only takes effect on the query that finally happens after the old entry expires. This is why the standard advice for a planned migration is to lower the TTL days in advance — say, from 24 hours down to 300 seconds — wait for the old, long TTL to fully expire everywhere, then make the actual change while the short TTL is in effect, and raise it again once things are stable.

Why the same record looks different from two networks at once

Every recursive resolver — your ISP's, your office router's, Google's 8.8.8.8, Cloudflare's 1.1.1.1, your phone's mobile carrier — maintains its own independent cache. If you changed a record 10 minutes ago and it had a 4-hour TTL, a resolver that queried it 3 hours ago is going to keep serving the old answer for another hour, no matter how fast your authoritative nameserver responds now. A different resolver that happens to query fresh right after your change sees the new value immediately. Two people checking the "same" domain from two different networks, at the same instant, can get genuinely different, both-correct-for-their-cache answers. Neither one is more wrong; they're just reading from caches that filled up at different times.

This is also why ipconfig /flushdns or clearing your browser's DNS cache sometimes appears to "fix" propagation instantly for you specifically — you're not making the change propagate faster, you're just discarding your own local stale copy so your next query has to go ask upstream again. It does nothing for anyone else's cache, which is why "it works for me now" from one person doesn't mean it works for everyone yet.

NS record changes are the slow exception

Most record changes (A, AAAA, CNAME, MX, TXT) are bound by that record's own TTL, typically minutes to a few hours. Changing which nameservers are authoritative for a domain — an NS record change, like moving a domain from one DNS host to another — is genuinely slower and more unpredictable, for a structurally different reason: NS records are cached not just by resolvers but by the parent zone (the TLD's nameservers, e.g. the servers for .com), and that glue typically carries a much longer TTL, often 24-48 hours, set by the registry rather than by you. During that window, some resolvers are still asking the old nameservers, which may or may not still have accurate records, while others have already picked up the new ones. This is the one scenario where "give it 24-48 hours" is genuinely the correct, unavoidable answer rather than a shrug — and it's also why registrars conventionally warn to keep the old DNS host's records intact and unchanged during a nameserver migration, so resolvers still pointed at the old servers keep getting correct answers until they catch up.

What actually determines how long you wait

• The record's TTL before you changed it — the single biggest factor for ordinary record changes. A record cached with a 3600-second TTL two minutes before you changed it will keep serving stale data to that resolver for up to 58 more minutes.
• Whether it's an NS change — governed by the parent zone's TTL on your domain's NS records, not your own DNS host's settings, and typically much longer.
• Negative caching — if a record didn't exist yet when a resolver checked, that "no such record" answer gets cached too, per the SOA record's negative-caching TTL, which can independently delay a newly-created record from appearing even after propagation of everything else is otherwise complete.
• Application-level caching that has nothing to do with DNS — a CDN's edge cache, a browser's own HSTS/connection cache, or an app that resolved a hostname once and pooled the connection can all make a service look "unpropagated" long after every DNS cache involved has correctly updated. This is worth ruling out before blaming DNS at all: query the record directly against an authoritative-adjacent public resolver first.

The TTL trade-off nobody explains up front

A long TTL and a short TTL aren't just "slow updates" versus "fast updates" — they're a genuine trade-off, and picking one without understanding the other side of it is how people end up either stuck waiting on a migration or overloading their own DNS infrastructure. A long TTL (say, 24 hours) means far fewer queries ever reach your authoritative nameservers, because almost every request gets answered from a resolver's cache instead — cheaper, faster for end users on repeat visits, and more resilient if your DNS provider has a brief outage, since cached answers keep working even while the authoritative server is unreachable. The cost is exactly the propagation delay described above: any future change to that record inherits the same long wait.

A short TTL (60-300 seconds) is what you want in the hours around an actual change — a failover, a migration, a load-balancing adjustment — because it caps the maximum staleness window at minutes instead of hours. The cost is that every one of those cache expiries turns back into a real query hitting your authoritative nameservers, which matters if a domain gets meaningful traffic; a large site running a 60-second TTL permanently, rather than just during a migration window, is choosing to pay a continuous DNS query-volume cost for a fast-failover capability it may only need a few times a year. The common, correct pattern is to run a moderate TTL (1-4 hours) as the default, and drop it deliberately in advance of any planned change — which only works if you remember that the drop itself has to propagate under the old TTL before it's actually in effect, which is the same lesson from the opposite direction.

Checking it without guessing

The only reliable way to know what's actually been cached where is to query multiple resolvers directly and compare, rather than trial-and-error refreshing a browser tab. Querying a handful of major public resolvers (Google, Cloudflare, Quad9, your own ISP's) side by side for the same record shows you exactly which ones have picked up the change and which are still serving the old TTL-bound answer — which tells you whether you're actually waiting on propagation or chasing a completely separate problem (a typo in the record, a firewall, an application cache) that looks identical from the outside but has nothing to do with DNS caching at all.