你配置了转发：contact@your-agency.com → you@gmail.com。测试正常。两周后，企业客户发来的合同却没有到达，垃圾邮件和收件箱里都找不到。日志显示 550 5.7.1 Unauthenticated email，这个错误可能有多种原因。也可能出现 550 5.7.520 Access denied，表示 Microsoft 365 按策略阻止了出站转发。邮件未到达并不能证明它被无声删除。
正确配置的发件人地址重写机制 SRS 可以解决部分问题。不使用它时，如果原始信封发件人的域名未授权转发服务器 IP，SPF 就可能失败。在 2026 年，Google 和 Yahoo 的发件人要求让认证检查更加重要，但并未要求所有人都在 DMARC 中发布 p=reject（Google 发件人要求）。即使采用严格策略，有效且对齐的 DKIM 仍可能让 DMARC 通过。本文介绍 SRS 的协议机制、限制，以及适当配置需要的组件。
如需了解完整流程，请先阅读邮件转发设置与常见故障处理指南。
什么是 Sender Rewriting Scheme（SRS）？
SRS 会重写信封地址，以降低转发导致 SPF 失败的风险。在继续传送邮件前，它会把 SMTP 信封地址（MAIL FROM）改为转发服务器域名下的地址。客户端界面通常不会显示这个地址，但可以在原始标头的 Return-Path 中查看。接收方随后检查新域名的 SPF，该域名必须授权实际连接 IP。这样 SPF 可能通过，但不保证投递成功，也不保证与可见 From 的 DMARC 对齐。单独一次 SPF 失败不能证明邮件被伪造。
邮件身份的两层结构
排查 SRS 时，应区分经常被混为一谈的两种身份。SPF 检查信封域名；DMARC 将 SPF 或 DKIM 认证的域名与可见 From 比较。转发会改变连接，可能对这些检查产生不同影响。
| 层级 | RFC | 字段 | 检查机制 | 收件人可见？ |
|---|---|---|---|---|
| 信封 (P1) | RFC 5321 | MAIL FROM / Return-Path | SPF | 通常不显示在界面中，但可在原始标头查看 |
| 标头 (P2) | RFC 5322 | From: | DMARC 对齐 | 是 |
信封参与传输和退信路由，其域名由 SPF 检查。标头 From 显示在客户端中，也是 DMARC 对齐的参照。新的转发连接在 IP 未获授权时可能导致 SPF 失败，但不一定使所有认证机制失败：有效且对齐的 DKIM 仍可能维持 DMARC 通过。
新一跳的问题：为什么 SPF 可能失败
转发服务器会与接收端建立新的 SMTP 连接。如果信封发件人仍为 alice@bank.com，连接 IP 却变成你的 IP，SPF 会根据 bank.com 的记录检查该 IP。在此示例中，它未获授权，所以 SPF 失败。如果 bank.com 发布 DMARC p=reject，又没有有效且对齐的 DKIM，接收方可能拒收。SMTP 拒绝可能产生未投递通知，并非总是无声消失。
| 步骤 | 操作 | 信封发件人 | 连接 IP | 示例 SPF 结果 |
|---|---|---|---|---|
| 1 | Alice → 你的服务器 | alice@bank.com | 银行的 IP | PASS |
| 2 | 你的服务器 → Gmail | alice@bank.com | 你的服务器 IP | FAIL：未获 bank.com 授权 |
即使规则配置正确，也可能出现这一问题，因为它取决于新服务器是否获准为信封域名发信。但不是所有转发都必然遇到它。SRS 是让这层身份适应新连接的一种方法。
SRS 如何重写信封
SRS 会在建立新的 SMTP 连接前，把 MAIL FROM 地址改为转发服务器域名下的地址。收件人看到的 From: 标头保持原发件人填写的内容。以下示例假设新域名正确授权了服务器：
# WITHOUT SRS - SPF fails downstream
Return-Path: <alice@bank.com>
Received-SPF: fail (IP not authorized for bank.com)
# WITH SRS - SPF passes on your domain
Return-Path: <SRS0=4fac=PM=bank.com=alice@your-domain.com>
Received-SPF: pass (IP authorized for your-domain.com)接收端检查 your-domain.com 的 SPF，该域名应授权服务器。在这种情况下，SPF 可能通过。收件人仍看到 From: alice@bank.com。SRS 改变了 SPF 检查的身份，但仍需单独判断它与原始 From 的对齐关系。
解读 SRS 地址格式
Return-Path 中的 SRS 地址看起来可能很复杂，但每一段都有用途。理解格式有助于验证重写，并结合日志和认证结果排查问题。
示例：SRS0=4fac=PM=bank.com=alice@your-domain.com
| 组件 | 值 | 用途 |
|---|---|---|
| 前缀 | SRS0 | 首次重写标记。第二次转发可能使用 SRS1，以限制地址增长，但不保证转发链可以无限延长。 |
| 认证码 | 4fac | 使用服务器密钥的 HMAC 示例，有助于验证 SRS 退信地址并降低伪造风险，但不能消除所有威胁。 |
| 时间戳 | PM | 循环 base32 时间戳示例。限制有效期可以减少重复使用地址造成的部分滥用；格式和期限取决于实现。 |
| 来源 | bank.com=alice | 保留原发件人信息，用于把未投递通知送回 alice@bank.com。 |
第二个问题：SRS 之后的 SPF 对齐
SRS 可能让 SPF 的验证通过，却无法保留与原始 From 的对齐。DMARC 要求 SPF 或 DKIM 至少有一条路径验证成功并对齐。因此，正确配置 SRS 也不足以保证 DMARC 通过。
DMARC 要求至少一个已认证域名与可见 From: 标头的域名对齐。在此 SRS 示例中：
- SPF 验证：PASS：你的 IP 已获信封域名
your-domain.com授权 - SPF 对齐：FAIL：信封
your-domain.com≠ 标头bank.com
此时 DMARC 可能依赖 DKIM。只要已签名部分没有发生会按签名规范化规则改变验证结果的变化，原始的有效且对齐签名就可能保留。添加“外部邮件”警示、附加病毒扫描页脚，或把 MIME 从 8 位转换为 7 位编码，都可能在影响已签名内容时使签名失效。
如果 SPF 不对齐，而修改又使对齐的 DKIM 失效，DMARC 就会失败。即使 SRS 正确完成地址重写，接收方仍可能按策略拒收。但这不意味着所有转发邮件都会丢失。
ARC：SRS 的补充机制
ARC (Authenticated Received Chain, RFC 8617) 可以补充 SRS。SRS 为 SPF 调整信封，而 ARC 用签名保护实际观察到的认证结果，并将其传递给下一个接收方。它不证明邮件不是垃圾邮件，也不保证接收方接受。
ARC 添加 ARC-Authentication-Results、ARC-Message-Signature 和 ARC-Seal。先前结果可以在后续 DKIM 失败时提供上下文，但邮件的 ARC 签名也可能因已签名部分的后续修改而失效。并非所有 ARC 组件都能承受任意正文变化。
限制：接收方决定是否信任 ARC 签名服务器和链。在支持相应功能的 Microsoft 365 环境中，获授权管理员可在适用且尚未列入时，通过 PowerShell（Set-ArcConfig）配置可信 ARC 签名方。配置应符合组织策略。Gmail 按自己的标准判断信任，无法手动强制。
生产环境可评估 SRS 对 SPF 的作用，以及 DKIM 无法保留时 ARC 提供的额外上下文。它们并不是每次投递都必须具备的通用条件，两者结合也不足以保证所有服务商接收。DNS、过滤、策略和信誉同样重要。
SRS 故障诊断清单
如果转发邮件没有到达，可用这份清单区分 SRS 问题、前置阻止和其他原因。
1. 检查 Return-Path 标头
从外部账户通过转发服务器发送测试邮件，然后在最终接收端检查原始标头。以下结果展示 SRS 前 IP 未获授权、之后获授权的示例，请检查自己的实际路径结果。
# SRS inactive - SPF will fail
Return-Path: <original-sender@external.com>
Authentication-Results: spf=fail (IP not authorized for external.com)
# SRS active - SPF passes on your domain
Return-Path: <SRS0=xxxx=yy=external.com=sender@your-domain.com>
Authentication-Results: spf=pass (IP authorized for your-domain.com)2. 检查 Microsoft 365 出站阻止
如果邮件从 Microsoft 365 转出，并出现以下策略阻止，邮件可能在离开环境前就被拦下。SRS 无法解除该限制。
550 5.7.520 Access denied, Your organization does not allow external forwarding.获授权管理员应在 Defender 门户中检查出站垃圾邮件策略，并确认该路径是否获准。不要通过关闭控制措施绕过策略。接收服务器上的 SRS 无法解决这类阻止。
3. 检查路由循环
如果 A 转发给 B，B 又转回 A，当规则允许路径重复、保护措施没有提前停止时，就可能形成循环。可在日志中查找以下信息：
554 5.4.14 Hop count exceeded
5.4.6 Routing loop detected停止转发，改用真实邮箱
为了避免按邮箱收费而把企业邮件送到个人收件箱，可能带来配置 postsrsd、管理 HMAC 密钥和排查 DMARC 对齐失败的维护工作。SRS 解决的是新一跳产生的部分问题。如果符合业务需求，真实邮箱可以避免这条转发路径。
| 转发方式 | 按套餐提供的 TrekMail 替代方式 |
|---|---|
| 把 sales@ 转发到 Gmail，并排查 SRS 故障 | 把 sales@ 托管为直接接收邮件的真实 IMAP 邮箱 |
| 为每台服务器配置 SRS、ARC 和 HMAC 密钥 | 没有这次转发跳转，该路径就不需要 SRS |
| SPF 不对齐时，无效 DKIM 可能导致 DMARC 失败 | 避免转发可以去除这类修改来源，但仍需检查认证 |
| 邮件未到达，却看不到投递信息 | 套餐和配置支持时，可使用投递日志与消息跟踪 |
与其把 contact@client-domain.com 转到 Gmail 并维护 SRS，不如在 TrekMail 上将 contact@client-domain.com 托管为 IMAP 邮箱。通过兼容客户端访问，也可使用支持相应集成的 Gmail 应用，邮件直接到达邮箱，不经过这次新跳转。这能减少转发问题，但不保证端到端认证或进入收件箱。可在域名邮件转发到 Gmail 指南和别名与邮箱比较中评估取舍。
管理多个客户域名？在 TrekMail 上集中管理邮箱，可以减少在不同服务器维护 SRS 的工作。邮箱隔离仍需适当权限和配置，不代表绝对安全，也不能保证固定的创建时间。多域名邮件托管指南介绍如何按套餐限制组织管理。
本文所述的 TrekMail 方案起价为每月 $3.50，包含 14 天免费试用。请先确认当前套餐的价格、条件和功能，再创建真实邮箱，替换不再需要的转发路径。
