DNS Propagation: What It Is and How to Check It

DNS propagation is the process by which updated DNS records are distributed across all DNS servers worldwide. When you change a DNS record — such as updating an A record to point to a new server, changing nameservers, or modifying MX records — these changes don't take effect instantly everywhere. Instead, they gradually spread across the global network of DNS resolvers.

During propagation, some users may see the old DNS records while others see the new ones, depending on which DNS server their device queries. This is completely normal and expected behavior.

DNS propagation takes time because of caching. Here's how the DNS caching system works:

When a DNS resolver looks up a domain for the first time, it queries the authoritative nameserver and caches the result. The cache duration is controlled by the TTL (Time to Live) value set on each DNS record. Until that TTL expires, the resolver serves the cached (old) result instead of querying the authoritative server again.

Since there are millions of DNS resolvers worldwide, each with its own cache, and each having cached the record at different times, the old records expire at different times across the internet. This staggered expiration is what we call "propagation."

Factors that affect propagation time:

• TTL value: Higher TTL = longer propagation. A record with a 24-hour TTL may take up to 24 hours to propagate fully.
• ISP DNS caching: Some ISPs ignore TTL values and cache records for longer periods.
• Local DNS caches: Your operating system and browser also cache DNS records.
• Multiple levels of caching: The request may pass through several DNS resolvers, each with its own cache.

In most cases, DNS propagation takes between 15 minutes and 48 hours, though the majority of users will see changes within a few hours.

Typical propagation times by change type:

• A/AAAA record changes: 1–24 hours (depends on the previous TTL)
• MX record changes: 1–24 hours
• Nameserver changes: 24–48 hours (registries have their own cache)
• New domain registration: Usually under 12 hours
• TXT record changes: 1–24 hours

If you're planning a migration or DNS change, you can reduce the propagation window by lowering the TTL of the affected records to a short value (like 300 seconds / 5 minutes) at least 24–48 hours before making the actual change. After the change has propagated, raise the TTL back to a longer value to reduce DNS query load.

Use LookMyIP's DNS Propagation Checker at lookmyip.com/propagation. It queries DNS servers across multiple global locations simultaneously and shows you whether each server is returning the old or new records. This gives you a real-time view of propagation progress.

What to look for:

• If all servers show the same (new) value, propagation is complete.
• If some show the old value and some show the new value, propagation is still in progress.
• If all servers still show the old value, the change may not have been applied to your authoritative nameservers yet — double-check with your DNS provider.

Lower TTL before making changes: Set the TTL to 300 seconds (5 minutes) at least 24–48 hours before you plan to make the DNS change. This ensures resolvers are already using a short cache period when the change happens.

Flush your local DNS cache: After making changes, clear your local cache to see the new records immediately on your own machine:

• Windows: ipconfig /flushdns
• macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
• Chrome: Visit chrome://net-internals/#dns and click "Clear host cache"

Use a different DNS resolver: If your ISP's DNS server is slow to update, try switching to Google DNS (8.8.8.8), Cloudflare DNS (1.1.1.1), or OpenDNS (208.67.222.222).

Don't make multiple changes during propagation: Wait for one change to fully propagate before making another. Stacking changes during propagation can lead to inconsistent states.

The term is misleading, and the misunderstanding it creates causes real mistakes.

Nothing propagates. Your authoritative nameservers do not push anything anywhere. When you change a record, the new value is available from your authoritative servers immediately — within seconds of the zone reloading.

What actually happens is expiry. Recursive resolvers around the world cached the old answer, each starting its own countdown when it first asked. A resolver that queried you 3,540 seconds ago with a 3,600-second TTL will serve stale data for another 60 seconds. One that queried 10 seconds ago will serve stale data for another 3,590. There is no coordination between them, which is why results appear to arrive in a ragged, random order.

This reframing has three practical consequences.

The maximum delay is exactly the old TTL, not 24 or 48 hours. The "48 hour" figure repeated across hosting support articles is folklore from an era when zone transfers between secondary nameservers ran on slow schedules. With a 300-second TTL, worldwide convergence takes five minutes.

Lowering the TTL after making the change does nothing. Resolvers cached the old record *with its old TTL*. Reducing it now only affects lookups that happen after the cache expires — by which point the change is already visible. The TTL must be lowered before the change, and you must wait out the original TTL for that reduction to take hold.

A resolver that shows the new value will never revert. If a checker shows mixed results, that is normal mid-transition behaviour, not a broken configuration. If a resolver flips back and forth *after* the TTL has fully elapsed, that is a real problem — usually inconsistent data between your authoritative nameservers.

Migrating a domain to a new host with no visible downtime is a scheduling problem, not a technical one. The sequence matters.

Three days before. Check the current TTL on every record you plan to change:

dig example.com A +noall +answer
example.com.   3600   IN   A   192.0.2.10

That 3600 is the number that governs your cutover window.

Two days before. Lower the TTL to 300 seconds on the records you will change. Change nothing else. Now wait at least the length of the *original* TTL — one hour in this example — so that every cached copy of the old, long-TTL record has expired and been replaced by a short-TTL copy.

Cutover day. Bring the new server up and confirm it serves the site correctly by IP or by a temporary hostname, before touching DNS. Then change the record. Convergence now takes five minutes rather than an hour.

Verify from multiple vantage points. A single dig from your own machine tells you about one resolver. Query several explicitly:

dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short
dig @9.9.9.9 example.com A +short
dig @208.67.222.222 example.com A +short

Or use the DNS propagation checker, which queries resolvers across multiple continents in parallel.

Leave the old server running for 48 hours. Some clients ignore TTLs entirely — a handful of corporate resolvers, some embedded devices, and browsers that pin DNS results for the life of a process. Keeping the old server answering costs nothing and catches them.

A week later. Raise the TTL back to 3600 or higher. Long TTLs reduce query load, improve resilience if your nameservers become unreachable, and cost nothing when records are stable.

Mixed results in a propagation checker are not always caching. Four other causes produce permanent, entirely legitimate differences.

GeoDNS. Some providers deliberately return different addresses depending on where the query came from, to route users to a nearby data centre. Two resolvers on different continents will *always* disagree, and no amount of waiting changes that.

Anycast. CDNs announce the same IP address from hundreds of locations simultaneously. Every resolver sees an identical answer, but the machine behind that address differs by geography. Here the DNS agrees and the servers differ — the inverse of GeoDNS.

Resolver-side minimum TTLs. Some public and ISP resolvers enforce a floor, refusing to honour TTLs below 30 or 60 seconds. If you set a 5-second TTL expecting instant convergence, these resolvers will still hold the record for their minimum.

Negative caching. If a record did not exist when a resolver last asked, the NXDOMAIN response is itself cached — governed by the minimum field in your SOA record, not by the TTL of the record you just created. This is the single most common cause of "I created the record but it still says not found". Check it with:

dig example.com SOA +short

The last number in the output is the negative cache TTL. If it is set to 86400, a name that was queried before it existed will return NXDOMAIN for a full day, no matter how quickly you added the record. Setting the SOA minimum to 300 is a good default for any zone that changes.

Can I force a resolver to drop its cache?

For your own machine, yes. On Windows, ipconfig /flushdns; on macOS, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder; on Linux with systemd-resolved, sudo resolvectl flush-caches. Cloudflare and Google both offer public cache-purge forms for their resolvers. You cannot flush an arbitrary third party's resolver, and you certainly cannot flush every ISP resolver on the internet.

Why does my site work on mobile data but not on Wi-Fi?

Different resolvers with different cache states. Mobile carriers use their own recursive resolvers, which cached your record at a different moment than your home ISP did. This is the clearest possible confirmation that the change is correct and simply has not expired everywhere.

Does changing nameservers take longer than changing a record?

Yes, and it is the one case where multi-day waits are real. NS delegation records are held at the TLD registry, and registries publish them with TTLs of 24–48 hours. You cannot lower those. Plan nameserver migrations with a two-day overlap during which both old and new nameservers serve identical zone data.

My hosting provider says it takes 24–48 hours. Are they wrong?

They are quoting a safe upper bound rather than a measured figure. With a 300-second TTL it will be minutes. Their number protects them from support tickets during the tail where a small number of non-compliant clients still hold old data.

Should I use a very low TTL permanently?

No. Low TTLs multiply query volume against your nameservers, increase page-load latency for users whose resolver has to re-query constantly, and remove the buffer that keeps your site reachable if your DNS provider has an outage. Use 300 during planned changes and 3600 or higher the rest of the time.