How long does DNS propagation take?

DNS propagation usually takes anywhere from a few minutes to a few hours, with a conservative upper bound of 24-48 hours for complete global distribution — and the single factor that decides where you land in that range is the TTL on the record before you changed it. "Propagation" is a slightly misleading word: nothing is being pushed across the internet. What actually happens is that every recursive resolver holding a cached copy of your old record keeps serving it until that record's TTL expires, then fetches the fresh answer on its own schedule. A record with a 300-second TTL updates almost immediately; one with an 86400-second (24-hour) TTL can serve stale answers for a full day. Nameserver changes at the registrar are the slow exception, often 24-72 hours.

That's the summary an AI Overview gives you. The part it can't give you is why the delay is really cache expiry and not distribution, how to read the staggered timeline below, and exactly how to shorten it — which is what the rest of this article walks through.

"Propagation" is cache expiry, not distribution

DNS propagation is the time it takes for a DNS change to become visible everywhere. But the word "propagation" implies your update is broadcast outward across the internet, and that is not what happens. Your authoritative nameserver updates the instant you save the record. Every other resolver in the world only learns about the change when the cached copy it is already holding expires — governed entirely by the record's TTL (Time To Live). There is no push, no notification, no global sync. Each cache simply counts down and re-fetches on its own.

Understanding this one fact — propagation is staggered cache expiry, not distribution — is what lets you plan maintenance, set realistic expectations, and troubleshoot the completely normal state where some locations see new data while others still see old.

How long each change type actually takes

The table below is the fast answer for "how long will my change take." The dominant variable in every row is the old TTL — the value cached alongside the record before you touched it.

Change type	Typical time to "mostly propagated"	Worst case	What controls it
A / AAAA record (IP change)	5 min - 1 hour	Old TTL (often up to 24 h)	Old TTL on the record; resolver cache compliance
CNAME record	5 min - 1 hour	Old TTL	Same as A record; usually within a few hours
MX record (mail server)	Minutes - a few hours	24 h+	Old TTL, plus sending mail servers cache MX too
TXT / SPF / DKIM record	Minutes - a few hours	Old TTL	Old TTL; verifiers re-query on their own cadence
Nameserver (NS) change	4 - 24 hours	24 - 72 hours	Registrar/TLD delegation + TLD NS TTL (often 24-48 h)
New record (didn't exist before)	Seconds - minutes	Negative-cache TTL (SOA)	No old value cached; only prior "does not exist" answers

Two rows deserve emphasis. Nameserver changes are the slow ones because they happen at the registrar and TLD registry, not in your zone, and TLD NS records commonly carry 24-48 hour TTLs. And a brand-new record is the fastest of all — there is no stale answer to expire, only cached "this name doesn't exist" (NXDOMAIN) responses governed by your zone's SOA minimum TTL.

Try it yourself: look up any record and see the live TTL each resolver reports.

Understanding DNS propagation helps you plan maintenance, set realistic expectations for domain changes, and troubleshoot issues where some locations see old data while others see new data.

The DNS Propagation Process

Timeline of DNS Propagation

Time 0: Change Made

• DNS record updated at authoritative nameserver
• Old DNS information still cached elsewhere

Time 0-5 minutes: Authoritative Update

• Authoritative nameserver has new record
• Only systems querying authoritative nameserver get new data

Time 5-30 minutes: ISP Resolver Updates

• Major ISP resolvers refresh their caches
• Larger percentage of users see new data
• Some ISPs still serving old cached data

Time 30 minutes - 12 hours: Regional Distribution

• Smaller ISPs and regional resolvers update
• Most users see new data
• Some edge cases still see old data

Time 12-48 hours: Global Distribution

• All nameservers have updated
• Caches expire worldwide
• Consistent results globally

Standard guidance: DNS propagation takes 24-48 hours for complete global distribution.

Factors Affecting Propagation Speed

1. TTL (Time To Live)

TTL is the most significant factor:

example.com    3600    A    192.0.2.1
                ^^^^
                TTL in seconds

• 3600 (1 hour): Cache expires after 1 hour; faster propagation
• 86400 (1 day): Cache expires after 24 hours; slower propagation
• 300 (5 minutes): Very fast propagation, more DNS traffic

During change:

• Old TTL value controls cache duration
• High TTL (86400) means old data cached for 24 hours
• Low TTL (300) means old data flushed after 5 minutes

Strategy:

1. Reduce TTL to 300 (one day before change)
2. Wait 24 hours for old TTL to expire
3. Make DNS change
4. Propagation happens quickly (5 minutes to hours)
5. Wait 24 hours, increase TTL back to 3600

2. Caching at Multiple Levels

DNS is cached at multiple layers:

1. Browser cache: Minutes to hours
2. Operating system cache: Minutes to hours
3. ISP resolver cache: Honors TTL
4. Authoritative nameserver: No cache, authoritative
5. Root/TLD nameservers: Cache for efficiency

Each level must refresh independently.

3. ISP Behavior

Different ISPs handle TTL differently:

• Strict compliance: Honor TTL exactly
• Longer caching: Cache longer than TTL specifies
• Shorter caching: Override TTL with lower values
• Inconsistent: Different behavior at different times

Can't control ISP behavior, only plan for variation.

4. Resolver Configuration

Public resolvers vs. ISP resolvers:

• Google DNS (8.8.8.8): Fast refresh, good compliance
• Cloudflare (1.1.1.1): Balanced refresh and efficiency
• ISP resolvers: Varies widely

Users experiencing slow propagation might be using ISP resolver with aggressive caching.

5. Type of Change

Different record changes propagate at different speeds:

• A record changes: Propagate quickly, widely distributed
• CNAME changes: Similar speed to A records
• MX/TXT changes: Propagate as quickly as A records
• Nameserver changes: May take 24-48 hours (registrar level)

Nameserver changes are slowest because registrar propagation is involved.

Monitoring Propagation

Online Propagation Checkers

Real-time tools showing propagation status:

• What's My DNS: DNS changes from 200+ locations
• WhatsMyDNS: Visual propagation maps
• DNS Propagation Checker: Check multiple record types
• Google Public DNS: dns.google propagation checker

These tools check your DNS from servers worldwide, showing how propagation progresses.

Command-Line Monitoring

# Check propagation over time
watch -n 60 'dig example.com A +short'

# Check from different nameservers
dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com A
dig @ns1.example.com example.com A

# Monitor specific record
while true; do
  echo "$(date): $(dig example.com MX +short)"
  sleep 300  # Every 5 minutes
done

# Check all record types
for type in A AAAA MX TXT NS; do
  echo "$type records:"
  dig example.com $type +short
done

Interpreting Propagation Data

What you're looking for:

100% of checkers:        NEW RECORD (fully propagated)
75-99% of checkers:      NEW RECORD (almost there)
50-74% of checkers:      NEW RECORD (in progress)
25-49% of checkers:      NEW RECORD (early stages)
1-24% of checkers:       NEW RECORD (just started)
0% of checkers:          OLD RECORD (not propagated)

Typical Propagation Times by Scenario

Scenario 1: A Record Change (IP Update)

Timeline:

• Immediate: Authoritative server has new data
• 5-15 minutes: Major resolvers see new data
• 15-60 minutes: Most users see new data
• 1-4 hours: Significant majority (95%+) see new data
• 4-24 hours: Practically complete

Example:

Changed: example.com A record from 192.0.2.1 to 192.0.2.2
Time:
- 0 min: Change made
- 5 min: You can see new IP with your nameserver
- 15 min: Major ISP resolvers see new IP
- 60 min: 90% of population sees new IP
- 4 hours: 99%+ of population sees new IP

Scenario 2: MX Record Change (Email Server Update)

Timeline:

• Similar to A record changes
• Mail servers may have cached old MX records
• Some emails might deliver to old mail server for 24 hours
• Recommends: Keep both old and new mail servers running during migration

Scenario 3: Nameserver Change

Timeline:

• Slower than typical DNS record changes
• Involves registrar-level changes
• Registrars notify root nameservers
• Can take 24-72 hours for global distribution
• Some edge cases may take longer

Example:

Changed: Nameservers from old-ns.example.com to new-ns.example.com
Timeline:
- 0-30 min: Change registered at registrar
- 30 min-4 hours: Root nameservers updated
- 4-24 hours: Significant propagation
- 24-72 hours: Near-complete propagation

Scenario 4: CNAME Change

Timeline:

• Similar to A records
• Systems may cache CNAME resolution
• Propagation usually within 4 hours

Preparing for DNS Changes

Pre-Change Preparation

1 day before change:

# Lower TTL to speed propagation
# Change from 3600 to 300 seconds
# This ensures old data clears quickly

# Update your DNS record TTL first
# Wait 24 hours for old TTL to expire

# Example:
# Day 1: Reduce TTL from 3600 to 300
# Day 2: Make the actual change
# Day 3: Optional - increase TTL back to 3600

Communicate changes:

• Notify users of expected propagation time
• Set expectations: "Changes may take up to 24 hours globally"
• Provide status updates via social media

During Propagation

Monitor consistently:

# Check propagation every 15-30 minutes
# Use online tools to see global status
# Document when different locations update

Keep old resources running:

• If migrating to new IP, keep old IP responding briefly
• If changing mail servers, keep old server accepting mail
• Prevents service disruption during propagation

Post-Propagation

Verify completion:

# Check major resolvers
dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com A
dig @208.67.222.222 example.com A

# Check from various geographic locations
# Use online propagation checkers

Common Propagation Issues

Issue 1: Slow Propagation (Stuck at 50%)

Possible causes:

• High TTL value still being honored
• Some resolvers caching beyond TTL
• Nameserver issues
• Registrar not updating properly

Solutions:

# Verify change at authoritative nameserver
dig @authoritative.nameserver.com example.com A

# Check if registrar properly updated
# Wait for old TTL to expire
# Try changing from different location

Issue 2: Inconsistent Results (Some See New, Some See Old)

Expected during propagation: This is normal intermediate state

Solutions:

• Use different DNS resolvers for different purposes
• Wait for complete propagation before declaring change complete
• Don't assume change is broken—it's likely still propagating

Issue 3: Propagation Doesn't Seem to Complete

Check:

# Is your change actually saved?
# Check with authoritative nameserver
dig @ns1.yourdns.example.com example.com A

# If authoritative has old data, change didn't save
# If authoritative has new data, it's a caching issue

Speeding Up Propagation

1. Lower TTL Before Change

Reduces old data cache duration:

24 hours before change:
- Set TTL to 300 (5 minutes)
- Wait 24 hours
- Make change
- New data propagates within hours
- After propagation complete, restore TTL to 3600

2. Use Multiple Record Types

Support both old and new simultaneously:

# During MX server migration
example.com    MX    10    old-mail.example.com
example.com    MX    20    new-mail.example.com

# Phase 1: Both servers running
# Phase 2: When propagated, increase priority of new server
example.com    MX    5     new-mail.example.com
example.com    MX    20    old-mail.example.com

# Phase 3: When certain all propagated, remove old
example.com    MX    10    new-mail.example.com

3. Use Global DNS Services

CDN/DNS services often propagate faster:

• Cloudflare DNS (can have hundreds of servers)
• Route53 (AWS global infrastructure)
• Google Cloud DNS (Google's infrastructure)

4. Pre-create Records

Add new records with low TTL before removing old:

# Pre-creation (few days before)
example.com    A    300    192.0.2.2  # New IP, low TTL

# Later
example.com    A    300    192.0.2.1  # Old IP still active

# When ready to switch
# Remove old, keep new

# New IP already cached in many resolvers
# Results in faster actual switch

Propagation and Business Impact

Planned Maintenance

When planning DNS changes:

• Schedule changes early in day
• Allow 4-8 hours for primary propagation
• Expect some users on old data for 24 hours
• Monitor for issues during propagation
• Keep old resources available during propagation window

Email Server Migration

Email is particularly sensitive:

• Emails to old MX still deliver for 24 hours
• Set up mail forwarding on old servers
• Run old and new mail servers in parallel
• Don't disconnect old server until certain propagation complete

Service Migration

When migrating services:

• Create temporary DNS records with low TTL
• Run new service in parallel
• Monitor both simultaneously
• Keep old service available 24 hours after DNS change
• Document which users are seeing which service

Best Practices

1. Lower TTL 24 hours before change
2. Monitor propagation globally
3. Keep old resources running during propagation
4. Document changes and propagation time
5. Notify affected users proactively
6. Verify propagation completion before decommissioning old systems
7. Test critical functionality during propagation

Conclusion

DNS propagation takes 24-48 hours for complete global distribution, but most users see changes within 4 hours. By understanding propagation mechanics, preparing properly, and monitoring progress, you can minimize service disruption and ensure smooth transitions.

The key to successful DNS changes is planning ahead, lowering TTL values before changes, running old and new systems in parallel during propagation, and maintaining realistic expectations about distribution timing.

Whether managing a simple A record change or complex infrastructure migration, proper propagation management is essential to preventing service disruptions and maintaining customer trust.