Separate an unexpected answer from a poisoning finding
DNS cache poisoning places incorrect data into a cache that later supplies answers to clients. For email authentication, that can distort the policy or key material a receiver retrieves. It is a possible explanation for suspicious resolver differences, not a diagnosis established by two disagreeing screenshots. First determine whether the observations concern the same owner name, record type, network view and time interval.
A useful investigation asks where the questionable answer entered the resolution path. An unauthorized authoritative edit, a poisoned recursive cache, a legitimate stale entry and a local resolver override are different conditions. They can all yield an answer that differs from an operator's expectation. Name the hypothesis and the evidence needed to distinguish it before recommending a repair.
Explain the security boundary without reproducing an attack
DNS resolvers need to reject responses that do not match their outstanding questions and apply rules about which received data is trustworthy. RFC 5452 section 9 specifies defensive matching requirements and unpredictable query identifiers and source ports. Those measures make forged responses harder to accept; they are not a substitute for maintaining supported resolver software and reviewing its actual configuration.
DNSSEC adds data-origin authentication and integrity where a validating resolver can establish the required chain of trust. The security states distinguish validated data from unsigned or unvalidated situations. RFC 4033 sections 3 and 5 explains these boundaries. A signed record visible in a tool is not, by itself, proof that the mail receiver validated it.
Encrypted transport to a resolver protects that connection under its own authentication assumptions. It does not establish that all data returned by the resolver is authoritative or correctly validated. Keep transport security, DNSSEC validation and administrative control as separate evidence fields rather than compressing them into a single secure-DNS badge.
Preserve a comparison that can be interpreted later
For each observation, retain the queried fully qualified name, type, resolver or authoritative endpoint, timestamp and network vantage point. Preserve response status, relevant flags, answer records, TTLs, authority material and any extended diagnostic information. Record whether validation was requested, performed locally or merely reported by an upstream resolver. Do not infer validation from an unexplained icon.
Compare a known baseline with the current delegated authority and more than one relevant recursive path when the organization authorizes those observations. Different public resolvers can provide useful comparison points, but none substitutes for the path actually used by the receiver. Preserve raw results before normalizing them into a table, so later reviewers can inspect omitted details.
The receiver's authentication result answers a different question: what it concluded for that message at processing time. A current lookup cannot reconstruct a past cache automatically. Correlate message time, queried identities and available resolver telemetry. Where telemetry is absent, mark the causal explanation unresolved instead of claiming that a particular DNS answer caused a specific pass or failure.
Test ordinary explanations before escalation
Cached positive and negative answers can diverge after a legitimate change. RFC 2308 section 5 describes retaining negative answers with their own lifetime. A newly published selector may therefore be visible at an authority while a resolver still returns earlier absence. That observation is compatible with caching and does not establish poisoning.
Resolution failures can also be cached under RFC 9520 section 3. SERVFAIL is not equivalent to a missing authentication record, and an immediate repeat may reproduce a retained failure rather than launch a fresh successful resolution. Separately, permitted serve-stale behavior under RFC 8767 means expiry alone is not a universal guarantee that old data cannot appear.
Check authorized split-horizon arrangements, inconsistent authoritative servers, recent delegation changes and local network policy. These explanations are not reasons to dismiss suspicious data. They provide competing hypotheses that an incident owner can confirm or rule out with evidence.
Fictional worked example of two different answers
In this fictional comparison, a mail owner expects a new selector at june._domainkey.example.com. The authority is recorded as serving the new key at 14:10, while Resolver A returns an earlier negative answer at 14:12 and Resolver B returns the key at 14:13. These times and results are invented, not query transcripts.
The proposed first decision is to examine the earlier negative response and its caching context. If Resolver A later returns the expected key in a manner consistent with that context, the case may be explained without poisoning. If it returns an unrelated key that never appeared in authorized history, the evidence becomes more suspicious, but the team still needs to investigate resolver and authoritative paths before identifying the cause.
No comparison should promote an invented example into an incident result. In a real case, both the suspicious value and the basis for calling it unauthorized need retained evidence and an accountable owner.
Choose recovery according to the affected layer
If the incident owner confirms a compromised recursive service, restore trustworthy operation using the organization's approved procedures and verify the affected clients' resolver paths. If authoritative content changed, repair and protect that administration path instead. A cache flush alone does not prevent reinsertion or reverse a compromised authority, and flushing a laptop does not clear a remote mail provider's cache.
After recovery, compare fresh observations with the approved baseline and inspect representative message outcomes. Record residual uncertainty about earlier decisions and downstream caches. The original-evidence requirement for this manuscript remains open: no timestamped resolver comparison with TTL, response type and authority has been collected, and no poisoning test or live remediation has been performed.