A header analyser can disagree with the original receiver without either observation being fabricated. They may have evaluated different message bytes, different DNS key state or different verification policies at different times. Preserve the original evidence and compare the conditions before deciding what the disagreement means.
A displayed historical result and a fresh cryptographic verification are different operations. Some tools summarize Authentication-Results already present in the sample. Others retrieve keys and verify the current sample. Establish which operation the analyser performs before comparing its output with the receiving system's result.
Preserve the original and identify the boundary
Export the raw message using a method that preserves the message representation. Keep an unedited original and compute a file hash for later comparison. Record the collection method, delivery time and source mailbox. A file hash can show that two exported files differ; it does not itself explain which difference matters to DKIM.
Identify the receiver-generated Authentication-Results and its trusted authserv-id. Headers supplied by an untrusted sender are not authoritative receiver evidence. RFC 8601 §7.1 describes this trust boundary. Also determine whether the receiver evaluated the message before a later gateway or export process changed it.
Compare the analyser's actual inputs
For an ordinary full-body signature, a copied header block omits the body needed to recompute its DKIM body hash. The special case l=0 hashes zero body octets and provides no body-integrity protection; it does not waive header, key or other verification checks. See RFC 6376 §3.5, §3.7 and §5.4.1. Pasting text can also change folding or line endings. If the analyser lacks the full message, it may be interpreting reported results rather than independently verifying the entire signature. Its interface label alone does not settle that question.
Compare the full samples when available. DKIM canonicalization in RFC 6376 §3.4 tolerates specified transformations, not arbitrary equivalence of rendered content. A different file hash does not automatically mean a DKIM failure, since some byte changes may normalize away; an identical file hash establishes only identical supplied bytes, not identical DNS or policy context.
Check what changed in DNS and time
Read d and s for each signature and record the key answers observed during the later check. The original key may have been retired, revoked or replaced since delivery. RFC 6376 §6.1.2 verification relies on retrieving appropriate verification material, so a historical pass can coexist with a later no-key result.
Also inspect any signature expiration x value and the verifier's time handling. A later tool may evaluate after the signature's expiration. RFC 6376 §6.1.1 permits verifiers to ignore expired signatures; a specific tool's behavior must be checked rather than assumed. Do not label that outcome as proof that the signature was expired when the receiver originally processed it. Where the old DNS answer is unavailable, state that the historical cryptographic calculation cannot be fully reproduced from current evidence.
Work through two contrasting examples
Illustrative example one: the receiver reports pass for selector old1 on Monday, and the sender retires old1 on Friday. A Saturday recheck reports no key. That later result does not erase Monday's trusted observation, although independently reproducing Monday's verification requires the relevant historical inputs.
Illustrative example two: the original received file verifies, while a pasted copy fails after a footer or MIME serialization changes. Compare the covered representation and the point where the change occurred. The problem may lie in sample handling rather than the sender's original signature. These are comparison fixtures, not claims about a real analyser or tenant.
Report the disagreement precisely
Create a comparison record containing sample hashes, collection methods, observation times, d and s, key answers, verifier versions, reported results and known policy differences. Inspect multiple signatures separately, since tools may highlight different ones. Keep DKIM validity distinct from DMARC alignment and final delivery.
Conclude only what the evidence supports: different bytes, changed DNS, elapsed validity, different selected signature, or unresolved context. Preserve uncertainty when the original inputs are missing. A later analyser is useful diagnostic evidence, but it is not a time machine and should not silently overwrite the trusted original receiver result.
Evidence needed for the next decision
Use a comparison row for each signature: original sample hash/time, later sample hash/time, d/s, observed key, x if present, tool/version, operation (report parsing or verification), result and remaining gap. Identical sample bytes with unavailable historical DNS leave a key-state gap, not proof that either tool is wrong. If samples differ, compare the covered canonical representation before assigning causality.