Ask who produced the answer
Two DNS lookups can disagree without either tool being broken. One may ask an authoritative server for the zone's current data; another may ask a recursive resolver that holds an earlier answer. A useful authentication investigation records which path produced each observation instead of treating a green check from any lookup site as the final state of the domain.
An authoritative server answers from the zones it serves. A recursive resolver works on a client's behalf, consulting other servers or reusing cached information. A stub resolver generally passes questions to a recursive service. The same software can perform more than one role, so identify the role of this particular response rather than relying on a product name. RFC 1034, sections 4.3.1 and 5.3.1.
This distinction matters when a newly published DKIM selector appears in the DNS host's tools but remains unavailable to a verifier. The authority can establish what a server currently serves; the recursive result helps explain what one receiving path may see. Neither observation stands in for the other.
Establish the delegation before choosing an endpoint
Start with the exact owner and type implicated by the message or service instruction. Follow the delegation to the zone responsible for that owner. A child zone can have different authoritative servers from the parent, and a provider alias can lead into a different zone again. The DNS host displayed on an old ticket may no longer be the delegated host. RFC 1034, sections 4.2.1–4.2.2.
Prepare a list of authoritative server names and their addresses, then query the relevant servers directly. Preserve which address was contacted. If different authorities return different records, investigate the DNS publication or zone-serving problem first. A resolver can legitimately encounter any available authority; choosing the server with the desired answer does not resolve the inconsistency.
A trace can help inspect the delegation path, but it is a separate observation. It does not reproduce a receiver's cached path, forwarding configuration, source network or DNSSEC validation behavior. Label a trace as a trace rather than presenting it as the mail provider's query history.
Interpret flags with their limits
The AA flag identifies an authoritative answer in the DNS response. RD records that recursion was requested; RA advertises recursion availability. RD and RA do not prove that the server performed a fresh lookup for this response. A recursive server can satisfy a request from cache. RFC 1035, section 4.1.1.
For a direct authority check, request no recursion and inspect the actual reply. A response without AA, a referral, REFUSED or a timeout calls for interpretation; the server address alone does not make every reply authoritative. Where aliases appear, keep each owner and target visible and identify which zone supplies the final data. Authority over the alias owner does not automatically establish authority over its target.
Retain the complete question, answer and authority sections. A command that prints only TXT strings hides context needed to distinguish old cached data, a referral, an alias and an absence response. Short output is useful for quick reading after the full diagnostic record has been saved.
Compare a fictional pair of resolver observations
Imagine a fictional selector blue._domainkey.example.com. At 10:00 UTC, two relevant authoritative servers return the newly intended public-key record. At 10:02, Resolver A returns an older key with 420 seconds remaining, while Resolver B returns the new key. These times, results and TTLs are invented to illustrate reasoning; no network measurements were made.
That pattern is consistent with different cache histories, but the observation alone does not prove the cause. Check that all questions used the same name, type and class, that the server endpoints were recorded, and that no split view or forwarding policy changed the answer. If Resolver A later refreshes from an inconsistent authority, simply waiting may not solve the problem.
The proposed incident note would state: “Authorities sampled agree on the new key; Resolver A still returns the old key; receiver outcome not yet observed.” It would not state that every receiver is updated or that authentication now passes. Keep the older public key's availability and the sender's signing transition under a coordinated rotation plan rather than deleting records to make a lookup screen look tidy.
Separate data problems from reachability problems
A recursive SERVFAIL does not establish that a record is absent. An authority may be unreachable, a delegation may fail, or DNSSEC validation may prevent the resolver from accepting the answer. A direct answer from one server narrows the investigation but does not prove that all dependencies are healthy for the recursive resolver.
Transport also matters. DNS requires TCP support, and a truncated UDP response can require a TCP retry. Compare a proposed dig @AUTH_IP blue._domainkey.example.com. TXT +norecurse with the same query using +tcp when transport is implicated. Do not alter firewall or security settings merely to make the test pass; have the responsible operator review the diagnosed path. RFC 7766, sections 5–6.
Make the comparison reproducible
Use one worksheet row per query: UTC timestamp, operator location, server endpoint, recursion choice, owner, type, class, response code, flags, records, TTLs and transport. Repeat selected observations at a documented interval and preserve the earlier rows. DNS caches evolve, so overwriting the first result removes useful timing evidence.
Finish with a controlled message through the affected sender and retain the identities and trusted receiver results. DNS comparison can explain a dependency; it cannot demonstrate inbox placement or a particular receiver's internal lookup. This article supplies a proposed workflow and a fictional comparison. Original timestamped authoritative and recursive answers remain required before its catalogue evidence gate can be closed.