邮件转发

SRS邮件转发原理、认证限制与配置排查

作者:Alexey Bulygin
展示SRS邮件转发改写信封发件人地址以进行SPF验证的示意图

你设置了转发,让 contact@yourdomain.com 将邮件转到 Gmail。运行一周后,客户邮件开始收不到。你可能没有收到通知,但 SMTP 拒绝也可能产生未送达报告。日志中出现 550 5.7.1 Unauthenticated email550 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 等邮件头中查看。

以下流程说明一种可能的故障,并非必然结果:

  1. Alice 从 alice@client.com 发信。她的 SPF 记录授权了原服务器,邮件到达你的服务器时通过 SPF。
  2. 你的服务器向 you@gmail.com 建立新的 SMTP 连接。此时发送 IP 变成你的服务器 IP。
  3. Envelope Sender 仍为 alice@client.com,但在此示例中,client.com 的 SPF 记录未授权你的服务器 IP。
  4. Gmail 检查 client.com 的 SPF,发现该 IP 未获授权,因此 SPF 失败。
  5. 如果 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 mismatchtimestamp 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。这不保证邮件投递。也可以将邮箱直接托管在最终接收位置,同时保留必要的认证配置和测试。

分享这篇文章

我们使用运行和保护 TrekMail 所必需的技术。确认后还会允许《Cookie 政策》中所述的有限分析和广告衡量。

登录 TrekMail

访问您的控制面板、邮箱和 DNS。

12 个字符 两次密码一致

重置邮件已发送

如果该邮箱对应已有账户,我们已发送密码重置说明。

继续即表示您同意 TrekMail 的 服务条款隐私政策.