你设置了转发,让 contact@yourdomain.com 将邮件转到 Gmail。运行一周后,客户邮件开始收不到。你可能没有收到通知,但 SMTP 拒绝也可能产生未送达报告。日志中出现 550 5.7.1 Unauthenticated email 或 550 5.7.26 This message does not have authentication information。这些错误并不对应唯一原因,但 SRS 邮件转发可以处理一个常见问题:转发服务器建立新的 SMTP 连接,却仍在信封中使用原发件人的域名。如果该域名未授权新的 IP,SPF 就可能失败。当 DMARC 设置为 p=reject,且没有有效并对齐的 DKIM 签名时,接收方可能根据自身策略拒收邮件。
启用 SRS 并不能解决所有问题。即使配置正确,DMARC 对齐和 DKIM 签名仍可能出问题。其他转发故障及诊断方法,请参阅邮件转发设置与故障排查指南。
什么是 SRS 邮件转发?
SRS 邮件转发采用 Sender Rewriting Scheme,在服务器将邮件重新投递到新目的地时,改写信封发件人地址。它将技术退信地址中的原域名替换为转发方域名。如果该域名的 DNS 授权了转发 IP,SPF 就可能通过。可见的 From 字段仍保留原发件人。SRS 只改写 MAIL FROM,并不加密邮件或隐藏身份,用户仍可查看技术邮件头。
Postfix 可通过 postsrsd 服务集成 SRS,部分 Microsoft 365 配置和托管邮件平台也提供支持。请核实当前版本、支持范围及配置。SRS 帮助 SMTP 转发适应 SPF 检查,但不保证投递或 DMARC 通过。
转发为何可能失败:新的 SMTP 跳点
转发会建立新的 SMTP 跳点,其 IP 可能未获原域名授权。邮件包含两种身份。Header From(RFC 5322)通常显示在客户端中,例如 From: alice@client.com。Envelope Sender(RFC 5321,MAIL FROM)则是用于 SPF 检查及退信路由的技术返回地址。界面通常不显示它,但用户可在 Return-Path 等邮件头中查看。
以下流程说明一种可能的故障,并非必然结果:
- Alice 从
alice@client.com发信。她的 SPF 记录授权了原服务器,邮件到达你的服务器时通过 SPF。 - 你的服务器向
you@gmail.com建立新的 SMTP 连接。此时发送 IP 变成你的服务器 IP。 - Envelope Sender 仍为
alice@client.com,但在此示例中,client.com 的 SPF 记录未授权你的服务器 IP。 - Gmail 检查
client.com的 SPF,发现该 IP 未获授权,因此 SPF 失败。 - 如果
client.com发布了p=reject,且没有有效并对齐的 DKIM 签名,DMARC 就会失败。Gmail 可能根据策略拒收,转发服务器也可能收到拒绝状态并生成通知。
SRS 如何帮助邮件通过 SPF
SRS 邮件转发在重新投递前改写 Envelope Sender,使用转发方域名。接收方随后检查该域名的 SPF,因此它必须具有有效记录,授权实际出站 IP。Header From 保持不变,收件人仍看到原发件人。退信经过转发方域名,由其按具体实现及验证规则还原原始地址。
理解 SRS 地址语法
启用 SRS 后,返回地址可能采用以下结构。这是带有消息认证码的地址,不是加密地址:
改写前:MAIL FROM: <alice@client.com>
改写后:MAIL FROM: <SRS0=4fac=PM=client.com=alice@yourdomain.com>
| 组成部分 | 示例 | 用途 |
|---|---|---|
SRS0 | 前缀 | 标识首次改写。再次转发时可能使用 SRS1。 |
4fac | 消息认证码 | 使用本地共享密钥的截断 SHA1 HMAC 示例。可降低伪造退信的风险,实际算法取决于实现。 |
PM | 时间戳 | Base32 循环时间戳示例。验证时间戳可限制旧地址的重复使用,但不能阻止所有重放攻击或发往伪造地址的反向散射退信。 |
client.com | 原域名 | 保留原发件人域名,用于退信路由。 |
alice | 原用户 | 原地址的本地部分。 |
@yourdomain.com | 改写域名 | 执行改写的域名,需有有效 SPF 记录授权转发 IP。 |
如果同一邮件再次转发(A → B → C),具体实现可能使用 SRS1 来限制 SRS0 地址的增长。实际封装不一定只包含认证码和时间戳。仍需核实本地部分是否满足 RFC 规定的 64 字符限制,即 RFC 5321 的要求;改写并不能保证任何地址都符合限制。
SRS 为什么还不够:DMARC 对齐问题
不少管理员启用 SRS 邮件转发后就认为配置完成,但邮件仍可能进入垃圾邮件。SRS 可以帮助 SPF 通过,却不一定保留原有的 DMARC 对齐。DMARC 要求 SPF 或 DKIM 至少有一种验证通过,并与 Header From 域名对齐。改写后,SPF 验证的是 yourdomain.com,而 Header From 仍为 client.com。此示例中的域名不对齐;其他情况则取决于域名关系和对齐模式。
如果 SPF 不对齐,DMARC 就依赖有效且对齐的 DKIM 签名。转发服务器的某些修改可能破坏签名,前提是修改涉及已签名部分,且不能被规范化规则消除:
- 在主题前添加
[EXTERNAL] - 插入防病毒页脚或法律声明
- 将 8 位编码转换为 7 位编码
- 改写 MIME 边界
这些修改并非必然破坏所有签名,但需要测试。如果 SPF 和 DKIM 都没有有效且对齐的通过结果,DMARC 就会失败。即使 SRS 正常工作,接收方仍可能按策略拒收或过滤邮件。
ARC(Authenticated Received Chain)的作用
ARC(RFC 8617)允许转发服务器记录实际观察到的认证结果,并对相应数据集进行签名。它添加三个邮件头:
- ARC-Authentication-Results: 记录中间服务器观察到的 SPF/DKIM/DMARC 结果
- ARC-Message-Signature: 对生成 ARC 数据集时的邮件头和正文进行签名;此后修改已签名部分可能导致签名失效
- ARC-Seal: 将当前 ARC 集合与之前的链关联起来的签名
如果最终接收方验证了 ARC 链并信任签署服务器,就可能据此接受后续 DMARC 失败的邮件。这不会将失败变成 DMARC 通过,也不保证投递。Gmail 自 2019 年起在生产环境中评估 ARC。
规划 2026 年的转发流程时,可考虑用 SRS 邮件转发处理 SPF,保留 DKIM 已签名部分,并在支持且有帮助时使用 ARC。这不是三项普遍要求,也不足以保证邮件投递。
不同平台如何配置 SRS
配置因平台而异:Postfix 可以集成外部服务,Microsoft 365 结合环境功能与策略,Google Workspace 则应用自身控制。请核实当前可用及已启用的设置,不要假定所有环境的默认值相同。
Postfix(自托管 Linux)
通过 postsrsd 服务是 Postfix 集成 SRS 的一种方式。以下命令仅为示例,需核实是否适用于当前发行版和版本:
apt-get install postsrsd
以下旧版示例在 /etc/postfix/main.cf 中使用 TCP 映射。进行获授权的修改前,应备份配置,与现有映射合并,并核实当前 postsrsd 版本支持的套接字、路径及格式:
sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipient
重要:核实当前版本的排除配置方式;示例使用 SRS_EXCLUDE_DOMAINS 指定本地域名,配置位于 /etc/default/postsrsd。错误的排除规则可能改写自身出站邮件,或与路由规则共同导致循环,但遗漏某个选项并不必然产生循环。修改前应测试入站、出站和退信路径。
Microsoft 365
Microsoft 365 在部分流程中支持 SRS;请核实当前出站池、混合环境及连接器的行为。类似 550 5.7.520 Access denied, Your organization does not allow external forwarding 的错误表示发送环境限制外部转发,并不能单独证明 SRS 故障。
在当前管理界面检查出站反垃圾邮件策略。经过安全审查后,只为获授权的用户和合法目的地开放必要转发,不要大范围关闭保护。以下命令并非通用,其参数可能不受支持;修改前应核实适用的 cmdlet、版本及文档:
Set-OutboundConnector -Identity "Outbound to Gateway" -SenderRewritingEnabled $true
Google Workspace
Google 使用自身机制和控制。以下风险并非 Workspace 独有,应结合实际环境检查:
- 流量限制:将 catch-all 邮件转到 Gmail 可能超过适用配额。大量垃圾邮件可能触发限制,但并非必然停用账号;应核实当前限额和账号状态。
- 循环与邮件缺失:路由规则及循环检测可能阻止某些转发。请检查可用日志、SMTP 响应和邮件跟踪工具,不要假定邮件总是被无声丢弃且没有记录。
排查 SRS 邮件转发故障
完整邮件头可以提供线索,但不一定可获取,也未必足以确定原因。可从 ProtonMail 向转发地址发送测试邮件,并在最终目的地检查收到的内容。还应结合可用的 SMTP 日志、配置和邮件跟踪结果。
检查 1:Return-Path
未显示 SRS 改写:Return-Path: <original@protonmail.com>
显示 SRS 改写:Return-Path: <SRS0=xxxx=yy=protonmail.com=original@yourdomain.com>
如果 Return-Path 仍是原域名,应检查该路径是否需要 SRS、是否属于排除范围,或是否绕过配置的映射。服务停止或集成错误也是可能原因,但仅凭该邮件头无法证明。
检查 2:Authentication-Results
在接收方可信的认证邮件头中,查找与改写域名关联的 spf=pass。SPF 通过但出现 dmarc=fail,可能是 SPF 不对齐,同时 DKIM 缺失、无效或不对齐。应检查签名及主题、正文改动,而不只是确认是否存在签名。
检查 3:DNS
dig yourdomain.com TXT +short
确认 SRS 域名有授权实际出站 IP 的有效 SPF,并且退信地址可达。存在 MX 记录并不足以证明可达,没有 MX 也不必然无法接收,因为可能通过 A/AAAA 使用隐式 MX 路由。应测试退信地址并检查接收方实际错误。
检查 4:Postfix 日志
grep "srs_forward" /var/log/mail.log
hash mismatch 或 timestamp expired 可能与节点间密钥不一致、密钥轮换、时钟偏差、配置错误或旧地址有关。重放尝试也可能出现这些错误,但错误本身不能证明攻击。
何时改用托管邮箱而不是 SRS 转发
SRS 邮件转发处理的是中间跳点造成的身份不匹配。SRS、保留 DKIM 签名以及按需使用 ARC 都会增加运维依赖。按用户计费可能让转发显得更便宜,但决策前也应计算维护及故障排查时间。
对比两种方式:
| SRS 邮件转发 | 托管邮箱(TrekMail) | |
|---|---|---|
| SPF 对齐 | 可能无法与原 From 对齐 | 出站路径获授权并正确对齐时可实现 |
| DKIM | 修改已签名部分可能破坏签名 | 签名取决于供应商和出站配置 |
| DMARC | 需要有效并对齐的 SPF 或 DKIM;ARC 可影响策略判断 | 需要配置并测试对齐 |
| 配置复杂度 | 集成 postsrsd、保留签名并按需使用 ARC | 根据可用功能使用域名设置向导 |
| 每用户成本 | 示例中为 $0,加上排查时间 | 按套餐采用固定价格和共享存储 |
| 多域名 | 服务器及路由配置 | 所述方案支持 1,000+ 个域名,实际限额需核实当前套餐 |
TrekMail 描述的是固定价格套餐,由邮箱和域名共享存储,并非无限容量或仅按存储计费。应核实当前限额和条件。代理机构可与常见 Gmail 转发设置比较,或阅读邮件别名转发的优势与限制指南。如果尚未决定使用别名还是真实邮箱,可查看域名邮件别名与邮箱对比。
直接将邮箱托管在 TrekMail 可去掉这一转发跳点,因此该路径可能不再需要 SRS 或 ARC。向导可以帮助准备 SPF、DKIM 和 DMARC,但每条出站路径都需授权和测试,包括套餐支持的外部 SMTP 服务商及其凭据。作为域名的 MX 服务器并不自动获得 SMTP 发送授权,也不保证认证通过。
试用 TrekMail:所述方案包括无需银行卡的 Nano,以及 Starter 的 14 天试用,起价为 $3.50/mo,包含托管 SMTP。请核实当前可用性、资格、功能和价格。
总结
SRS 邮件转发适用于文中讨论的 2025-2026 年转发场景,并非所有转发服务器的普遍要求。没有 SRS 时,如果原域名未授权新 IP,SPF 可能失败。使用 SRS 后,正确授权可让 SPF 通过,但仍可能无法与原 From 对齐。DMARC 需要有效且对齐的 SPF 或 DKIM。
在 Postfix 中应核实 postsrsd 版本、main.cf 映射和排除规则。在 Microsoft 365 中应检查获授权的策略和实际可用功能,不要应用不兼容命令。在 Workspace 中应检查配额、规则、日志和账号状态。
按需使用 SRS,保留 DKIM 签名,并在接收方支持且信任链时使用 ARC。这不保证邮件投递。也可以将邮箱直接托管在最终接收位置,同时保留必要的认证配置和测试。