You updated a DNS record an hour ago. Your colleague sees the new value, you see the old one, and the client sees something else entirely. Nothing is broken; you're watching DNS propagation, the period during which cached copies of the old record expire across the world's resolvers at different times.
This guide shows you how to check propagation properly, how to read TTL so you know exactly how long the wait will be, and how to tell "still propagating" apart from "I actually misconfigured the record".
What propagation actually is
DNS changes don't get pushed anywhere. When you update a record, only the domain's authoritative nameservers change. Every other resolver on the planet (your ISP's, Google's, the one in your office router) keeps serving its cached copy until that copy's TTL (Time To Live) expires, then fetches the new value on the next query.
So "propagation" is really just caches expiring on their own schedules. A record with a 3600-second TTL can take up to an hour to converge globally after the change. The often-quoted "up to 48 hours" applies mainly to nameserver (NS) changes at the registrar, which involve TTLs further up the chain that you don't control.
Step 1. Identify what you changed
Propagation behaves differently depending on the record type, so be precise about what's in flight:
- A / AAAA: IP address changes. Governed by the record's own TTL, typically 300-3600 seconds.
- CNAME: alias changes. Same TTL rules, but remember resolution then continues through the target's records too.
- MX / TXT: mail routing and SPF/DKIM/verification records. Same mechanics; mail servers often cache aggressively, so allow the full TTL before declaring email cutover complete.
- NS: nameserver delegation. The slow one. The parent zone (e.g. the
.comservers) caches delegation with TTLs commonly at 48 hours, which is where the two-day figure comes from.
Step 2. Confirm the authoritative servers have the new value
Before checking the world, check the source of truth. If the authoritative nameservers don't have your change, nothing will ever propagate.
# find the authoritative nameservers dig NS example.com +short # query one directly, bypassing all caches dig A example.com @ns1.exampledns.net +short
Wrong value here means the change didn't save, you edited the wrong zone, or your DNS provider has its own internal publishing delay. Fix that first; no amount of waiting helps if the source is wrong.
Step 3. Query multiple public resolvers
Now sample the big public resolvers to see how far the change has spread:
dig A example.com @8.8.8.8 +short # Google dig A example.com @1.1.1.1 +short # Cloudflare dig A example.com @9.9.9.9 +short # Quad9 dig A example.com @208.67.222.222 +short # OpenDNS
A mixed result (some resolvers new, some old) is propagation working exactly as designed. The DNS Lookup tool runs the same query from our infrastructure, which gives you one more vantage point that isn't sitting behind your local network's caches.
On Windows without dig, nslookup example.com 8.8.8.8 does the same job.
Step 4. Check from different geographic locations
Anycast resolvers like 8.8.8.8 are actually fleets of servers worldwide, each with its own cache. The Google node answering you in London may have a different cached copy than the one answering a user in Sydney. So even "checked 8.8.8.8" only tells you about your nearest node.
For a true global picture, use a multi-location propagation checker (DNSChecker and similar services query from dozens of countries), or if you have servers in other regions, run dig from them directly. In practice, once the authoritative servers are correct and two or three major public resolvers agree, the rest of the world follows within one TTL.
Step 5. Verify your TTL settings
TTL tells you exactly how long the worst case is. Read the remaining TTL in any dig response; it's the second column:
$ dig A example.com @8.8.8.8 ;; ANSWER SECTION: example.com. 284 IN A 203.0.113.10
That 284 means this resolver's cached copy expires in 284 seconds, after which it must fetch fresh. Query the authoritative server to see the configured TTL (the full value, since authoritative answers aren't cached copies).
The pro move for planned changes: lower the TTL in advance. Drop it to 300 seconds at least one full old-TTL period before the change, make the change, confirm, then raise it back. This shrinks the propagation window from hours to minutes.
Step 6. Wait, and know when waiting is wrong
Once the authoritative answer is correct, propagation completes on its own. Maximum wait equals the old TTL for ordinary records, up to ~48 hours for NS delegation changes.
Waiting is the wrong move when:
- The authoritative servers show the old value (step 2 failed; the change never landed).
- A resolver still serves the old value long after the TTL has expired. Rare, but some ISP resolvers ignore TTLs and over-cache. Nothing you can do but report it or route around that resolver.
- You changed nameservers and the old and new providers serve different zone contents. Both are "authoritative" during the transition; make sure the zones match before flipping NS, or users will flap between answers. Check which nameservers the registry currently lists with a WHOIS lookup.
Step 7. Clear your local cache to see the update
Your own machine is usually the last cache standing. Once public resolvers show the new value:
# macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder # Windows ipconfig /flushdns # Linux (systemd-resolved) sudo resolvectl flush-caches
Restart the browser too: Chrome and Firefox keep an internal DNS cache, and DoH-enabled browsers may be talking to a resolver you haven't checked.
After the change settles
Propagation checking is a point-in-time activity, but records have a habit of changing again: a teammate's edit, a provider migration, or something less benign. A DNS record drift monitor re-checks your records on a schedule and alerts with a diff when anything moves, so the next change doesn't surprise you. The setup is covered in how to monitor DNS records for drift.
TL;DR
- Know which record type changed: A/CNAME/MX/TXT follow the record TTL; NS changes can take up to 48 hours.
dig NS example.com +short, then query an authoritative server directly. Wrong there = not a propagation problem.- Sample public resolvers:
dig A example.com @8.8.8.8 +short,@1.1.1.1,@9.9.9.9. Mixed answers = propagation in progress. - Check from multiple geographies for the global picture; your nearest anycast node isn't the whole story.
- Read the TTL column in dig output: that's your maximum remaining wait. Lower TTLs ahead of planned changes.
- Flush your OS and browser cache last; your own machine is usually the final holdout.