You just updated a DNS record — maybe you pointed your domain at a new host, or changed a mail server. You refresh your browser and... nothing. The old site is still there. Or worse, it works on your phone but not on your laptop. Before you panic and change everything again, what you are experiencing is almost certainly DNS propagation, and checking it properly takes about two minutes.
Despite the name, there is no single "propagation" event where your change travels across the internet like a wave. Here is what really happens.
When you edit a DNS record at your DNS provider, that change is saved on your authoritative nameservers immediately. The delay comes from caching. DNS resolvers all over the world — run by ISPs, companies, and public services — store copies of DNS records so they do not have to ask your nameserver every single time someone visits your site. Each cached copy has an expiration timer called the TTL (time to live), which you set on the record itself.
Until those cached copies expire, different visitors will see different answers. Your neighbor on another ISP might get the new record in minutes while your own connection keeps serving the old one for hours. That inconsistency is what people mean by "propagation in progress." Nothing is broken — the internet is just remembering the old answer for a little while.
The simplest check starts at the source: query your authoritative nameserver directly. If the new value is there, your change was saved correctly and the rest is just waiting on caches.
Use a free DNS lookup tool to view your domain's current records — A, AAAA, CNAME, MX, TXT, and the rest — as seen by public resolvers. Compare what the tool shows against what you intended to set. This immediately separates two very different problems: a record that was never saved correctly, versus a record that is fine but still cached in some locations.
For a quick sanity check on where your domain actually resolves, a domain to IP lookup shows the IP address your domain currently points to. If you just migrated hosts, this tells you in seconds whether the world is seeing the old server or the new one.
If you need background on what each record type does, our guide to DNS records explained covers the common types and when to use them.
A single lookup only tells you what one resolver sees. To check propagation globally, you want to query many resolvers in many locations and compare the answers. When most of them return your new value, propagation is effectively complete.
There are two practical approaches. The manual one: use several public DNS checkers and note the results per location. The more thorough one: query specific public resolvers directly (Google's 8.8.8.8, Cloudflare's 1.1.1.1, Quad9's 9.9.9.9, and a few regional ones) and compare. If you are comfortable with a terminal, you can do this with dig:
dig @8.8.8.8 example.com A +short
dig @1.1.1.1 example.com A +short
dig @9.9.9.9 example.com A +shortIf all three return your new IP, the major public resolvers have picked up the change. If your own ISP's resolver still shows the old value, the problem is local caching on your provider's side — not your DNS configuration.
One common trap: your browser and operating system also cache DNS. Before concluding that propagation is stuck, flush your local DNS cache and test in a private browsing window. Many "propagation problems" turn out to be a stubborn browser cache.
The honest answer is: it depends on your TTL, but usually much less than people fear.
The TTL you set on the record is the maximum time a resolver should cache it. In practice, most DNS changes are visible worldwide within a few minutes to a few hours. The old saying that propagation takes "24 to 48 hours" comes from an era of very long default TTLs and is mostly outdated — though it can still apply if your previous TTL was set to a day or more.
This is why the standard advice for planned migrations is to lower your TTL well in advance. If you know you are moving hosts next week, drop the TTL on the relevant records to something short (say, 300 seconds) at least as long as your old TTL before the move. That way, when you make the actual change, old cached copies expire within minutes instead of hours. After the migration is stable, you can raise the TTL again to reduce query load.
Note that you cannot retroactively shorten caching that is already in progress. Lowering the TTL only affects how long resolvers cache the record from now on. The old value, cached under the old TTL, will live out its full lifetime wherever it was already stored.
Most of the time, patience is the fix. But there are situations where waiting will not help because the configuration itself is wrong. Run through this checklist before you start waiting:
If your records are correct and consistent across public resolvers but your ISP still shows the old value after the TTL has clearly expired, some ISPs simply ignore TTLs and cache longer. There is nothing you can do on your end except wait — or switch your own device to a public resolver like 1.1.1.1 for testing.
Checking DNS propagation is really two checks: first, confirm your authoritative records are correct; second, confirm the rest of the world is picking them up. A free DNS records lookup handles the first part, and comparing a few public resolvers handles the second. Lower your TTL before planned changes, flush your local cache before diagnosing, and remember that an inconsistent result during the first hour is normal — not a sign that something broke.
Query your domain's records with a DNS lookup tool and compare the results against what you set. Then check several public resolvers (8.8.8.8, 1.1.1.1, 9.9.9.9) to see if they all return the new values. When the majority agree, propagation is effectively done.
Cached copies of your old record are still stored by DNS resolvers, your operating system, or your browser. Each cache expires according to the record's TTL. Flush your local DNS cache and try a private browsing window before assuming the change failed.
Usually minutes to a few hours, depending on the TTL of the old record. The "24 to 48 hours" figure is mostly outdated unless your previous TTL was very long. Lowering the TTL before a planned change is the best way to speed things up.
Not retroactively — caches holding the old value will keep it until the old TTL expires. For future changes, lower the TTL on the records at least one old-TTL period before you plan to change them, so cached copies expire quickly when you do.
First verify the record is actually correct in the right DNS zone — check which provider serves your domain and confirm there are no typos or conflicting records. If the authoritative records are right and public resolvers agree, your ISP may be caching longer than the TTL; that resolves on its own.
