Observe the caches.
Skip the fake map.

DNS changes do not travel across a single global progress bar.

Authoritative servers publish zone data. Recursive resolvers fetch that data and retain it in caches. A client usually sees the recursive answer available through its resolver, not a broadcast from the zone owner. Two users can therefore observe different answers while old cache entries remain valid.

This checker compares Google Public DNS and Cloudflare 1.1.1.1 through their DNS-over-HTTPS interfaces. Both services use distributed anycast systems. The browser does not select a country or prove which physical location handled the request, so the interface reports provider observations instead of drawing fictional location pins.

The returned TTL is remaining evidence, not a launch timer.

A record’s time to live tells a conforming cache how long it may retain the data. A resolver that cached the old answer one second before a change can keep it longer than one that had no cached copy. The TTL shown in a recursive response can also be the time remaining in that provider’s cache rather than the zone’s original configured TTL.

Lower the TTL before a planned change, wait for the previous longer TTL to age out, make the change, and preserve before-and-after evidence. Raising the TTL afterward does not erase old cached answers.

NXDOMAIN and “no data” can outlive the mistake that caused them.

DNS negative caching allows resolvers to retain evidence that a name does not exist or that the requested type has no data. The relevant SOA information helps set that lifetime. Creating a missing DKIM or DMARC record may therefore not make a previous negative response disappear immediately from every recursive cache.

The resolver ledger distinguishes NXDOMAIN from a successful response with no matching answer. It also preserves authority records when the JSON interface returns them. A failed browser request is reported separately; it is not silently treated as DNS absence.

Compare the exact owner name, type, and value that mail systems need.

Treat propagation as a controlled migration.

1. 01
   Record the current state.

   Save owner name, type, values, TTL, delegation, and a timestamp before editing.

2. 02
   Reduce TTL early.

   Do it at least one previous-TTL interval before the change when the DNS provider permits it.

3. 03
   Publish overlapping service where possible.

   Keep old and new signing keys, routes, or validation paths usable during the cache window.

4. 04
   Compare expected values.

   Use exact matching for an entire record or contains matching for a stable token such as a DMARC version tag.

5. 05
   Validate the application layer.

   DNS agreement does not prove DKIM signing, DMARC alignment, SMTP reachability, or receiver acceptance.

6. 06
   Retire the old path last.

   Wait through the applicable cache window and monitor real mail before removing compatibility.