What this checker actually measures
Each result row is a real query sent to that specific resolver at the moment you pressed the button. We do not cache answers between checks and we do not infer results from a sample — if a resolver appears in the list, it was asked directly and its answer, response time, or failure is reported as it came back.
That matters because "propagation" is not a broadcast. Nothing pushes your change outward. Every resolver independently holds whatever answer it last fetched until that answer's TTL expires, then fetches again. What you are watching is a few hundred caches expiring at different moments.
How to read the results
| Column | What it tells you |
|---|---|
| Response rate | How many of the 85 resolvers replied at all. A reply of "no record" or "name not found" counts as a reply. This number says nothing about whether your change has spread. |
| Record agreement | Of the resolvers that replied, how many returned the most common answer. This is the number to watch: 100% means every resolver that answered agrees, and a lower figure means some caches still hold an older value. |
| Answers | Shown when resolvers disagree. Each card groups the resolvers that returned the same set of values, so old and new answers are easy to tell apart. |
| Location and provider | Which resolver answered. Most large public resolvers are anycast, so the answer comes from their node nearest us rather than a fixed city — the operator is what matters, not the coordinates. |
| Records | The exact values that resolver returned. Different values across rows means the change is still spreading. |
| Response time | How long that single query took from our server. High values usually mean network distance, not a DNS problem. |
| answered | The resolver returned one or more records. |
| no record | The resolver says the name exists but has no record of this type. Normal for, say, an MX query on a www host. |
| not found | The resolver says the name does not exist (NXDOMAIN). Worth investigating if many resolvers agree. |
| timed out | No answer within the timeout, usually because that resolver rate-limited this query. Not evidence your DNS is broken. |
| failed | The resolver returned SERVFAIL or refused the query. A few of these are noise; many at once often point at a DNSSEC or delegation problem. |
Why has my change not propagated yet?
Almost always the TTL. If the previous record had a TTL of 3600, a resolver that fetched it 10 minutes before your change will keep serving the old value for another 50 minutes, no matter what your authoritative servers now say. Nothing you can do from your side shortens that window once it has started.
- The old TTL is still running. Wait it out. Lowering the TTL now affects the *next* change, not this one — see lower your TTL before a migration.
- You edited the wrong zone. Very common after a nameserver move: the records live at the old provider while delegation points at the new one. Confirm with the NS lookup.
- Your own device is caching. Browsers and operating systems keep their own caches. If this tool shows the new value but your machine does not, the problem is local — why is my DNS not propagating lists the flush commands.
- Negative caching. If a name did not exist when a resolver last asked, that "does not exist" answer is cached too, governed by the SOA minimum field. Check it with the SOA lookup.
- A proxy or CDN sits in front. If the record points at a CDN, you may be seeing the CDN's address rather than your origin — which is correct and will not change.
How long does propagation take?
For a record change, the honest answer is: up to the old TTL, plus a small margin. A record with a 300-second TTL is effectively global in five minutes. One with a 86400-second TTL can take a full day. The widely repeated "24 to 48 hours" figure is a hangover from an era of very long default TTLs and slow registry updates — it is not a law of DNS.
Nameserver changes are the exception that keeps the old advice alive. Those are published by the registry rather than by you, and TLD zones typically use TTLs measured in hours or days, so a delegation change genuinely can take much longer than a record edit.
Checking the same thing from a terminal
This tool is a parallel version of a query you can run yourself. To confirm any individual row, ask that resolver directly:
# Ask one specific resolver, the way a single row here does
dig @8.8.8.8 +short example.com A
# Include TTLs so you can see how long the answer will stay cached
dig @1.1.1.1 example.com A +noall +answer
# Ask the authoritative nameservers directly — no caching involved,
# this is the value that resolvers will pick up as their TTLs expire
dig @$(dig +short NS example.com | head -1) example.com A +noall +answerA workflow that avoids downtime
- A day or two before the change, lower the TTL on the records you will edit to 300 seconds and let the old TTL expire.
- Make the change and confirm it saved by querying your authoritative nameservers directly.
- Use this checker to watch the change spread. With a 300-second TTL, most resolvers update within minutes.
- Once the results agree, verify the dependent services — for a mail-related change, run the deliverability test.
- Raise the TTL back to something sensible (3600 or higher) so you are not paying for lookups you do not need.
If the change was to mail routing specifically, propagation is only the first thing to verify. Confirm the MX records resolve, then check that SPF, DKIM, and DMARC survived the move — a zone rebuilt at a new provider very often loses them.