How DNS Propagation Works & How to Check It

Updated February 6, 2026

When you update a DNS record — change your website's IP address, switch email providers, add an SPF record — the change doesn't take effect everywhere at once. It spreads gradually across the internet through a process called DNS propagation. Understanding this process is essential for planning DNS changes and troubleshooting why your updates haven't taken effect yet.

How DNS Resolution Works

To understand propagation, you first need to understand the DNS resolution chain. When you type example.com into your browser, the request passes through multiple layers of caching:

The Resolution Chain

1. Browser cache — Your browser checks its own DNS cache first (typically cached for 1-2 minutes).
2. Operating system cache — If not in the browser cache, the OS resolver is queried (cache duration varies by OS).
3. Router cache — Some home and office routers cache DNS responses.
4. ISP recursive resolver — Your ISP's DNS server (or whatever resolver you use, like Google's 8.8.8.8 or Cloudflare's 1.1.1.1) checks its cache.
5. Authoritative nameserver — If no cached copy exists anywhere, the recursive resolver queries your domain's authoritative nameserver and gets the fresh record.

Each layer caches the response for the duration of the record's TTL (Time to Live). This caching is what makes DNS fast — billions of queries don't need to reach authoritative servers for every request. But it's also what makes propagation slow.

What Determines Propagation Speed

TTL (Time to Live)

TTL is the most important factor. It's a value (in seconds) attached to every DNS record that tells resolvers how long to cache it.

If your A record has a TTL of 86400 (24 hours), a resolver that cached it at 8 AM won't check for updates until 8 AM the next day — even if you changed the record at 8:01 AM.

Resolver Behavior

Not all resolvers honor TTL strictly:

• Most major resolvers (Google, Cloudflare, Quad9) respect TTL values accurately.
• Some ISP resolvers may impose a minimum TTL and ignore values below their threshold.
• Some resolvers may serve stale records briefly while fetching a fresh copy in the background (RFC 8767).

Negative Caching

If a resolver queries a record that doesn't exist, it caches the negative response (NXDOMAIN) for the duration specified in the SOA record's minimum TTL. This means if you check for a new record before it's published, the "doesn't exist" response gets cached too.

The Propagation Timeline

Here's a realistic timeline of what happens when you change a DNS record:

Before the change:

• Your old record has been cached by resolvers worldwide with its current TTL.

Immediately after the change:

• Your authoritative nameserver serves the new record instantly.
• Resolvers that have never cached your record (or whose cache just expired) get the new record immediately.

Within the old TTL window:

• Resolvers gradually expire their cached copies and fetch the new record.
• Some users see the new record, others still see the old one.

After the old TTL has fully elapsed:

• All properly behaving resolvers should have the new record.
• In practice, expect full propagation within 1.5x to 2x the old TTL.

How to Speed Up Propagation

The most effective strategy is to lower your TTL before making changes:

Step 1: Lower the TTL (24-48 Hours Before)

Change the TTL on the record you plan to modify from its current value (e.g., 86400) to a low value (e.g., 300):

; Before: high TTL
example.com.    86400    A    93.184.216.34

; Step 1: lower TTL (wait 24-48h for this to propagate)
example.com.    300      A    93.184.216.34

Wait for the old high TTL to expire. After 24-48 hours, all resolvers should now be caching your record with the short 300-second TTL.

Step 2: Make the Change

Now update the record to its new value. Since resolvers are caching with a 300-second TTL, the change propagates within minutes:

; Step 2: change the value
example.com.    300    A    198.51.100.42

Step 3: Raise the TTL

Once propagation is complete and everything is working, raise the TTL back to a normal value:

; Step 3: restore normal TTL
example.com.    3600    A    198.51.100.42

How to Check Propagation

Method 1: DNS Propagation Checker

The easiest approach is to use a propagation checking tool like DNS Kit that queries your domain from dozens of DNS servers worldwide and shows you which ones have the old record and which have the new one.

Method 2: Query Specific Resolvers

You can manually query different DNS resolvers to compare results:

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

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

# Query your ISP's resolver
dig example.com A +short

# Query your authoritative server directly
dig @ns1.your-dns-provider.com example.com A +short

If the authoritative server returns the new value but public resolvers still return the old value, propagation is in progress.

Method 3: Check the TTL Countdown

You can see how much time remains on a cached record:

dig example.com A

Look at the TTL value in the response (the number before the record type). It counts down from the original TTL to zero. When it reaches zero, the resolver fetches a fresh copy.

Special Propagation Scenarios

Email Migration

When migrating email providers, both old and new mail servers should accept email during the transition:

1. Lower MX record TTL to 300 seconds, 48 hours before migration.
2. Configure the new mail server to accept email for your domain.
3. Update the MX records.
4. Keep the old mail server running for at least 48 hours after the change.
5. Monitor for stragglers and raise TTL once propagation is complete.

For more about MX records and email routing, see our MX records guide.

Nameserver Changes

Changing your domain's nameservers (NS records at the registrar) is a special case. The registrar updates the parent zone (e.g., .com), and propagation depends on the TTL of the delegation records in the parent zone, which you don't control. These typically have TTLs of 48 hours, which is why nameserver changes are often quoted as "up to 48 hours." To understand how this delegation chain works — from root zone through TLD to your domain — see our DNS delegation guide.

Anycast DNS

Many modern DNS providers use anycast — the same IP address is announced from multiple geographic locations. When you update a record on an anycast network, the change propagates to all edge locations almost instantly (usually within seconds). The remaining propagation delay is entirely due to resolver caching.

Troubleshooting Propagation Issues

Record not changing at all?

• Verify the change was saved on your DNS provider's dashboard.
• Query your authoritative nameserver directly to confirm the update is live.
• Check that you're editing the correct zone (root domain vs. subdomain).

Some locations see the change, others don't?

• This is normal during propagation. Wait for the old TTL to expire.
• Clear your local DNS cache: sudo dscacheutil -flushcache (macOS) or ipconfig /flushdns (Windows).

Change reverted after appearing to work?

• You may have been hitting a resolver that had already expired its cache, while others still had the old record.
• Wait for full propagation before assuming the change is permanent.

For more on checking and troubleshooting DNS, see How to Check DNS Records and our DNS record types reference.