You changed a DNS record an hour ago, but half your visitors still hit the old server. Nothing is broken — you're watching DNS propagation happen in real time. This guide explains exactly why it happens, how long it really takes, and how to check the status across the globe.
What is DNS propagation?
DNS propagation is the window of time during which a change to your domain's DNS records spreads to DNS resolvers around the world. During that window, some resolvers still return the old answer while others already return the new one.
The word “propagation” is a little misleading. Nothing is actively pushed out to the internet. Your authoritative nameserver simply starts serving a new value, and every other resolver picks it up only when its cached copy of the old value expires. Propagation is really cache expiry happening at thousands of independent resolvers, each on its own schedule.
Why DNS changes aren't instant
When someone visits your site, their device rarely asks your nameserver directly. The request passes through several caching layers, and each one can hold onto an answer:
- The operating system cache on the user's own computer or phone.
- The recursive resolver run by their ISP or a public provider like Google (
8.8.8.8) or Cloudflare (1.1.1.1). - Intermediate caches in routers, corporate networks, and CDNs.
Each cached record carries a TTL (Time To Live) — a number of seconds telling resolvers how long they may reuse the answer before checking again. If your A record has a TTL of 3600, a resolver that fetched it will keep serving the old IP for up to an hour, even after you've made the change. Multiply that across every resolver worldwide and you get the staggered rollout everyone calls propagation.
How long does propagation take?
It depends entirely on which record you change and the TTLs involved. Realistic expectations:
| Change type | Typical TTL | Realistic propagation |
|---|---|---|
| A / AAAA / CNAME (low TTL) | 300–3600s | 5 minutes – 1 hour |
| MX / TXT (mail & verification) | 3600s | Up to a few hours |
| Nameserver (NS) change | Up to 172800s | Up to 24–48 hours |
| New domain / first setup | — | Minutes to a few hours |
The classic “DNS can take up to 48 hours” advice applies mainly to nameserver changes, where TLD registries and long NS TTLs are involved. Everyday record edits on a well-configured zone are usually visible in minutes.
How to check DNS propagation
Because every resolver expires its cache at a different time, checking from your own machine only tells you one data point. To see the real picture you need to query many resolvers in different regions at once and compare the answers to your authoritative nameservers.
- Note the value you expect to see (the new IP, CNAME target, or MX host).
- Query several global public resolvers and compare their responses.
- Query your authoritative nameservers directly — they should always show the new value immediately. If they don't, the change never saved at your DNS host.
- Watch for the moment every location agrees. That's full propagation.
Check your DNS propagation now
Query your domain against DNS resolvers worldwide and see exactly where your change has landed — free, no signup.
Open the DNS Checker →DNS record types at a glance
Knowing which record you're changing tells you what to expect and what it affects:
| Record | Points to | Common use |
|---|---|---|
A | An IPv4 address | Maps a domain to a server |
AAAA | An IPv6 address | IPv6 equivalent of an A record |
CNAME | Another domain name | Aliases (e.g. www → root, or vendor verification) |
MX | A mail server (with priority) | Routes email for the domain |
TXT | Arbitrary text | SPF, DKIM, DMARC, domain verification |
NS | Authoritative nameservers | Delegates who controls the zone |
SOA | Zone metadata | Serial number, refresh & TTL defaults |
How to speed up propagation
You can't force other people's resolvers to update early, but you can make the next change roll out fast:
- Lower the TTL in advance. Drop the record's TTL to
300seconds (5 minutes) at least 24–48 hours before your planned change. Resolvers will then re-cache with the short TTL, so at cutover the old value expires within minutes. - Make the change, then raise the TTL back. Once the new value is confirmed everywhere, restore a longer TTL (e.g.
3600) to reduce lookup load and improve resilience. - Flush your own caches so you can verify quickly:
ipconfig /flushdnson Windows,sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponderon macOS. - Avoid changing nameservers unless necessary. Editing records within your existing DNS host propagates far faster than moving the whole zone to new nameservers.
Troubleshooting common issues
The change shows on some resolvers but not others
This is normal mid-propagation. Give it up to the old TTL to fully clear. If it persists well beyond the TTL, an ISP resolver may be ignoring TTLs (some do) — there's little you can do except wait it out.
Even my authoritative nameservers show the old value
The edit didn't save, or you edited the wrong zone. Confirm you're editing records at the DNS host listed in your domain's current NS records — not an old provider you've since left.
Email started bouncing after an MX change
During MX propagation, mail can hit the old server. Keep the previous mail host active until every resolver shows the new MX, and double-check that your SPF/DKIM TXT records moved too.
My site works but shows the old content
That's often a browser or CDN cache, not DNS. Confirm the resolved IP first with a lookup, then clear the CDN/browser cache separately.