Why do some users see new DNS record while others see old?

Different users use different resolvers with independent caches. Google 8.8.8.8 may refresh quickly; ISP resolvers may cache longer. Expected behavior during propagation window. Keep old services running until propagation confirmed complete across all resolvers.

DNS Propagation Checker

Check DNS propagation status for any domain — verify whether your DNS changes have spread to public resolvers worldwide. Diagnose slow or incomplete propagation. Free online DNS propagation checker.

Why Check DNS Propagation?

Confirm your DNS changes are live globally: After updating DNS records, changes don't appear instantly — they propagate gradually as resolvers across the world refresh their caches. A propagation check tells you whether your changes are visible to the public internet or still being served from stale caches.
Diagnose "works for me but not for others" problems: Different users see different DNS results during propagation windows — some see the new record, others the old one, depending on which resolver they use and when it last refreshed. A propagation check reproduces this inconsistency and identifies its scope.
Determine when migration cutover is safe: For migrations where the old server must be kept running until all users are on the new server, DNS propagation checking tells you when the old server traffic has dropped to near zero — indicating global propagation is complete.
Verify TTL reduction took effect before migration: Lowering TTL before a planned migration only helps if resolvers actually refreshed after the TTL change — querying from multiple locations confirms the new (lower) TTL is being served globally before the migration window opens.
Investigate propagation anomalies: Occasionally, certain ISPs or regions receive DNS updates much later than others due to resolver caching policies or network topology — propagation checking from multiple resolver locations helps identify geographic propagation gaps.

Check DNS Propagation

How to Check DNS Propagation

Enter the domain you changed: Type the exact domain or subdomain whose DNS record you recently modified — use the same name you changed in your DNS provider's control panel.
Select the record type you changed: Query the specific record type you modified (A, MX, TXT, CNAME, etc.) — this returns the current value being served by public resolvers for that record type.
Compare the result to your expected value: If the lookup returns your new record value, propagation has reached the queried resolvers. If it still shows the old value, propagation is still in progress for those resolvers.
Re-query after TTL expires: If propagation isn't complete, wait for the old record's TTL period to elapse, then check again — resolvers can't update their cache until the cached TTL expires.
Query multiple times over time: Run the same lookup every 5-15 minutes during a migration to track propagation progress and determine when the new records are universally live.

Real-World Use Case

A hosting company migrates a high-traffic e-commerce site to a new server at a new IP address. They lower the A record TTL to 300 seconds 24 hours before the migration, then update the A record to the new IP during a 2 AM maintenance window. By 2:15 AM they run DNS propagation checks and see the new IP from some resolvers but the old IP from others. Rather than declaring the migration complete, they keep both servers running and check propagation every 15 minutes. By 3:30 AM, all queries return the new IP — they then shut down the old server safely, having used propagation checking to confirm the migration window rather than relying on a fixed time estimate.

Understanding DNS Propagation

Propagation is not instant: DNS changes don't broadcast — resolvers only update their cached records when the TTL expires and they re-query the authoritative nameserver. The propagation window equals the TTL of the old record before the change.
Different resolvers propagate at different rates: Major public resolvers (8.8.8.8, 1.1.1.1) typically refresh quickly; ISP resolvers may cache for longer periods or ignore TTL reductions. This creates the "works for me, not for others" effect during migrations.
Lower TTL before changes to speed propagation: Reduce your record's TTL to 300-600 seconds at least 48 hours before a planned change — this pre-stages resolvers to refresh frequently, making the actual change propagate within 5-10 minutes instead of 24+ hours.
Negative caching (NXDOMAIN) also propagates: If a record was recently queried and returned NXDOMAIN (not found), resolvers cache that negative response for the negative TTL period — newly added records won't appear until that negative cache expires.
Propagation is complete when 100% of queries return new value: Don't declare migration complete until you've confirmed the new record is being returned consistently — occasional old-value results indicate stragglers still propagating.

Performance & Limits

Live resolver queries: Each lookup queries public DNS resolvers in real time via DNS-over-HTTPS — results reflect the current state of propagation, not a simulated view.
All record types supported: Check propagation for any record type — A, AAAA, MX, TXT, CNAME, NS, SOA — not just the most common types.
Fast query response: Results return within 200-800ms, enabling rapid re-querying during time-sensitive migration windows.
No installation or account: Browser-based tool requires no software, command-line access, or registration.
Unlimited queries: No rate limiting — run as many propagation checks as needed during active migrations.

Common DNS Propagation Mistakes

Not lowering TTL before migration: The most common propagation mistake — making DNS changes with a 24-hour TTL means users experience a full day of inconsistency. Always pre-lower TTL before planned changes.
Declaring propagation complete too early: Seeing the new record in one query doesn't mean all resolvers have updated — wait until multiple consecutive queries return the new value before decommissioning the old server.
Testing propagation from your local network only: Your local resolver may have cached the new value while others haven't — always test from multiple resolver perspectives, not just your own browser's cache.
Confusing authoritative vs. recursive resolver timing: The authoritative nameserver always has the latest record immediately — only recursive resolvers (what end users query) have caches that need to expire. Checking authoritative results directly will always show the new record even before propagation completes.

Privacy & Security

DNS-over-HTTPS queries: All propagation checks use DoH, keeping your query targets private from network-level observation.
No logging: Domains queried are not stored or retained beyond the current browser session.
Public DNS data only: DNS records are publicly accessible by design — propagation checking reads only publicly available information.
No account required: Check DNS propagation without registration or personal information.

Frequently Asked Questions

How long does DNS propagation take?

DNS propagation time is determined by the TTL (Time To Live) of the record being changed. If your A record has a TTL of 3600 seconds (1 hour), resolvers that cached the old record will serve it for up to 1 hour after you make a change. Common TTLs range from 300 seconds (5 minutes, fast propagation) to 86400 seconds (24 hours, slow propagation). The widely-cited "48-72 hours for DNS propagation" is outdated — modern DNS changes with low TTLs propagate globally in minutes. To achieve fast propagation, reduce your TTL to 300 seconds at least 48 hours before making changes.

Why do some users see the new DNS record while others still see the old one?

During DNS propagation, different users see different results because they use different DNS resolvers with independently-managed caches. Your colleague who uses Google's 8.8.8.8 resolver may get the new record immediately after TTL expiry, while a user on a slow-refreshing ISP resolver may see the old record for hours longer. This is expected behavior — it's called the "propagation window" and is the reason you should keep old services running until propagation is confirmed complete. The inconsistency typically resolves within the old record's TTL period once all resolvers refresh their caches.

Does DNS propagation work the same for all record types?

Yes — propagation mechanics are the same for all record types (A, MX, TXT, CNAME, etc.). Each record has its own TTL, and propagation completes when that TTL expires and resolvers re-query. However, practical propagation times differ: A records often have shorter TTLs (common values: 300-3600s) while MX records sometimes have longer TTLs (3600-86400s). TXT records used for domain ownership verification sometimes have very low TTLs since they're frequently added/removed. Always check the TTL of the specific record type you changed to estimate propagation time, rather than assuming a fixed duration.

Can I speed up DNS propagation after making a change?

You cannot force resolvers that have cached your old record to refresh early — they'll cache it for the full remaining TTL duration. What you can do proactively (before future changes): reduce the record's TTL to 300 seconds at least 48 hours before your planned change. This pre-stages resolvers to update within 5 minutes of your actual change. After a change is already made with a high TTL, you're limited to waiting for the TTL to expire. Some large public resolvers (like Cloudflare's 1.1.1.1) have cache-flush tools that can accelerate propagation for their specific resolver, but these don't affect other resolvers on the internet.