DNS Propagation Checker
Verify your DNS changes have spread globally. Query 16 public resolvers across the world simultaneously and see propagation status in real time.
Why DNS Propagation Matters After Every DNS Change
Every time you update a DNS record — whether you're migrating servers, changing email providers, or adding a new subdomain — you need to verify the change has actually reached resolvers worldwide. Incomplete propagation can cause split-brain scenarios where some users reach your new server and others still hit the old one.
Critical scenarios where propagation monitoring matters:
- Server migration: If your A record is partially propagated during a migration, some users will reach the new server (working) while others hit the old one (potentially broken if you've already moved the application).
- Email provider change: Partially-propagated MX records mean emails may be split between old and new mail servers, causing messages to be lost or misrouted.
- SSL certificate issues: During a migration, if old-DNS users reach a server without the correct SSL certificate, they'll get browser security warnings.
- CDN activation: When routing traffic through a CDN by changing your CNAME, partial propagation means some users bypass the CDN entirely.
Understanding the propagation matrix
The table lists resolvers across different networks and shows the answer each one currently serves. A record is "fully propagated" only when every resolver returns the same value — not just your ISP's. Mismatches are expected in the first minutes after a change; what matters is the trend.
- All resolvers match new value: migration complete, safe to flip traffic.
- Mixed old/new answers: propagation in progress — caches are expiring at different rates depending on the original TTL.
- Some resolvers return SERVFAIL: usually a DNSSEC signature mismatch during a key rollover, not a propagation delay.
- One stubborn resolver: large ISPs sometimes hold cached records past TTL; the fix is time, not a re-query.
Common issues and fixes
- Change invisible after an hour: the previous TTL was probably 86400; drop TTL to 300 at least 24 hours before your next migration.
- ISP resolver still returns the old IP: test from
1.1.1.1or8.8.8.8to confirm it is a local cache issue, not an authoritative problem. - SOA serial not incremented: some hidden-primary setups require bumping the serial before slaves will publish the new zone.
- DNSSEC validation failures: ensure the DS record at the registrar matches the active KSK; mismatches break resolution entirely.
- Split-horizon surprises: your corporate resolver may answer differently than public resolvers — propagation looks wrong when it is just internal DNS.
What to do next
Keep the TTL low until you see convergence across every resolver in the matrix, then raise it back for cache efficiency. Schedule migrations during low-traffic windows and keep the old endpoint alive until propagation is complete.
For continuous monitoring, FlashMon.app tracks changes automatically and alerts you the moment something breaks.
Monitor DNS changes automatically
Get instant alerts the moment any DNS record for your domain changes — catch unauthorized changes before they cause downtime.
Frequently Asked Questions
DNS propagation is the time it takes for updated DNS records to spread across the global network of DNS resolvers after you make a change. When you update a DNS record (for example, changing your A record to a new IP after a server migration), the change is first applied to your domain's authoritative nameserver. However, thousands of DNS resolvers worldwide cache your old records for the duration of the old TTL value. Until those cached entries expire and the resolvers fetch the updated records, different users may see different results depending on which DNS resolver their ISP uses — this inconsistency is what's called 'propagation in progress.'
Propagation time is almost entirely determined by the TTL (Time to Live) of the record you changed. If your old A record had a TTL of 86400 (24 hours), you must wait up to 24 hours for all resolvers to expire their cached copy and fetch the new value. If the TTL was 300 (5 minutes), propagation should complete within 5–15 minutes globally. The most common mistake is forgetting to lower the TTL before making a change. Best practice: at least 48 hours before a planned migration, lower your TTL to 300. Make the DNS change, confirm propagation with this tool, then raise the TTL back to its normal value.
Each DNS resolver (Google 8.8.8.8, Cloudflare 1.1.1.1, your ISP's resolver, etc.) caches DNS records independently. After you update a record, each resolver will continue serving its cached copy until the TTL expires — at which point it sends a fresh query to your authoritative nameserver and gets the new value. Because they refresh at different times, there's a window where some resolvers have the new value and others still have the old one. Additionally, some DNS providers aggressively cache beyond the stated TTL, and some have multiple geographic cache layers that need to be invalidated independently.
The majority value is the DNS result returned by the largest number of servers in our test. It represents the 'expected' or 'correct' answer that has propagated to the most resolvers. Servers showing this value are marked as 'Propagated'. Servers showing a different value (typically the old record) are marked as 'Different' and highlighted in yellow — these are still caching the outdated information. Servers that didn't respond within 5 seconds are marked as 'Timeout'. Full propagation is achieved when all servers agree on the same value.
Not necessarily. If the majority of servers (and especially the major ones like Google 8.8.8.8 and Cloudflare 1.1.1.1) are returning the correct value, most of your users will reach your site without issues. Users whose ISP uses one of the slower-updating resolvers may still temporarily see the old destination — but this is a minority and self-corrects as TTLs expire. The cases where incomplete propagation is actually problematic: if you moved email hosting and MX records haven't propagated, emails could go to the wrong server. If you're migrating from HTTP to HTTPS and your SSL certificate is on the new server only, users hitting the old server will get certificate errors.
The only reliable way to speed up DNS propagation is to set a low TTL before making changes — you can't retroactively speed it up once the change is live with a high TTL. However, there are things that help for specific resolvers: Google's DNS cache can sometimes be purged using Google's Public DNS cache flush tool (https://developers.google.com/speed/public-dns/cache). Cloudflare's DNS cache can be purged via the Cloudflare dashboard if your domain uses Cloudflare. For most resolvers, you simply have to wait for the TTL to expire. Using multiple DNS providers with anycast routing (like Cloudflare or Google Cloud DNS) typically means faster initial propagation because their infrastructure is distributed globally.