DNS Propagation Checker

This DNS propagation checker queries 6 major global DNS resolvers simultaneously, Cloudflare (1.1.1.1 and 1.0.0.1), Google Public DNS (8.8.8.8 and 8.8.4.4), OpenDNS (208.67.222.222), and Quad9 (9.9.9.9), and displays their responses side by side. After you make a DNS change, these resolvers may return different answers because each one independently caches the record for the duration of its TTL. This tool shows exactly which resolvers have picked up the new value and which are still serving the old cached record.

DNS propagation is governed by the TTL (Time to Live) of the changed record, as defined in RFC 1035. The TTL is the number of seconds a resolver is permitted to cache the record before it must re-query the authoritative nameserver. A record with TTL 300 will propagate within about 5 minutes. A record with TTL 86400 may take up to 24 hours. The key insight is that propagation is not a single global event. It is a distributed, gradual process where each of the world's millions of resolvers independently expires its own cached copy at its own time.

The tool checks propagation for any DNS record type. A (IP address), AAAA (IPv6), MX (mail servers), TXT (SPF, DMARC, DKIM, ownership verification), CNAME (aliases), NS (nameserver delegation), and SOA (zone authority metadata). Select the record type that matches your change. If all 6 resolvers return the same value, a green banner confirms propagation is complete. If they show different values, a warning banner indicates propagation is still in progress.

DNS changes are one of the most common causes of unexpected downtime and email delivery failures during migrations. The problem is not the change itself. It is the gap between when the authoritative nameserver has the new value and when all the world's caching resolvers expire their old cached copies. During this propagation window, different users see different things: some connect to the new server, some to the old. Some emails go to the new mail server, some to the old one. Without a propagation checker, you have no visibility into how wide this gap is or when it closes.

For email migrations specifically, incomplete propagation creates split delivery. A situation where inbound email is divided between the old and new mail provider during the MX propagation window. If you cut over your email client immediately when you change MX records, you will likely miss messages delivered to the old server while it is still being used by some senders. Checking MX propagation across all resolvers before declaring the migration complete tells you when it is safe to fully switch over. The same applies to SPF and DMARC TXT changes. A new SPF record not yet propagated will cause authentication failures at receivers still caching the old record.

For website and API migrations, A record propagation determines when users are directed to the new server. Deploying a new application on the new server before propagation is complete means some users hit the new version and some hit the old one simultaneously. Which can cause session conflicts, data inconsistencies, and user confusion. Checking propagation before executing the cutover procedures prevents this split-traffic scenario.

The pre-change TTL reduction strategy is the single most impactful action you can take before any planned DNS change. Lowering the TTL to 300 seconds 24-48 hours before the change means all the world's resolvers will be refreshing the record every 5 minutes. When you make the change, propagation completes within 5-10 minutes rather than up to 24 hours. After confirming propagation with this tool, restore the TTL to 3600 or higher to reduce nameserver load. Use the DNS Lookup Tool to check the current TTL on your records before planning a change.

Most propagation issues trace to one of a small number of causes. Here is how to diagnose and resolve each one.

DNS propagation is a consequence of the design of the Domain Name System. DNS was designed for performance and scale. With over 300 million domains and billions of queries per day, having every device query authoritative nameservers directly for every lookup would be impossibly slow. Instead, caching resolvers store the answers to recent queries and serve them to devices on the network, dramatically reducing authoritative query load. The TTL value on each DNS record is the mechanism that balances this performance optimisation against the need for timely updates.

When a DNS change is made at an authoritative nameserver, the new value is available immediately to anyone who queries that nameserver directly. But caching resolvers worldwide are serving their cached copies to millions of clients. Each resolver will continue serving its cached copy until the TTL expires. At which point it discards the old entry, queries the authoritative nameserver, and caches the new response for the new TTL duration. This is what propagation means: the gradual expiry of cached copies across millions of independent resolvers.

The resolvers this tool queries, Cloudflare, Google Public DNS, OpenDNS, and Quad9, are the four most widely-used public DNS resolver networks globally, collectively serving hundreds of millions of users. They implement DNS strictly and refresh cached records at TTL expiry without extension. ISP-level resolvers may be less strict, sometimes holding cached values beyond the specified TTL to reduce their own query load. This means it is possible for this tool to show full propagation while some users on specific ISPs still see old values. Though this is rare and resolves within hours in most cases.

For email authentication records specifically, SPF, DKIM, and DMARC, propagation has direct deliverability consequences. Use the dedicated authentication tools for deeper analysis: the SPF Record Checker validates your SPF record syntax and mechanism count, the DMARC Checker evaluates your DMARC policy and reporting configuration, and the DKIM Analyzer verifies your DKIM public key and bit strength. Use this propagation checker to confirm those records are visible at all major resolvers before declaring an email migration complete.