DNS Propagation Checker

How the check works

01
One question, two resolvers
Your browser asks Google Public DNS (dns.google) and Cloudflare (cloudflare-dns.com) for the same record over DNS-over-HTTPS, at the same moment.
02
Answers are compared
Values are compared in one spelling, so quotes around TXT data or a trailing dot do not count as a difference. A value only one resolver returns is highlighted.
03
TTLs show the cache
Each TTL is the time that resolver may keep its copy. An old answer with a long TTL left can stay until it runs out.

How to Check DNS Propagation

Enter the domain

Type the domain or subdomain whose record you changed, such as example.com or mail.example.com. A full URL works too; only the hostname is used.
Pick the record type

Choose A or AAAA for a website address, CNAME for an alias, MX for mail, TXT for verification and SPF, or NS for name servers.
Run the check

Click Check. Both resolvers are asked at the same moment, and their answers appear side by side.
Read the verdict and the TTLs

A green banner means both return the same values. A highlighted value comes from only one resolver; its TTL tells you how long an old cached answer can last.

When to Check DNS Propagation

Moving a site to a new host

After pointing the A or AAAA record at the new server, see whether both resolvers already return the new address before you switch the old server off.

Changing mail providers

Check that the new MX records are what both resolvers return, so incoming mail is delivered to the new provider.

Domain verification records

Services ask for a TXT or CNAME record to prove you own a domain. Confirm it is visible on both resolvers before you press Verify.

Name server changes

After changing name servers at the registrar, compare the NS records to see whether the new delegation has been picked up.

Why use a DNS propagation checker?

After you change a DNS record, the change is live on your domain's name servers at once, but resolvers that cached the old answer keep serving it until its TTL runs out. That delay is what people call propagation. Asking two large public resolvers the same question at the same moment shows whether they already return the new value, and their TTLs show how long an old cached answer can last. It is a quick check for a migration, a new mail provider or a verification record, without claiming to see every resolver in the world.

DNS Propagation Checker asks two public DNS resolvers, Google Public DNS and Cloudflare, for the same record of a domain at the same moment and puts their answers side by side. It compares A, AAAA, CNAME, MX, TXT and NS records in one spelling, highlights any value only one resolver returns, and shows each resolver's remaining TTL, which is how long an older cached answer can last. It does not claim to see every resolver in the world: it names the two it asks.

Use it after a site migration, a mail provider change or a new verification record. To read one record type in more detail, use the DNS Lookup. To find the hostname behind an address in the answers, use the Reverse DNS Lookup, and to check the SPF, DKIM and DMARC records of a domain, the DNS Security Scanner.

How it compares

Many propagation checkers show a world map of results from servers in dozens of cities. This page is narrower and says so: two named public resolvers, queried from your browser, with their TTLs shown so you can see how long a cached answer can last. After a change, that is usually the question: every resolver's cached copy of the old answer expires on the record's TTL, so the TTL tells you how long to wait.

On this page, the queries go from your browser to dns.google and cloudflare-dns.com. The REST API and MCP tool are a separate path: a call sends the domain to FindUtils over HTTPS, which asks the same two resolvers and returns the comparison. FindUtils does not store that input, and logs the request without its content.

Tips for DNS Changes

Lower the TTL of a record a day before you change it, so cached copies expire quickly when you switch.
Same values with different TTLs is normal: each resolver counts down its own copy.
Check every record type a change touches; a site move can involve A, AAAA and CNAME records.
If one resolver still shows the old value, wait for its TTL to run out before you investigate further.
Raise the TTL again once the change has settled, to cut the number of queries to your name servers.

Frequently Asked Questions

What does this DNS propagation checker do?

It asks two public DNS resolvers, Google Public DNS (dns.google) and Cloudflare (cloudflare-dns.com), for the same record of a domain at the same moment, and shows their answers side by side with each TTL. It says whether they agree and highlights any value only one of them returns. It supports A, AAAA, CNAME, MX, TXT and NS records.

Does this check DNS propagation worldwide?

No. It checks two named public resolvers, not every resolver or region in the world. Google Public DNS and Cloudflare are large, widely used resolvers, so agreement there is a good sign, but an internet provider's resolver or a resolver in another network can still hold an older cached answer until its TTL runs out.

Why only Google Public DNS and Cloudflare?

The page queries the resolvers straight from your browser, which only works with resolvers that answer DNS-over-HTTPS JSON requests from a web page. Google Public DNS and Cloudflare do. Keeping the list short also means every answer on the page comes from a resolver it names.

Why do the two resolvers show different TTLs for the same record?

The TTL counts down from the moment each resolver fetched the record. If Google Public DNS fetched it 100 seconds before Cloudflare did, its remaining TTL is 100 seconds lower. Different TTLs with the same values are normal and do not mean the change has failed.

How long does DNS propagation take?

As long as the old record's TTL, counted from when each resolver last fetched it. A record with a TTL of 3600 can be served from a cache for up to an hour after you change it. Name server changes at the registrar can take longer, because the delegation records of the parent zone carry their own TTLs. Lower the TTL a day before a planned change to make the switch faster.

What does it mean when the resolvers differ?

One resolver returns a value the other does not. Usually one of them still has the old answer cached and will pick up the new one when its TTL runs out; the TTL column shows how long that can be. If the difference stays after the old TTL has passed, check that every name server of the domain serves the same records. Some large sites answer with a different address on each query to spread load; for them a difference in A or AAAA records is normal, and repeating the check shows the addresses changing.

What does NXDOMAIN mean here?

NXDOMAIN means the resolver says the name does not exist. For a new domain or subdomain, a resolver that looked up the name before it existed can keep that negative answer cached for a while, as set by the zone's SOA record. If both resolvers say NXDOMAIN, check the spelling and that the record was created on the domain's name servers.

Why does an A query also show a CNAME?

When the name you asked about is an alias, the resolver follows the CNAME to the real name and returns both. The page lists the A records it found and shows the CNAME it followed underneath, so you can see which name the addresses belong to. Use the DNS Lookup to read any one record type through Google Public DNS in more detail.

Is the domain I check private?

On this page, the domain name is sent from your browser straight to Google Public DNS (dns.google) and Cloudflare (cloudflare-dns.com) over HTTPS. It does not pass through FindUtils, and FindUtils keeps no record of it. The REST API and MCP tool are a separate path: a call sends the input you include to FindUtils over HTTPS, where it is processed and the result returned. FindUtils does not store that input, and logs the request without its content.

Run it from code

$ curl -X POST \
  api.findutils.com/api/tools/dns-propagation-checker/execute \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{"domain":"example.com","record_type":"A"}'

$ claude mcp add findutils \
  --transport http https://mcp.findutils.com/ \
  --header "Authorization: Bearer YOUR_API_KEY"
# then call findutils:dns_propagation_checker

Running a tool needs an API key. Keys are not for sale yet: ask for early access. About API keys

The REST API and the MCP tool are a separate path from this page: a call sends the input you include to FindUtils over HTTPS, where it is processed and the result returned. FindUtils does not store that input, and logs the request without its content.

API reference Add to Claude

How the check works

One question, two resolvers

Answers are compared

TTLs show the cache