Why propagation happens at all
There is no single database of DNS. Instead, resolvers operated by ISPs, public providers, and companies each keep their own cache of answers to avoid asking your authoritative name servers for every request. When you edit a record, your name server updates immediately, but every resolver that already has the old answer keeps serving it until its cached copy expires. That staggered expiry across the world is what people call propagation.
Because caches expire at different moments, propagation is never a clean switch. One visitor in Tokyo may get the new value while another in Berlin still gets the old one. This is normal and temporary, and it is why a change can look 'live' on your machine but broken for a colleague.
TTL is the dial that controls it
Every record carries a Time To Live (TTL), the number of seconds a resolver is allowed to cache it. A 3600-second TTL means a resolver may serve the old answer for up to an hour after you change it. Lowering the TTL a day before a planned change shrinks that window, so the update rolls out in minutes instead of hours.
You can watch propagation happen by querying your domain from many locations at once. This site's checker does exactly that for A, AAAA, CNAME, MX, TXT, and other records, showing which resolvers already return the new value and which are still catching up.
The chain of caches a change has to cross
A single DNS answer can be cached in several places between your name server and a visitor's browser. First there is the recursive resolver run by the ISP or public provider. Then, for some records, the parent zone that delegates your domain. Finally, the operating system and the browser each keep their own short-lived cache. A change is only truly 'propagated' once every layer that mattered has let its old copy expire.
This layered caching is why flushing your own machine (for example with 'ipconfig /flushdns' on Windows or 'sudo dscacheutil -flushcache' on macOS) can make a change appear for you while a colleague on a different network still sees the old value. Your local cache cleared, but their resolver's did not. A worldwide checker sidesteps local caches entirely by asking many independent resolvers directly.
How to check DNS propagation the right way
The reliable way to judge propagation is to query the record from many geographic locations and compare the answers, rather than reloading your own site and hoping. Enter your domain and pick the record type you changed. When nearly every location returns the new value, the change is effectively live; a handful of stragglers will catch up as their TTL expires.
If a location keeps returning the old value long after the TTL should have elapsed, the problem is usually not propagation. Double-check that you edited the correct record on the authoritative name servers, that there is no conflicting duplicate record, and that your registrar's delegation points at the DNS host you actually edited.
Common DNS propagation myths
The biggest myth is that 'DNS propagation always takes 24 to 48 hours'. For most record edits with a sensible TTL, changes are visible almost everywhere within minutes to a couple of hours. The two-day figure is a worst case that mainly applies to name server (NS) changes, whose delegation is cached at the top-level domain.
Another myth is that you can force the whole internet to update by flushing your cache or paying for a premium plan. You control only your own authoritative records and their TTL; every other resolver expires its cache on its own schedule. Lowering the TTL in advance is the only real lever, and it must be done before the change, not after.