转发的消息可能是合法的，但仍然失败 DMARC。最后一个接收服务器评估它实际接收到的连接和消息，而不是发送者的意图或早期传送的结果。有用的问题是哪个经过身份验证的身份在转发跃点之后仍然与可见的 From 域保持一致。在考虑政策例外之前保留这种区别。
重建路线
参考： RFC 8601 §1.2, RFC 8601 §5.
收集原始原始消息、转发的原始消息、时间戳、转发配置和接收方生成的身份验证结果。将SMTP信封与可见标头分开：保存的邮件不一定保留每个跃点使用的信封。从负责这些跃点的系统获取跟踪证据。不要对待发件人插入的 Authentication-Results 场作为可信接收者观察。 RFC 8601 解释了这个边界。
标记原始发送者、中间人和最终接收者。然后记录连接IP、信封域、可见域和每个 DKIM 在每个适用的评估点签署域。路线图仅在反映观察到的换乘情况时才有用。未知的跃点仍然未知，而不是被分配假定的身份验证结果。
确定幸存路径
参考： RFC 7208 §2.3, RFC 9989 §4.4, RFC 9989 §5.3.5, RFC 6376 §3.4.
SPF 根据信封标识评估连接系统。在最终接收方，转发服务器可能位于原始信封域的授权之外。一个保存下来的 DKIM签名 仍然可以提供对齐的通行证，因为验证与签名消息和签名域相关联。内容重写可以删除剩余的路径。 DMARC需要一致的身份验证结果，而不仅仅是任何SPF或DKIM通行证。 RFC 9989, RFC 7208 和 RFC 6376 定义这些单独的检查。
SRS 重写的信封可能会通过转发器域的SPF ，而不与原始作者的发件人域一致。来自同一转发器的新签名具有类似的限制。这两种观察结果都意味着该消息一定是恶意的，并且都不会自动修复作者的一致身份验证。
运行有界示例
参考： RFC 9989 §4.4, RFC 9989 §5.3.5.
保留的严格对齐模型可以与SMTP捕获分开检查。直接盒提供一致的SPF和DKIM通行证。保留转发案例提供SPF失败和对齐DKIM成功，因此严格对齐模型仍然通过。页脚情况提供了两条路径的故障并失败。这 SRS 案例隔离了成功但未对齐的SPF身份如何改变这一推理。
这些布尔值是有意输入的，而不是实时DNS查询或加密签名验证的结果。生成的原始消息是合成的，从未被接收过。它们说明了受控的身体变化，但不满足具有可信结果的真实原始和转发消息的要求。下面保留的SMTP实验室部分提供了本地接收的历史证据；外部生产证据仍然存在。
修复狭窄原因
参考： RFC 9989 §7.4.
要求中介尽可能保留签名内容，并验证原始服务中的签名位置。在更改广泛域策略之前测试代表性授权路由。如果接收方应用本地例外，则保留其范围、所有者、到期日和独立过滤要求。例外情况下的递送不是DMARC通行证。
仅当丢失的路径、所做的更改和观察到的接收者决策被单独记录时才结束调查。重新测试定期和小批量的工作流程以及明显的日常路径。仅为了隐藏一个转发缺陷而在整个组织范围内进行监控可能会减少对不相关邮件的保护，而无需修复中介。
保留SMTP实验室证据
参考： RFC 7208 §4, RFC 6376 §6.
保留的捕获日期为 2026 年 11 月 7 日21:29:16 UTC，记录环回接收器通过实际SMTP捕获直接、保留转发和页脚修改的消息。它观察到原始连接的对等点127.0.0.2和转发连接的对等点127.0.0.3 。 pyspf 根据隔离的固定装置DNS评估这些 IP； dkimpy 验证了实际的 RSA 签名。直接案例通过了两项检查，保留的转发副本未能通过SPF但通过了对齐的DKIM ，而页脚副本则未能通过两项检查。接收方生成的Authentication-Results和完整的原始消息与信封和 SHA-256 值一起保留。
本次修订检查了历史运行程序和保留的消息；网络实验没有重新运行。其最初的执行仅使用环回并且不发送互联网邮件。它的接收者根据自己的检查创建Authentication-Results ，使这些字段具有已知的实验室来源。身份验证结果和处置保持独立：所有六个SMTP样本均在显式捕获策略下收到 250，包括失败样本。信任边界是这个受控实验室，而不是生产邮箱提供商。 DNS适配器提供保留的固定答案而不是查询公共DNS ，并且DMARC评估器仅使用严格的域相等。完整的组织域发现、生产策略解析和实时部署结果尚未经过测试。