Different authoritative servers should provide a coherent view of the zone they serve. When authentication checks disagree, query each advertised authority for the same owner, type and class. Keep the unedited responses before normalizing them; a terse list of values can hide referrals, errors and missing authority flags.
Establish which servers matter
References: RFC 1034 §4.2, RFC 1035 §4.1.1.
Read the parent delegation and compare it with the child apex NS set. Resolve the advertised server names to addresses and record which address was queried. A hostname can have several addresses, and anycast can route the same address to different instances. One successful query therefore does not prove every possible backend is current.
Use a direct non-recursive query such as dig @SERVER_IP _dmarc.example.test. TXT +norecurse. Inspect the response code and AA flag, answer and authority sections, and any alias. A referral or non-authoritative response from a server you expected to be authoritative is a different finding from an authoritative answer with stale content.
Compare data without destroying structure
References: RFC 2181 §5, RFC 1035 §3.3.14, RFC 1982 §3.2.
DNS record-set ordering is not a policy priority. Sort independent record objects for comparison, but preserve string order inside each TXT record. TTLs may differ because of configuration or query context; record them rather than silently discarding them. A recursive TTL countdown should not be compared as if it were an authority's zone configuration.
Query SOA as supporting context. An SOA serial is not a hash of the zone. Matching serials cannot prove matching records, and a larger printed integer is not universally newer because serial arithmetic wraps. Under RFC 1982, comparisons exactly half the serial space apart are undefined; do not force them into a newer/older ordering. Compare the requested data directly and use the provider's transfer or publication logs to explain differences.
Reproduce disagreement and harmless reordering
Create two isolated authorities for example.test. Both publish the same MX set, but return its records in different orders. Expected normalized comparison is equal. Next give authority A _dmarc.example.test TXT "v=DMARC1; p=none" and B _dmarc.example.test TXT "v=DMARC1; p=reject". Expected comparison is unequal even if both SOA serials are deliberately the same.
Query both authorities with the same type and options. Store server address, timestamp, response code, flags, complete records and serial. The original offline comparison is supplemented by the retained historical loopback observation below. No public policy or production DNS server was changed.
Repair the publication path
References: RFC 1034 §4.3.5, RFC 8767 §4.
Check whether one server is a stale secondary, a retired provider still present in delegation, or a destination that never received the intended update. Repair the supported publication or transfer path rather than making random repeated edits in several panels. Confirm the same expected data at every tested authority after the change.
Repeat observations from relevant networks when anycast or split views are suspected. Distinguish an intentional view policy from an accidental public inconsistency. Finish with recursive and representative mail evidence because authoritative agreement alone cannot eliminate already cached answers or prove authentication of a message.
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.
Actual UDP queries to two loopback fixed-zone authorities returned p=none and p=reject for the same absolute TXT owner. Both responses had AA set. The capture preserves each endpoint, UTC time, TTL, response type, code and wire bytes. This demonstrates a real observed lab inconsistency; it does not survey a public anycast service. The capture labels are authority_A_policy; authority_B_policy. 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.