DNS Propagation Checker

How we check, and what this check does not show

Queries go from our server to 15 public resolvers run by different operators over DNS-over-HTTPS, and directly to the domain's authoritative nameservers. Most public DNS services use anycast, so the answer comes from the point of presence nearest to our server, not from servers in different countries. This is a comparison of how different public resolvers see the domain, not a check "from 30 countries".

We cannot see your ISP's resolver, your router or your computer's cache: they may still hold an old answer after every public resolver has updated. Results are cached for 60 seconds.

Why DNS changes take up to 24–48 hours to propagate

A new value appears on the authoritative nameservers almost as soon as you save it in the dashboard. But every resolver that already asked for the record keeps the old answer cached until its TTL expires, and only then asks again. With a TTL of 3600 that is up to an hour; with 86400, up to a day.

Changing nameservers at the registrar takes longest: the delegation in the TLD zone (.com, .uk, .de…) is often cached for 1–2 days. That is where the familiar "24–48 hours" comes from. How to speed up a move and clear your local cache is covered in the guide below.

Free DNS Propagation Checker

This tool shows whether a domain's DNS records have updated across different public resolvers. We query 15 services in parallel over DNS-over-HTTPS (Google Public DNS, Cloudflare, Quad9, OpenDNS, AdGuard, NextDNS, Control D, Mullvad, DNS.SB, AliDNS, DNS4EU, SWITCH, CZ.NIC, Yandex, IIJ) and ask the zone's authoritative nameservers directly. Each row shows the answer, the remaining TTL and the response time; identical answers are grouped and differences highlighted. Add an expected value, such as your new IP, to see at a glance which resolvers already return it. The check is free; results are cached for 60 seconds.

15 public DNS resolvers from different operators, queried in parallel in 1–2 seconds

A direct query to the domain's authoritative nameservers as the reference for comparison

A, AAAA, CNAME, MX, TXT, NS, SOA and CAA records, including subdomains such as www and _dmarc

Remaining TTL per resolver and an estimate of how long an old answer may persist

Identical answers grouped, differences highlighted

Expected value field: a per-resolver tick showing whether it already returns your new IP or record

How to Use

Enter a domain or subdomain (you can paste a page URL; we take the host name from it)
Pick the record type and, optionally, enter the expected value, such as the new server IP
Compare the answers with the authoritative nameservers; if some resolvers lag behind, click “Check again” later — their TTL tells you roughly when

FAQ

No, and we do not present it as one. All queries leave from our server, and most public DNS services use anycast, answering from the point nearest to it. The tool shows how different DNS operators and the domain's own authoritative servers see the domain, which is enough to tell whether a change has propagated.

No longer than the record's previous TTL: resolvers that cached the old value will ask again once it expires. Changing nameservers at the registrar takes longer, up to 24–48 hours, because the delegation in the TLD zone is cached for a day or two.

That is how CDNs, load balancers and GeoDNS work: the authoritative server returns different addresses depending on who asks, or in rotation. If the authoritative nameservers in our report also answer differently, the difference is expected, not a propagation problem.

The old answer is held by your ISP's DNS, your router, your operating system or your browser, none of which we can check. Flush the DNS cache on your computer and in the browser, or temporarily switch to a public resolver; the guide on this page explains how.

Up to 6 checks per minute per IP plus a daily free allowance, tripled after free sign-up. Repeating the same domain and type within 60 seconds is served from cache and does not count toward the daily limit.

What DNS propagation actually is

"DNS propagation" is a loose but established term. Nothing is pushed anywhere: once you save a record in your DNS dashboard, the new value appears on your zone's authoritative nameservers almost immediately. The delay comes from caches. Every resolver that has already looked up your domain — your ISP's DNS, Google, Cloudflare, your router, your operating system, your browser — keeps the old answer until its TTL expires and only then asks again. So checking DNS propagation really means asking: who still has the old value cached?

The report above shows this directly. The authoritative nameserver rows show the zone's current value; the public resolver rows show what each one hands out to users right now. If the nameservers already return the new value and some resolvers still return the old one, nothing is broken — you are waiting for their TTL to run out.

How to read TTL and how long to wait

TTL (time to live) is the number of seconds a resolver may cache a record. On an authoritative server you see the full TTL; on a public resolver you see what is left — how many more seconds it will keep serving what it already knows.

TTL	How long an old answer can live	Where you see it
60–300	1–5 minutes	Cloudflare proxied records (Auto = 300), records prepared for a move, load balancing
3600	up to an hour	the default at many registrars and hosts
14400–86400	4–24 hours	MX, TXT, NS; older zones where nobody touched the TTL
172800	up to 2 days	NS delegation in the .com/.net zone and many other TLDs

The key point: you wait for the old TTL. If a record had a TTL of 86400 and you set 300 at the same moment you changed the IP, resolvers that fetched it yesterday will still hold it for up to a day — they only learn the new TTL on their next query.

Negative answers are cached too. If you visited new.example.com before creating the record, resolvers remember the NXDOMAIN for the period defined by the zone's SOA record (the lower of the SOA's own TTL and its minimum field). Select the SOA type in the tool to see those values.

How long does DNS propagation take when you change an A record?

As long as the old TTL, if you prepare properly:

At least one old TTL period ahead (a day is safe), lower the TTL on your A/AAAA records to 300.
Wait until the public resolvers in the report no longer show a TTL above 300 — the long TTL has worked through.
Change the IP. Put the new address in the expected value field and recheck: within 5–10 minutes nearly every resolver should return it.
Keep the old server running for another day. ISPs and corporate networks that ignore short TTLs will keep sending some visitors there for a while.
Once things are stable, raise the TTL back to 3600 or more.

Mail works the same way: when you change MX records, the old mail server must keep accepting mail for at least the old MX TTL. Confirm the result with the MX lookup and the SPF checker — SPF is the record people most often forget during a mail move.

Changing nameservers: why 24–48 hours, and how to move safely

Switching DNS providers means changing the nameservers at your registrar. The registrar usually passes them to the TLD registry within minutes to an hour, but resolvers that already know the old delegation keep it until the TTL of the NS records in the parent zone runs out. For .com that is 172800 seconds — two days. Until then, some visitors' resolvers ask the old nameservers and some ask the new ones.

Hence the main rule: keep the zone identical on the old and the new provider for the whole move. Copy every record (A, AAAA, CNAME, MX, TXT including SPF, DKIM and verification strings) to the new provider before switching NS, and do not delete the old zone for at least two days. Then it does not matter which nameserver a resolver reaches — the answer is correct.

To check: select the NS type to see which delegation public resolvers have cached, then SOA to see the primary server (mname) and the zone serial number. If the authoritative nameservers in the report answer differently, the zone is out of sync between them. What is set at the registrar is shown by a WHOIS lookup.

Cloudflare: the orange cloud and "wrong" IPs

When a record is proxied by Cloudflare (orange cloud), resolvers return Cloudflare's IP addresses rather than your server's, with a TTL of 300. That is why moving a server behind Cloudflare involves no DNS propagation at all: you change the origin IP in the dashboard, the public addresses stay the same, and Cloudflare starts connecting to the new server almost at once. Your real IP only shows up in the report if you switch the record to DNS only (grey cloud) — not worth doing just to check, because it exposes your origin address.

The reverse case: you just added a domain to Cloudflare and some resolvers still return your old host's IP. That is not a Cloudflare fault but old nameservers still cached — see the nameserver section above.

Why your ISP still shows the old IP

ISP cache. Some ISPs enforce a minimum TTL or serve an expired answer when they cannot fetch a fresh one quickly (serve-stale, RFC 8767). We cannot see that resolver, so the report can be all green while you still get the old site.
Device and browser cache. Windows, macOS and browsers keep their own DNS caches.
The hosts file. A leftover line in C:\Windows\System32\drivers\etc\hosts or /etc/hosts overrides any DNS.
Secure DNS in the browser. With Chrome's Secure DNS turned on, the browser asks its chosen provider instead of your system DNS, so the browser and the command line can disagree.

How to flush the DNS cache on Windows, macOS, Linux and Chrome

Windows (Command Prompt as administrator):

ipconfig /flushdns

macOS (Terminal):

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Linux with systemd-resolved:

resolvectl flush-caches

Chrome: open chrome://net-internals/#dns and click "Clear host cache", then on chrome://net-internals/#sockets click "Flush socket pools". Firefox: about:networking#dns, "Clear DNS Cache".

The big public resolvers let you request a refresh for a specific name: Google Public DNS has a Flush Cache page and Cloudflare 1.1.1.1 has Purge Cache. Your ISP's cache cannot be flushed this way; either wait out the TTL or temporarily set a public resolver in your network settings.

To see every record of a domain in one go, use DNS Lookup.