Two checkers can disagree without either displaying the current authoritative record incorrectly. They may ask different questions, use different resolvers or apply different authentication logic. First capture their inputs and outputs precisely; a red or green status is a conclusion, not a DNS trace.
Match the actual question
References: RFC 1035 §4.1.1, RFC 2308 §2.2, RFC 7208 §4.1.
Record the exact fully qualified name, record type, timestamp and tool version. For DKIM include the selector and signing domain. For SPF record the evaluated identity and source IP if the checker performs policy evaluation. A tool looking only at apex TXT is not performing the same task as one recursively evaluating include dependencies for a particular sender.
Preserve response codes and all relevant answer sections. NOERROR with no requested data differs from NXDOMAIN, SERVFAIL and timeout. An alias can lead a tool to a different terminal owner. A tool that joins all TXT records into one string may report a parser artifact rather than a resolver disagreement.
Identify the path and policy
References: RFC 4033 §3, RFC 4035 §5.5.
Find the configured recursive resolver or forwarder where the tool exposes it. VPNs, enterprise views, local overrides, validation and filtering can change observations. A checker hosted elsewhere may have a different cache history. Do not infer the actual mail receiver's resolver from your browser's resolver setting.
Query the authoritative servers directly for a publication baseline, then query the named recursive services. Direct authority visibility does not prove successful DNSSEC validation. If a validating resolver returns SERVFAIL while a direct lookup returns data, investigate the chain and diagnostics; do not assume validation is the only possible cause.
Reproduce two legitimate cache histories
References: RFC 1034 §5.3.3, RFC 8767 §4.
Use a lab timeline: at t=0 resolver A caches policy P with TTL 300. At t=100 authority changes to policy Q. At t=120 resolver B makes its first query and obtains Q, while A may still serve P with about 180 seconds of remaining freshness in this simplified model. This is not a universal discard deadline: implementations using RFC 8767 can retain and serve stale answers under specified failure conditions. Expected difference is explained by cache timing, not by two current authority policies.
Keep a second case where the authoritative servers themselves disagree. In that case, waiting for A's cached data to expire does not fix the underlying publication fault. The retained historical offline capture records these two classifications. It does not emulate resolver-specific stale-answer features, prefetching or production caching.
Resolve causes in the right order
Fix conflicting authoritative data first. Then examine cache age, negative-cache entries, aliases, split views and validation failures. Repeat the exact question rather than making unrelated edits until all dashboards turn green. Record any tool normalization or parser limitation as a separate issue.
When the inputs and DNS answers match but authentication conclusions still differ, compare application algorithms and identity assumptions. A live receiver result on a representative message is a different evidence layer from DNS publication. Keep the final claim narrow: which name and type were returned, by which path, at what time, and what remains untested.
Retained historical lab evidence
The retained capture is dated 7 November 2026. The following describes that bounded historical observation, not a new execution or a test of EmailAuth.ai.
Two limited caching forwarders queried the same loopback authority. One was primed before the policy changed and still returned p=none with a reduced TTL; the newly queried forwarder returned p=reject. A direct query captured the current authoritative p=reject answer. Each capture includes UTC time, TTL, type, endpoint, AA/RA and wire bytes. These custom forwarders demonstrate this controlled cache history, not every recursive implementation. The capture labels are resolver1_cached_old; resolver2_fresh_new; authority_current. The retained runner and raw captures are included in this review package as historical evidence. They were inspected, not rerun for this review. Production DNS, DNSSEC and SMTP outcomes remain untested.