一封电子邮件包含多个身份，他们回答不同的问题。 SMTP信封引导传输，作者提供的标头描述消息，接收系统添加跟踪信息，身份验证评估器报告他们的发现。令人信服的显示名称或一行“通过”并不足以证明出处。首先确定哪个系统创造了每个价值以及您的组织实际上可以信任哪些部分。
区分信封和内容
邮件来自 RCPT TO 属于SMTP事务。它们不需要与可见的 From 和 To 标头匹配。退回地址、邮件列表、别名、密件抄送收件人或转发规则可以使差异合法化。用于传递的收件人集并不是简单地通过读取“To”和“Cc”来重建的。
最终传送系统将反向路径记录在 Return-Path 根据 RFC 5321。当信封的插入边界可信时，该标头是有关信封交付的证据；它不是原作者身份的通用证书。转发可以重写各跳之间的信封，因此请比较相关事务，而不是假设一个地址在整个路由中持续存在。
指定可见字段的属性
From 标识消息的作者字段 RFC 5322。发送方在使用时标识负责在该字段的定义意义上进行传输的代理。 Reply-To 提供建议的回复目的地。日期和消息 ID 有助于解释和关联，但它们不能仅通过出现在消息中进行独立验证。
DKIM 验证可以验证相对于签名域的签名标头内容。它不会将每个未签名的字段都转换为经过验证的证据，也不会确定 From 中指定的人员授权了业务交易。检查哪个签名已通过、其 d 域和签名标头列表。 DMARC 结盟 涉及可见的 From 域和相关的经过身份验证的 SPF 或DKIM域，而不是匹配的回复或消息 ID。
建立接收边界
接收SMTP服务器在“已接收”跟踪字段前面添加。阅读跟踪，了解您的组织运行的系统以及他们观察到的外部边界。早期或外部提供的跟踪文本可能会产生误导。同样地， RFC 8601 定义 Authentication-Results 在理解的信任范围内；攻击者可以插入看起来像是有利结果的标头。
考虑一条具有两个Authentication-Results字段的假设消息：一个声称来自receiver.example ，另一个声称来自forged.example 。这两个标签都无法证明自己的起源。仅当接收服务的记录边界和日志证实其授权验证者插入了第一个边界时，才信任第一个边界；否则将其来源标记为未解决。第二个并不是认证的证据，仅仅因为它包含通行证。
将地图变成调查
对于每个相关身份，记录值、源系统、观察到的跃点、信任基础及其回答的问题。可见的作者域回答了与经过身份验证的提交帐户或信封退回域不同的问题。将原始字节保留在有限的证据存储中，并使用经过编辑的工作副本进行日常讨论。密文可能会使DKIM失效，因此在需要验证时请保留未更改的原始文件。
将标头映射与SMTP日志和可信接收方结果进行比较。在假设的计费路线中，MAIL FROM 是bounce@vendor.example ，而From 是invoices@brand.example 。这种差异可能是合理的。已验证 DKIM签名 即使信封域不同，使用d=brand.example也可以提供精确的对齐。假设适用的DMARC政策并且没有未解决的评估错误；这里没有测试任何实际的提供者、签名或消息。
最后得出与证据相关的结论：哪个域经过了身份验证、观察到了哪些路由以及哪些授权问题仍然存在。不要将这些发现归结为声称每个字段或请求的操作都是值得信赖的。
使用五栏出处注释
- 值：复制原始证据中的确切字段或信封标识。
- 生产者：识别哪个客户端、中继、交付服务或验证者提供了它。
- Hop：记录观察到的事务或接收边界。
- 信任基础：解释为什么该系统的记录是可信的，或者将其标记为不可信。
- 含义：说明该值回答的问题，以及它不证明的身份或业务授权。