How Long Does DNS Propagation Take? The Short Answer
Most DNS changes show up within minutes to a few hours. A simple A-record change with a short TTL often appears on major public resolvers within 5 minutes. A nameserver change is the slow exception: it can genuinely take 12 to 48 hours to settle everywhere, because the delegation itself is cached by registries and resolvers for up to 48 hours.
The famous "wait 24 to 48 hours" line is not a law of DNS. It is a planning buffer from an era of long default TTLs. In 2026, the real answer depends on one thing above all: the TTL that was cached before you made the change. Nothing you do after editing a record can force a resolver that already cached the old value to forget it early.
This post explains the mechanics in plain language, gives realistic timelines by change type, and shows how to plan a change so it lands in minutes instead of days — plus how to check progress with Nomlen's free DNS checker.
First, "Propagation" Is the Wrong Word
DNS does not push your new record out to servers around the world like a broadcast. When you edit a record at your DNS host, that change is live on your authoritative nameservers almost immediately — usually within seconds to a minute.
What takes time is cache expiry. Recursive resolvers — run by ISPs, Google (8.8.8.8), Cloudflare (1.1.1.1), and corporate networks — have already stored your old record, and they will keep serving it until its Time To Live (TTL) runs out. So different visitors see different answers during the window: your neighbour may reach the new server while you still reach the old one. That staggered, location-by-location expiry is what everyone calls propagation.
Two practical consequences follow:
- You cannot speed up someone else's cache. Flushing your own computer's DNS cache helps only you. There is no global "clear" button.
- The old TTL rules the wait, not the new one. If the old record had a 24-hour TTL and you change it to 60 seconds, resolvers that cached the old value still honour the old 24-hour countdown.
How Long Each Type of Change Takes
The table below gives realistic ranges. "Typical" assumes a sensibly short TTL was set before the change; "worst case" is what happens when a long TTL was cached beforehand.
Change type | Typical time | Worst case | What controls it |
|---|---|---|---|
A / AAAA record (IP change) | 5 minutes – 1 hour | Up to 24 hours | Old TTL on the record |
CNAME record | 5 minutes – 1 hour | Up to 24 hours | Old TTL, plus the target record's TTL |
MX record (mail) | Minutes – a few hours | 24 hours or more | Old TTL; mail servers also cache aggressively |
TXT record (SPF, DKIM, verification) | Minutes – a few hours | Up to 24 hours | Old TTL; verifiers re-query on their own schedule |
New record (never existed before) | Seconds – minutes | Negative-cache time in the SOA record | Only prior "does not exist" answers can delay it |
Nameserver (NS) change | 4 – 24 hours | 24 – 72 hours | Registry delegation TTL, often 24–48 hours |
Why are nameserver changes so much slower? An A-record edit only needs resolvers to expire one cached record. A nameserver change adds layers: your registrar updates the delegation, the TLD registry (for example, .com) publishes it, and resolvers must expire their cached NS entries before they even ask your new provider. Measured in October 2026, the NS TTL published by the .com registry was 172,800 seconds — a full 48 hours — which is exactly where the "up to 48 hours" figure comes from. It is real for NS changes, and misleading for ordinary record edits.
TTL: The One Setting That Decides Everything
TTL is measured in seconds. Common values:
- 60 seconds — used for fast-failover and migration windows; resolvers recheck every minute.
- 300 seconds (5 minutes) — Cloudflare's default for proxied records, and a good general default.
- 3,600 seconds (1 hour) — a common registrar and hosting default.
- 86,400 seconds (24 hours) — for records that almost never change; the source of most "it took all day" stories.
Provider defaults matter more than most people realise. As of October 2026, Cloudflare serves proxied records at a fixed 300-second TTL and allows 60 seconds to one day on DNS-only records, while Amazon Route 53 fixes alias records at 60 seconds. Typical registrar DNS panels, by contrast, commonly default to between one hour and a day — so if you never touched the TTL column, that default is your cutover window whether you intended it or not.
The Zero-Downtime Migration Playbook
1. Lower the TTL at least 24–48 hours before the change
Lowering the TTL only helps if you do it before the old value expires. Drop the records you plan to change to 300 seconds (or 60 seconds for a critical cutover) a full day or two ahead, then wait out the old TTL. Only then make the actual change.
2. Keep the old server running in parallel
During the window, some visitors will still hit the old IP. Keep the old site, app, or mail setup serving valid responses until checks show the new values everywhere. Shutting the old server down early turns a staggered migration into an outage for the stragglers.
3. Make the change, then verify — don't just wait
Query your domain from several public resolvers and from a global checker. If Google's 8.8.8.8 and Cloudflare's 1.1.1.1 both return the new IP, most of the internet will follow within the TTL window. Check with Nomlen's free DNS checker to see your records from multiple angles, and compare against what your DNS host shows.
4. Raise the TTL back after things settle
Once propagation is confirmed, raise stable records back to 3,600 seconds or higher. This cuts query load and protects you against brief DNS-host outages, since resolvers can keep serving the cached good answer longer.
How to Check Propagation Properly
A single lookup from your own laptop proves almost nothing — it reflects your ISP's cache, your operating system's cache, and possibly your browser's cache. Check three layers instead:
- Authoritative answer: query your DNS host's nameservers directly. If they return the new value, your edit is live at the source.
- Public resolvers: compare 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), and 9.9.9.9 (Quad9). Agreement across them means the change has broadly landed.
- Global locations: a multi-location checker shows which regions still serve the old value. A few stragglers late in the window are normal, not a fault.
On the command line, dig example.com A @8.8.8.8 queries Google's resolver directly, and dig example.com A @1.1.1.1 does the same for Cloudflare. Replace example.com with your domain and compare the answers. If you just changed a record and want to rule out your own machine, flush your local cache — ipconfig /flushdns on Windows, or the equivalent resolver flush on macOS and Linux — and try a different network, such as mobile data, before concluding the change has failed.
If you are troubleshooting a related problem — a site that loads on one network but not another, or a "server not found" error after a move — our guides on what flushing your DNS actually does and how to look up who owns a domain cover the neighbouring checks.
When Propagation Seems Stuck: 6 Real Causes
1. The old TTL was long
The most common cause. If the previous record had a 24-hour TTL, some resolvers will legitimately serve the old value for a full day. There is no fix except waiting — and lowering the TTL next time, in advance.
2. Your local cache is lying to you
Your operating system, browser, and home router can each cache DNS. If global checkers show the new value but your laptop shows the old one, flush local caches and test on mobile data before touching the DNS settings again.
3. The nameserver change hasn't reached the registry yet
After changing nameservers at your registrar, confirm the delegation itself: the TLD's nameservers must point at your new provider. If they still list the old provider, the change is stuck at the registrar step, not in propagation.
4. A stale record at the old provider is still answering
During a nameserver migration, resolvers that still use the old delegation ask the old provider. If the old zone still exists with old values, those visitors keep getting old answers until the delegation cache expires. This is expected — another reason to keep old and new in sync during the window.
5. Negative caching for brand-new records
If someone queried a hostname before it existed, resolvers cached the "does not exist" answer for the negative-cache duration in your zone's SOA record (often 30 minutes to an hour, sometimes longer). A brand-new subdomain can therefore look delayed even though nothing is wrong.
6. Your network redirects DNS queries
Some ISPs and corporate networks intercept DNS traffic and force it through their own resolver, so switching to 8.8.8.8 in your settings changes nothing. In that case, use a web-based checker or a different connection to get an honest reading.
Propagation Times for Common Scenarios
Putting it together, here is what to tell your team — or yourself — before each kind of change:
- Pointing a domain at a new host (A record, TTL pre-lowered): expect most visitors on the new server within an hour, effectively complete within the old TTL.
- Switching DNS providers (NS change): plan for a full day, budget 48 hours, and do not decommission anything for 72 hours.
- Adding email authentication (TXT/SPF/DKIM): usually visible within minutes to a few hours, but allow a day before declaring a verification failure — some verifiers check infrequently.
- Launching a brand-new domain: often resolving within minutes to two hours; the long tail is resolver caching of the fresh delegation, not a problem with the registration.
FAQs
How long does DNS propagation take in 2026?
Most record changes take minutes to a few hours, depending on the old TTL. Nameserver changes take 12 to 48 hours, and occasionally up to 72 hours, because the TLD registry caches the delegation for up to 48 hours.
Can I speed up DNS propagation?
Not after the fact. You can only shorten the wait by lowering the TTL 24 to 48 hours before the change. Once resolvers have cached the old value, they will serve it until its TTL expires.
Why does my site work on my phone but not my laptop?
Different networks use different resolvers with different cache states. Your phone on mobile data may query a resolver that already expired the old record, while your laptop's network still serves the cached old one. This staggered state is normal during propagation.
Does flushing my DNS cache speed up propagation?
Only for your own device. Flushing clears your local cache so your next lookup fetches fresh data, but it has no effect on any other visitor's resolver.
How do I know propagation is complete?
When authoritative nameservers, major public resolvers (8.8.8.8, 1.1.1.1, 9.9.9.9), and global location checkers all return the new value, propagation is effectively complete. A few obscure resolvers may lag, but they serve a negligible share of traffic.
Do I need to wait 48 hours after changing nameservers?
Plan as if you do, even if most traffic moves sooner. The .com registry's NS TTL is 48 hours, so some resolvers can legitimately use the old delegation for that long. Keep the old setup running for the full window.
Why is my new subdomain not resolving?
Either the record is not yet live at your authoritative nameservers, or a resolver cached a "does not exist" answer before you created it. Check the authoritative answer first; if it is correct, wait out the negative-cache period, typically under an hour.
Does changing DNS affect my email?
Only if you change MX records or nameservers. An A-record change for your website does not touch mail routing, but a nameserver change moves every record type to the new provider — so make sure MX, SPF, DKIM, and DMARC records exist at the new provider before switching.
