The DNS Propagation Checker queries DNS servers around the world to verify that your DNS record changes have propagated globally. After updating A, AAAA, MX, NS, or CNAME records, use this tool to confirm that the new values are visible from multiple geographic locations.
Use Cases
•Verify DNS changes after switching hosting providers
•Monitor propagation progress after updating MX records
•Troubleshoot why some users see different DNS records
•Confirm global DNS consistency after migration
How to Use
•Enter the domain name you want to check propagation for
•Click "Run" to query DNS servers across multiple locations
•Compare results from different regions to check propagation status
Frequently Asked Questions
DNS propagation typically takes 24 to 48 hours, though many providers update within a few hours. Factors include the TTL (Time To Live) value of your DNS records, your DNS provider, and the caching policies of recursive resolvers.
You can check A (IPv4), AAAA (IPv6), MX (mail exchange), NS (nameserver), CNAME (canonical name), and TXT record propagation. The checker queries multiple global resolvers for each record type to provide a comprehensive view.
Different DNS resolvers around the world update their caches at different times. Some may have the old records cached while others already show the new ones. This is normal during the propagation window and is why we query multiple global locations to give you an accurate picture.
Usually by design, not by error. Anycast DNS and large CDNs return different addresses depending on which resolver asks, steering each client to a nearby edge. That is normal and desirable. The answer only becomes a problem during a migration, when the variation means some resolvers still hold the old record and others have the new one — which is exactly the state this page is built to expose.
That this page got no answer from that particular server: a timeout, a blocked UDP query, or a network path that drops direct DNS. Some networks and containers deliberately prevent direct external queries. Check whether the failure is consistent across runs and whether other resolvers answered — if several fail while others succeed, the problem is reachability rather than your domain.
It follows the lowest TTL among the records involved, and that is often longer than people expect — a day is common for records set to 86400. Lower the TTL before a planned migration so you are not waiting out a long cache, and raise it again afterwards. Checking propagation here repeatedly is how you confirm it has finished rather than assuming the clock worked.
No, it only means the resolvers agree. Every one of them could be consistently wrong, holding a record you forgot to update or an answer cached from before the change. Agreement is a necessary condition, not a sufficient one: for what a domain should resolve to, the DNS checker and record pages are the tools that read the authoritative answer.
Yes, and that is the primary use. Run it repeatedly through the change and watch the split resolve: resolvers that still return the old target stop answering that way as their caches expire, and consistency returns once the last one updates. If a single resolver stays behind long after the others have moved, the problem is its cache rather than your records.
How the Resolvers Are Queried
Enter a domain and this page asks eight public resolvers directly — Cloudflare, Google, Quad9, OpenDNS and others — and reports what each one returns. The point is disagreement: a resolver still holding an old answer is exactly what makes a migration appear broken for some visitors.
1Send each query to that specific resolver rather than to this machine's own resolver. An earlier version listed eight servers but called the system resolver eight times, so every row showed one answer and agreement was guaranteed — the page could not detect the problem it existed to find.
2Record each answer with its response time, and mark a resolver that failed or returned nothing as unresolved rather than omitting it. A resolver that cannot be reached is itself worth seeing, since some networks block direct UDP to port 53.
3Judge consistency from the answers actually received: consistent only when every resolver that replied returned the same record. A split answer is the finding, and it names exactly which resolvers are behind.
Split answers are often normal rather than broken. Large CDNs and anycast providers deliberately return different addresses to different resolvers, so disagreement is only a problem when you are mid-migration and the two answers differ in kind — an old host alongside a new one.
Tips & Best Practices
•Test DNS propagation from multiple geographic locations
•Monitor propagation status after DNS changes
•Use propagation checking to verify DNS migration completion
•Check propagation delays that may affect certificate validation
Technical Details
Propagation: DNS record propagation checking across resolvers Locations: Multiple geographic locations for comprehensive coverage Resolvers: Public and custom DNS resolver testing Output: Propagation status with location-specific results
