How Long Does DNS Propagation Take? Real Timelines by Change

DNS propagation takes as long as the TTL on the old record: usually between five minutes and a day for a normal record change. A record nobody has looked up yet appears almost instantly. Nameserver changes are the slow ones, taking up to 48 hours for .uk and .com domains because the registry's delegation records are cached for two days.

The "up to 48 hours" your host quotes is the worst case for one kind of change, not a rule for every edit. Our free DNS propagation checker queries Cloudflare, Google, AdGuard, Alibaba and NextDNS at the same moment and shows the answer and remaining TTL from each, so you can see exactly where a change has reached. This guide sets out realistic timelines for each type of change and explains how to read those results. For the step-by-step procedure for changing DNS safely, see our DNS propagation explained guide.

The short answer, by type of change

The rest of the article explains where each of those numbers comes from.

Why it's "up to TTL", not "exactly TTL"

Nothing is broadcast when you edit a record. Each recursive resolver (your ISP's, your office's, Google's 8.8.8.8, Cloudflare's 1.1.1.1) fetches your record once and keeps it until its TTL runs out. Every resolver fetched it at a different moment, so each one's cache expires at a different moment.

If your record has a TTL of 3600 seconds:

• A resolver that fetched it 59 minutes before your change updates within a minute.
• A resolver that fetched it one second before your change keeps the old answer for almost a full hour.
• A resolver that never fetched it sees the new value immediately.

So after one full TTL, every resolver that follows the rules has the new value. Most get there sooner.

The TTL that counts is the old one

This catches people out. Suppose your A record has a TTL of 86400 (one day) and you lower it to 300 today, then change the IP ten minutes later. Resolvers that cached the record yesterday are still holding the 86400 version. They won't come back for up to a day, so they never see your lower TTL until it's too late.

The fix is timing: lower the TTL first, wait at least one full old TTL (a day in this example), then make the change. Our guide to pointing a domain to a new host builds this into a migration checklist.

Some resolvers shorten long TTLs

Resolver software usually caps how long it will keep a record, whatever TTL you set. Unbound, a common resolver, defaults to a one-day maximum. BIND defaults to one week. Large public resolvers set their own limits too. A cap only ever shortens the wait. It can't make propagation slower than your TTL.

Some resolvers also implement "serve stale" (RFC 8767), handing out expired answers if they can't reach your nameservers. That only kicks in when your DNS is unreachable, which is one more reason not to switch off old DNS hosting the moment you move.

New records and negative caching

Adding a record that has never existed, such as a new shop.example.co.uk, usually shows up everywhere within seconds. No resolver has anything cached for it.

The exception is a name someone looked up before you created it. The resolver got "no such name" back and cached that answer too. RFC 2308 says the negative answer is cached for the lower of two values in your zone's SOA record: the SOA record's own TTL and its minimum field.

You can see those values with:

dig example.co.uk SOA +noall +answer
# example.co.uk. 3600 IN SOA ns1.host.example. hostmaster.host.example. 2026102001 7200 900 1209600 300
#                ^^^^ SOA TTL                                                                 ^^^ minimum

Here negative answers are cached for 300 seconds. This bites most often when you test a subdomain before creating it, or when a verification service such as Google's or Microsoft's checks for a TXT record before you've added it. If verification fails, wait for the negative TTL and try again.

Nameserver changes: why .uk takes up to two days

Changing nameservers is different from editing a record. You're changing the delegation: the NS records held by the registry in the parent zone, which tell resolvers where your zone lives.

For .uk domains the registry is Nominet. When we queried Nominet's servers in October 2026, the NS records for .uk delegations came back with a TTL of 172,800 seconds: two days. The .com registry uses the same value. Resolvers that cached your old delegation can keep using it for up to 48 hours, which is where the famous "24 to 48 hours" figure comes from.

You can check this yourself:

# Ask a Nominet server directly for your delegation (replace with your domain)
dig example.co.uk NS @nsa.nic.uk +norecurse

# Windows
nslookup -debug -type=NS example.co.uk nsa.nic.uk

The number in the second column (or ttl = on Windows) is the delegation TTL. You can't change it. It's set by the registry.

Things that make nameserver changes go smoothly:

• Keep the old DNS host serving identical records for at least 48 hours. During the overlap some resolvers ask the old servers and some ask the new ones. If both give the same answers, nobody notices.
• Copy every record across first, including DKIM selectors and verification TXT records that automatic imports miss.
• Deal with DNSSEC before you switch. If a DS record is published, remove it and wait for its TTL to pass, or the domain may stop resolving entirely on validating resolvers. See what is DNSSEC.
• Changing registrar isn't changing nameservers. Moving a .uk domain to a new registrar with an IPS tag doesn't touch DNS unless you also change nameservers. Our .uk transfer guide covers that process.

There's one more subtlety. Once a resolver reaches your nameservers, it may then use the NS records published inside your zone, with whatever TTL your old DNS host set there. Different resolver software handles this differently. It's another reason to update the NS records in the old zone to point at the new nameservers, if the old host allows it, and to keep that zone running.

Email changes take longer to settle

Changing MX records follows the same TTL rules, but email adds its own delay. A sending server that looked up your old MX just before the change may deliver to the old provider for up to the TTL. Messages queued for retry may also arrive at the old server later.

In practice:

• Lower the MX TTL a day ahead.
• Keep old mailboxes accessible for a few days after the switch and check them.
• Confirm the new MX values with our MX lookup.

Our MX records explained guide covers priorities and the right values for Google Workspace and Microsoft 365.

How to read a propagation checker

A propagation checker asks several public resolvers the same question at the same time. When you run ours, you'll see one of three results.

All resolvers agree on the new value. You're done as far as major public resolvers are concerned. ISP resolvers will follow within the TTL.

Some show the old value. That's normal during the TTL window. Look at the TTL column: it's the number of seconds that resolver will keep its cached answer. When it reaches zero, it fetches again and gets the new value. Nothing else needs doing.

All show the old value long after the TTL. The change probably isn't live at the source. Query your authoritative nameserver directly to check:

dig www.example.co.uk A @ns1.yourdnshost.example +short

If that shows the old value too, the edit didn't save, you edited the wrong zone (common when the domain's nameservers point to Cloudflare but you edited the record at your registrar), or you changed the record name by mistake. Our DNS lookup tool shows which nameservers are actually authoritative for your domain.

Why results can flip-flop

Large public resolvers use anycast: the same IP address is served from many data centres, and each data centre, sometimes each server, keeps its own cache. Google describes per-machine caches in its front-end pool. So two queries to 8.8.8.8 a minute apart can return different answers during the TTL window. That's caching, not a fault.

Clearing caches you control

You can't flush other people's resolvers, but you can clear your own layers when testing:

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Google Public DNS and Cloudflare's 1.1.1.1 also provide web pages to purge a single name from their caches. Your router may hold its own cache too, and restarting it clears that.

What TTL should you use?

Cloudflare's "Auto" TTL is 300 seconds, which is why changes on Cloudflare-hosted DNS tend to appear quickly. There's no benefit in setting very low TTLs on records that never change. They create more queries and make you more dependent on your DNS host being reachable every minute.

A realistic migration timeline

For a typical small-business website move where you're only changing the A record:

1. Day 1: Check the current TTL on your A record with the DNS propagation checker. Lower it to 300.
2. Day 2 (after one full old TTL): Change the A record to the new host's IP.
3. Day 2, plus 5 to 10 minutes: Most visitors are on the new server. Check the propagation results.
4. Day 3 to 5: Keep the old host running for stragglers, then raise the TTL back to 3600.

If you're changing nameservers instead, add two days of overlap with both DNS hosts serving identical records.

After a migration, it's worth running a free MakeItFlow audit to confirm your DNS, SSL and email records look right from outside. Website Monitoring (Starter plan and up) can then re-scan the site daily or weekly and email you when the score changes, which catches records that go missing afterwards.

FAQ

Is DNS propagation really 48 hours?

Only for nameserver changes on domains like .uk and .com, where the registry caches delegations for two days. A normal record change takes up to the record's TTL, often an hour or less. Many changes appear within minutes.

Why can I see my new site but my customer can't?

You and your customer use different resolvers, and theirs fetched the old record more recently than yours did. It will update once the TTL runs out. Ask them to try mobile data or another network in the meantime.

Can I make DNS propagate faster?

Not after the change has been made. The only real control is lowering the TTL well before the change. You can flush your own device and router caches and use the purge tools from Google and Cloudflare, but you can't flush ISP resolvers.

Does Nominet make .uk changes slower?

Nominet doesn't add a delay to ordinary record edits, because those live on your own DNS host. It's the nameserver delegation, which Nominet publishes with a two-day TTL, that can take up to 48 hours to be seen everywhere.

Why do propagation checkers show different results from different locations?

Each resolver, and often each data centre behind a single anycast address, keeps its own cache that was filled at a different time. During the TTL window some will have the old answer and some the new one. Once the TTL has passed they should all agree.

How do I know if my change saved at all?

Query your authoritative nameserver directly with dig or nslookup, naming the nameserver. If it still returns the old value, the change wasn't made in the zone that is actually live, so check which nameservers your domain uses.