You changed a DNS record ten minutes ago. Your phone shows the new site, your laptop shows the old one, and a client says their email is bouncing. Hosting companies call this "propagation" and tell you to wait up to 48 hours, but nothing is actually propagating: resolvers around the world are holding cached copies of your old records until they expire. Once you understand that, you can plan changes so most visitors see the new records within minutes and nobody sees a broken site.
Key takeaways
- DNS changes are live on your nameservers almost immediately, but resolvers keep serving cached old records until their TTL expires.
- Lower the TTL on records you will change to 300 at least one full old-TTL period before the change, then raise it again afterwards.
- Nameserver changes are slower because the parent zone's TTL is set by the registry, commonly up to two days.
- When moving DNS providers, copy every record, remove the DNSSEC DS record first and keep the old zone active for at least 48 hours.
What "propagation" actually is
When you edit a record at your DNS provider, the change is live on your authoritative nameservers almost immediately. Nothing pushes it out to the rest of the internet.
Instead, every visitor's device asks a recursive resolver (their ISP's, their company's, or a public one like Google's 8.8.8.8 or Cloudflare's 1.1.1.1). The resolver asks your nameservers once, then caches the answer for as long as the record's TTL allows. Until that cached copy expires, the resolver keeps handing out the old answer without asking again.
So "propagation time" is really "the time until every cache holding the old answer expires." That's controlled mostly by a number you set yourself.
TTL: the number that controls the wait
TTL (time to live) is the number of seconds a resolver may cache a record:
www.example.com. 3600 IN A 203.0.113.10
; ^^^^ cache for up to 1 hour
If a resolver fetched this record one minute before you changed it, it may serve the old IP for up to 59 more minutes. Some practical points:
- TTL is a maximum, not a promise. Resolvers can drop records from cache earlier, and many public resolvers apply their own upper caps to very long TTLs.
- The TTL that matters is the one that was cached. Lowering a TTL from 86400 to 300 only helps once resolvers have picked up the new, lower value. Anyone who cached the record at 86400 keeps it for up to a day.
- Lower TTLs mean more queries to your nameservers. With managed DNS that rarely matters for small sites, but there's no reason to keep stable records at 60 seconds forever.
Typical values:
| Situation | TTL |
|---|---|
| Stable records (MX, verification TXT, NS) | 3600 to 86400 |
| Web records that might change | 3600 |
| During a planned migration | 300 |
| Failover setups managed by a provider | 30 to 60 |
The layers of caching
Several caches sit between your nameservers and the visitor, which is why two devices can disagree:
- Browser cache. Browsers keep their own short DNS cache and reuse open connections.
- Operating system cache. Windows, macOS and Linux (with systemd-resolved) cache lookups.
- Router cache. Many home and office routers run a small caching resolver.
- Recursive resolver. The ISP or public resolver, usually the biggest factor.
- Negative cache. If someone looked up a name before it existed, the resolver caches "doesn't exist" for a time based on your zone's SOA record (RFC 2308). Creating a new subdomain can therefore be slow for resolvers that already asked about it.
To clear the local layers when testing:
# Windows
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux with systemd-resolved
resolvectl flush-caches
For public resolvers, Google Public DNS and Cloudflare's 1.1.1.1 both offer web tools to purge a name from their caches. That fixes it for users of those resolvers, but not for ISP resolvers.
Nameserver changes are slower
Changing nameservers at your registrar is a different kind of change. The delegation lives in the parent zone (such as .com), and those NS records have their own TTL, set by the registry, not by you. For many TLDs it's long, commonly up to two days, which is where the "24 to 48 hours" advice comes from.
During that window, some resolvers ask the old provider and some ask the new one. That's harmless if both providers serve identical records. It becomes an outage when the new zone is incomplete or the old provider deletes the zone too early.
There's also a newer wrinkle: resolvers that implement serve-stale (RFC 8767) may keep answering with expired data for a while when they can't reach a domain's nameservers. That's designed to help during outages, but it's another reason to keep the old zone working rather than deleting it on switch day.
How to change DNS records safely
Use this procedure for a server move, a new host or a new CDN.
1. Find the current TTLs
dig www.example.com A +noall +answer
dig example.com MX +noall +answer
The second column is the TTL. Query your authoritative nameserver directly (@ns1.yourprovider.example) to see the configured value rather than a resolver's countdown.
2. Lower the TTL in advance
At least one full old-TTL period before the change, lower the TTL on the records you'll edit to 300. If the current TTL is 86400, do this a day or more ahead.
3. Run the old and new servers in parallel
Make sure the new server is fully working before you point DNS at it. Test it by overriding DNS locally with your hosts file:
# Windows: C:\Windows\System32\drivers\etc\hosts
# macOS/Linux: /etc/hosts
203.0.113.50 example.com www.example.com
Check the site, forms, logins and the TLS certificate. Then remove the hosts entry.
4. Make the change
Update the record. Within roughly the lowered TTL, the large majority of resolvers will be on the new IP. Keep the old server running and serving the site (or redirecting) for at least a day to catch stragglers.
5. Verify from outside your network
dig www.example.com A @8.8.8.8 +short
dig www.example.com A @1.1.1.1 +short
dig www.example.com A @ns1.yourprovider.example +short
All three should agree. Multi-location DNS lookup sites are useful for a broader check.
6. Raise the TTL again
Once everything is stable, put TTLs back to 3600 or higher.
How to change nameservers safely
Moving DNS hosting to a new provider is the riskiest DNS change most businesses make. Follow this order:
-
Copy every record to the new provider: A, AAAA, CNAME, MX, every TXT (SPF, DKIM selectors, DMARC, verification tokens), SRV and CAA. Automatic imports often miss DKIM selectors and subdomains, because providers can't list names they don't know about. Compare against an export from the old provider.
-
Check the new zone before switching by querying the new nameservers directly:
dig example.com MX @new-ns1.provider.example +short dig selector1._domainkey.example.com TXT @new-ns1.provider.example +short -
Handle DNSSEC first. If the domain has a DS record, remove it and wait for its TTL to expire, or use a multi-signer migration. Skipping this is the most common cause of a total outage. See What is DNSSEC.
-
Change the nameservers at the registrar.
-
Keep the old zone active and unchanged for at least 48 hours, longer if you can. Don't cancel the old DNS plan on the same day.
-
Re-enable DNSSEC at the new provider and add its DS record.
Protecting email during DNS changes
Email is where sloppy migrations cause the most damage, because failures are silent: senders get bounces, you get nothing.
- Copy MX records exactly and confirm the priorities.
- Copy SPF, DKIM and DMARC records. A missing DKIM selector at the new provider means mail fails authentication and may land in spam. Our guide to why emails go to spam covers the knock-on effects.
- If you're also changing email providers, lower the MX TTL in advance and keep the old mailboxes accessible for a few days, since some mail will still arrive there.
Check the result
After any DNS change, run a free audit to confirm your A, AAAA, NS, MX, TXT, SOA and CAA records, DNSSEC status and email authentication all look right from the outside. Paid plans can re-scan on a daily or weekly schedule and email you the results, which is a useful safety net for a week after a migration.
Frequently asked questions
How long does DNS propagation take?
For a normal record change, up to the old TTL, which is often an hour or less. Nameserver changes at the registrar are slower because the parent zone's TTL is set by the registry, commonly up to two days. Lowering TTLs ahead of time shortens record changes but not the registry's delegation TTL.
Can I speed up DNS propagation?
You can't force every resolver to refresh, but you can lower TTLs before a change, flush your own device and router caches, and use the purge tools offered by Google Public DNS and Cloudflare's 1.1.1.1. The real fix is planning, so the long cache period has already passed when you switch.
Why does my site work on mobile data but not on Wi-Fi?
They use different resolvers. Your mobile carrier's resolver has fetched the new record, while your Wi-Fi network's resolver or router is still serving its cached copy. Flush the router or wait for the TTL to run out.
Should I set my TTL to 60 seconds permanently?
Usually not. It increases query volume and makes your site more dependent on your DNS provider being reachable at every moment. Keep stable records at an hour or more, and lower them only before planned changes.
What to do next
Before your next DNS change, write down the records you'll touch, check their current TTLs, and lower them a day ahead. For nameserver moves, export the old zone, check for a DS record, and plan to keep the old provider active for two days. For a refresher on what each record does, see DNS records explained.
Sources
Written by the MakeItFlow team
We build the website audit these guides are based on. Every fact is checked against the primary sources listed above and this guide was last reviewed on 21 October 2026 . How we research and check
Check your own site in 30 seconds
Run a free audit covering speed, SEO, DNS, email authentication and security headers — and get a prioritised fix list.
