Checking from one machine asks one server. This checker lists each DNS server's exact response on its own row, so you can tell the difference between a cached old value, a missing record, and a resolver that simply did not reply.
Rows fill in the moment each resolver answers. You are not left staring at a spinner while the slowest server in the set times out.
Tell the checker what the record should say and every location is graded against it, so you see at a glance which DNS servers have picked up your change.
Paste a full URL, a bare domain, a subdomain, or an IP address. The checker strips the scheme and path, converts international names to punycode, and rejects anything that cannot be a valid hostname.
Pick A for a website address, MX for mail servers, NS for nameservers, TXT for SPF, DKIM or verification records, or any of the other types. Then press Check DNS.
The record is requested from every DNS server in the list at the same time. Each row shows the answer that server currently holds, and the map colours each location to match.
Open the options next to the record type and enter the new value. Rows that already return it are marked as a match; rows still holding the old value are flagged so you know how far the change has spread.
There is no central switchboard that pushes DNS changes out to the internet. When you edit a record, only your authoritative nameservers know about it. Everyone else finds out the next time they ask.
The catch is that resolvers remember answers. Each record carries a TTL, a number of seconds a resolver is allowed to keep reusing it without asking again. A record with a TTL of 3600 can sit in Google's cache for up to an hour after you changed it, and in your ISP's cache for the same amount of time, but those two timers started at different moments.
That is why a change looks live from one office and broken from another. DNS propagation is not a process that runs somewhere; it is simply caches expiring at different times. A global DNS propagation check gives you a snapshot of where those caches currently stand, which a singlenslookup or dig from your own machine cannot.
Practical advice: lower the TTL before a migration, not after. Set it to 300 seconds a day in advance so the old value expires quickly once you flip the switch. Then check here, wait for every row to agree, and only then decommission the old server.
The same tool works as an A record checker, MX record checker, nameserver checker, TXT record checker and more. Pick the type from the dropdown next to the domain box. If you are not sure which one applies, the third column lists the situation where each type usually matters.
| Type | What it holds | Typical reason to check it |
|---|---|---|
| A | Maps a hostname to an IPv4 address Website moved to a new server | Website moved to a new server |
| AAAA | Maps a hostname to an IPv6 address Enabling IPv6 on your site | Enabling IPv6 on your site |
| CNAME | Points a name at another hostname www pointing to a CDN or platform | www pointing to a CDN or platform |
| MX | Mail servers that accept email for the domain Switching to Google Workspace or Microsoft 365 | Switching to Google Workspace or Microsoft 365 |
| NS | Nameservers that are authoritative for the zone Moving DNS hosting to a new provider | Moving DNS hosting to a new provider |
| TXT | Free-form text, used for SPF, DKIM, DMARC and ownership checks Verifying a domain with a SaaS vendor | Verifying a domain with a SaaS vendor |
| SOA | Zone metadata including the serial number Confirming secondary nameservers are in sync | Confirming secondary nameservers are in sync |
| SRV | Host and port for a named service SIP, XMPP or Minecraft server setup | SIP, XMPP or Minecraft server setup |
| CAA | Which certificate authorities may issue for the domain Fixing a failed SSL certificate issuance | Fixing a failed SSL certificate issuance |
| PTR | Reverse DNS: maps an IP address back to a hostname Checking outbound mail server reputation | Checking outbound mail server reputation |
Most people reach for a DNS checker right after a change, when something works for them but not for someone else. These are the situations that come up most often.
Run an A record check. If most rows show the new IP and a few show the old one, you are just waiting on TTLs. If every row shows the old IP, the record was never updated at the authoritative nameservers, and no amount of waiting will fix it.
Check MX. The new provider's servers should appear on every row with the priorities you configured. A mix of old and new MX hosts means some senders are still delivering to the old mailbox.
Look up TXT and search the results for the token they gave you. Most verification systems use a handful of resolvers; if the record has not reached those yet, the check fails even though it is correct.
Query NS. This is the slowest kind of change because the top-level domain's nameservers cache delegations for up to 48 hours. Until every row lists the new nameservers, some visitors are still being served from the old DNS provider.
Check the A or CNAME record for the full hostname. Your own resolver learned the new name the moment you tested it; others will not ask until someone in their region does. Rows marked Missing simply have not looked yet.
Look up CAA. If the domain has CAA records that do not list your certificate authority, issuance fails everywhere. If you just added one, wait for every row to show it before retrying the certificate request.
Every propagation check queries this list. It mixes the big anycast networks people actually use, such as Google, Cloudflare, Quad9 and OpenDNS, with regional ISP resolvers whose caches behave independently. That spread across the Americas, Europe, Africa and Asia-Pacific is what makes stale answers visible.
United States6
Canada2
Mexico1
Brazil1
United Kingdom1
France1
Spain1
Portugal1
Netherlands1
Germany2
Switzerland2
Austria1
Denmark1
Czech Republic1
Cyprus1
Turkey1
Russia1
South Africa1
India1
Pakistan1
Bangladesh1
China4
Taiwan1
South Korea1
Japan1
Thailand1
Malaysia1
Singapore1
Indonesia1
Australia1
New Zealand1A DNS checker is a tool that queries a domain's DNS records from several DNS servers at once and shows you what each one returns. Checking from your own computer only asks the resolver it happens to use. A propagation checker asks dozens of public resolvers around the world, which is the only way to see whether a recent change has reached everyone or is still spreading.
Type your domain into the box at the top of this page, choose the record type you changed (A for a website, MX for email, NS for a nameserver move, TXT for verification records) and press Check DNS. Each resolver is listed with the value it currently returns. When every row shows your new value, the change has propagated. If some rows still show the old value, those resolvers are holding a cached copy that will expire when its TTL runs out.
When you change a DNS record, the update is written to your domain's authoritative nameservers straight away. Every other resolver on the internet keeps a cached copy of the old answer until that copy expires. DNS propagation is the period during which some resolvers have the new value and others still hand out the old one. This tool shows you which is which.
Most changes are visible almost everywhere within an hour or two. The upper bound is the TTL that was set on the old record, plus the time it takes each resolver to notice. If the old record had a 24-hour TTL, some resolvers can keep serving it for a full day. Nameserver changes at the registrar can take up to 48 hours because the top-level domain's zone has its own cache. The often-quoted "24 to 72 hours" is a worst case, not the norm.
In most cases it is propagating, just slowly, because the old record had a long TTL. If every resolver still shows the old value long after that TTL has passed, the change was probably never saved on the authoritative nameservers, or the domain is delegated to a different DNS provider than the one you edited. Run an NS check to confirm which nameservers the domain actually uses, then check the record on that provider.
Those resolvers cached the record before you changed it and have not refreshed yet. Their copy will expire when the TTL runs out. For CDN and geo-routed domains, different IP addresses per region are normal and not a sign of a problem. If a location keeps showing an old value long after the TTL has passed, check that the change was actually saved at your DNS provider.
The resolver answered, but said there is no record of that type for the name (NODATA), or that the name does not exist at all (NXDOMAIN). Right after creating a new subdomain this is normal for a little while. If it never resolves, the record probably was not created on the authoritative nameservers.
You cannot force other people's resolvers to drop their cache, but you can plan ahead. Lower the TTL on a record to 300 seconds a day before you change it, make the change, then raise the TTL again once everything has settled. On your own machine you can flush the local DNS cache and use a public resolver such as 8.8.8.8 or 1.1.1.1 to see the new value immediately.
Every check runs against 42 public recursive DNS servers in 31 countries, operated by companies like Google, Cloudflare, Quad9, OpenDNS and regional ISPs across the Americas, Europe, Africa and Asia-Pacific. Each one is queried directly, so what you see is what that resolver would return to a real user in that region.
Your computer, your router and your ISP each keep their own DNS cache. If any of them still holds the old record you will keep seeing the old site even when this page shows the change is live everywhere. Flushing the local DNS cache and restarting the browser usually fixes it.
Yes. Enter the full hostname, such as mail.example.com or www.example.com, exactly as it appears in your DNS zone. Subdomains are looked up the same way as the root domain and have their own records and TTLs.
Yes. Choose the AAAA record type to check the IPv6 address a hostname points to. You can also run reverse DNS checks for IPv4 and IPv6 addresses with the PTR type.
Yes. There is no sign-up, no limit on the number of checks for normal use, and no tracking of the domains you check. Results can be shared with a link that re-runs the same check.