DNS
DNS change verifier
Get a plain pass or fail on whether the value you just set has actually taken effect.
Free, no accountLive check
Result
Fill in the form and press Verify the change. The verdict and the detail appear here.
What this is
"Did my dns change take effect?" is the whole question this tool answers: enter the value you just set, and it compares that value, forgivingly, against what Cloudflare and Google actually return right now, then hands back a headline rather than a dashboard to interpret.
A record you just edited at your DNS host is not the same as a record every resolver has already re-fetched; the old value stays cached, correctly, until its TTL runs out wherever it was cached. This tool reads what is cached right now at two independent resolvers and compares it against the exact value you typed, so the answer is "yes", "partly" or "no" rather than a record dump you have to compare by eye.
For why "did my change take effect" is really "has the old TTL expired yet," and how TTL fits alongside the other records a domain carries, see our blog guide "The DNS records a domain needs, and what each one actually does."
How to read the result
The comparison is forgiving on purpose: a trailing dot, a difference in letter case on a hostname, the quoting a TXT record arrives wrapped in, and whether an MX value is written with or without its priority number in front all count as the same value, because none of those differences is the mistake this tool exists to catch.
A pass here comes from precisely two resolvers - Cloudflare’s and Google’s global anycast networks - answering, not from a survey of every ISP’s own resolver around the world the way some incumbent checkers imply with a country map; it is a strong sign the change took, not a claim that every network everywhere already sees it.
A partial result names which resolver already has it and roughly how many seconds the other should need, taken from that resolver’s own TTL; a full fail shows what each resolver returns instead, so you know whether the record was never saved correctly or is simply still spreading.
Common mistakes
What goes wrong most often, and how to tell.
- Typing the value with a trailing dot or different case and calling it a mismatchDNS treats a hostname without regard to letter case, and a trailing dot after the last label is just the formal way of writing "this name is already complete" - neither is a real difference from what was actually set, which is why this check ignores both before comparing.
- Comparing a TXT value against its quoted, escaped formA resolver often hands back a TXT record wrapped in quotes with its own escaping, which looks nothing like the plain text that was typed into a DNS panel even when the two are identical once unwrapped. Comparing the raw strings byte for byte reports a perfectly correct record as broken.
- Checking again a minute after saving the recordA resolver that already cached the old value keeps answering with it until that cache naturally expires, which can be minutes or hours depending on the old TTL. Checking again immediately mostly just re-reads the same cache you read a minute ago.
Questions
What people ask about this tool.
- Cloudflare and Google each operate as one global anycast network rather than a set of country-specific servers, so there is no honest way to turn either of them into a worldwide map. Agreement between the two is the strongest signal a free tool reaching the public internet can offer; it is evidence the change is visible, not a certificate that it already is everywhere.
- The priority is a separate number from the mail server’s hostname, and a resolver can report either alongside the host or with it already stripped depending on how it was queried. Treating "10 mail.example.com" and "mail.example.com" as the same answer compares the part that actually identifies which server handles mail.
- It tells you the record was saved correctly and one resolver has already re-fetched it, while the other is still serving a cached copy from before the change. That is exactly what spreading looks like partway through, and it is expected to clear itself once the slower resolver’s TTL runs out.
- A record can be saved under the wrong name, the wrong record type, or with a typo in the value itself, and all three look identical to "it has not spread yet" until you see exactly what the resolvers currently return instead of what you expected.
Sources
Every fixed value here comes from the provider’s own documentation. These pages change, so each says the day it was last read.
- Google, “DNS-over-HTTPS (DoH) JSON API” read 11 October 2026
- Cloudflare, “Make API requests: DNS JSON” read 11 October 2026
- IETF, “RFC 1035: Domain Names - Implementation and Specification” read 13 October 2026
Use it from the API
The same check, as one request.
This example uses a name RFC 2606 reserves for documentation, ending in .example, .test, .invalid or .localhost. None of them is a real domain, and nobody can register one.