DNS Propagation: Why Changes Take Time (and How to Speed It Up)

You updated your domain's DNS records. Your registrar confirms the change. But your website still loads the old page, your email still goes to the wrong server, and your colleague in another city sees something completely different from what you see.

This is DNS propagation — and it's the source of more domain-migration frustration than almost any other technical process.

The good news: it's not magic, and it's not entirely out of your control. There's a specific mechanism causing the delay, a lever you can adjust before your next migration to make it dramatically faster, and a way to check exactly how far along propagation is right now.

This guide explains all three.

DNS (Domain Name System) translates domain names like `example.com` into IP addresses like `93.184.216.34`. Every device on the internet uses DNS resolvers — servers that do this translation — and those resolvers cache the answers to avoid looking them up repeatedly.

DNS propagation is the process of those cached answers expiring and being replaced with the new ones after you make a change.

When you update a DNS record — pointing your domain to a new server, adding an MX record for email, changing a CNAME — you're updating the authoritative nameservers for your domain. Those are the servers that hold the definitive answer.

But the internet doesn't check authoritative nameservers for every single DNS query. That would be too slow and too much load. Instead:

1. A resolver (like Google's 8.8.8.8 or your ISP's DNS server) receives a query for your domain 2. It checks its cache — if it has a recent answer, it returns that without contacting the authoritative server 3. If the cache has expired (based on TTL — more on this below), it fetches a fresh answer from the authoritative server

"Propagation" is really just the worldwide process of all these caches expiring and refetching. Different resolvers have different cache ages, so they see the new answer at different times. That's why your colleague in another city might see your new site while you still see the old one — you're being served by different resolvers.

The common answer is "24–48 hours," but that's a ceiling, not an average. Understanding why it takes any time at all comes down to three factors:

1. TTL (Time to Live) Every DNS record has a TTL value — a number in seconds that tells resolvers how long to cache the answer. A TTL of `86400` means resolvers cache the record for 24 hours before asking the authoritative server for a fresh copy. A TTL of `300` means they refresh every 5 minutes.

This is the primary lever controlling propagation time. If your A record has a TTL of `86400` when you make a change, resolvers that just refreshed their cache will hold the old answer for up to 24 hours.

2. Resolver behavior Not all resolvers respect TTL strictly. Some ISP resolvers are known to ignore TTLs and cache records longer than instructed. Large public resolvers (Google DNS, Cloudflare DNS) tend to be more compliant, but ISP resolvers vary widely. This is why propagation is never exactly predictable.

3. The chain of caches DNS queries often pass through multiple levels: your device's local cache → your router's DNS cache → your ISP's resolver → upstream resolvers. Each level can cache independently. Even after upstream resolvers have updated, your router or device may still be serving the old answer from its own local cache.

The "up to 48 hours" estimate assumes a worst-case TTL of 86400 plus some buffer for non-compliant resolvers. In practice, with a TTL of 300 and compliant resolvers, propagation is effectively complete within 10–15 minutes.

Most DNS tutorials treat TTL as an afterthought. It's actually the most actionable thing you control in a migration.

Here's the technique experienced engineers use before any planned domain migration:

Step 1: Lower your TTL 24–48 hours before the migration Change your current DNS records' TTL to a low value — `300` seconds (5 minutes) is a good target. Do this 24–48 hours before the actual migration, so existing caches can expire and resolvers begin using the shorter TTL.

Why wait? Because if your current TTL is 86400 (24 hours), resolvers that just cached your record won't pick up the TTL change for up to 24 hours. You need to wait for those old caches to expire before the short TTL takes effect.

Step 2: Make the DNS change With the short TTL in place, resolvers are now caching your record for only 5 minutes. When you flip the IP address (or CNAME, or MX), the old cached answers expire within 5 minutes. Propagation that would have taken 24 hours now takes 15–30 minutes.

Step 3: Restore the TTL after migration Once you've confirmed the new destination is working correctly, raise the TTL back to a normal value (3600 or 86400). Low TTLs mean more DNS queries, which adds load to your authoritative nameserver and increases latency for users on cold resolvers.

What TTL should you use normally? - `86400` (24 hours) — standard for stable records unlikely to change - `3600` (1 hour) — good balance for most records - `300` (5 minutes) — use temporarily before migrations - `60` or lower — only for active traffic shifting (blue/green deployments, failover)

Check what TTL your records currently have using the DNS lookup tool at myipco.com/dns-lookup.

If your DNS change seems stuck, work through these in order:

Your local cache hasn't expired Your device caches DNS answers independently of resolvers. Even after global propagation completes, your own machine may still have the old answer cached.

Fix: flush your local DNS cache. - Windows: `ipconfig /flushdns` in Command Prompt - macOS: `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder` - Linux: `sudo systemd-resolve --flush-caches` or `sudo service nscd restart` - Browser cache: browsers cache DNS separately. Try a fresh private/incognito window, or clear the DNS cache in Chrome at `chrome://net-internals/#dns`.

Your router is caching the old record Home routers act as local DNS resolvers and cache records themselves. Restarting the router flushes this cache.

Your registrar hasn't updated the zone yet Some registrars have internal propagation delays — the change goes into their system but takes minutes to hours to push to the actual nameservers. Check if the change is visible on the authoritative nameserver directly using the DNS lookup tool.

The TTL was high when you made the change If you didn't pre-lower your TTL, resolvers that recently cached the record will hold it for the full TTL period. You can't speed this up retroactively — you wait or use the lookup tool to check which resolvers have already updated.

Wrong record type changed A common mistake: changing the A record when there's also a CNAME pointing to the domain, or updating one subdomain while forgetting another. Use the DNS lookup tool to check all relevant record types for your domain.

Negative caching (NXDOMAIN) If a resolver queried for your domain before it existed and received NXDOMAIN ("this domain doesn't exist"), that negative response is also cached — for the duration of the SOA record's negative TTL. This can delay new domain registrations from being visible.

You can check whether your DNS changes have reached specific resolvers using the DNS lookup tool at myipco.com/dns-lookup.

Enter your domain and select the record type you changed (A, CNAME, MX, TXT, etc.). The tool queries the authoritative nameservers and returns the current published records — this tells you what the authoritative answer is, which is the source of truth that all resolvers eventually converge to.

What to look for: - If the authoritative answer shows your new record, the change is published. Propagation is a matter of resolver caches expiring. - If the authoritative answer still shows the old record, the change hasn't been picked up from your registrar yet — check your registrar's control panel.

Checking from multiple locations The biggest limitation of any single-location DNS checker is that it only shows you what one resolver sees. Propagation is geographically uneven: resolvers in one country may have updated while resolvers elsewhere still have the old record. Tools like whatsmydns.net complement this by showing resolver results from multiple geographic locations simultaneously.

A practical propagation checklist: 1. Check authoritative answer at myipco.com/dns-lookup — confirms the change is published 2. Flush your local DNS cache (commands above) 3. Test in a private browser window (rules out browser DNS cache) 4. If needed, temporarily switch your device's DNS to 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google) — these update faster than most ISP resolvers

Propagation is technically never "complete" in an absolute sense — resolvers around the world refresh at different times, and some will always be slightly behind. In practice, "complete" means: all major resolvers have the new answer, and normal users are no longer seeing the old one.

For a record with TTL `300`: complete in 10–30 minutes after the authoritative servers update. For a record with TTL `3600`: complete in 1–4 hours. For a record with TTL `86400`: complete in 24–48 hours, with stragglers possibly longer.

Signs propagation is complete: - The DNS lookup tool shows the new record from the authoritative server - Testing from multiple devices on different networks (mobile data vs. home Wi-Fi) shows consistent results - External propagation checkers show green across most geographic regions

One practical tip: don't test exclusively from your own network. Your home ISP's resolver may be slow to update while a mobile network (using different resolvers) has already propagated. Switching to mobile data for a quick test often reveals whether the new record is live globally even when your home connection still sees the old one.

For a broader understanding of how DNS works and what each record type does, the DNS explained guide covers the full picture.