How Long Do DNS Changes Take to Update Everywhere?

Most DNS record changes begin appearing within a few minutes, but that does not mean every user receives the new answer at the same moment. The authoritative DNS provider must publish the change, and then thousands of independent recursive resolvers, internet providers, corporate networks, routers, operating systems, browsers, and applications must stop using any older answer they cached.

For a routine website record with a five-minute time to live, most users may reach the new destination within five to 30 minutes. A record that previously had a one-hour or 24-hour TTL can remain old in some caches for that entire period. Changing a domain’s nameservers can take up to 24–48 hours, and a DNSSEC mistake can make the domain fail instead of merely appearing delayed.

There is no single global DNS propagation switch and no tool that can prove every resolver everywhere has updated.

Quick Answer

DNS changes usually become visible to many users within a few minutes to several hours. Allow up to the record’s previous TTL for resolvers that cached the old answer. Nameserver or DNS-provider changes may take 24–48 hours, while DNSSEC transitions sometimes require additional staged waiting periods.

A newly added record may appear immediately for people who never queried it, but users who recently received an NXDOMAIN or “record not found” answer may continue seeing that negative result until its negative-cache TTL expires.

These are planning ranges, not guarantees:

DNS change	Common planning range	Main source of delay
A, AAAA, or CNAME with 300-second TTL	About 5–30 minutes	Old cached answer, provider publication, local caches
Record with one-hour TTL	Up to about one hour, sometimes longer	Previous TTL and resolver behavior
Record with 24-hour TTL	Up to about 24 hours	Previous record may remain cached all day
New record that was never queried	Seconds to minutes	Authoritative publication
New record after users received NXDOMAIN	Minutes to hours	Negative caching based on the zone’s SOA settings
MX, SPF, DKIM, or DMARC change	Minutes to 24 hours; allow longer for migrations	TTL, independent mail systems, validation and retry behavior
Nameserver or DNS-host change	Several hours to 24–48 hours	Parent-zone delegation and cached NS records
DNSSEC DS or DNSKEY transition	One full relevant TTL per stage; often 24–48 hours for DS changes	Parent and child records must remain synchronized
Correction after a bad change	At least the TTL of the bad answer	Resolvers may cache the mistake just as they cached the correct record

DNS Does Not Literally “Update Everywhere”

The phrase DNS propagation suggests that one central system pushes a new record across the world. Public DNS does not work that way.

Your authoritative nameservers publish the official answer for the domain. Recursive resolvers—operated by internet providers, companies, schools, security products, and public services such as Google Public DNS—look up that answer for users. They normally cache it for the record’s time to live, or TTL, so they do not need to ask the authoritative server for every visit.

If a resolver has no cached answer, it can ask for the current record immediately. If it cached the old answer ten seconds before the change, it may continue returning that value until almost the entire TTL has elapsed.

That creates a rolling transition:

one resolver may show the new value seconds after the change;
another may keep the old value for five minutes;
another may keep it for several hours; and
a resolver that never had the old record cached may see no transition at all.

The update is complete for practical purposes when the authoritative servers are correct, the important caches have expired, and the old destination no longer receives meaningful traffic. Absolute confirmation from every resolver is not possible.

The Two Main Parts of the Timeline

Authoritative publication time

The DNS hosting company first has to distribute the new zone data to its own authoritative nameservers. This can be fast. Amazon Route 53 says record changes generally reach all Route 53 authoritative nameservers within 60 seconds. Cloudflare says zone changes normally take effect globally within five minutes and usually much less.

That provider-specific publication time does not erase answers already cached elsewhere.

Recursive cache expiration

Recursive resolvers use the TTL attached to the answer they previously received. Cloudflare defines TTL as the record field that controls how long the record is cached and therefore how quickly changes can reach users. Google Cloud gives the example that a TTL of 86,400 seconds instructs resolvers to cache the answer for 24 hours.

This second stage is usually what people mean when they complain that DNS has not propagated.

The Previous TTL Controls the Current Change

One of the most important DNS rules is also one of the easiest to miss: lowering the TTL at the same moment you change the destination does not make all existing caches expire sooner.

Suppose a website record has this value:

old IP address: 192.0.2.10
old TTL: 86,400 seconds, or 24 hours

At noon, the owner changes both the IP address and TTL:

new IP address: 198.51.100.25
new TTL: 300 seconds, or five minutes

A resolver that fetched the old answer at 11:59 a.m. can retain it until almost 11:59 a.m. the next day. That resolver never saw the new five-minute TTL because its cached copy still carries the old 24-hour instruction.

The new TTL controls answers fetched after the change. It cannot retroactively rewrite older caches.

How Far in Advance Should You Lower the TTL?

Lower the TTL at least one full current TTL before the planned cutover. For a record currently set to 86,400 seconds, reduce it at least 24 hours in advance. For a 172,800-second TTL, allow at least two days.

Cloudflare recommends reducing critical TTLs 24–48 hours before a migration—or longer when the existing TTL requires it—and identifies 300 seconds as a common short migration TTL. AWS migration guidance similarly emphasizes waiting for the previous TTL to expire before making the decisive change.

A reliable sequence is:

Record the current value and TTL.
Lower the TTL without changing the destination.
Wait at least the full old TTL.
Confirm that authoritative servers return the lower TTL.
Make the destination change.
Monitor both the old and new systems during the transition.
Keep the old system available for at least the appropriate cache window when possible.
After the change is stable, raise the TTL to a sensible long-term value.

Short TTLs improve responsiveness but increase query volume and dependence on authoritative availability. AWS describes TTL as a tradeoff among change responsiveness, resolver latency, reliability, and query volume.

How Long Different Record Types Usually Take

A and AAAA records

A records map names to IPv4 addresses, while AAAA records map names to IPv6 addresses. With a five-minute TTL, many users receive the new address within five to 30 minutes. With a one-hour TTL, plan for at least an hour of mixed traffic.

Check both record types. Updating the A record while leaving an old AAAA record can make the site work over IPv4 and fail or reach the old server over IPv6.

CNAME records

A CNAME points one hostname to another hostname. The effective chain may involve several TTLs: the CNAME’s TTL and the TTLs of the records used to resolve its target. A correct CNAME can appear updated while the target hostname still resolves to an old address.

MX records

MX records direct incoming mail. Their DNS behavior still follows TTLs, but the real-world email transition also depends on sending mail servers, queues, retries, spam filtering, authentication, and whether both old and new providers can accept mail.

Cloudflare recommends reducing an MX TTL to five minutes three to five days before certain email-security deployments. The extra preparation is operational caution, not proof that every MX change inherently needs five days.

Keep the old mail service accepting messages during the cache window when the providers allow it. DNS may change correctly while messages already queued elsewhere continue following an earlier delivery attempt.

TXT records

TXT records commonly support domain verification, SPF, DKIM, DMARC, and other services. A verifier may query DNS immediately, use a cached answer, or recheck on its own schedule. If the authoritative TXT record is correct but a setup screen still says pending, the delay may belong to the verifying service rather than DNS.

Large or malformed TXT records can also cause lookup problems that waiting will not fix.

NS records and nameserver delegation

Changing nameservers transfers authority for a domain to a different DNS service. The registrar sends the delegation to the registry or parent zone, and recursive resolvers may retain the previous NS information.

AWS states that changing a domain to Route 53 nameservers can take up to two days because resolvers commonly cache nameserver answers for long periods. Its migration documentation notes that 172,800 seconds—two days—is a typical NS TTL in some configurations.

Do not delete the old DNS zone immediately. Keep identical essential records available at both providers during the transition whenever possible.

CAA records

CAA records identify certificate authorities permitted to issue certificates for the domain. The DNS record may update within its TTL, but certificate issuance is a separate process. A stale or incorrect CAA record can block a certificate request even when the website’s A record is correct.

SRV records

SRV records provide service locations and ports for applications such as communications or directory services. The DNS TTL is only one part of the timing; client software may also cache service discovery results or keep established sessions open.

Why a Brand-New Record Can Still Look Missing

A record that did not exist before has no old positive answer to expire. It can therefore appear very quickly after the authoritative servers publish it.

However, DNS also supports negative caching. If a resolver recently asked for new.example.com and received NXDOMAIN, meaning the name did not exist, it may cache that negative answer. RFC 2308 defines this behavior, and the negative TTL is derived from the zone’s SOA record values.

This creates a counterintuitive result:

a person who never checked the new hostname can see it immediately;
a developer who tested it just before creating the record may continue seeing “not found”; and
a monitoring service may remain negative until its cached denial expires.

Deleting a record and quickly recreating it can produce the same effect. Check the zone’s negative-cache settings before a planned launch involving a previously nonexistent name.

Why Some Resolvers Show Old Data After the TTL

TTL is the maximum time a normal cache should use a record before refreshing it, but the internet is not perfectly uniform.

Possible explanations include:

the resolver applies a minimum or maximum caching policy;
a browser, operating system, router, proxy, VPN, or security product has another cache;
the query reached a different DNS view or split-horizon zone;
not all authoritative nameservers contain the same zone data;
the domain’s parent delegation still points to an old provider;
an unreachable authoritative service caused a resolver to serve stale data;
the application maintains its own cache or open connection; or
the user is checking a different record type, such as AAAA instead of A.

RFC 8767 defines a serve-stale mechanism that lets recursive resolvers return expired DNS data when authoritative servers cannot be reached, improving resilience during an outage. A stale result beyond the normal TTL can therefore be deliberate protection, not necessarily a broken resolver.

If the authoritative nameservers are reachable and consistent, stale serving should not be the normal long-term state.

DNSSEC Can Turn a Slow Transition Into an Outage

DNS Security Extensions allow validating resolvers to confirm that DNS answers are authentic. A signed zone publishes DNSKEY records, while a DS record in the parent zone establishes the chain of trust.

During a DNS-provider or nameserver migration, the old and new signing information must remain coordinated. Removing a DNSKEY while a cached DS record still points to it can make validating resolvers return SERVFAIL. Users may describe that as propagation, but waiting blindly is not a sufficient repair plan.

Cloudflare advises waiting for the DS record’s TTL to expire before changing dependent DNSSEC information. Its guidance notes that DS expiration commonly requires 24–48 hours for many top-level domains and recommends at least one full relevant TTL for each staged step.

Before changing nameservers:

determine whether DNSSEC is enabled at the registrar;
record the current DS and DNSKEY values and TTLs;
follow the old and new providers’ supported migration procedure;
do not remove trust-chain records out of order;
test with a validating resolver and a DNSSEC diagnostic tool; and
stop if signed and unsigned results disagree unexpectedly.

DNSSEC migrations deserve a written sequence and rollback plan. They should not be improvised during a live outage.

DNS, Website Cache, and SSL Are Separate

A domain can resolve to the correct new server while the browser still displays old content or a warning.

CDN or reverse-proxy cache

A content delivery network may keep an older HTML page, image, script, or redirect according to HTTP cache settings. DNS TTL and CDN cache TTL are separate values. Purging the CDN does not flush recursive DNS, and changing DNS does not automatically purge webpage content.

Browser and application cache

The browser may reuse a redirect, service worker, cached page, connection, or application result. An incognito window can help test some browser state but does not bypass every network resolver.

TLS certificate provisioning

The new server must present a certificate valid for the requested hostname. DNS can be fully correct while certificate issuance, validation, deployment, or load-balancer configuration is still pending.

Hosting configuration

The destination server must recognize the domain, serve the correct site, redirect the desired hostname, and accept both IPv4 and IPv6 traffic where published. A default hosting page is often proof that DNS reached the new server—not evidence that DNS is still old.

Database and application state

A migration may point users to two servers containing different files, sessions, shopping carts, or database data. DNS split traffic exposes that application mismatch; DNS did not create it.

DNS and Email Delays Are Also Different

After an MX change, mail can arrive at both old and new systems for a while because different sending servers hold different cached answers. Messages that previously failed may remain in an SMTP retry queue and arrive later.

SPF, DKIM, and DMARC changes can be visible in DNS while mail receivers continue evaluating messages sent before the update or while a provider’s verification screen waits to retest. Conversely, a valid MX record does not prove that the destination accepts the recipient, has the correct mailbox, or passes authentication.

For an email migration:

Create users and mailboxes at the new provider first.
Add and verify required SPF, DKIM, DMARC, and provider records.
Lower the old MX TTL well before the change.
Keep the old service active during the cache and retry window.
Change MX records and remove conflicting priorities carefully.
Test inbound and outbound mail with multiple external providers.
Monitor both systems for delayed delivery.
Increase TTLs only after stable operation is confirmed.

Do not publish two unrelated SPF records. SPF policy uses one applicable record, and an invalid policy is a configuration problem rather than a propagation delay.

How to Check Whether DNS Has Updated

Do not rely on one propagation-checker map. Test the layers separately.

Query the authoritative nameservers

Ask each authoritative server directly for the exact record type. If one returns the new value and another returns the old value, the provider’s authoritative set is inconsistent. Recursive caches cannot solve that.

Useful checks include:

dig NS example.com

dig @authoritative-name-server example.com A

dig @authoritative-name-server www.example.com CNAME

dig @authoritative-name-server example.com MX

dig @authoritative-name-server example.com TXT

Replace the example values with the real domain and authoritative server. Verify the answer, TTL, response status, and authoritative flag.

Query several recursive resolvers

Compare the default local resolver with independent public 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

Different answers with steadily decreasing TTLs commonly indicate normal cache expiration. A SERVFAIL response may point to DNSSEC, delegation, timeout, or authoritative-server trouble.

Trace the delegation

dig +trace example.com follows delegation from the root toward the authoritative servers. It helps identify an incorrect parent-zone delegation, missing glue, or disagreement between expected and published nameservers.

A trace is not a substitute for checking recursive resolvers because it largely bypasses the same cached path users take.

Check every relevant record type

Test the apex domain and www separately. Check A and AAAA, not only one. For email, inspect MX, SPF, DKIM selectors, DMARC, and the address records of mail hosts.

Test the destination directly

If DNS is correct, test the new server, CDN, certificate, or mail service independently. This separates a name-resolution problem from an application problem.

Can You Flush DNS Everywhere?

No. You can clear a local device cache, restart a home router, or use a specific public resolver’s refresh tool. Google Public DNS offers a cache-flush page for common record types. That affects Google’s recursive service; it does not command every internet provider, company resolver, browser, or device to discard its cache.

Similarly, changing the computer to a different DNS resolver can reveal the new answer if that resolver has no old cache. It does not make the original resolver update.

Local cache clearing is useful when:

authoritative servers and independent resolvers already show the new value;
only one device remains stale;
a VPN or security client was recently changed; or
testing needs a fresh local lookup.

It is not a cure for a wrong authoritative record, inconsistent nameservers, bad delegation, or broken DNSSEC.

Why “Wait 48 Hours” Is Sometimes Bad Advice

Waiting is appropriate when the authoritative records are correct and unexpired caches explain the difference. It is harmful when the configuration itself is wrong.

Do not merely wait if:

every authoritative nameserver returns the old value;
some authoritative servers return different zone data;
the registrar publishes the wrong nameservers;
DNSSEC validation returns SERVFAIL;
the record name, type, value, priority, or trailing dot is wrong;
the zone exists at the new provider but is not delegated to it;
both old and new records were accidentally left active;
a required AAAA, CAA, MX, or verification record is missing;
the destination server is not configured for the hostname; or
the TTL countdown repeatedly resets without reaching the new answer.

Propagation cannot correct a typo. First establish that the authoritative answer and delegation are right; then allow caches to expire.

A Safe DNS Change Plan

Several days before

Inventory A, AAAA, CNAME, MX, TXT, CAA, SRV, NS, SOA, DS, and DNSKEY records.
Export or copy the existing zone.
Identify the longest positive, negative, NS, and DS TTLs.
Build the new service and test it without changing public DNS.
Copy the complete zone to a new DNS provider before changing delegation.
Confirm DNSSEC migration requirements.

At least one old TTL before

Lower critical record TTLs, often to 300 seconds where supported.
Wait the full previous TTL before the cutover.
Confirm the lower TTL at every authoritative nameserver.
Keep old hosting, mail, and application services operational.

During the change

Change only the planned records.
Save screenshots or an audit log of old and new values.
Query authoritative servers directly.
Check several recursive resolvers.
Monitor traffic, errors, certificate status, and mail delivery.
Avoid unrelated plugin, CDN, firewall, or server changes that obscure the cause.

After the change

Keep the old destination available for the expected cache window.
Verify IPv4, IPv6, apex, www, email, subdomains, and APIs.
Check DNSSEC validation.
Download or preserve logs needed for diagnosis.
Restore longer TTLs only when the new path is stable.
Document the final zone and renewal responsibilities.

How Long Should the Old Server Stay Online?

Keep the old server or service available for at least the longest relevant previous TTL after the cutover, plus a practical safety margin. If nameservers changed with a two-day delegation TTL, keeping the old DNS provider and destination functioning for 48–72 hours is often sensible.

High-risk applications may need a longer dual-running period because established connections, background jobs, webhooks, mail queues, partner allowlists, and hard-coded addresses can outlive DNS caches.

The old and new systems must remain compatible during that interval. If both accept writes, plan how databases, uploads, orders, or messages stay synchronized.

What Happens If You Roll Back?

Rollback is another DNS change and creates another cache window.

Some resolvers may still hold the old pre-migration answer. Others may have cached the new destination. After rollback, a third group may retrieve the restored value. Traffic can remain split until the TTL attached to every relevant answer expires.

This is why a migration should preserve both endpoints and use short TTLs established well in advance. A low TTL cannot prevent every failure, but it reduces the time users remain on a destination after a rollback.

Document the exact time of each change. Repeatedly switching records every few minutes makes results harder to interpret and can extend mixed behavior.

If you are troubleshooting a website, home network, or online account, these guides may also help:

Frequently Asked Questions

How long does a basic DNS record change take?

Many changes appear within minutes, but a resolver that cached the previous answer can use it until the old TTL expires. With a five-minute TTL, allow roughly five to 30 minutes; with a one-hour TTL, allow at least an hour of mixed results.

Why do some people see the new website while others see the old one?

Their recursive resolvers cached the previous answer at different times. One cache may have expired while another still has valid time remaining. Different IPv4, IPv6, VPN, corporate, or application paths can also produce different results.

Does lowering the TTL make an existing DNS change faster?

Not for caches that already stored the old record. They follow the previous TTL. Lower the TTL and wait one full old TTL before changing the destination.

How long do nameserver changes take?

Allow several hours to 24–48 hours. Parent-zone and recursive NS caches often have longer TTLs than ordinary website records. Keep the old DNS zone active during the transition.

Why is a newly created subdomain still showing NXDOMAIN?

A resolver may have cached the earlier “name does not exist” response. That negative cache follows the zone’s SOA-based negative TTL even though no positive record existed before.

Can I force DNS to update everywhere?

No. You can clear caches you control and request a refresh from certain public resolvers, but you cannot flush every provider, company, router, device, browser, or application cache on the internet.

Is 24–48 hours always required for DNS propagation?

No. Routine records with short TTLs often update for most users within minutes. The 24–48-hour guidance is more relevant to long TTLs, nameserver delegation, some DNSSEC steps, or providers that publish changes slowly.

Why does DNS still look old after the TTL expired?

Check local or application caches, split DNS, VPNs, IPv6 records, inconsistent authoritative servers, parent delegation, and serve-stale resolver behavior. A wrong configuration will not correct itself with more waiting.

How long does an MX record change take?

The DNS answer follows its previous TTL, commonly minutes to a day. Actual mail delivery can remain mixed longer because sending servers cache records, queue messages, retry failures, and interact separately with the old and new providers.

Does clearing the browser cache flush DNS?

Not necessarily. Browser content, browser DNS, operating-system DNS, router, VPN, and recursive-resolver caches are separate. Clearing webpage files does not change an ISP resolver’s cached DNS answer.

Can changing DNS break an SSL certificate?

DNS does not alter the certificate itself, but directing traffic to a server without the correct certificate creates a warning. CAA records and DNS-based validation can also affect issuance. Verify certificate readiness before cutover.

Why does www work when the root domain does not?

They are different DNS names and may use different records, providers, proxies, or certificates. Check the apex and www records separately, including both A and AAAA responses.

What is the safest TTL for a migration?

Five minutes, or 300 seconds, is a common temporary value when the provider supports it. Lower it at least one full existing TTL in advance. After the migration is stable, raise it to a value appropriate for reliability and future change needs.

Can DNSSEC make propagation take longer?

DNSSEC adds DS and DNSKEY cache windows that must be staged correctly. The main risk is not merely delay: mismatched trust-chain records can cause validating resolvers to reject the domain with SERVFAIL.

Quick Summary

Most routine DNS record changes become visible to many users within a few minutes to several hours. The longest normal delay is usually controlled by the previous TTL, because resolvers that already cached the old answer continue using it until that time expires. A five-minute TTL often produces a five- to 30-minute transition, while a 24-hour TTL can preserve old answers for a full day.

Nameserver changes may require 24–48 hours because delegation records often have longer TTLs. Brand-new records can still be delayed when resolvers cached an NXDOMAIN response. DNSSEC changes require special sequencing because mismatched DS and DNSKEY records can cause complete validation failure.

Lower TTLs at least one full old TTL before a planned change, keep old and new services available during the cache window, and query each authoritative nameserver before blaming propagation. Then compare several recursive resolvers and test website, CDN, certificate, hosting, and email systems separately.

You cannot flush DNS everywhere or prove that every resolver has updated. You can confirm that the authoritative configuration is correct, wait the documented cache windows, monitor old and new traffic, and preserve a safe rollback path.

Sources & References

Editorial Review

Reviewed by Claire Bennett, Managing Editor

Last reviewed: August 2026

Quick Answer Guide publishes practical, research-based answers to common questions about money, technology, health, travel, home improvement, and everyday life. Content is reviewed using official government resources, educational institutions, industry publications, and other authoritative sources when appropriate. Articles are updated periodically to improve accuracy and usefulness.

How Long Does It Take for DNS Changes to Update Everywhere?