发件人重写方案 解决转发中的信封问题。中介将SMTP返回身份更改为它可以支持的身份，而不是要求下一个接收者在原始发件人的域下授权中介。那可以改善 SPF 行为并提供返回的递送通知的路由。它本身并不验证可见作者的身份或批准消息的内容。
确定重写的内容
参考： RFC 7208 §2.4.
比较 邮件来自 转发服务之前和之后。保持可见 来自标题 在一个单独的列中。重写的本地部分可以对转发实现所需的信息进行编码，但操作诊断应从结果域和反向路由行为开始。不要尝试从一个样本重建未记录的提供者编码并将其称为通用格式。
Microsoft 在以下文档中记录了自己对 SRS 的使用 Microsoft 365中的发件人重写方案。其实现重写适用的出站转发信封，并使显示的发件人地址保持不变。 Microsoft 还记录了中继池消息会跳过 SRS，并且本地路由有特殊情况。特定于提供商的承保范围和例外情况很重要；该描述并不能证明每个转发产品的行为都相同。
分别重新计算SPF和对齐方式
参考： RFC 7208 §4.1, RFC 9989 §4.4.2, RFC 9989 §5.3.5.
在最终接收方，根据重写的信封域策略评估转发服务器的 IP。如果获得授权， SPF可以通过该域。接下来，将该经过身份验证的域与适用的域下的可见域进行比较 DMARC 结盟 模式。这两个步骤不得合并为单个绿色指示器。 RFC 7208 和 RFC 9989 定义这些不同的问题。
对于author.example处的可见From 和forwarder.example处的重写信封， forwarder.example的SPF通行证不提供与author.example严格对齐；这些不相关的示例域也不满足宽松对齐。幸存的对齐 DKIM签名 仍然可以让DMARC通过。如果页脚破坏了该签名，SRS 不会修复剩余的作者身份验证失败。
执行配对案例
参考： RFC 9989 §4.4.
检查保留的严格对齐模型案例 srs-preserved 和 srs-footer。两者都为forwarder.example提供SPF通行证以及相同的可见author.example身份。只有保存完好的箱子才能对齐 DKIM 经过;因此，该模型仅在此处返回 true。跟踪记录原始和重写的域身份，而不是提供编码的本地部分作为信任证明。
这些是带有提供的身份验证布尔值的本地模型结果。该装置既不实现 SRS 编码算法，也不验证弹跳地址，实时 SPF记录 或DKIM签名。没有获得真实的提供商转发样本。使用示例来设计真实的跟踪，而不是声明部署已接受。
安全地验证操作行为
参考： RFC 7208 §2.4.
在授权的测试设置中，确认传送失败通过预期路径返回，并且不会创建开放的转发或退回滥用通道。仅保留诊断所需的样本数据，并避免在公共票据中暴露编码的收件人信息。在进行更改之前，请检查提供商文档以了解支持的路由组合和混合例外情况。
将 SRS 服务视为转发设计中的一个组件。保留签名内容、监控转发信誉并记录最终接收者的决定。如果业务路线仍需要本地例外，则单独审核；请勿将信封重写描述为跳过发件人身份验证或内容过滤的权限。成功的返回路径是一个操作结果，而不是消息合法性的证明。
保留的实验室证据
参考： RFC 7208 §4, RFC 6376 §6.
保留的 2026 年 11 月 7 日捕获记录使用forwarder.example上的显式 SRS 形状的重写信封记录了两次实际的SMTP传送。 pyspf 根据该域的固定策略评估观察到的127.0.0.3对等点并返回通过。 dkimpy 通过保留的作者签名并通过页脚修改的副本。因此，严格对齐计算仅通过保留的情况。保留包络字符串和接收器观察结果。这是执行的信封重写，而不是 SRS 编码、时间戳验证、秘密身份验证或退回反转的实现。
对保留的赛跑者和2026年11月7日捕获的赛跑者进行了检查；本次审查没有重新运行网络实验。最初的实验仅使用环回并且不发送互联网邮件。它的接收者创建 Authentication-Results 根据其自己的检查，使这些字段具有已知的实验室来源。身份验证结果和处置保持独立：所有六个SMTP样本均在显式捕获策略下收到 250，包括失败样本。信任边界是这个受控实验室，而不是生产邮箱提供商。 DNS适配器提供保留的固定答案而不是查询公共DNS ，并且DMARC评估器仅使用严格的域相等。完整的组织域发现、生产策略解析和实时部署结果尚未经过测试。