DNS Propagation Checker

When you change a DNS record (new IP, new MX, new TXT), the change has to propagate across the global network of caching DNS resolvers. Each resolver holds the old record until its TTL (time-to-live) expires, then asks the authoritative server for the new value.

TTL is typically 300 seconds (5 min) to 86400 seconds (24 hours). Until every resolver has refreshed, users at different ISPs see different records — some get the new IP, some still get the old one. That's "propagation in progress."

This tool checks 12 major resolvers simultaneously so you can see propagation status at a glance instead of waiting and re-checking manually.

Two reasons:

• Geo-DNS / GeoIP routing — Google and Cloudflare run authoritative DNS that returns different IPs depending on where the question came from. A resolver in Europe gets European IPs; a resolver in Asia gets Asian IPs. This is intentional and means visitors get the nearest edge server. Not a propagation problem.
• Round-robin / load balancing — many large sites return multiple IPs and rotate which one is listed first to spread load. The result for a single resolver query may differ from the result a moment later.

For small/medium sites without geo-DNS, all resolvers should return the same record once propagation completes.

Depends on the TTL you set BEFORE the change. Common timelines:

• 5-minute TTL — propagation complete in ~10 minutes globally
• 1-hour TTL — propagation complete in ~2 hours
• 24-hour TTL — propagation can take 24-48 hours
• Some misbehaving resolvers hold records longer than the stated TTL — up to a few days in rare cases

Pro tip: if you know you'll be changing a record soon, lower its TTL to 300 seconds a day or two before the change. Then propagation completes quickly when you make the actual switch.

A few possibilities:

• Resolver doesn't have the record yet — they may not have cached it because no one has queried for that domain through them recently
• Resolver filters the query — some family-safe resolvers (CleanBrowsing) intentionally block certain domains
• Resolver is currently overloaded — UDP responses can be dropped under load. Try Refresh.
• Timeout — the resolver took longer than 4 seconds. Rare but happens for resolvers far from our server.

A is the IPv4 address record (looks like 192.0.2.1). AAAA is the IPv6 address record (looks like 2001:db8::1). Modern infrastructure typically has both. A domain without an AAAA record only serves IPv4; one with both can serve both.

MX records tell mail servers where to deliver email for the domain. Format: priority + mail server hostname. For example 10 mail.example.com.

TXT records hold arbitrary text. Common uses: SPF (anti-spam), DKIM (email signing), DMARC (mail policy), domain ownership verification by services like Google Search Console.

PTR records do the opposite of A/AAAA records — they map an IP address back to a hostname. Where example.com → 93.184.216.34 is a forward lookup, 93.184.216.34 → example.com is the reverse.

To check a PTR record, enter an IP address (not a domain) and select PTR from the dropdown. We automatically convert the IP to its .in-addr.arpa (IPv4) or .ip6.arpa (IPv6) reverse-zone format before querying.

PTR records are mainly used for: mail server reputation (most providers reject mail from servers without proper PTR), traceroute readability, and security auditing. Most regular websites don't need PTR records at all — they're set by the network operator who owns the IP block, not by the domain owner.

SOA (Start of Authority) is the most important record in a DNS zone — every zone has exactly one. It contains the foundational information about the zone:

• Primary nameserver — which server is authoritative
• Responsible party — admin email (encoded with a dot instead of @)
• Serial number — version of the zone, incremented on every change; secondary servers use this to detect updates
• Refresh / Retry / Expire — how often secondaries should re-check, retry on failure, give up
• Minimum TTL — default TTL for records without an explicit one, also used for negative caching

Most users never need to look at SOA directly. It's useful when troubleshooting DNS propagation (the serial number tells you whether secondaries have the latest version) or when diagnosing zone configuration issues.

We construct binary DNS query packets following RFC 1035 (the DNS protocol specification), open UDP sockets to all 12 resolvers in parallel, use stream_select() to multiplex the receive side, then parse the binary responses (including DNS name compression pointers).

This is necessary because PHP's built-in dns_get_record() only queries the local resolver — there's no way to specify "ask 8.8.8.8 specifically" with native functions. So we wrote our own DNS resolver from scratch.

DNS changes slowly relative to other queries, but 5 minutes is short enough that you can monitor propagation in near-real-time. SSL is cached 24 hours, WHOIS 24 hours, ping 10 minutes, DNS 5 minutes — each tuned to how often the underlying data actually changes.

Hit "Check again" to bypass cache. Rate limit still applies (30 requests / hour / IP).