证据包应该让第二个分析人员了解事件，而无需重复收集工作或猜测哪个文件是权威的。围绕读者的问题和实际的传递路线进行组织。一大堆屏幕截图的 ZIP 不如一小部分可追踪的、具有明确出处和未解决问题的工件有用。
说明事件及其范围
从简短的案例摘要开始：预期的行为、观察到的症状、受影响的时间窗口、相关的发送者和接收者范围、业务影响和尚未解答的问题。将个人失败与更广泛的趋势区分开来。记录证据是否来自提供商租户、本地测试或构建的教学示例。
将当前的假设与既定事实分开。例如，“网关可能修改了主体”是一个假设，直到前后字节或等效的可信证据支持它。一个 DKIM 单独的故障并不能识别正在修改的系统。 RFC 6376描述了签名检查，而不是自动责任归属。 RFC 6376第 6 节.
保留原件并创建清单
将未修改的收到邮件、相关发件人日志、收件人诊断信息和授权的DNS观察结果保留在受限制的原始区域中。记录每个工件的收集方法、收集器、时间、时区和 SHA-256 哈希值。将经过净化的衍生品放在单独的区域中，并具有自己的哈希值和转换日志。哈希值根据清单验证字节一致性；它不验证基本声明。
对于DNS证据，记录确切的查询、记录类型、解析程序、响应时间和返回的数据。今天记录的屏幕截图并不是昨天配置的历史证明。对于消息，在需要签名验证时保留原始字节，并将人类可读的摘录保留为方便视图而不是替换。
建立每个收件人的时间表
将提交、转发接受、特定于收件人的拒绝、重试、最终响应和通知作为不同的事件进行跟踪。包括每行的源文件名或哈希值。 RFC 5321解释了SMTP接受和重试上下文； RFC 3464定义了传递状态收件人块。 RFC 5321, RFC 3464.
将原始时间戳与标准化 UTC 值一起保留。标记不确定的时钟偏移和丢失的事件。不要从中继的最终 250 响应推断邮箱位置，或从聚合推断特定邮件结果 DMARC 数数。明确标记每个陈述是观察到的、推导出来的还是仍然是假设的。
包括可重复的检查和限制
提供命令或脚本、工具版本、选定的签名或记录、输入哈希、预期观察结果和实际输出。避免嵌入凭据或生产签名机密。使用注入公钥的本地测试应该表明没有发生DNS查找；合成解析器示例不应伪装成提供者评估。
对于已完成的检查，保留其实际输出并明确标记丢失或更改的工件。对于建议的检查，将其标记为未执行并说明所需的访问或输入。不要用作为观察结果呈现的预期输出来填充空的证据包。
明确下一步行动
最后以经验证的发现、剩余差距、建议的缩小修正、所有者和成功条件结束。将配置更改和外部共享的授权与证据收集分开。修复获得批准后，添加新的已识别测试并保留旧证据，而不是用成功的屏幕截图替换失败。
另一位分析师应该能够回答三个问题：根据每个来源发生了什么，什么可以独立检查，以及什么仍然需要访问或判断。这就是完成标准，即使诚实的结论是现有记录尚无法确定原因。
绘制一个假设的未解决的交付案例
假设应用程序日志记录了中继接受情况，但接收者没有报告任何消息。案例摘要应该说明目标传送未解决，而不是身份验证失败。最小建议包包括授权的原始提交或其保留的字节、中继的队列标识符和时间戳、每个接收者的跟踪、任何后续的 DSN 以及接收方观察（如果可用）。
将每个不可用的项目标记为缺失。下一个所有者是有权访问相关中继或接收者跟踪的人；在真正同意之前，让该人保持未分配状态。合适的成功条件是原始接收者的相关配置以及对任何剩余间隙的解释，而不仅仅是另一个成功的发送。
这是一个假设的包大纲，而不是交付的文件、已执行的事件调查或真实组织授权收集、共享或保留的声明。
使该包对下一位分析师有用
- 从症状、范围、时间窗口和未解决的问题开始。
- 将每个观察结果链接到原始工件和集合上下文。
- 单独的原件、衍生件和假设解释。
- 仅在执行时包括可重复的检查输入和实际输出。
- 分配下一个证据请求及其成功条件，而无需发明所有者或批准。