How Long Does DNS Propagation Take? A Practical Answer

Last updated: June 10, 2026

You updated a DNS record and hit save. Now you are refreshing the live site every few minutes. The registrar said “allow up to 48 hours for changes to propagate.” A colleague’s machine is already seeing the new record, but yours is not. You are stuck in the most familiar part of every DNS migration: waiting and wondering whether something went wrong.

The good news is that DNS propagation is rarely as slow as the standard warning suggests. The reasons it sometimes takes hours instead of minutes are knowable in advance. This guide explains what propagation actually is and what controls how long it takes. You will also learn what to do (and not do) while you wait.

The Honest Short Answer

Most DNS changes for A, AAAA, MX, TXT, and CNAME records propagate within 5 to 60 minutes. The condition is that the previous TTL was set to a normal value. The worst case roughly equals the old TTL. Nameserver changes are the exception, taking 24 to 48 hours.

For a typical record change, most users see the new value within an hour. A small number of stragglers can take up to whatever the previous TTL was. If your previous TTL was 24 hours, the worst case is roughly 24 hours.

Nameserver (NS) changes are the real exception. They happen when you move a domain to a different DNS provider entirely. Those can take 24 to 48 hours. The reason is cache layers at the TLD registry that enforce their own multi-hour minimums.

The classic “DNS takes 24 to 48 hours” advice was originally about nameserver changes. It got generalized to every DNS change. That generalization is misleading for the common case. The rest of this article unpacks why, and how to plan a change so it completes in minutes.

What “DNS Propagation” Actually Means

DNS propagation is the gradual expiration of the old record from caches around the world. It is not the spread of the new record outward. There is no global broadcast. Each recursive resolver holds the old answer until its TTL timer expires, then refetches fresh.

The term “DNS propagation” is misleading. It implies that a new record spreads outward across the internet like a wave. That mental model is wrong. Replace it with the correct one and everything else makes sense.

There Is No Global Broadcast

You update an A record from 192.0.2.10 to 192.0.2.20 at your authoritative DNS provider. Exactly two things happen instantly. First, the new value is written to your authoritative nameserver. Second, nothing else changes anywhere else in the world.

Your update is not pushed to ISPs, public resolvers, or anyone else. There is no central registry that distributes DNS changes. The change exists only at your authoritative DNS until someone asks for it.

What’s Really Happening: Cache Expiration

Everywhere in the world, recursive DNS resolvers have cached the OLD value of your record. ISPs, public DNS services like Cloudflare and Google, corporate networks, and so on. They cached it the last time someone in their service area asked for it.

Each of those caches holds the old value until its time-to-live timer expires. Only then does the resolver discard the cached value. It asks your authoritative nameserver fresh, which is when it finally picks up the new record.

So “propagation” is not the new value spreading outward. It is the old value gradually expiring. Each resolver expires independently, on its own schedule. That is why one user sees the new site and another user across town still sees the old one. To understand why caching exists, our how DNS works walkthrough covers the full resolution chain.

The Two Things That Control Your Wait Time

Two factors control how long propagation takes. The TTL value set on the previous version of the record is the dominant one. The cache behavior of individual recursive resolvers is a minor secondary factor. The old TTL alone determines the worst-case wait.

With the right mental model in place, the actual factors that determine propagation time are simple.

1. The TTL on the OLD Record

The single biggest factor is the TTL set on the record before you changed it. TTL (Time to Live) is a value in seconds attached to every DNS record. It tells resolvers how long they may cache the answer. Common TTL values include:

• 300 seconds (5 minutes) — aggressive, used when fast changes matter
• 3600 seconds (1 hour) — the typical default at most registrars
• 14400 seconds (4 hours) — common at hosting-bundled DNS
• 86400 seconds (24 hours) — used for very stable records

Say your old record had a TTL of 3600. Any resolver that cached the old value within the past hour keeps serving it. The hold lasts up to one hour from when the resolver cached. The math is simple: the worst-case wait equals the old TTL value. In practice, the average user sees the change much sooner than the worst case. Most resolvers cached the old record at staggered times.

2. Resolver Cache Behavior

Some recursive resolvers ignore TTLs above a certain ceiling. ISPs occasionally cap TTLs at 1 hour even when the record specifies 24 hours. The goal is to bound the impact of any one stale record on their cache. Others cache for slightly longer than the TTL specifies, to reduce load.

The biggest public resolver puts a hard number on this. Google Public DNS caps cached TTLs at 21,600 seconds (6 hours). A record published with a 24-hour TTL behaves like a 6-hour record for every query through 8.8.8.8. RFC 2181 explicitly permits resolvers to impose these ceilings. Cloudflare’s 1.1.1.1 generally honors the origin TTL, but each anycast node caches independently.

A 2023 measurement study of 27,131 resolvers across 220 countries quantified this directly. About 4.1% of resolvers extended TTL values beyond what records specified. About 1.97% shortened them (Bhowmick et al., 2023). The deviations are real but limited in scope.

These deviations are small and only matter at the edges. They explain a familiar puzzle. The old TTL was 1 hour. Two hours have passed and one user still sees the old value. For more on resolver behavior, see DNS records explained.

Typical Propagation Times by Change Type

A, AAAA, MX, TXT, and CNAME records all propagate at the same speed governed by their own TTL. Nameserver (NS) records propagate much slower. TLD registry caches enforce multi-hour minimums that no domain owner can override.

Different DNS record types follow slightly different patterns. Here is what to expect for the most common changes.

A and AAAA Records (IP Addresses)

The most common type of DNS change is pointing a domain at a new server. Propagation tracks the TTL exactly. With a 300-second TTL, most users see the new address within 5 to 15 minutes. With a 3600-second TTL, expect 30 minutes to 1 hour for the majority. The last stragglers take up to an hour. With a 24-hour TTL, plan around it.

MX Records (Email Routing)

Functionally identical to A records in propagation behavior. The same TTL math applies. There is one operational nuance worth knowing. Mail servers may use the old MX briefly during the transition. They might fail or land at the old destination. Then they retry.

Most mail servers retry over 24 to 72 hours. Messages rarely get lost outright during an MX change. You may see brief deliverability blips. To verify MX records during a change, use the MX lookup tool. The DNS propagation checker offers a side-by-side view.

TXT Records (Verification, SPF, DMARC)

Same TTL behavior as A and MX records. The main complication with TXT records is not propagation timing. It is that some services aggressively cache verification tokens for hours independent of TTL. When you add a Google site verification or an SPF record, the verification request itself may pass within minutes. A service polling the record on a schedule may take longer to notice.

CNAME Records (Aliases)

Same TTL behavior, but with an added layer. A CNAME points to another name that itself has DNS records and a TTL. The effective propagation time is roughly the longer of the CNAME’s TTL and the target name’s TTL. If your CNAME has a 5-minute TTL but the target name has a 1-hour TTL, plan around the hour.

Nameserver (NS) Records

This is the change people are warned takes 24 to 48 hours. That warning is correct. Nameserver changes are processed at the TLD registry level. Verisign handles .com and .net. PIR handles .org. And so on.

The TLD’s own DNS responses for your domain’s NS records are cached by every resolver in the world. The cache TTL at the TLD level is typically 48 hours. Worse, you cannot lower the TLD’s NS TTL because you do not control it. The registry does.

There is one way to avoid the wait on a nameserver change. Keep both old and new providers serving identical records during the cutover. Users seeing either result then get the same answer.

Why Different Devices See Different Answers

Different devices on different networks query different recursive resolvers. Each resolver caches independently. One resolver may have refreshed and picked up the new record while another is still serving the old value. The disagreement disappears when both devices use the same resolver.

You change the record. Your phone shows the new site immediately. Your laptop next to you still shows the old one. This is the most common puzzle of any DNS migration. The explanation is always the same:

The same effect plays out across geographies. A friend in another city checks the site and sees the new version while you still see the old one. They are hitting a different resolver. That resolver’s cache expired at a different moment than yours.

The DNS propagation checker exists specifically to surface this. It queries Google’s and Cloudflare’s public resolvers side by side. You can see whether the disagreement is a real cache lag, or whether one resolver is returning a different answer.

What to Do While You Wait

Four actions actually help during DNS propagation. Lower TTL before the change rather than after. Query multiple public resolvers to track real progress. Avoid repeatedly flushing local caches. Verify the change at your authoritative nameserver before assuming propagation is slow.

Most of the things people try during DNS propagation either do not help or actively make troubleshooting harder. Here is what actually moves things forward.

Lower the TTL BEFORE the Change, Not After

This is the single most useful trick in DNS migration. A day or two before a planned change, edit the record. Drop the TTL to 300 seconds. Wait for the OLD TTL to fully expire across the world. Now make the actual change.

Every resolver will pick up the new value within 5 minutes. They cached the previous value with a 5-minute TTL. After the migration is stable, raise the TTL back to 3600 or higher. This avoids constant queries from every resolver on the planet hammering your authoritative nameservers.

Check From Multiple Resolvers Instead of Just Yours

Your local view of DNS is the least informative view available. Your browser, your operating system, and your ISP’s resolver are all caching the record. Possibly differently from each other. To know what is actually happening, query multiple public resolvers directly. The DNS propagation checker does this from the browser. The DNS lookup tool lets you query individual record types.

Don’t Repeatedly Flush Your Local DNS Cache

Flushing your local cache once, right after you make a change, is fine. It verifies the new record reaches you. Doing it repeatedly accomplishes nothing. After the flush, your machine asks your ISP’s resolver. That resolver still has the same cached answer from a minute ago. Stale records do not live exclusively on your machine. They mostly live upstream. If you need the exact command for your OS or browser, our how to flush DNS cache guide covers Windows, macOS, Linux, and Chrome.

Verify the Change at the Authoritative Nameserver

Before you spend hours wondering why propagation is slow, confirm the change is even live at your own authoritative DNS. A surprising number of “propagation problems” are actually “the change never saved” or “the change saved on the wrong subdomain.” A direct query to your authoritative nameserver bypasses every cache. It shows the literal current state of your DNS. If the new value is not there, no amount of waiting will help.

Common Pitfalls That Slow You Down

Four specific issues turn a quick DNS change into a multi-hour wait. A high TTL set before the change. A stale browser or operating system cache. An old hosts file entry that overrides DNS. A cached negative answer from checking too early.

A few specific situations turn what should be a quick change into a multi-hour wait.

High TTL Set Long Before the Change

Say your record’s TTL was 86400 (24 hours). You did not lower it in advance. You are committed to a 24-hour worst case. Lowering it after the change is already live does nothing for the current update. Every resolver that already cached the old value with a 24-hour TTL keeps it for up to 24 hours. The new record’s TTL value does not retroactively shorten the old one. Lower TTL is forward-looking only.

Stale Browser or OS Cache

Even after DNS propagates correctly, your browser and operating system may continue showing the old version for several minutes. They cached the answer when it arrived. In Chrome, chrome://net-internals/#dns shows the cache and offers a clear button. On Windows, run ipconfig /flushdns from an elevated prompt to clear the OS resolver cache. On macOS, run sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.

An Old hosts File Entry

You may have manually mapped a domain to an IP address in your operating system’s hosts file. That is a common debugging trick. That mapping overrides DNS entirely. No amount of propagation will help. Your machine never queries DNS for that domain.

Check C:\Windows\System32\drivers\etc\hosts on Windows. Check /etc/hosts on macOS and Linux. Look there first if a single machine is mysteriously stuck on an old record.

You Queried the Record Before It Existed

Negative answers get cached too. Query a brand-new record before it is published and the resolver caches the “does not exist” response. RFC 2308 defines this negative caching. The hold time comes from the zone’s SOA record, commonly 5 minutes to 1 hour. The fix is patience or testing against the authoritative nameserver directly.

When to Worry vs. When to Wait

DNS changes progress normally during the first hour. They continue fine up to the old TTL value. Beyond that point, something is likely wrong. The change never saved, was made to the wrong record, or a conflicting record exists at another provider.

Here is a rough timeline for when “still showing the old record” is normal versus when something is actually wrong.

Related Tools & Resources

NetworkCheckr provides browser-based tools for every part of the DNS workflow, plus articles that explain the underlying concepts. The DNS propagation checker is the natural next step after reading this article. Related tools and reference content are listed below.

• DNS Propagation Checker — query Google and Cloudflare side by side to see who has the new record.
• DNS Lookup — check individual A, AAAA, MX, TXT, CNAME, and NS records for any domain.
• DNS Records Explained — what each record type does, and when to use which.
• How DNS Works — the full resolution chain from browser cache to authoritative nameserver.
• What Is Reverse DNS? — PTR records and email deliverability, with their own propagation considerations.
• All NetworkCheckr Tools — the full set of free browser-based networking utilities.

Frequently Asked Questions

Six common questions cover the edge cases that come up most often during DNS propagation. Why it takes so long. How to speed it up. The longest realistic wait. Device-to-device discrepancies. Whether flushing helps. And how it differs by record type.