Check a record
Presets
How it works
Ask four resolvers
Cloudflare, Google, DNS.SB and AliDNS, all in parallel from your browser — four operators on independent networks, including one inside China.
Find the consensus
Whichever answer the most resolvers return is treated as the current live value.
Flag the stragglers
Any resolver returning something different is still serving a cached copy of the old record.
Read the TTL
The remaining TTL on each stale answer tells you the longest you have to wait.
What propagation actually is
There is no moment when a DNS change goes live everywhere. Your authoritative nameserver updates instantly. Everyone else finds out only when the copy they already hold expires. That expiry is the TTL you set on the record, and until it runs out a resolver will keep serving the old answer with complete confidence.
This is why checking your own resolver proves nothing. If you have never looked up the name from that resolver before, it fetches the current value and shows you the new record immediately. A colleague on a different network, whose resolver cached the old value an hour ago, sees the old one. Both are behaving correctly.
Why this matters for sending
Authentication is the case where the gap bites. You publish SPF, DKIM and DMARC, confirm them in your own browser, and start sending. Receiving mail servers using a resolver that still holds the old NXDOMAIN answer see no record at all — so SPF fails, DKIM fails, and DMARC does whatever your policy says. If that policy is at reject, the first hours of a campaign are quietly destroyed by a record that you can see and they cannot.
The fix is boring and effective. Drop the TTL to 300 seconds a day before you plan to change anything, make the change, confirm consensus here, then raise the TTL again. On a fleet of sending domains this is the difference between a clean cutover and a week of unexplained failures.
Reading the result
Full agreement across every reachable resolver means the change is done. A mixture of the new value and no value at all is normal mid-propagation, and usually resolves within minutes. The case worth attention is resolvers actively returning a different value, because their remaining TTL is a hard floor on how long the old record survives in the wild.
These are public recursive resolvers, not a per-country authoritative survey. They are a good proxy for global cache state because they are large, independent and geographically spread, but a resolver appearing to lag simply has a warmer cache, not a fault.
Frequently asked questions
How long does DNS propagation take?
As long as the TTL that was on the previous record, and no longer. If the old record had a TTL of 3600 then one hour after the change every resolver has expired its copy. The commonly repeated figure of 24 to 48 hours comes from the old default TTL on registrar panels, not from any technical requirement.
I changed a record but this still shows the old value. What went wrong?
Probably nothing. Check whether the stale resolvers agree with each other and look at their remaining TTL. If the consensus value is the new one and only a couple of resolvers lag, wait for their TTL. If every resolver shows the old value and time has passed, you likely edited the record at a provider that is no longer authoritative — check with the NS checker.
Why do some resolvers show no record when others show one?
A resolver that has never been asked for the name has nothing cached, so it fetches the live answer. A resolver returning nothing usually means the record genuinely does not exist yet at the authoritative server, or you are querying the wrong hostname — DMARC lives at _dmarc.example.com, not example.com.
Can I speed propagation up?
Not after the fact. The old TTL is already in flight. You can only prepare for it: lower the TTL well before the change so the cached copies expire quickly when the time comes.
Does this check authoritative nameservers directly?
No. Browsers cannot query authoritative servers directly, so this asks four public recursive resolvers instead. That is what you want anyway — receiving mail servers use recursive resolvers too, so this is closer to what they actually see.
Why include Chinese resolvers?
Because propagation is not uniform globally and AliDNS behaves differently from western resolvers. If you send to recipients in Asia it is worth knowing whether your record has reached them.
Last reviewed
What to run next
The checks that most often follow this one.
More in this category
Guides that go deeper
When the tools tell you something is wrong
The diagnostics here are free and always will be. When the fix is bigger than a DNS record, this is the work I do.
Deliverability rescue
Mail landing in spam, replies gone quiet, or a domain suddenly blocked. I find the actual cause rather than guessing, and fix it.
- Authentication and alignment failures
- Blocklist delistings and reputation repair
- Gateway and filter-level blocks
- A written report on what broke and why
Email & sending infrastructure
Sending domains, inboxes, authentication and warmup, built to survive volume instead of burning down in a month.
- Domain and inbox fleets at any scale
- SPF, DKIM, DMARC and tracking domains
- Google Workspace and Microsoft 365 inboxes
- Handover documentation you actually own
Domain, DNS & migration
Changing registrar, mail provider or host without a day of downtime or a week of mail silently failing.
- Registrar and nameserver moves
- Workspace and Microsoft 365 migrations
- MX, SSL and subdomain cutover
- Staged rollout with rollback at every step
Monitoring & retainer
Infrastructure drifts. Records get edited, certificates expire, domains get listed. Ongoing eyes on the fleet.
- Scheduled checks across every domain
- Alerts before your clients notice
- Monthly reporting
- Priority response when something breaks
Start with a call
Bring a domain and the symptom. I will tell you what is actually wrong and whether you need me at all — plenty of people leave that call able to fix it themselves.
Thirty minutes, no pitch
We will run the checks together on your actual domains, and you will leave knowing what is broken, what it takes to fix, and what it should cost. If that is a job you can do in-house, I will say so.