收件箱屏幕截图很少包含足够的证据来诊断身份验证问题。从受影响邮箱中收到的确切邮件开始。保留获取信息的时间和地点，然后收集完整的原始消息视图。这使得后来的分析与产生所报告体验的实际副本相关联。
获取消息级证据
参考： RFC 6376 §3.7.
Google 的浏览器说明是打开电子邮件，使用“回复”旁边的“更多”，选择“显示原始内容”并复制完整的标题。选择受影响的消息而不是同一对话中的不同项目。当字节保留导出可用时，单独保存可用的原始消息工件；单独复制的标头并不包含重新验证所需的所有内容 DKIM. Gmail标头说明.
记录邮箱上下文、收集时间以及工件是否是原始导出、复制文本或屏幕截图。分析人员应该知道行结尾、折叠或MIME内容在收集过程中是否可能发生变化。不要内联转发消息，并将生成的新消息描述为未修改的原始消息。
读取身份和结果
参考： RFC 8601 §5.
谷歌解释说，邮寄者和签名者信息可以帮助检查身份验证，而未经身份验证的邮件不会自动成为垃圾邮件，并且经过身份验证的邮件也不会自动安全。将视觉指标作为切入点，然后保留完整的证据进行技术分析。 Gmail身份验证帮助.
在值得信赖的 Authentication-Results 场，保留 SPF 结果及其评估身份、 DKIM结果和签名域以及 DMARC 结果并且从域中可见。不要将不相关的跃点的结果合并到一个想象的接收者判决中。一条消息可能携带多个签名或认证结果字段，因此请记录它们的顺序和范围。 RFC 8601.
保留收到的证据，与复查不同
参考： RFC 6376 §3.6, RFC 6376 §6.
接收器的结果描述了其在处理时的评估。今天的本地DKIM检查会评估当前可用的字节和密钥材料。密钥轮换、更改的DNS答案或修改的导出可能会产生不同的结果，而不会证明原始接收者是错误的。标题文本记录了声称的观察结果；它本身并不是一种新的密码验证。 RFC 6376第 3 节和第 6 节.
随附的合成消息有两个Authentication-Results字段。解析器返回两者，而不是默默地选择第一个。这是提取测试，而不是Gmail捕获或信任算法。在实际调查中，接收服务和可信路由必须确定哪个结果是相关的。
分享最小有用的神器
参考： RFC 8601 §7.
保留原始限制。当不需要完整的消息内容或个人地址时，创建单独标记的诊断副本。保留问题所需的域关系和时间戳，并公开任何编辑。对于签名验证，请安排未修改字节的授权安全传输，而不是假装始终可以检查经过编辑的副本。
谷歌还描述了一个在线标头分析器，但将证据粘贴到任何分析器中都会将其传输到该服务。执行此操作之前，请检查收件人、数据和组织共享规则。最后明确说明在Gmail中观察到的内容、推断出的内容以及尚未测试的内容。
阅读带注释的示例而不授予信任
参考： RFC 8601 §5.
保留的注释寄存器按顺序列出每个原始字段及其实际生成器、声明的来源和信任限制。 From 是作者提供的身份； To 是显示的收件人，而不是SMTP信封的证明。消息 ID、日期和主题是发件人控制的上下文。每个Authentication-Results字段都声明一个报告服务和结果，但trusted.example和untrusted.example都无法建立真正的接收者来源。 List-ID 命名所声明的列表；取消订阅字段描述了操作机制，而不是列表所有权。在分类示例中，CAT、DIR、SCL 和 BCL 是 Microsoft 风格的判断，而不是 Microsoft 的观察结果。未建立接收链、 SPF信封身份或连接 IP。
使用此地图作为带注释的教学示例。对于真实消息，用收集和接收者证据替换每个假设的来源，并明确保留任何未经验证的边界未解决。