An evidence pack should let a second analyst understand the incident without repeating the collection work or guessing which file is authoritative. Organize it around the reader's question and the actual delivery route. A large ZIP of screenshots is less useful than a small, traceable set of artifacts with clear provenance and unresolved questions.
State the incident and its scope
Start with a short case summary: the expected behavior, observed symptom, affected time window, relevant sender and recipient scope, business impact and the question still unanswered. Distinguish individual failures from broader trends. Record whether evidence came from a provider tenant, a local test or a constructed teaching example.
Separate the current hypothesis from established facts. For example, “a gateway may have modified the body” is a hypothesis until before-and-after bytes or equivalent trusted evidence support it. A DKIM failure alone does not identify the modifying system. RFC 6376 describes the signature checks, not an automatic attribution of responsibility. RFC 6376 section 6.
Preserve originals and create a manifest
Keep unmodified received messages, relevant sender logs, recipient diagnostics and authorized DNS observations in a restricted originals area. Record the collection method, collector, time, timezone and a SHA-256 hash for each artifact. Put sanitized derivatives in a separate area with their own hashes and a transformation log. A hash verifies byte consistency against the manifest; it does not authenticate the underlying claim.
For DNS evidence, record the exact query, record type, resolver, response time and returned data. A screenshot of today's record is not historical proof of yesterday's configuration. For messages, retain the raw bytes when signature verification is needed, and keep human-readable extracts as convenience views rather than replacements.
Build a per-recipient timeline
Track submission, relay acceptance, recipient-specific refusals, retries, final responses and notifications as distinct events. Include source filenames or hashes for every row. RFC 5321 explains SMTP acceptance and retry context; RFC 3464 defines delivery-status recipient blocks. RFC 5321, RFC 3464.
Keep original timestamps alongside normalized UTC values. Mark uncertain clock offsets and missing events. Do not infer mailbox placement from a relay's final 250 response or infer a particular message outcome from an aggregate DMARC count. Explicitly label whether each statement is observed, derived or still hypothetical.
Include reproducible checks and limitations
Provide the commands or script, tool versions, selected signature or record, input hashes, expected observations and actual output. Avoid embedding credentials or production signing secrets. A local test using an injected public key should say that no DNS lookup occurred; a synthetic parser example should not masquerade as a provider evaluation.
For a completed check, retain its actual output and mark missing or changed artifacts explicitly. For a proposed check, label it not performed and state the access or input needed. Do not fill an empty evidence pack with expected outputs presented as observations.
Make the next action clear
End with the verified finding, remaining gaps, proposed narrow correction, owner and success condition. Keep authorization for configuration changes and external sharing separate from evidence collection. After an approved repair, add a new identified test and preserve the old evidence rather than replacing the failure with a success screenshot.
Another analyst should be able to answer three questions from the pack: what happened according to each source, what can be independently checked, and what still requires access or judgment. That is the completion standard, even when the honest conclusion is that the available records cannot yet establish a cause.
Sketch a hypothetical unresolved delivery case
Suppose an application log records relay acceptance, but the recipient reports no message. The case summary should say that destination delivery is unresolved, not that authentication failed. A minimal proposed pack includes the authorized original submission or its retained bytes, the relay’s queue identifier and timestamp, per-recipient trace, any later DSN and the recipient-side observation when available.
Mark each unavailable item as missing. The next owner is the person with access to the relevant relay or recipient trace; leave the person unassigned until actually agreed. A suitable success condition is a correlated disposition for the original recipient and an explanation of any remaining gap, not merely another successful send.
This is a hypothetical pack outline, not delivered files, an executed incident investigation or a claim that a real organization authorized collection, sharing or retention.
Make the pack useful to the next analyst
- Start with the symptom, scope, time window and unresolved question.
- Link each observation to an original artifact and collection context.
- Separate originals, derivatives and hypothetical explanations.
- Include reproducible check inputs and actual outputs only when performed.
- Assign the next evidence request and its success condition without inventing an owner or approval.