What Is DNS Propagation and How Long Does It Take?

You change a DNS record and expect your website to update immediately. Instead, some visitors see the old version, some see the new one, and support tickets arrive from users experiencing issues you can't reproduce yourself. That's DNS propagation — and understanding it removes a lot of confusion when you're migrating hosting, switching DNS providers, or troubleshooting inconsistent behaviour.

What DNS Propagation Actually Is

When you change a DNS record at your authoritative nameserver, the change takes effect there instantly. The problem is that the internet doesn't query your authoritative nameserver every time someone visits your domain — that would be too slow and create too much load.

Instead, DNS results are cached by recursive resolvers (the DNS servers used by your ISP, your company network, or public services like Google's 8.8.8.8 or Cloudflare's 1.1.1.1). These resolvers hold cached copies of DNS records and serve them to users without querying the authoritative nameserver on every request.

DNS propagation is the process of these cached copies expiring and being replaced with the new values from your authoritative nameserver. Until a resolver's cache expires, it serves the old record to all users whose DNS traffic routes through it.

How Long Does It Take?

The honest answer: it depends on your TTL.

TTL (Time to Live) is a value on every DNS record that tells resolvers how long to cache the result, in seconds. When a resolver fetches a DNS record, it holds it for the TTL duration, then fetches a fresh copy. Until the TTL expires, the resolver serves the cached value — even if you've made a change at the authoritative nameserver.

Common TTL values:

If your record has a TTL of 86400 and you make a change, resolvers that cached the old value immediately before your change will continue serving the old result for up to 24 hours.

The "propagation" period is essentially max(remaining cache time across all resolvers). In practice, most resolvers update within a few hours for a 24-hour TTL, because their caches weren't all populated at the same moment.

Why Some Users See the Change Faster Than Others

Different users route through different resolvers. Your home ISP uses one set of resolvers. Your mobile carrier uses another. Google Public DNS, Cloudflare DNS, and corporate networks each have their own caching infrastructure.

Each resolver has its own independently timed cache. One resolver might have cached your old A record 23 hours ago (expiring in 1 hour). Another cached it 2 hours ago (expiring in 22 hours). This is why during propagation, some users see the new IP address and some see the old one — they're hitting different resolvers at different stages of their cache cycle.

This also explains why you might see the new version on your laptop but a colleague across the country still sees the old one.

How to Check Propagation Status

Command Line

Check what a specific resolver is returning:

# Check against Google's resolver
dig @8.8.8.8 yourdomain.com A

# Check against Cloudflare's resolver
dig @1.1.1.1 yourdomain.com A

# Check against your local resolver
dig yourdomain.com A

If these return different values, propagation is still in progress.

Online Tools

whatsmydns.net checks your domain against DNS resolvers in multiple countries and shows which are returning the old value and which have updated. This is the most practical way to see propagation status globally.

DNSChecker.org provides a similar view with a visual map.

Checking Your Authoritative Nameserver Directly

To confirm your change is live at the authoritative source before propagation completes:

# Find your nameservers
dig NS yourdomain.com

# Query the authoritative nameserver directly
dig @ns1.yournameserver.com yourdomain.com A

If the authoritative nameserver returns the new value but resolvers still show the old one, your change is correct — you're just waiting for caches to expire.

How to Speed Up Propagation

The only lever you control is TTL. Lower TTL = faster propagation after a change.

The right approach: Lower your TTL before making a change, not after.

1. In advance of your change (at least one TTL period before), lower the TTL to 300 seconds (5 minutes)
2. Wait for the current TTL to expire across resolvers — after one full TTL period, all caches should have refreshed with the low-TTL value
3. Make your change — now resolvers will cache the new value for only 5 minutes
4. Verify the change is working correctly
5. Raise the TTL back to a normal value (3600 or higher)

If you change the TTL and the change at the same time, some resolvers still hold the old record cached under the old TTL — they won't pick up the new low TTL until their cache expires under the old value.

Common Propagation Scenarios

Migrating Hosting

Changing your A record to point to a new server. With a 24-hour TTL and no pre-lowering, some users will reach the old server for up to 24 hours. Ideal approach: lower TTL to 5 minutes 24+ hours before migration, migrate, verify, then raise TTL.

During the migration window, run both old and new servers simultaneously so users hitting either see a working site.

Switching DNS Providers

Changing NS records at your registrar. NS records typically have long TTLs (48 hours or more) set by the registry, and propagation for NS changes can take longer than for regular record changes. Ensure all records are correctly configured at the new DNS provider before updating NS records.

Domain Transfer

When transferring a domain, NS record propagation follows the same rules. After the transfer completes and NS records update, standard propagation applies.

Propagation Isn't "The Internet Updating"

A common misconception is that propagation involves records being actively pushed to servers around the world. Nothing is actively pushed. It's purely a matter of caches expiring and resolvers fetching fresh data on their next query.

This means there's no way to force global propagation to happen faster (beyond lowering your TTL proactively). It also means that checking "is propagation complete?" really means "have all relevant resolvers' caches expired?"

Monitoring DNS During and After Changes

During a DNS migration or major record change, it's useful to monitor what users are actually seeing — not just what your authoritative nameserver says.

After a change, set up DNS record monitoring to ensure your records remain as intended. DNS records can change unexpectedly (accidental edits, migrations that miss records, provider issues), and monitoring catches these changes the moment they occur.

Domain Monitor monitors your DNS records alongside uptime, SSL, and domain expiry. Create a free account to add DNS monitoring for your domain. For Domain Monitor's DNS monitoring features, see DNS monitoring is here.

For a deeper understanding of DNS records, see A record vs CNAME vs ALIAS, DNS record types explained, and ultimate guide to DNS. If a change you've made still hasn't taken effect after the TTL has passed, see DNS propagation taking too long? What to check first for a systematic diagnosis.

Also in This Series

• What Happens When a Domain Expires? Full Lifecycle Explained
• Domain Grace Period vs Redemption Period vs Pending Delete
• Why Domain Auto-Renew Fails and How to Prevent It
• How to Monitor MX, SPF, DKIM, and DMARC Records
• A Record vs CNAME vs ALIAS: Which Should You Use?