你设置了邮件转发，测试也正常。两周后，客户发来的合同邮件却没有出现：不在垃圾邮件里，也看不到退信。检查日志后发现：550 5.7.1 Unauthenticated email from domain.com。
可能的原因之一是缺少或错误配置了发件人地址重写机制（SRS），但这个代码并不对应唯一原因。邮件认证会检查服务器是否获准为信封中的域名发送邮件。转发可能改变这一关系。SRS 会让信封发件人适应新的发送过程，但在 2026 年，它本身仍不足以解决全部问题：了解限制与理解功能同样重要。
本文介绍 SRS 的作用、故障情况，以及转发系统需要的组件。如果你还在排查更广泛的投递问题，例如 MX 记录错误、catch-all 配置不当，或 DNS 更改影响路由，请先阅读邮件转发设置与故障处理指南。
为什么转发可能导致 SPF 失败
如果转发服务器从自己的 IP 发信，却在信封发件人中保留原始域名，而该域名未授权此 IP，SPF 就可能失败。在 DMARC p=reject 策略下，如果也没有有效且对齐的 DKIM，接收方可能拒收。这不一定是无声丢弃：提交邮件的服务器可能收到 SMTP 错误，并生成未投递通知。
邮件并非通过一条连续管道传送，而是经过一连串 SMTP 连接，每一跳都重新建立 TCP 连接。以下示例展示一种可能的失败过程：
alice@client.com向contact@your-agency.com发信- 你的服务器接收邮件：提交邮件的 IP 已获
client.com的 SPF 授权 - 你的服务器与 Gmail 建立新的 SMTP 连接来转发邮件
- Gmail 看到连接来自你的 IP
- 信封发件人仍为
alice@client.com - Gmail 检查
client.com的 SPF：在此示例中，你的 IP 未获授权 - SPF 失败。如果
client.com发布p=reject，且没有有效且对齐的 DKIM，Gmail 可能拒收邮件
RFC 7208（SPF 规范）承认转发可能给 SPF 检查带来困难。重写信封发件人后，可以检查转发服务器的域名，而不必要求每个原始发件人都授权转发 IP。
两层身份：信封与标头
邮件有两层发件人身份。信封发件人（RFC 5321、MAIL FROM、P1）用于 SPF 检查和退信路由，也可在原始标头的 Return-Path 中查看。标头 From（RFC 5322、P2）则是 Gmail 或 Outlook 等客户端显示的发件人。SRS 会让信封身份适应新的发送过程，但不一定让其域名与可见 From 对齐。
| 层级 | 技术名称 | RFC | 用途 | 可见对象 |
|---|---|---|---|---|
| 信封发件人 | MAIL FROM / Return-Path | RFC 5321 (P1) | SPF 检查与退信路由 | 服务器及查看原始标头的用户 |
| 标头 From | From: 标头 | RFC 5322 (P2) | 客户端显示的发件人 | 最终用户 |
转发后，标头 From 仍为 alice@client.com。你的服务器创建新的 SMTP 事务，SPF 在这一跳检查信封发件人。如果新 IP 未获授权，就会出现问题；如果 SRS 改变了信封域名，还需要单独判断它与 From 的对齐关系。
SRS 实际做了什么
SRS 会在转发服务器建立新的 SMTP 连接前，重写信封发件人（P1）地址。用户看到的 From 保持不变。使用授权转发服务器的域名，可能让 SPF 在接收端通过，但不保证检查结果或投递成功，也不能单独建立与原发件人的 DMARC 对齐关系。
邮政类比：你收到 Alice 的信，把它装进新的邮袋继续寄送，却保留 Alice 的退回地址。收件方看到你递送的是标有 Alice 地址的信，可能对发送授权产生疑问。使用 SRS 后，你把退回地址换成自己的地址，使它对应这次新寄送。如果邮袋被退回，它会先到你这里，再由你把退件转给 Alice。
| 组件 | 转发前 | SRS 重写后 |
|---|---|---|
| 标头 From (P2) | alice@client.com | alice@client.com（不变） |
| 信封发件人 (P1) | alice@client.com | SRS0=4fac=PM=client.com=alice@your-agency.com |
| 发送 IP | 你的服务器 | 你的服务器 |
| 此示例在正确授权下的 SPF 结果 | FAIL | PASS |
解读 SRS 地址格式
SRS 会在转发前把信封发件人转换为编码地址。接收方检查的是转发服务器的域名。该地址包含用于验证退信的认证码、限制有效期的时间戳，以及将通知送回原发件人的原始地址。这是结构化数据，并非杂乱字符。
SRS 重写地址示例：
SRS0=4fac=PM=client.com=alice@your-agency.com- SRS0：首次转发。继续转发时可能出现
SRS1，有助于限制地址增长，但不保证可以无限延长转发链 - 4fac：某种实现中的 HMAC-SHA1 认证码示例。它用于验证传入退信；拒绝无效认证码有助于减少非请求退信造成的滥用。算法和长度取决于具体实现
- PM：时间戳。7 至 21 天只是有效期示例，并非通用期限；拒绝过期地址可以降低部分重放风险，但不能完全消除风险
- client.com=alice：编码后的原发件人，用于把退信通知送到正确地址
何时需要 SRS
跨域名自动转发时，如果转发服务器 IP 未获原发件人 SPF 授权，SRS 就值得考虑。不使用 SRS 可能导致 SPF 失败，但对齐的 DKIM 仍可能让 DMARC 通过。多域名转发基础设施需要检查这些条件，并监测转发邮件。
自有域名转到个人 Gmail。你拥有 cool-startup.com，并把全部邮件转到 founder@gmail.com。在这条路径上，SRS 可能对 SPF 很重要。如果原发件人未授权转发服务器，不使用 SRS 就可能导致 SPF 失败；但只要有效且对齐的 DKIM 保留下来，严格的 DMARC 策略也不会必然导致拒收。
使用共享邮件集群的 MSP 或机构。你托管了 200 个客户域名，客户不断设置向 Comcast、AT&T、Outlook 等服务商转发的规则。转发垃圾邮件可能影响 IP 信誉，并增加进入 Spamhaus 等名单的风险，但这并非必然，也不一定会在数周内发生。SRS 不能替代过滤，也不保证良好信誉。
带出站连接器的 Microsoft 365。在 M365 中，SRS 行为可能随路径和配置而变化。如果使用连接器，应查阅对应版本和类型的文档，确认是否支持 SenderRewritingEnabled，以及该设置如何生效。还应检查出站垃圾邮件策略和外部转发阻止代码 5.7.520；这是策略限制，不是 SRS 故障的证据。任何更改都应获得组织授权。
为什么只有 SRS 还不够
SRS 可能让转发服务器域名的 SPF 通过，但这不等于DMARC 对齐。DMARC 要求 SPF 或 DKIM 至少有一个已认证域名与可见 From 对齐。如果 SRS 使用不同于原发件人的域名，SPF 就不对齐；此时 DMARC 可能依赖有效且对齐的 DKIM 签名能否保留。
如果以下修改影响已签名部分，并根据签名规范化规则改变验证结果，就可能使 DKIM 失效：
- 在主题中加入
[EXTERNAL]，可能使已签名的主题标头验证失败 - 附加病毒扫描通知或退订链接等页脚，可能改变正文哈希覆盖的内容
- 重写 MIME，例如从 8 位编码转换为 7 位编码，可能改变已签名内容
如果 SPF 不对齐，而邮件修改又使对齐的 DKIM 失效，DMARC 就会失败。接收方按自身策略处理，可能拒收，之后也可能有或没有发给原发件人的通知。
ARC (Authenticated Received Chain, RFC 8617) 可以向接收方提供认证上下文，但不会修复对齐。转发服务器在继续发送前用 ARC 签名保护实际观察到的结果，并加入三个标头：
ARC-Authentication-Results：记录实际观察到的 SPF、DKIM 和 DMARC 结果，而不是预设它们都通过ARC-Message-Signature：对创建签名时的部分邮件内容签名，不一定等同于刚收到邮件时的状态ARC-Seal：把当前实例与 ARC 链关联起来的数字签名
Gmail 等接收方可能在转发邮件认证失败时评估 ARC。如果信任 ARC 签名方和链，可以对通常的 DMARC 处理作出例外决定。决定权在接收方；信誉可能影响判断，但不保证获得信任或被接受。
如何验证 SRS 是否工作
从外部账户向转发地址发送测试邮件，然后在接收端查看原始标头。Return-Path 可以显示是否存在 SRS 重写，或是否保留了原始地址。还需要检查认证结果，不能仅凭以下示例中的注释判断 SPF。
步骤 1：检查接收端的 Return-Path
# SRS inactive - SPF is almost certainly failing:
Return-Path: <original-sender@protonmail.com>
# SRS active:
Return-Path: <SRS0=xxxx=yy=protonmail.com=sender@your-domain.com>步骤 2：验证 SRS 域名的 DNS
# Check SPF on your forwarding domain:
dig TXT your-domain.com | grep spf
# Check MX - bounces need a place to go:
dig MX your-domain.comSRS 域名需要可用的退信路径，以及授权发送服务器的 SPF。通常会配置显式 MX，但没有 MX 并不总意味着无法接收：SMTP 可以通过隐式 MX 机制使用 A 或 AAAA。应验证退信是否实际可达，而不只是检查记录是否存在。
步骤 3：检查 Linux 邮件日志
grep "srs_forward" /var/log/mail.loghash mismatch 或 timestamp expired 可能源于密钥不同步或轮换、地址损坏，或退信延迟，并不能证明有人发起恶意重放。Postfix 通常需要外部 SRS 集成，PostSRSd 是其中一种选择。应检查适合当前版本的配置，包括适用时的 SRS_EXCLUDE_DOMAINS，以及本地路由，避免不必要的地址重写或潜在循环。
更简单的替代方案：停止转发
SRS 用于让信封适应一次新的 SMTP 投递。改用自己域名下的真实邮箱，并通过 IMAP 访问，可以避免这次转发跳转，减少相关问题。但这不保证端到端认证，也不会消除所有风险；入站投递和访问控制仍然重要。
转发受欢迎也有成本原因：没人愿意为了每月只收到五封邮件的邮箱支付按用户计费的费用。SRS 有时服务于出于价格考虑而选择的架构，不仅仅是解决技术需求。
本文所述的 TrekMail 模式提供每月 $3.50 起的套餐，包含多个域名和固定价格的共享存储，并在套餐限制内不按用户收费。你可以把 sales@yourdomain.com 用作真实 IMAP 邮箱，在 Outlook 等兼容客户端或支持相应集成的 Gmail 应用中访问，再停用这条转发路径。请核实当前功能和条件；避免转发跳转并不保证不会出现认证失败。
对于多客户环境，多域名邮件托管指南介绍如何组织和管理大量域名。如果保留部分邮箱、部分旧转发规则的混合配置，邮件别名与转发指南介绍在路径中使用 SRS 的设置方法。
无论继续转发还是改用邮箱，都应理解 SRS 的作用、验证它是否工作，并根据接收方评估 ARC。配置不完整可能导致正常邮件无法到达，这会影响业务运行，而不只是一个技术话题。
可以从免费 TrekMail 账户开始；在所述条件下，无需信用卡，也没有试用到期日。请确认当前功能和限制，了解如何管理多域名邮件，而不依赖这套复杂转发路径。
