DNS Propagation Checker

After changing a record or moving name servers, different resolvers pick up the new value at different times. This checker queries 17 independent public resolvers in the US, Europe, Russia, China and Korea at the same moment and shows which ones already return the new value.

How propagation really works

DNS does not push changes. Each resolver caches an answer for the TTL it received, so an A record with a 3600-second TTL can stay old for up to an hour after you change it. Name server changes at the registrar take longer because the TLD’s NS records usually carry a 1–2 day TTL.

A resolver shown in amber returns something other than the majority answer — usually the old record still cached. Red means the resolver did not respond from our network. Run the check again after the TTL shown has elapsed.

DNS propagation checker at a glance

How to use this tool

1. Enter the exact name you changed: example.com for the apex, www.example.com for www, or _dmarc.example.com for a DMARC record. A pasted URL is reduced to its host name.
2. Pick the record type you changed: A, AAAA, CNAME, MX, NS, TXT, SOA or CAA.
3. Press Check propagation. The tool asks all 17 resolvers in one run, with a 2-second timeout per resolver, so a full check takes a few seconds.
4. Compare the “Most common answer” with what you published. Then look at the TTL column of the resolvers that still disagree: that number is the longest you still have to wait for each of them.
5. Run it again once the largest remaining TTL has passed. Results for the same name and type are cached on our side for five minutes and are labelled “(cached result)”, so re-running sooner returns the same snapshot.

Before you trust any resolver, check the source. Run the DNS lookup with “Authoritative name server” selected: if the authoritative server does not return the new value yet, the change was not saved in the zone that is live, and waiting will not help.

How to read the results

Field	What it means
Resolvers answering	How many of the 17 resolvers returned at least one record of the chosen type. Green when all did.
Agree on most common answer	How many resolvers returned the most frequent answer. Green when all agree, amber when at least half do, red when fewer than half do.
Most common answer	The answer most resolvers returned. This is a majority vote, not a judgement of right or wrong: early after a change the majority can still be the old value.
Green dot	The resolver returned the most common answer.
Amber dot	The resolver returned a different answer, or returned no record of this type. The Answer column shows the response code in that case, for example “NXDOMAIN — no A record” or “NOERROR — no TXT record”.
Red dot, “No response”	The resolver did not answer our query, usually a timeout after 2 seconds (the reason is shown in brackets). That says nothing about your domain; some resolvers rate-limit or filter foreign queries.
TTL	Seconds the resolver will keep its cached answer. On a resolver with the old value this is the exact time left before it asks again.

Multiple values (for example two A records) are sorted before comparison, so the order a resolver returns them in does not matter. When more than three different answers come back, the tool adds a note: large sites and CDNs return different addresses per location on purpose, so disagreement is normal for them.

Common problems and how to fix them

No resolver shows the new value after hours

The change is not in the zone the world reads. Typical causes: the record was edited in cPanel or DirectAdmin while the domain uses Cloudflare or registrar DNS, the record was saved in a zone that was never delegated, or a cluster did not sync. Compare the NS records with where you edited:

dig +short NS example.com
dig +short A example.com @$(dig +short NS example.com | head -1)

Resolvers return NXDOMAIN for a record you just created

If anything looked up the name before it existed, resolvers cached the “does not exist” answer. That negative answer is kept for the smaller of the SOA record’s TTL and its last field (minimum), as described in RFC 2308. Look up the SOA in the DNS lookup to see that value; on many zones it is 300 to 3600 seconds. Avoid testing a name before creating it when timing matters.

A few resolvers show different IP addresses that are not your old ones

If the domain is behind a CDN or uses geo-DNS, each resolver gets the addresses closest to it. Cloudflare-proxied records always return Cloudflare anycast IPs rather than your server, so do not expect to see the origin IP at all. Only treat a mismatch as stale when the value equals your previous record.

Name server change at the registrar is not showing

Delegation is cached from the parent zone, not from your new provider. For .com and .net the delegation NS records carry a TTL of 172800 seconds (two days). Check what the registry publishes, which changes within minutes of the registrar update:

dig NS example.com @a.gtld-servers.net +norecurse

If the registry already lists the new name servers, keep the old provider’s zone online and identical until the old delegation has expired everywhere. Deleting it early is the classic cause of an outage during a DNS move.

A TXT verification record is “not found” by the service

Select TXT, enter the exact host the service asked for and check whether resolvers return it. If they do, the service is probably reading a cached negative answer; wait for the SOA minimum and retry. If they do not, look for a doubled name such as _acme-challenge.example.com.example.com caused by entering the full name in a panel that appends the domain.

My own PC still opens the old server

Your browser, operating system and router cache too. Flush the local cache (ipconfig /flushdns on Windows, resolvectl flush-caches on systemd Linux, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder on macOS) and restart the browser. Google Public DNS and Cloudflare 1.1.1.1 also offer cache purge pages for individual names.

Planning a change so it propagates in minutes

1. Look up the current TTL of the record with the authoritative server. Note it down; that is how long caches may hold the old value.
2. At least one full old-TTL period before the change, lower the TTL to 300 seconds. In Cloudflare, proxied records already use 300 seconds (“Auto”).
3. Make the change. Keep the old server running and, for mail, accepting mail during the window.
4. Check here until all resolvers agree and their TTL values are at or below 300.
5. Raise the TTL back to its normal value (3600 or more) once everything points to the new target.

For MX changes, keep the old mail server accepting mail for at least the old MX TTL plus a day, and collect anything that still arrives there. Senders that cached the old MX deliver to it until their cache expires.

Official documentation: AlmaLinux wiki, Linux man pages.

Related guides: Cloudflare Tunnel (cloudflared): expose an internal service without opening ports · Cloudflare in front of cPanel: DNS, proxy mode and real visitor IPs done right · Adding MailBaby SPF, DKIM and DMARC records in Cloudflare DNS.

Frequently asked questions