Redaction is an evidence transformation. It can make a sample safer to discuss while removing the information needed to answer the original technical question. Start by defining that question: header interpretation, domain alignment, routing, signature verification or content filtering. The minimum useful data differs for each task.
Preserve the original and identify the derivative
Store the original message in a restricted location and compute its byte-level SHA-256 fingerprint. Make a separate copy for sanitization. Record the collector, collection method, time and original hash; then record a new hash for the derivative. A hash supports later integrity comparisons but does not prove the truth of the message or who sent it.
Do not overwrite the only original or label an edited file “raw original.” Message headers can contain recipient addresses, internal hosts, public and private IP information, tracking URLs and identifiers. MIME parts and attached messages can repeat sensitive information that is absent from the visible body. RFC 5322 describes message structure; the redaction workflow here is an operational recommendation, not a prescribed redaction standard. RFC 5322 sections 2 and 3.
Preserve relationships needed for diagnosis
For a domain-alignment discussion, keep the relationship between visible From, envelope identity and signing domains clear. Replacing every domain with the same placeholder can manufacture alignment; replacing aligned domains with unrelated placeholders can destroy it. If real domains cannot be shared, provide an explicitly illustrative mapping that preserves the relationship and state that real DNS cannot be checked from the derivative.
For routing, preserve hop order and clearly label removed hosts or addresses. For timeline analysis, retain timezone offsets and explain any time shifting. For delivery-status analysis, keep recipient-block boundaries, Action, Status and relevant diagnostics while removing unrelated message content. RFC 3464 defines these per-recipient fields. RFC 3464 section 2.
Do not promise signature-preserving redaction
Changing a signed header or signed body can break DKIM. Some whitespace changes survive relaxed canonicalization, but this is not a general redaction guarantee. Even a change outside one signature's coverage can alter another signature or remove context needed to interpret trust. Preserve signed bytes when the question requires cryptographic verification. RFC 6376 sections 3.4 and 5.
A redaction log should identify each transformation and the diagnostic ability it removes. Do not claim a derivative preserves signature verification merely because it still displays a DKIM-Signature field. No sanitizer can be assumed complete without review of the resulting content.
Inspect the entire derivative before sharing
Review headers, plain-text and HTML parts, attachments, nested messages, URLs, comments and filenames. Remove action tokens such as recipient-specific unsubscribe values where they are not needed. Avoid a simple search-and-replace as the only privacy check because encoded or repeated data may remain.
Give the analyst a short capability statement: this copy can support header interpretation and the labeled identity relationship, but cannot establish original signature validity or undisclosed DNS state. If the analyst needs more, seek authorization for the specific additional data and recipient rather than automatically sending the full original. Keep the redaction log restricted when it contains the mapping back to personal details.
Work through a hypothetical alignment sample
Suppose the question is whether a bounce subdomain and visible author domain have the relationship required by the configured alignment mode. An authorized illustrative mapping might replace the author with brand.example, its bounce subdomain with bounce.brand.example and an unrelated vendor with vendor.example. Mapping all three to example.com would conceal the distinction.
Label the mapping as illustrative and state the relevant strict or relaxed relationship. It is not a substitute for evaluating the real domains, policy or DNS. If the question changes to DKIM validity, use the restricted original under an approved access arrangement instead of promising that the redacted copy can answer it.
Before sharing, inspect every part for repeated addresses, tokens and identifiers, including nested messages. This is a hypothetical selection workflow, not an executed redaction or a claim that an actual sample is safe to disclose.
Share the least evidence that answers the question
- Keep the only original restricted and create a separately labeled derivative.
- Preserve needed identity relationships, recipient blocks, hop order and time context.
- Review all MIME parts, nested content, links and filenames.
- State which tests the derivative can no longer support.
- Obtain authorization for the actual data and recipient before external sharing.