Free tools
DNS propagation checker
Read one record from the zone's own authoritative nameservers and from three public resolvers at once. The authoritative answer is what your users will eventually see; the public resolvers show how far it has spread.
How the authoritative view is found
The tool walks down from the registrable domain to find the zone that actually owns the name (a delegated subdomain has its own nameservers), then asks those servers directly, bypassing every cache. This is the same walk DoDomain uses to verify a customer's records, so a record this page shows as authoritative is a record the connect flow would accept.
Nothing actually propagates
"Propagation" is the wrong metaphor, and believing it is the reason people wait for something that already happened. DNS does not push a change outward. When you edit a record, your provider writes it into the zone and the authoritative nameservers start answering with the new value immediately; that part is done in seconds.
What takes time is the opposite: caches expiring. Every recursive resolver that asked before your change is holding the old answer, and it is entitled to keep serving it until the time-to-live it was given runs out. Nobody can expire that entry from outside. So the honest question is never "has it propagated" but "is the authoritative answer right, and how long until the caches that hold the old one let go", which is exactly the two columns this page shows.
A resolver that never asked about your name gets the new value on its first query. This is why a record can look live to a colleague on a different network and stale to you within the same minute, with nothing wrong anywhere.
The glossary entry on DNS propagation covers the same ground in plain terms, including negative caching and nameserver changes.
TTL, and how to plan a change
A TTL is a number of seconds attached to every answer. It is a ceiling, not a schedule: the resolver may cache the answer for up to that long, and clocks start when that resolver asked, not when you published. A record with a TTL of 3600 that was fetched 59 minutes ago will refresh in a minute; the same record fetched ten seconds ago will not refresh for an hour.
The sequence that makes a cutover fast is therefore front-loaded:
- Lower the TTL on the records you are about to change to something small (300 seconds is a common choice).
- Wait one full old TTL. This is the step people skip. Until the previous long TTL has expired everywhere, resolvers are still holding an answer that says "cache me for an hour"; the new short TTL only applies to lookups made after they refresh.
- Make the change. The worst case is now five minutes, not an hour.
- Once the new value is stable, raise the TTL again.
Absence is cached too. When a name does not exist, resolvers apply negative caching (RFC 2308): the duration comes from the zone's SOA record and is bounded by that record's own TTL. This is the mechanism behind the most frustrating version of the problem: you look up a record before creating it, get "no such name", create it, and then still see nothing for a while. The record is fine; the negative answer is cached. How long depends on the zone: the TTLs we measured across 36 zones ran from one minute to two days, with a median of 15 minutes.
Nameserver changes are the slow case, and the one you cannot optimise. The delegation lives in the parent zone at the registry, with a TTL of two days for .com, .net and .uk and between 15 minutes and a day for the other top-level domains we measured, and it is not a value you control. Keep the old nameservers serving the old records until it expires rather than deleting the zone the moment the new ones are live.
Authoritative, recursive, stub: who answers what
Three different kinds of server are all called "DNS", and knowing which one you are looking at is most of debugging.
Authoritative nameservers hold the zone. They answer from the zone data itself and never cache anything on your behalf; they are the source of truth, and they are what the left-hand column of this page reads. Recursive resolvers (your ISP's, your company's, or a public one like 1.1.1.1, 8.8.8.8 or 9.9.9.9) do the legwork for clients: they ask the root servers which nameservers serve the TLD, ask those which nameservers serve the domain, ask those for the record, and cache every step for its TTL. Stub resolvers are the thin client in your operating system that simply forwards to a recursive resolver; browsers add a small cache of their own on top, which is why flushing the OS cache sometimes does not seem to help.
Almost every "DNS is broken" report resolves to identifying which of these three is holding the wrong answer, and only the first one is yours to fix.
Delegation, NS records and lame servers
A zone ends where a delegation begins. The parent zone publishes NS records naming the child's nameservers, and those parent-side records are what resolvers follow; the child publishes its own NS set at its apex too, and when the two disagree you get behaviour that depends on which server a resolver happened to ask. Checking the delegation at the parent is the first thing to do when a domain resolves for some people and not others.
When a zone's nameservers are named inside the zone they serve (ns1.acme.com serving acme.com), the parent must also publish their addresses as glue, or resolving them would require resolving them. Missing glue is a real and confusing outage.
A lame delegation is a nameserver listed in the delegation that does not actually serve the zone. Because resolvers try the listed servers in whatever order suits them, lameness shows up as intermittent failure rather than a clean one. Delegation also applies below the apex: if eu.acme.com has been delegated to its own nameservers, a record at api.eu.acme.com lives in that zone, and editing it in the acme.com dashboard changes nothing. That is the case the walk above exists for, and the provider detector will name the owning zone and the host that serves it.
The record types this tool reads
| Type | What it carries | What to watch for |
|---|---|---|
A | One or more IPv4 addresses for the name. | Several A records at one name are a round-robin, not a mistake; resolvers hand them out in varying order, so two views can list the same set differently and still agree. |
AAAA | One or more IPv6 addresses for the name. | An absent AAAA is not an error: it means the name is IPv4-only. Publishing an AAAA that points somewhere dead is worse than publishing none, because IPv6-capable clients prefer it. |
CNAME | An alias: this name is another name, and the resolver restarts the query there. | A CNAME cannot coexist with any other record at the same name, which is why it can never sit at a zone apex. A proxy in front of the zone may also flatten it, so the authoritative answer comes back as addresses rather than the target you entered. |
TXT | Free text. In practice: domain-ownership proofs, SPF policies, DKIM keys, DMARC policies. | A value longer than 255 characters is transmitted as several chunks that receivers join back together; that is one record, not two. Two separate records at one name is a different thing, and for SPF it is an error. |
MX | Mail exchangers for the domain, each with a numeric preference. | Lower preference wins. MX targets must be hostnames with address records; pointing an MX at an IP address or at a CNAME is invalid, however many providers accept the input. |
These five are the types a DoDomain connect session can request, write and verify, which is why they are the five offered here. The CNAME row hides the single most expensive assumption in custom-domain work: because a CNAME may not share a name with any other record, and a zone apex must always carry SOA and NS records, a CNAME can never be created at acme.com itself. Providers sell their own answers to that: ALIAS, ANAME and CNAME flattening, and they are provider features, not DNS. The apex-domain guide goes through what each one does and which providers offer one.
When the views disagree and it is not caching
A stale public resolver is the boring explanation and usually the right one. The alternatives worth checking, roughly in the order they occur:
- A proxy in front of the zone. With Cloudflare's proxy enabled, the authoritative answer for a proxied name is Cloudflare's edge address, not the value you typed, and a proxied CNAME may be flattened into address records. The record is saved correctly and reads back wrong. Setting the record to DNS-only makes the published value visible again.
- Two records where you expected one. An old A record left beside a new one, or a value added rather than replaced, gives both views an answer set larger than intended, and they may still agree with each other.
- The wrong name. A record created at
www.acme.com.acme.combecause a trailing dot was omitted in a provider that appends the zone. Looking up the name you meant returns nothing while the dashboard shows a record. - A wildcard covering the gap. A
*record answers for names that have no record of their own, so a missing record can look present until you compare it against what you expected. - Split-horizon or GeoDNS. The zone is deliberately answering differently by client location or network. Disagreement is then the design, and this tool is the wrong instrument.
- DNSSEC. A broken chain, usually a DS record at the registry that no longer matches the zone's keys, makes validating resolvers return SERVFAIL while non-validating ones answer normally. The signature is what fails; the record is fine.
What this check does not tell you
It reads one name and one type. It does not poll every nameserver in the zone against each other; the authoritative column is whichever of the zone's nameservers answered, so a zone whose servers are out of sync with one another can still show a clean result. It does not validate the DNSSEC chain, look the name up from multiple geographies, or say anything about whether the host behind the address is serving traffic. It does not judge record content beyond reading it: whether an SPF policy is valid is a separate question, and the SPF record checker answers it.
If what you are really doing is pointing a customer's domain at your product, the records, the verification and the drift monitoring afterwards are the whole of what DoDomain does: the connect flow is the short version, and the SSL guide covers what has to happen after the DNS is right.
Frequently asked questions
What does propagated mean on this page?
That every public resolver which answered returns the same answer set as the zone's authoritative nameservers. The authoritative answer is the thing being propagated, so the tool never calls a record propagated on the strength of public resolvers alone: if the authoritative nameservers cannot be read, it says it could not judge.
Why do the public resolvers show an old value?
Recursive resolvers cache each answer for the record's TTL. After you change a record, a resolver that cached the old value keeps serving it until that TTL runs out; the authoritative view is already correct, and the tool shows both so you can see which is which. Lower the TTL before a planned change to shorten this window.
Which record types can I check?
A, AAAA, CNAME, TXT, MX: the same set the DoDomain connect flow can write and verify. CNAME answers are shown as the target hostname, MX answers as priority and exchange, TXT answers verbatim.
Why is a resolver marked error?
Its lookup did not complete (a timeout, a refusal, or a server failure), so it has no answer to compare. An errored view is never counted as agreeing or disagreeing; the verdict is based only on the views that completed, and says how many that was.
How long does DNS propagation actually take?
For a record you changed, at most its previous TTL: that is how long a resolver which had already cached the old value may keep serving it. A resolver that never asked before gets the new answer immediately. Nameserver changes are the slow case, because the delegation TTL at the registry is not yours to lower: two days for .com, .net and .uk, and between 15 minutes and a day for the other top-level domains we measured.
Why does a record work for me but not for a colleague?
Almost always caching: your resolver asked after the change and theirs asked before, so theirs is still inside the old TTL. The other common causes are a corporate or ISP resolver with its own long minimum TTL, an operating-system or browser cache in front of the resolver, and a split-horizon setup answering internal clients differently from the public internet.
Can I force DNS to update faster?
No. Nothing can expire a cache entry that another operator holds; the TTL you published is the contract. What you can do is plan: lower the TTL to a few minutes at least one old-TTL period before the change, make the change, then raise it again once the new value is stable.
Does this tool check the record from many countries?
No, and a tool that claims to mostly is not either. It reads the zone's own authoritative nameservers plus three anycast public resolvers, which answers the question that matters: is the record correct at the source, and has it reached the caches most of the internet uses. Geographic maps are useful only for GeoDNS and anycast setups that deliberately answer differently by location.
Start on the free plan
No card, no sales call: create an app, mint a session, and watch the first domain verify.
More free tools
- DNS provider detector
Which DNS host serves a domain, and whether one-click setup is available there.
- SPF record checker
Parse a domain's SPF, walk its includes, count the lookups against the limit of ten.