A saved message is valuable evidence, but a new DKIM verification is a new event. It tests the saved representation and the available key under the verifier's rules at that time. Preserve the original receiver's reported result alongside the new test so an apparent disagreement can be investigated instead of silently overwritten.
Preserve the input before parsing
Save the message as bytes and compute a SHA-256 fingerprint before opening it in software that may rewrite headers, line endings or MIME structure. Keep any analysis or redaction in a derivative file. DKIM operates on canonicalized message material, not on a screenshot or a visually equivalent rendered message. RFC 6376 defines simple and relaxed canonicalization with specific tolerances. RFC 6376 section 3.4.
A relaxed signature tolerates certain whitespace differences; it does not authorize arbitrary rewriting. Changes to signed text can still invalidate it. Check the signed-header list and any body-length tag before describing what the signature protects. A signature with limited body coverage is different from one covering the entire canonicalized body.
Record the key and verifier context
The signature's d= and s= values identify the signing domain and selector used to find the public key. Record the queried name, response time, resolver context and retained key bytes when legitimately available. A current lookup may differ from the key that existed at delivery because of rotation, revocation or DNS change. Failure to obtain a key now is not proof that the receiver lacked it then. RFC 6376 sections 3.6 and 6.
Record verifier name, version, settings and the signature selected. Multiple signatures can yield different results. Do not describe a default check of one signature as verification of all signatures. Expiration, algorithm support and local policy can also affect an outcome, so retain the diagnostic rather than reducing every failure to “message tampered with.”
Compare a hypothetical old pass with a new failure
Suppose a trusted receiver recorded DKIM pass at delivery, but a later saved-file check cannot obtain the selector key. That new result establishes present verification limits, not an old failure. Retain the query name, lookup time and diagnostic; seek authorized historical key or DNS evidence if the question requires it.
In a different case, the current key is available but the analyst’s derivative has changed signed body text. Test the preserved original separately before blaming a relay or sender. If only the edited copy survives, the historical signature outcome remains unresolved. These are hypothetical diagnostic branches, not executed cryptographic operations or DNS replay.
If a public key is supplied through a local callback rather than obtained from DNS, label that input explicitly. A pass under an injected key does not establish that the signing domain published or authorized that key. Never include a private signing key in the evidence pack.
Explain disagreement without overclaiming
If the saved copy fails but a trusted receiver recorded pass, compare artifact provenance, transformations, key availability and verifier behavior. If the saved copy passes, that establishes the tested signature under the supplied key and rules, not inbox placement, sender intent or current DMARC policy. DKIM's signing identity and DMARC alignment are separate questions.
Close the evidence record with two lines: what the receiver reported at delivery, and what the independent check observed now. Include timestamps, artifact hashes, signature identity and unresolved differences. This preserves a useful audit trail even when the original environment cannot be reconstructed.
Keep verification scope distinct from DMARC
A passing signature establishes the selected DKIM result under the actual key source, bytes and verifier rules. DMARC also needs the signing domain’s alignment with From and an applicable policy evaluation. Use the current RFC 9989 sections 5.3 and 5.4 rather than treating every DKIM pass as DMARC pass or a statement of safe content.
Record historical and current results separately
- Preserve the saved bytes and their fingerprint before parsing.
- Identify the exact signature, d=, s=, canonicalization and signed coverage.
- Retain public key source, lookup time, verifier version and diagnostic.
- Compare transformations and key changes without assuming tampering.
- Keep the original receiver report and the new evaluation as two timestamped observations.