What this analysis does
After publishing or changing an email DNS record, Mailybox queries Google, Cloudflare, AdGuard and DNS.SB over DNS-over-HTTPS alongside the authoritative path, then compares the answers and remaining TTLs. Disagreement during the old TTL window is expected; disagreement that persists points at a zone or nameserver problem. Record types are pre-mapped, so checking DMARC or a DKIM selector needs no knowledge of the underlying owner name.
After a DNS change, the question is not whether it was saved but whether the world can see it yet. Resolvers cache the previous answer for as long as its TTL allows, so the same record can be new at one vantage point and old at another. Asking several independent resolvers at once shows where the change stands.
Independent vantage points, compared
The checker queries four large public resolvers over DNS-over-HTTPS — Google, Cloudflare, AdGuard and DNS.SB — and the authoritative path through the server’s own resolver. Each answer is normalized and compared. Agreement across all five means the change has propagated to the resolvers most users depend on; disagreement shows which caches still hold the old value and for how long.
Email record types are pre-mapped. Choosing DMARC queries _dmarc under the domain and keeps only v=DMARC1 answers; choosing a DKIM selector queries the correct _domainkey name. There is no need to know the owner name convention.
- Four public resolvers plus the authoritative path.
- Answers are filtered to the relevant record so unrelated TXT values do not cause false mismatches.
- The lowest remaining TTL is reported.
Mismatch during the TTL window is normal
A resolver that cached the old record shortly before the change will serve it until that TTL expires. Seeing two different answers for a few hours after a change is expected, and the remaining TTL tells you how long to wait. Only disagreement that persists beyond the previous TTL indicates a real problem.
When it does persist, the usual cause is authoritative nameservers that are out of sync — a secondary that failed to transfer the zone, or two DNS providers configured at the registrar but only one updated. Comparing the authoritative path against the public resolvers narrows that quickly.
Diff the complete before and after stateRead the DNS change review guide
Lower the TTL before the change, not after
Reducing the TTL at the moment of a change does nothing for caches that already hold the long-lived old value. Lower it ahead of time by at least the current TTL, make the change, verify propagation with this checker, then restore the normal TTL.
For authentication records the stakes are real: a receiver still seeing the old SPF or DKIM record will fail mail sent through the new path. Verifying propagation before switching a sending platform is what prevents that window of failures.
Example: a DMARC record published twenty minutes ago
Evidence supplied
Domain example.com, record type DMARC, previous TTL one hour.
How to read the result
Three resolvers return the new policy, one still returns the old one with 2,400 seconds remaining, and the authoritative path returns the new value. The finding reports partial propagation, names the lagging resolver, and states that full agreement is expected within the remaining TTL.
Known limits
- Five vantage points sample propagation; ISP and corporate resolvers may lag further.
- The authoritative path is observed through the server’s resolver, not by querying each nameserver directly.
- A record that has propagated is visible, not necessarily correct; validate its content with the matching checker.
Common questions
How long does propagation take?
Up to the TTL that the old record carried, as seen by each resolver. Public resolvers usually refresh within that window; some networks extend caching.
Why do resolvers disagree long after the TTL?
Most often the authoritative nameservers themselves disagree — a zone transfer failed or two providers are configured and only one was updated.
Does this check every DNS server in the world?
No. It samples four major public resolvers and the authoritative path, which covers most users. It cannot see private corporate resolvers.