You’ve just updated your DNS records — pointed your domain to a new hosting provider, or changed a nameserver, or updated an A record. You refresh your site and… nothing. The old version is still showing. An hour later, still the same. Two hours in, your colleague in another city says it’s showing the new version, but you’re still seeing the old one. What is going on?

This is DNS propagation — one of the most reliable sources of confusion and frustration in web management. It’s not a bug, it’s not something wrong with your configuration, and it doesn’t mean the change failed. It’s the distributed nature of the internet’s directory system doing exactly what it was designed to do.

This guide explains precisely why propagation happens, what controls how long it takes, how to make it faster when it matters, and how to verify that your changes have reached the rest of the world. By the end, propagation will make complete sense — and the next time you’re waiting for a DNS change to land, you’ll know exactly why and exactly what to do.

1. What DNS Propagation Is

DNS propagation is the process by which a change to a DNS record spreads across the internet’s global network of DNS resolvers and caches until every resolver in the world is returning the updated answer.

When you update a DNS record — say, changing the A record for yoursite.com from an old server IP to a new one — that change is immediately live on your authoritative nameserver. The authoritative nameserver is the definitive source of truth for your domain’s DNS records. The change is made. It’s done. From your authoritative nameserver’s perspective, the update is complete.

The problem is that most internet users don’t query your authoritative nameserver directly. They query a recursive resolver — typically operated by their ISP, or by a public service like Google (8.8.8.8) or Cloudflare (1.1.1.1). These resolvers cache DNS results to reduce load and improve response speed. And once a resolver has cached your old DNS record, it will keep serving that cached answer to everyone who asks — until the cache entry expires.

The Scale of the Problem

There are thousands of recursive DNS resolvers operating around the world — run by ISPs, cloud providers, enterprise networks, and public DNS services. Each one independently caches DNS records according to its own schedule. When you change a DNS record, you have no way to directly notify any of them. You simply update your authoritative nameserver and wait for their cached copies to expire.

2. Why It Takes Time

DNS was designed in 1983, when the internet was small enough that a single text file could list every hostname. The architects who designed DNS made a deliberate decision: resolvers should cache answers to reduce load on the authoritative infrastructure and to keep response times fast for users. That caching is the direct cause of propagation delays.

The Chain of Caches

A DNS query doesn’t just pass through one cache — it passes through several, each with its own expiry schedule:

1. Browser cache — your browser stores recently resolved domain names for a short period (typically 1 minute to 1 hour, depending on the browser)
2. Operating system cache — your computer’s OS maintains its own DNS cache, separate from the browser’s
3. Recursive resolver cache — your ISP’s or chosen DNS provider’s resolver caches answers according to the record’s TTL
4. Intermediate resolvers — large networks may have additional caching layers between the end user and the upstream resolver

For a DNS change to be visible to a particular user, every cache in their specific chain must expire and fetch a fresh answer. A user whose ISP’s resolver cached your record an hour before you made the change may need to wait longer than someone whose resolver happened to re-query just after your update went live.

Why Different People See Different Things

During propagation, it’s completely normal — and expected — for different people in different locations to see different results for the same domain. Someone in Frankfurt might see your new server while someone in Chicago still sees the old one. This isn’t a problem. It’s the natural consequence of a globally distributed cache system where each resolver updates on its own schedule.

3. TTL: The Number That Controls Everything

TTL — Time to Live — is the single most important factor in how long DNS propagation takes. It is a value, measured in seconds, that you set on each DNS record. It tells resolvers exactly how long they are permitted to cache that record before they must re-query the authoritative nameserver for a fresh answer.

A TTL of 86400 means resolvers can cache the record for 86,400 seconds — exactly 24 hours. A TTL of 300 means they can only cache it for 5 minutes before re-querying. The lower the TTL, the faster your DNS changes propagate.

TTL value vs. typical real-world propagation time. Actual times vary depending on resolver behaviour and when the cache was last populated.

TTL Is Not a Guarantee

TTL tells resolvers the maximum time they should cache a record — it doesn’t force them to check immediately when it expires. A resolver might cache slightly longer than the TTL due to implementation quirks. More importantly, the TTL value in effect at the moment you make your change is what matters — if your TTL was 86400 when you updated the record, resolvers that cached the old value just before your change can legitimately hold onto it for up to 24 hours, even if you immediately lower the TTL on the new record.

Default TTL Values

Different registrars and DNS providers set different default TTL values. Common defaults:

• Cloudflare — automatically manages TTL; proxied records use automatic, DNS-only records default to 1 hour
• GoDaddy — 1 hour default (3,600 seconds)
• Namecheap — 30 minutes default (1,800 seconds)
• Route 53 (AWS) — 300 seconds default for new records
• Many cPanel hosts — 14,400 seconds (4 hours) default

4. How Long Propagation Actually Takes

The “24 to 48 hours” figure quoted everywhere is outdated and overly pessimistic for most situations in 2026. Modern DNS infrastructure is faster, TTL defaults have come down, and major public resolvers like Cloudflare’s 1.1.1.1 respect TTLs aggressively. Here’s a more realistic picture.

What Actually Determines the Real-World Time

• Your TTL at the time of the change — the dominant factor by far. A 5-minute TTL means most of the world sees your change within 30–60 minutes. A 24-hour TTL means the slowest resolvers can legitimately take a full day.
• Whether you pre-lowered your TTL — if you lowered it 24+ hours in advance, propagation after the change is fast. If you didn’t, you’re at the mercy of the previous TTL.
• The type of change — changing an A record propagates based on TTL. Changing nameservers involves additional layers of the DNS hierarchy and typically takes longer — nameserver changes must propagate through the TLD registry, which adds a step.
• ISP resolver caching behaviour — some ISPs ignore TTL and cache longer than they should. This is non-compliant behaviour but it exists, and it’s why a small number of users may see stale results even after the TTL should have expired.

5. How to Speed Up Propagation

You can’t force propagation to happen instantly — once a resolver has cached a record, there’s no mechanism to push an update to it directly. But you can take steps that dramatically reduce the waiting time for planned changes.

Step 1: Lower Your TTL Well in Advance

This is the single most effective thing you can do. Before any planned DNS change — a site migration, a nameserver switch, a hosting move — reduce your TTL to a low value and wait for the existing caches to expire before making the change.

The process:

1. Check your current TTL on the records you’ll be changing
2. Reduce the TTL to 300 seconds (5 minutes)
3. Wait at least as long as the old TTL before proceeding — this ensures all resolvers that cached under the old TTL have expired their copies
4. Make your DNS change
5. After the change is confirmed propagated, restore the TTL to a normal value (3,600 or higher)

Step 2: Flush Your Own Cache

Your local browser and OS caches will keep serving old results even after the broader internet has updated. To see the real current state of propagation:

• Browser: open an incognito/private window, or clear browser DNS cache (in Chrome: chrome://net-internals/#dns → Clear host cache)
• Windows: run ipconfig /flushdns in Command Prompt
• macOS: run sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder in Terminal
• Linux: sudo systemd-resolve –flush-caches or restart the nscd service

Step 3: Use a Fast Public DNS Resolver

Switching your device’s DNS to a fast, TTL-respecting resolver like Cloudflare (1.1.1.1) or Google (8.8.8.8) means you’ll see propagated changes faster than users on a slow ISP resolver. This is also useful for testing — if 1.1.1.1 is showing the new record, most of the world likely is too.

6. How to Check Propagation Status

Several free tools let you query DNS resolvers around the world simultaneously and see what value each one is currently returning for your domain. These are invaluable during and after a DNS change.

whatsmydns.net

The most widely used DNS propagation checker. Enter your domain and select the record type (A, AAAA, CNAME, MX, NS, TXT), and it queries resolvers in dozens of locations worldwide and displays a colour-coded map and list showing which are returning the old value and which have the new one. A green result means the updated record, red means the old one is still cached. Simple, fast, and accurate.

dnschecker.org

Similar to whatsmydns.net with a slightly different interface and a different set of global resolver locations. Running your check on both tools gives you a broader picture, since they query different resolvers in different regions.

dig (Command Line)

For technical users, dig is the most precise DNS query tool. You can query specific nameservers directly to see exactly what they’re returning:

# Query your authoritative nameserver directly
dig @ns1.yourhostingprovider.com yoursite.com A

# Query Cloudflare's resolver to check propagation
dig @1.1.1.1 yoursite.com A

# Query Google's resolver
dig @8.8.8.8 yoursite.com A

# Check what TTL is currently being served
dig yoursite.com A +ttlid

Querying your authoritative nameserver directly shows you what the correct answer should be. Querying public resolvers shows you what those resolvers are currently returning. The difference between the two tells you exactly how propagation is progressing.

Google Admin Toolbox

Google’s own DNS diagnostic tool at toolbox.googleapps.com/apps/dig/ lets you perform dig-style queries from Google’s infrastructure. Particularly useful for checking whether Google’s crawlers and indexers will see your updated records — relevant when you’re migrating a site and want to ensure Google sees the new server.

7. Why You See Different Results Than Others

One of the most disorienting aspects of DNS propagation is seeing your updated site while a colleague in another office still sees the old one — or vice versa. This is normal and has straightforward explanations.

Different Resolvers, Different Cache Ages

You and your colleague are almost certainly using different recursive resolvers. Your home ISP uses one resolver; their office network uses another. Each independently caches DNS records on its own schedule. One may have re-queried just after your change went live and has the new value; the other queried 20 minutes before and has the old value cached for several more hours.

Geographic Resolver Differences

Even using the same public resolver (like 1.1.1.1), users in different regions may hit different physical instances of that resolver’s infrastructure — and those instances may have different cache states. Cloudflare’s 1.1.1.1 has servers in hundreds of cities worldwide; a user in Sydney hitting the Sydney instance and a user in Paris hitting the Paris instance may see different cache states for the same record at the same moment.

Your Own Browser Cache

You may be seeing the old version simply because your browser cached the DNS resolution before you made the change. This is the most common reason site owners see stale results long after everyone else reports seeing the new version. Always test in an incognito window and after flushing your OS DNS cache.

8. Propagation During a Site Migration

Site migrations are the highest-stakes DNS propagation scenario — you’re moving a live website from one server to another, and you need to minimise the time visitors hit the wrong server. Here is the complete approach.

The Problem: Two Servers, One Domain

During propagation, some visitors will be directed to your old server and some to the new one. If your old server is offline, visitors directed to it see an error. If content differs between old and new, visitors get inconsistent experiences. The goal is to manage this window carefully.

The Gold Standard Migration Approach

1. At least 24–48 hours before the migration: Lower the TTL on your A record (and any other records pointing to the old server) to 300 seconds. Wait the full current TTL period before proceeding.
2. Before cutting over: Build the new site on the new server and test it by editing your local hosts file to point the domain to the new server IP — you can verify the new site works perfectly without touching DNS.
3. At migration time: Update the A record to the new server’s IP address.
4. Keep the old server running for at least 48–72 hours after the DNS change. Visitors still directed to the old server should see the old content — better a slightly stale page than a 404 error.
5. Monitor using whatsmydns.net to track propagation progress worldwide.
6. After propagation is complete: Restore the TTL to a normal value (3,600 or higher) and decommission the old server.

Testing the New Server Before Going Live

You can access your new hosting server directly using its IP address to verify everything works before updating DNS. Edit your computer’s hosts file to temporarily map your domain to the new server IP — this overrides DNS on your machine only, so you see exactly what the new server serves without any global DNS changes:

# Add to /etc/hosts (macOS/Linux) or C:\Windows\System32\drivers\etc\hosts (Windows)
185.220.101.5   yoursite.com
185.220.101.5   www.yoursite.com

With this in place, your browser will go directly to the new server while the rest of the world still hits the old one. Test everything thoroughly, then remove the hosts file entry and make the DNS change with confidence.

9. Common Propagation Problems and Solutions

Change Seems Stuck After 48 Hours

Cause: A specific resolver is caching beyond the TTL (non-compliant behaviour), your TTL was very high at the time of the change, or the change wasn’t actually saved correctly.

Fix: First, verify the change is correct on your authoritative nameserver by querying it directly with dig. If the authoritative answer is correct, use whatsmydns.net to identify which specific regions are still showing the old value. If it’s isolated to a single ISP or region and more than 48 hours have passed, it’s likely that resolver is ignoring TTL — most users are on compliant resolvers and will see the correct value. The stuck resolver will eventually update.

Site Works for Me But Not Colleagues

Cause: Your local resolver has updated but theirs hasn’t. Normal propagation in progress.

Fix: Ask them to flush their DNS cache and try again, or test using a different DNS resolver (set DNS to 1.1.1.1 temporarily). If the global propagation checkers show the new value for their region, the issue is local to their device or ISP resolver.

Email Stopped Working After Updating Nameservers

Cause: When you changed nameservers to a new provider, the new provider’s DNS zone may not have the same MX records as the old one. Email routing is handled by MX records, and if they weren’t configured on the new nameservers, email delivery fails.

Fix: Log in to your new DNS provider and verify that all MX records are present and correct. This is the most common and most painful consequence of a nameserver change — always audit your complete DNS zone before switching nameservers.

SSL Certificate Showing Errors After DNS Change

Cause: SSL certificates are issued per-server. Moving to a new server means you need a new certificate issued on the new server. Additionally, if DNS hasn’t fully propagated, the CA’s domain validation request may hit the old server and fail, preventing certificate issuance.

Fix: Wait for DNS to fully propagate before attempting to issue a new SSL certificate on the new server. Most certificate authorities validate domain ownership via DNS or HTTP — both require your domain to be pointing at the new server.

10. Migration Propagation Checklist

Use this checklist for any planned DNS change that involves moving a live website or making critical infrastructure updates.

24–48 Hours Before the Change

• Note the current TTL on all records you’ll be changing
• Lower TTL on A record, AAAA record, and CNAME records to 300 seconds
• Lower TTL on MX records to 300 seconds if email routing will change
• Wait the full duration of the original TTL before proceeding
• Verify the new server is built, tested, and ready to receive live traffic

At Migration Time

• Update A record to new server IP address
• Update www CNAME or A record to match
• Update any subdomain records that need to change
• Verify MX records are correct for email delivery
• Begin monitoring propagation on whatsmydns.net

During Propagation

• Keep old server running and serving content
• Do not cancel old hosting account
• Test new site from multiple locations using VPN or whatsmydns.net
• Monitor for any SSL certificate errors on the new server
• Test email delivery to and from the domain

After Propagation Is Complete

• Confirm whatsmydns.net shows new values globally
• Test the site on both root domain and www subdomain
• Verify SSL certificate is valid on the new server
• Restore TTL to normal value (3,600 or higher)
• Keep old server active for at least 72 hours as a precaution
• Cancel old hosting only after the 72-hour window has passed