What is DNS propagation?

DNS propagation is the period after a DNS change is made during which different resolvers worldwide may return different values — some still serving the cached old record, others fetching the freshly updated one. It ends once every resolver's cached copy has expired and the new record has been re-fetched.

How long does DNS propagation take?

In most cases, propagation completes within the TTL you set on the record plus a small margin (typically 10–30 minutes for a 3600s TTL). Some ISP resolvers ignore TTL caps and cache for up to 48 hours, which is why the old "48-hour rule" exists. Modern public resolvers like Google (8.8.8.8) and Cloudflare (1.1.1.1) respect TTL closely.

What TTL should I set before a migration?

Lower your TTL to 300 seconds (5 minutes) at least one full original TTL cycle before the migration. This ensures all resolvers have re-fetched the record with the new short TTL, so after you make the final change, propagation completes in roughly 5 minutes instead of hours.

Why do some users see the new site while others see the old one?

Each user's DNS resolver has its own cache with its own expiry clock. Resolvers that queried the authoritative server after your change serve the new record immediately; resolvers that cached the old record continue serving it until their TTL expires. This is expected behavior, not an error.

Does a TTL of 0 mean instant propagation?

A TTL of 0 tells resolvers not to cache the record at all, so every lookup goes directly to the authoritative server. In practice, many resolvers enforce a minimum cache of 30–300 seconds for stability, so you may still see a short lag even with TTL=0.

What is the difference between authoritative and recursive resolvers?

Authoritative nameservers hold the definitive records for a zone. Recursive resolvers (used by end users) query authoritative servers on behalf of clients and cache responses according to the TTL. Changes take effect on the authoritative server instantly but reach end users only after recursive resolver caches expire.

DNS Propagation Checker

Name: DNS Propagation Checker
Availability: InStock
Author: Nham Vu

Understand DNS propagation and estimate how long your DNS changes will take to reach global resolvers based on TTL settings.

Propagation Estimator

Client-side estimation — no live DNS queries made.

Current TTL (seconds)

Record Type

Resolver Profile to Target

Enter your TTL and click Estimate Propagation to see the timeline.

What is TTL?

Time To Live — the number of seconds a resolver is allowed to cache a DNS record before asking the authoritative server again. Shorter TTL means faster propagation but higher query load.

Why the "48-hour" myth?

The old 48-hour figure came from ISP resolvers that ignored TTLs and cached for up to two days. Modern resolvers respect TTL, so most propagation now completes within a few hours or less.

The DNS Propagation Sequence

1

You update a record on your authoritative nameserver.

Change is instant on the authoritative server.
2

Resolvers that already have the old record cached keep serving it until their TTL expires.

No action on their side until cache expires.
3

Once a resolver's TTL expires, it queries the authoritative server and gets the new record.

From this moment that resolver returns the new value.
4

Repeat for every recursive resolver on the planet.

Propagation is complete when all cached copies have expired.

Summary

Understand DNS propagation and estimate how long your DNS changes will take to reach global resolvers based on TTL settings.

How it works

Enter the TTL value currently set on your DNS record (in seconds).
Select the record type you changed (A, AAAA, CNAME, MX, TXT, etc.).
Choose the resolver profile that matters most to you.
The estimator calculates the maximum cache window and adds a safety margin for slow resolvers.
Read the propagation timeline and tips to minimize user impact during the cutover.

Use cases

Estimate downtime window before pointing a domain to a new host.
Verify that a low TTL pre-staged before migration has fully expired.
Explain to clients why some users still see the old site after a DNS change.
Plan maintenance windows around DNS caching behavior.
Understand why MX record changes affect email delivery timing differently from A records.
Debug inconsistent site access after moving to a new IP address.
Confirm when a TXT/SPF update has propagated for email deliverability.
Educate team members on resolver caching before a domain migration.

Frequently Asked Questions

Last updated: 2026-06-09 · Reviewed by Nham Vu