DNS Propagation: How Long It Takes and How to Know When a Change Is Live

You change a website's IP address, move email to a new provider, point a subdomain at a SaaS platform, or replace your nameservers. The DNS control panel says the change is saved, but one network sees the new destination while another still reaches the old one.

That is the situation people usually describe as DNS propagation.

The useful question is not simply “Has 24 hours passed?” It is which DNS answer is being cached, where, and for how long?

This guide explains what DNS propagation actually means, how TTL affects the transition, which record type to inspect, and how to tell the difference between normal cache behavior and a configuration mistake.

What DNS propagation actually is

“Propagation” sounds as if a central system sends your new DNS value from server to server until every machine on the internet has received it.

DNS is more decentralized than that.

When a user looks up a hostname, the request usually goes through a recursive DNS resolver. The resolver asks the relevant authoritative servers for an answer when necessary, then caches that answer for a period determined by its TTL.

If you change the authoritative record, the new value may be available there immediately. A recursive resolver that already cached the old answer, however, may continue serving it until that cached entry expires.

This is why two people can query the same hostname at the same time and legitimately receive different answers.

How long does DNS propagation take?

There is no reliable universal rule that says every DNS change takes 24, 48, or 72 hours.

A straightforward record change can start showing up in minutes. Other resolvers may retain the previous answer for hours.

What matters includes:

• the TTL that existed before the change;
• when each resolver cached the previous answer;
• local OS, browser, router, or enterprise DNS caches;
• the record type you changed;
• whether you changed the domain's nameservers;
• whether a CDN or geo-aware DNS setup intentionally varies answers;
• negative caching for names or records that previously did not exist.

Suppose an A record had a TTL of 3600 seconds. A resolver that cached the old IP just before you changed it may keep that answer for close to an hour. Another resolver whose cache was already near expiration may retrieve the new IP almost immediately.

The clock therefore does not start from exactly the same point for every resolver.

TTL: the number that matters most

TTL stands for Time to Live. It tells a resolver how long a DNS answer may be cached before it should be refreshed.

Common values include:

• 300 seconds — 5 minutes;
• 1800 seconds — 30 minutes;
• 3600 seconds — 1 hour;
• 14400 seconds — 4 hours;
• 86400 seconds — 24 hours.

A shorter TTL can make planned migrations smoother because stale answers expire sooner. A longer TTL reduces repeated authoritative lookups but can leave old data cached for longer during a change.

If you are planning a major migration, lowering the TTL before the move is more useful than lowering it at the same moment you change the destination. Caches that already stored the old record under the previous TTL do not retroactively adopt your new lower value.

Check the record you actually changed

A surprising amount of DNS troubleshooting goes wrong because the wrong record type is being checked.

A records

An A record maps a hostname to an IPv4 address. Check it when a website, API, or other service moved to a new IPv4 destination.

AAAA records

An AAAA record maps a hostname to IPv6. If both A and AAAA exist, changing only A can leave IPv6-capable users reaching a different server.

CNAME records

A CNAME makes one hostname an alias of another. It is common for www, SaaS services, verification endpoints, and CDN-related setups.

MX records

MX records identify the mail servers responsible for receiving email for a domain. They matter when moving Google Workspace, Microsoft 365, a hosting mail service, or another mail provider.

TXT records

TXT records are commonly used for SPF, ownership verification, DMARC-related data, vendor validation, and other service configuration.

NS records

NS records identify the nameservers responsible for a zone. Changing them is different from editing a normal record inside the same DNS provider because the parent delegation and registrar are part of the path.

How to check whether a DNS change is live

Refreshing the website is a poor DNS propagation test because it mixes DNS, TLS, HTTP, CDN behavior, and application behavior into a single result.

A better approach is to query the exact record that changed and compare answers from multiple recursive DNS views.

A DNS propagation check can show whether different resolvers have converged on the same answer, which TTL values they are reporting, and whether a location-sensitive response may be involved.

1. 1Identify the exact hostname and record type you changed: A, AAAA, CNAME, MX, TXT, or NS.
2. 2Query that hostname rather than assuming the root domain and a subdomain share the same records.
3. 3Compare the returned value with the new value you expect to be authoritative.
4. 4Look at more than one resolver view instead of relying only on your home, office, or mobile network.
5. 5Use the TTL as context and recheck after a reasonable interval rather than refreshing continuously.
6. 6If DNS answers agree but the service still fails, move your troubleshooting to TLS, HTTP, the CDN, or the application.

The ProntoUso checker compares six DNS views: Brazil, the United States, Europe, and Asia using location-aware Google Public DNS queries, plus global Google Public DNS and Cloudflare 1.1.1.1 views.

The regional entries use EDNS Client Subnet (ECS). They are regional DNS perspectives, not physical ProntoUso probes sitting in six data centers.

That distinction matters because the tool is comparing how public DNS infrastructure answers from different perspectives, not measuring network latency from those countries.

What resolver consensus tells you

If all successful resolver views return the same set of answers, that is a strong sign that the DNS state visible to those resolvers is consistent.

If some show the old value and others show the new one, cache expiration may still be in progress.

However, different answers do not always mean stale DNS.

Before deciding that a change is “not propagated,” ask whether the hostname is expected to produce a single global answer.

Why your computer may still see the old address

Public DNS tools may show the new record while your browser still reaches the old destination.

Possible causes include:

• the operating system's DNS cache;
• browser-specific DNS caching;
• a home or office router cache;
• an ISP or corporate recursive resolver;
• a VPN;
• a proxy;
• a manual hosts file entry;
• an old AAAA record while you are only checking A.

Testing from a second network can be helpful, but remember that two networks are still only two data points.

If DNS now resolves correctly but the site returns an unexpected response, check the next layer. An HTTP status lookup can help distinguish “DNS points to the right place” from “the web server is returning the right response.”

DNS is correct but HTTPS is broken

Website migrations often expose a second issue after DNS starts reaching the new server: the browser reports a certificate warning.

That is not necessarily a propagation problem.

If the new server does not have a certificate covering the hostname, or it is presenting a default certificate for another site, waiting for more DNS caches to expire will not fix it.

Inspecting the TLS certificate currently presented by the hostname can confirm whether the server reached through DNS is actually serving the expected certificate.

Think of the layers separately:

DNS gets you to a destination. TLS proves the identity of the HTTPS endpoint. HTTP and the application determine what happens after the connection is established.

“No answer” does not always mean the domain is broken

A DNS query can succeed without returning the record type you requested.

For example, a subdomain that is only used for a website may have A and AAAA records but no MX record. Querying MX for that hostname can legitimately return no answer.

It is useful to distinguish:

• a valid name with no record of the requested type;
• a name that does not exist;
• a resolver that failed to respond;
• a valid answer that points somewhere unexpected.

Always verify the exact hostname and record type before treating an empty result as an outage.

Nameserver changes are a different class of migration

Changing an A record inside the current DNS zone is relatively contained. Changing the domain's nameservers changes who is authoritative for the zone.

That means the new DNS provider should already have a complete copy of every record the domain needs before you update the delegation at the registrar.

• !Create the complete zone at the new DNS provider before changing nameservers.
• !Verify important A, AAAA, CNAME, MX, and TXT records.
• !Copy email authentication records such as SPF, DKIM, and DMARC when applicable.
• !Confirm the new authoritative nameservers answer correctly before changing the registrar.
• !Keep the old DNS zone available during the transition when practical.
• !Avoid unrelated DNS changes during the same window if you need easy troubleshooting.

A missing MX or TXT record during a nameserver migration can make the website work perfectly while email breaks. That is not slow propagation; it is an incomplete new zone.

Can you force DNS propagation?

Not across the public internet.

You control the records and TTLs you publish. You do not control every recursive resolver that may already have a valid cached answer.

After a change, the productive steps are:

1. verify that the authoritative DNS is serving the intended value;
2. compare multiple public recursive resolver views;
3. wait for old caches according to the previous TTL;
4. avoid repeatedly changing the record while troubleshooting;
5. verify the destination service independently.

Flipping an IP back and forth can make the situation harder to interpret because different caches may end up holding different generations of your configuration.

Negative caching: the case people often miss

DNS can cache the fact that something did not exist.

Suppose you query api.example.com before creating it. A resolver may cache the negative response. You then create the hostname and expect it to work immediately, but that resolver can continue to remember the earlier “not found” result for a period controlled by the DNS zone's negative caching behavior.

This is one reason creating a brand-new record can sometimes appear delayed even though there was no previous positive value to replace.

When should you stop waiting and start troubleshooting?

Use the previous TTL as a practical reference, not a generic “48-hour” rule.

If the old TTL was 300 seconds and several independent resolvers are still returning an obsolete, unexpected answer many hours later, investigate.

If the TTL was 86400 seconds, old caches during part of the following day are less surprising.

For NS changes, also account for parent-zone delegation and registrar behavior.

Ask these questions:

• Does the authoritative DNS return the new value?
• Which recursive resolvers still return the old one?
• Is the observed TTL consistent with caching?
• Is a CDN or geo-aware DNS involved?
• Are you querying the correct record and hostname?
• Is the current failure actually at the DNS layer?

Common DNS migration mistakes

Time is often blamed for problems that are really configuration errors.

Common examples include:

• editing a DNS zone that is no longer authoritative;
• changing www while forgetting the apex domain, or vice versa;
• updating A but leaving AAAA pointed at the old server;
• entering the wrong IP address;
• creating a CNAME where another conflicting record already exists;
• moving mail without copying MX and TXT records;
• switching nameservers before building the new zone;
• confusing an HTTP redirect or server error with DNS;
• treating CDN-generated regional IP differences as failure.

A propagation check is most useful when you know what answer you expect.

Frequently asked questions

Does DNS propagation always take 24 to 48 hours?

No. Many changes appear much faster. The previous TTL, existing caches, record type, and resolver behavior are more useful than a fixed universal timeframe.

Does flushing my DNS cache update DNS for everyone?

No. It only removes cache on the device or resolver you flush. Other recursive resolvers keep their own caches.

If Google and Cloudflare show the new answer, is propagation finished?

It is a strong positive signal, not a guarantee for every resolver on the internet. Also remember that CDNs and geo-aware DNS may intentionally return different answers.

Does lowering TTL after the change make existing caches expire sooner?

Not necessarily. A cache that stored the previous answer using the previous higher TTL can continue to honor that stored lifetime.

Why do different countries see different IPs?

CDNs, global load balancing, and GeoDNS can intentionally route users to different endpoints based on location or network conditions.

Should I check both A and AAAA?

If both are published, yes. IPv6-capable clients may use AAAA even when your A record is already correct.

The key takeaway

DNS propagation is best understood as a cache transition, not a worldwide update timer.

Start with the exact record that changed. Compare several resolver views. Use TTL as context. Know whether your DNS setup is expected to vary by location.

Once DNS is consistently returning the intended destination, stop waiting for “more propagation” and troubleshoot the next layer. That is usually the fastest way to distinguish a real DNS problem from a TLS, HTTP, CDN, or application issue.