DNS Propagation: How Long It Takes & How to Check

The Problem: Why DNS Changes Are Not Instant

When you point your domain to a new IP address, you might expect the change to take effect immediately - after all, you made the change at your registrar seconds ago. But your users are not querying your registrar directly. They are querying a chain of caches, and each cache has its own expiry timer. Until every cache in the chain expires and fetches the new record, different users around the world will see different answers for the same domain.

This is not a bug. It is how DNS is designed to be scalable. Without caching, every DNS query for google.com would travel all the way to Google's authoritative nameservers - billions of times a day. Caching distributes that load across millions of resolvers worldwide.

The downside is propagation delay: after you make a change, it can take anywhere from a few minutes to 48 hours for the new record to be visible everywhere on the internet.

The DNS Caching Hierarchy

DNS queries are cached at multiple independent layers. Each layer has its own TTL (Time to Live) counter:

Layer 1: Your Browser

Modern browsers cache DNS responses for a short time (typically 60 seconds in Chrome, up to the record TTL in Firefox). Browser caching rarely causes problems because the cache expires quickly, but it can confuse developers testing changes on their own machine.

# Clear Chrome DNS cache
chrome://net-internals/#dns  → click "Clear host cache"

# Clear Firefox DNS cache
about:networking#dns  → click "Clear DNS Cache"

Layer 2: Operating System Resolver

Your OS maintains its own DNS cache, separate from the browser. This cache respects the record's TTL value. It is a common source of confusion: even after clearing your browser cache, the OS cache can still serve stale data.

# Flush DNS cache on macOS
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

# Flush DNS cache on Windows
ipconfig /flushdns

# Flush DNS cache on Linux (systemd-resolved)
sudo systemd-resolve --flush-caches

Layer 3: ISP / Recursive Resolver

This is the most significant caching layer. Your ISP or the resolver you use (8.8.8.8, 1.1.1.1, etc.) caches DNS records for the duration specified by the record's TTL. If your A record has a TTL of 3600 seconds (1 hour), the ISP resolver will not re-query your authoritative nameserver for up to one hour after it first fetches the record. This is the primary source of propagation delay.

Layer 4: Authoritative Nameservers

These are the nameservers operated by your DNS provider (Cloudflare, Route53, GoDaddy, etc.). Changes here are immediate - the moment you save a record, your authoritative nameservers serve the new value. The delay comes from all the recursive resolvers worldwide that have cached the old value and will not re-query until their cache expires.

The old saying “DNS propagation takes 24-48 hours” comes from the era when most DNS records had TTLs of 86400 seconds (24 hours). With modern best practices (TTL 300-3600), propagation typically completes in 15-60 minutes.

Step-by-Step: How to Speed Up DNS Propagation

You cannot force the world's resolvers to flush their caches. But you can dramatically reduce the maximum wait time with this procedure:

1. Lower your TTL 24-48 hours before the change. Reduce the TTL on the record you plan to change to 300 seconds (5 minutes). You must do this in advance because existing caches will hold the old TTL value until it expires.
2. Wait for the old TTL to expire. Once you lower the TTL, wait for the old TTL period to pass. If the old TTL was 3600 seconds, wait at least 1 hour before proceeding.
3. Make the DNS change. Update the record to the new value. Because the TTL is now 300 seconds, resolvers worldwide will fetch the new value within 5 minutes of their cached entry expiring.
4. Monitor propagation. Use propagation checkers to watch the new value spread (see below).
5. Raise TTL back to normal. After confirming the new record is globally visible and stable, set the TTL back to a sensible value (3600 for most records, 86400 for rarely-changing records).

How to Check DNS Propagation Status

Using dig (Command Line)

The most reliable method for developers. Query specific resolvers directly to see what they currently have cached:

# Query Cloudflare's resolver
dig @1.1.1.1 example.com A

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

# Query your ISP's resolver (default)
dig example.com A

# Check the TTL remaining in cache (look for the number before "IN A")
# example.com.  298  IN  A  93.184.216.34
#               ^^^
#               298 seconds remaining in cache

Using nslookup (Windows/macOS/Linux)

nslookup example.com 1.1.1.1
nslookup example.com 8.8.8.8
nslookup -type=MX example.com

Using Online Propagation Checkers

These services query dozens of resolvers around the world simultaneously and show you which regions see the new record:

• whatsmydns.net - queries 23 global locations
• dnschecker.org - 100+ locations, supports all record types
• viewdns.info - includes propagation history
• SecureBin DNS Lookup - query any record type for any domain instantly

Common DNS Record Types and Typical Propagation Times

• A record (IPv4 address): Propagates based on TTL. With TTL 300, typically 5-15 minutes globally.
• AAAA record (IPv6 address): Same as A record.
• CNAME record (alias): Same propagation pattern. Note: cannot coexist with other records at the zone apex.
• MX record (mail): Changes take effect quickly, but email in transit during the changeover may be delivered to the old server. Plan mail changes during low-traffic periods.
• NS record (nameserver delegation): Slowest to propagate because the parent zone (e.g., .com TLD nameservers) must update. Can take 12-48 hours regardless of TTL. This happens when you change your DNS provider at the registrar.
• TXT record (SPF, DKIM, domain verification): Same as A record propagation, but SPF/DKIM changes affect email deliverability globally so verify from multiple locations before considering it complete.

Real Example: Migrating a Site to a New Host

Here is how to handle a typical scenario - migrating example.com from old server (203.0.113.10) to new server (198.51.100.20) with zero downtime:

# Step 1: Check current A record and TTL (48 hours before migration)
dig example.com A
# Result: example.com. 86400 IN A 203.0.113.10

# Step 2: Lower TTL to 300 at your DNS provider
# (Make this change via your registrar/DNS provider's web interface)

# Step 3: Wait 86400 seconds (current TTL) for caches to expire and pick up TTL=300
# Now resolvers worldwide will cache for only 5 minutes

# Step 4: Set up and verify new server (while old server still active)
curl -H "Host: example.com" http://198.51.100.20/

# Step 5: Change A record to new IP
# example.com.  300  IN  A  198.51.100.20

# Step 6: Verify propagation from multiple resolvers
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
dig @9.9.9.9 example.com A

# Step 7: Keep old server alive for ~1 hour after the change
# to serve any stragglers hitting cached old IP

# Step 8: Raise TTL back to 3600 or 86400

Frequently Asked Questions

Why does my DNS change show immediately for me but not for others?

Because you are seeing the result from your local resolver (or directly from the authoritative nameserver after flushing your cache), while other users are being served a cached copy by their ISP's resolver. Your ISP and theirs may have cached the old record at different times, so they expire at different times. This is normal and will resolve itself as each cache expires.

Can I force DNS propagation to complete faster?

Not directly - you cannot push updates to other resolvers. The only effective technique is pre-lowering your TTL before making changes, as described above. Some DNS providers (Cloudflare, Route53) offer very low minimum TTLs (as low as 1 second) for critical records. Major resolvers like Cloudflare 1.1.1.1 also respect short TTLs faithfully.

My site shows the new IP but email is still going to the old server. Why?

Email routing uses MX records, not A records. Your web traffic A record may have propagated while your MX record (or the A record the MX points to) still has a cached old value. Check specifically: dig example.com MX and then dig mail.example.com A to trace the full email delivery chain.

How long does changing my nameservers (DNS provider) take?

Nameserver changes (e.g., moving from GoDaddy DNS to Cloudflare) involve updating the NS records in the .com or .net TLD registry, which is operated by Verisign. TLD registries typically have TTLs of 172800 seconds (48 hours) on NS records and are slower to respond to updates. Expect 24-48 hours for NS changes to propagate fully, regardless of what TTL you set on your records.

Why do different propagation checkers show different results?

Each checker is querying resolvers in different geographic locations. Those resolvers have independent caches that expired at different times. A resolver in Tokyo might have fetched the new record two hours ago, while one in Buenos Aires still has the old value cached from this morning. This is expected behaviour and not a sign anything is wrong - it means propagation is still in progress.

The Bottom Line

DNS propagation is not magic or mystery - it is simply a worldwide cache expiry process governed by the TTL values on your records. The best practice is to pre-lower TTLs to 300 seconds at least 24 hours before any significant DNS change, then raise them back after the change is verified. With a low TTL in place, propagation typically completes within 5-15 minutes rather than hours.

Use our free DNS Lookup tool to verify your records from your browser instantly: Use our DNS Lookup tool here →