How Long Does DNS Propagation Take (and How to Speed It Up)
You changed a DNS record — moved the site to a new server, switched mail providers, pointed the domain at Cloudflare — and now some people see the new site and others the old one. Hosting companies usually say "allow 24–48 hours for DNS propagation". The real answer depends on what you changed and on one number you can control: the TTL. With some preparation, a typical record change takes minutes, not days.
What "propagation" really is
Nothing is actually pushed around the internet. When you save a record, your DNS provider's authoritative nameservers start returning the new value almost immediately. The delay comes from caches. Every resolver that looked up your domain before — your ISP's DNS, Google Public DNS, Cloudflare 1.1.1.1, your office router, your operating system, your browser — keeps the old answer until its cached copy expires, and only then asks again. "Waiting for propagation" really means waiting for those caches to run out.
TTL: the number that sets the wait
Each DNS record has a TTL (time to live) in seconds. It tells resolvers how long they may keep the answer. A record with TTL 3600 can be served from cache for up to an hour after it was fetched; with TTL 86400 — up to a day.
| TTL | How long an old answer can live | Where you typically see it |
|---|---|---|
| 60–300 | 1–5 minutes | Records prepared for a move, load balancing, Cloudflare proxied records |
| 3600 | Up to an hour | A common default at registrars and hosts |
| 14400–86400 | 4–24 hours | MX, TXT and older zones nobody has touched |
| 172800 | Up to 2 days | NS delegation for .com, .net and many other zones |
The catch: resolvers keep the old TTL, not the new one. If the record had TTL 86400 and you lowered it to 300 at the same moment you changed the IP, a resolver that fetched it yesterday still holds the old value — with the old 24-hour lifetime — until that runs out. It learns the new TTL only on its next query.
Why "24–48 hours" is only a rule of thumb
The figure comes from the worst case. Nameserver delegation for popular TLDs such as .com is published with a TTL of two days, and some long-TTL records stay cached for a day. Add resolvers that impose their own minimum cache time or serve expired answers when they cannot reach your servers, and "up to 48 hours" became the safe thing for support teams to say. For an ordinary A record change with a 300–3600 second TTL, most of the internet usually sees the new value within minutes to an hour. Nobody can promise an exact time for every network, because some resolvers do not strictly follow TTLs.
Record changes vs nameserver changes
These are two different operations, and they propagate differently.
- Changing a record (A, AAAA, CNAME, MX, TXT) inside the zone you already use: the wait equals that record's old TTL. You control it fully.
- Changing nameservers (moving DNS to another provider, adding a domain to Cloudflare): you edit the NS records at the registrar, the registrar passes them to the TLD registry, and resolvers that already know the old delegation keep it until the TTL of the NS records in the parent zone expires — up to two days for .com. You do not control that TTL.
The safe way to change nameservers is to make the zone identical on both providers before switching: copy every A, AAAA, CNAME, MX and TXT record (including SPF, DKIM and site verification strings), switch NS at the registrar, and keep the old zone for at least two days. Then it does not matter which provider a resolver asks — the answer is correct. If DNSSEC is enabled, plan the DS record change with both providers' instructions in hand: a DS record that does not match the new provider's keys makes the domain fail for validating resolvers.
Negative caching: when "not found" is cached too
If someone looked up new.example.com before you created it, resolvers cached the "does not exist" (NXDOMAIN) answer. How long they keep it is set by the zone's SOA record — the lower of the SOA record's own TTL and its minimum field. So create records first and test them second; looking up a name "to see if it works yet" before it exists can make you wait longer.
How to speed it up: lower the TTL in advance
- A day or more before the change, lower the TTL on the records you plan to change (for example, the A and AAAA records) to 300 seconds.
- Wait out the old TTL. Check that public resolvers no longer report a TTL above 300 for those records.
- Make the change. Most resolvers will pick up the new value within about five minutes.
- Keep the old server running for at least a day. Some ISPs and corporate networks ignore short TTLs and will keep sending visitors there for a while. For mail, the old server must keep accepting messages at least for the old MX TTL — check the new records with the MX lookup.
- Raise the TTL back to 3600 or more once everything is stable, to reduce query load and gain resilience.
Local caches: flush them before you panic
Often the internet is already updated and only your own machine is behind. Clear the caches between you and the resolver:
| Where | Command or action |
|---|---|
| Windows | ipconfig /flushdns in Command Prompt run as administrator |
| macOS | sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder |
| Linux with systemd-resolved | resolvectl flush-caches |
| Chrome, Edge | chrome://net-internals/#dns → "Clear host cache"; then #sockets → "Flush socket pools" |
| Firefox | about:networking#dns → "Clear DNS Cache" |
| Router | Restart it; many home routers keep their own DNS cache |
Also check the hosts file (C:\Windows\System32\drivers\etc\hosts or /etc/hosts): a forgotten line there overrides any DNS. And if the browser uses its own "secure DNS" provider, the browser and the command line may disagree. Google Public DNS and Cloudflare 1.1.1.1 have web pages for requesting a cache refresh for a specific name; your ISP's cache cannot be cleared that way, but you can switch your device to a public resolver for a while.
How to check DNS propagation
Use the DNS propagation checker. It queries a set of public DNS-over-HTTPS resolvers and your zone's authoritative nameservers side by side. Read it like this:
- Authoritative nameservers show the new value, some public resolvers the old one — everything is configured correctly; those resolvers are waiting out their TTL. The remaining TTL in each row tells you roughly how long.
- Authoritative nameservers still show the old value — the change was not saved, was made in the wrong zone, or you are editing DNS at a provider the domain does not use. Check the NS records and the registrar data in a WHOIS lookup.
- Authoritative nameservers disagree with each other — the zone is out of sync between them, a provider-side problem.
From the command line, dig example.com @8.8.8.8 asks one public resolver, and dig example.com @ns1.your-dns-provider.com asks your authoritative server directly. To see every record of the domain at once, use the DNS lookup, and to confirm which IP the site resolves to, the domain to IP lookup. The record types themselves are explained in checking domain DNS records, and practical ways to find a site's address are in how to find the IP address of a website.