UtilityKit

500+ fast, free tools. Most run in your browser only; Image & PDF tools upload files to the backend when you run them.

DNS Propagation Checker

Check DNS propagation across multiple global nameservers to see how widely a recent DNS change has spread.

About DNS Propagation Checker

The DNS Propagation Checker queries multiple geographically distributed public DNS resolvers simultaneously and shows the result each resolver returns for a given domain and record type. After making a DNS change — such as updating an A record, MX record, or switching nameservers — it can take 24-48 hours for the change to propagate to all resolvers worldwide. This tool lets you see which nameservers in which regions have already picked up the new record and which are still returning cached old values, giving you a real-time view of propagation progress. It supports A, AAAA, CNAME, MX, TXT, NS, PTR, and SOA record types.

Why use DNS Propagation Checker

  • Queries 15+ nameservers across multiple global regions simultaneously.
  • Supports all common DNS record types.
  • Color-codes results to instantly show consistent vs inconsistent responses.
  • Helps diagnose propagation delays after DNS changes.
  • Queries 15+ nameservers across multiple global regions simultaneously in one click.
  • Supports all common DNS record types: A, AAAA, CNAME, MX, TXT, NS, PTR, SOA, CAA, SRV.

How to use DNS Propagation Checker

  1. Enter the domain name you want to check.
  2. Select the DNS record type (A, AAAA, MX, TXT, CNAME, NS, etc.).
  3. Click Check to query global nameservers simultaneously.
  4. Review which resolvers return the new value vs cached old value.
  5. Enter the domain name you want to check (no http:// prefix needed).
  6. Select the DNS record type from the dropdown — A for IPv4, AAAA for IPv6, MX for mail servers, TXT for SPF/DKIM/verification, NS for nameservers.
  7. Click Check to query 15+ global nameservers simultaneously.

When to use DNS Propagation Checker

  • Verifying that a DNS record change has propagated globally after migration.
  • Checking whether a domain's nameserver change has taken effect.
  • Troubleshooting why a site is accessible from some locations but not others.
  • Confirming MX or SPF record updates have propagated before testing email.
  • Verifying that a DNS record change has propagated globally after a server migration.
  • Checking whether a domain's nameserver change has taken effect at major resolvers.

Examples

Check A record after migration

Input: Domain: example.com, Record: A

Output: Google (8.8.8.8): 93.184.216.34 ✓ Cloudflare (1.1.1.1): 93.184.216.34 ✓ Quad9 (9.9.9.9): 93.184.216.34 ✓ OpenDNS (208.67.222.222): 93.184.216.34 ✓ Level3 (4.2.2.1): 192.0.2.10 ✗ (stale) Result: 14/15 resolvers updated — propagation 93% complete

Check MX records

Input: Domain: example.com, Record: MX

Output: All resolvers consistent ✓ 10 mail.example.com 20 mail2.example.com TTL: 3600s on all resolvers

Check TXT (SPF) record

Input: Domain: example.com, Record: TXT

Output: Google: "v=spf1 include:_spf.google.com ~all" ✓ Cloudflare: "v=spf1 include:_spf.google.com ~all" ✓ Quad9: "v=spf1 ~all" ✗ (old SPF, cache TTL 1820s) Verdict: most resolvers have the new SPF; full propagation in ~30 min

Tips

  • Lower your TTL to 300 seconds (5 minutes) at least 24 hours before a planned DNS change so propagation completes within minutes, not days.
  • After the change is fully propagated, raise TTL back to 3600 or 86400 to reduce DNS query volume and improve cache hit rates.
  • If results are still inconsistent after 4 hours, check whether you actually saved the record at your DNS provider — accidental no-saves are common.
  • Some ISPs run their own caching resolvers with custom TTL overrides — propagation may take longer at those ISPs than at public resolvers.
  • For email delivery testing, also re-check SPF and DKIM with a separate DNS lookup tool to confirm the records resolve correctly, not just propagate.
  • If one specific resolver consistently fails, it may be querying a regional sub-resolver — re-run after 30 minutes before assuming a real issue.
  • Use NS lookup mode to verify nameserver delegation matches your registrar's WHOIS — mismatches cause hidden propagation issues.

Frequently Asked Questions

How long does DNS propagation take?▾
Most DNS changes propagate within 1-4 hours for the majority of resolvers. Full global propagation can take up to 48 hours depending on TTL values and resolver caching policies.
Why do some resolvers still show old values?▾
Resolvers cache DNS responses for the duration of the record's TTL (Time To Live). Until the cache expires, they serve the old value even after the authoritative record has changed.
How do I speed up DNS propagation?▾
Before making a DNS change, lower the TTL of the affected record to 300 seconds (5 minutes) a day in advance. This reduces cache lifetime so resolvers pick up the change faster.
Which resolvers does this check?▾
The tool queries a set of well-known public resolvers including Google (8.8.8.8), Cloudflare (1.1.1.1), and regional resolvers across North America, Europe, Asia-Pacific, and South America.
What if all resolvers show different values?▾
Diverse results are normal during propagation. Once propagation is complete, all resolvers should return consistent responses.

Explore the category

Website Status Checker Check whether any website or URL is up or down and see its HTTP response code, response time, and server headers. WCAG Contrast Checker Check foreground and background color contrast ratios against WCAG 2.1 AA and AAA accessibility standards. DNS Lookup Tool Query public DNS records with SSRF-safe hostname validation Editorconfig Generator Generate .editorconfig with global defaults and per-extension overrides. HTTP Headers Checker Inspect response status and headers from public HTTPS origins SSL Certificate Checker Peek TLS certificate metadata with SSRF-safe hostname rules
How DNS Works: A Step-by-Step Journey from Domain to IP You type a domain and a page loads — but between those two events is a surprisingly elegant distributed lookup system. Here is exactly what Feb 2026 · 9 min CIDR Notation Explained: How to Read /24, /16, and Why It Matters If a Slack message that contains '10.0.0.0/16' makes you nod and quietly Google 'what does /16 mean again', this is the post for you. Read / May 2026 · 10 min

Glossary

TTL (Time To Live)
An integer field on each DNS record (in seconds) that tells resolvers how long to cache the response before re-querying. Lower TTL = faster propagation but higher query volume.
Anycast DNS
A routing technique where the same IP (e.g. 1.1.1.1, 8.8.8.8) is announced from many physical data centers globally, and BGP routes each user to the nearest one. Used by major public resolvers for low latency and resilience.
A record
An IPv4 address record — maps a hostname (e.g. www.example.com) to a 32-bit IPv4 address. The most common DNS record type.
AAAA record
An IPv6 address record — maps a hostname to a 128-bit IPv6 address (e.g. 2606:2800:220::ace). Pronounced 'quad-A'.
CNAME record
Canonical Name record — aliases one hostname to another (e.g. www.example.com → example.com). Cannot coexist with other records on the same name.
MX record
Mail Exchange record — specifies the mail server(s) that accept email for a domain, with a priority value for ordering.
TXT record
A free-form text DNS record commonly used for SPF, DKIM, DMARC, domain ownership verification, and other metadata.
NS record
Nameserver record — declares which DNS servers are authoritative for the domain. Set at both the registrar (delegation) and the zone itself.
Recursive resolver
A DNS server that takes a client query and walks the DNS hierarchy (root → TLD → authoritative) to return a final answer, caching responses along the way.