你设置了转发规则，发送测试邮件，一切正常，于是继续处理其他事情。
后来，客户说没有收到你的回复。你看不到退信，也没有 NDR 未送达报告。邮件似乎消失在服务器之间，但具体原因仍需查看投递日志才能确定。
当你将邮件转发到其他地址时，服务器会与目标建立新的 SMTP 连接。目标检查 SPF 时使用的是你的 IP，而非原发件服务器的 IP。如果原始信封发件域没有授权这个 IP，SPF 可能失败。如果原来与可见 From 域对齐的有效 DKIM 签名也未能保留，DMARC 就会失败。p=reject 请求接收方拒收，但实际拒收、过滤或其他处理方式，以及是否产生退信，取决于接收方。
这不一定是配置拼写错误，而可能是转发机制与现代身份验证之间的冲突。完整的邮件转发设置与故障修复指南介绍了不同场景。本文聚焦身份验证层：常见故障、错误代码及相应措施。
为什么转发邮件可能导致身份验证失败
转发时，目标接收 MTA 根据转发服务器的 IP 检查 SPF。邮件具有不同的发件身份，转发可能使它们不再对齐。SPF 验证信封发件人；DMARC 要求至少有一个成功的 SPF 或 DKIM 结果，其域与可见 From 域对齐。两个对齐的验证结果都不存在时，DMARC 失败；后续处理由接收方策略决定。
| 层级 | RFC | 含义 | 验证机制 |
|---|---|---|---|
| 信封 (P1) | RFC 5321 | SMTP 会话中的 MAIL FROM，用于退信路由，投递后体现在 Return-Path 中 | SPF |
| 邮件头 (P2) | RFC 5322 | 收件人在邮件客户端中看到的 From: 字段 | DKIM；DMARC 检查域对齐 |
路径如下：服务器 A 将邮件发送至转发服务器 B，B 再与目标 C 建立新的 TCP 连接。C 看到 B 的 IP。SPF 根据原始信封发件域的 DNS 询问："这个 IP 是否被授权代表该域发送邮件？"如果 B 未获授权，SPF 可能失败。这很常见，但并非每次转发都必然如此。
DMARC 只需一个成功且对齐的 SPF 或 DKIM 结果，因此保留下来的原始 From 域 DKIM 签名可以让转发邮件通过 DMARC。关键是签名覆盖的邮件头和规范化后的正文；并非所有修改都会破坏 DKIM。两个对齐的验证结果都缺失时，DMARC 失败。p=reject 请求拒收，但并不保证某种投递结果或退信行为。
三类常见故障
转发可能遇到管理策略拦截、身份验证失败或路由循环。每一类的原因和处理方法都不同。并非每种故障都有固定的 SMTP 错误代码，但先确定类型有助于缩小排查范围。
1. Microsoft 365 阻止出站转发 (550 5.7.520)
Microsoft 365 将自动外部转发视为潜在的数据外泄途径。生效的默认策略可能在邮件离开 Exchange Online 之前，阻止将邮件转发至租户外部的规则。
550 5.7.520 Access denied, Your organization does not allow external forwarding.这是策略限制，不是协议错误。获得授权的管理员可以按以下步骤处理：
- 打开 Microsoft 365 Defender Portal。
- 进入 Email & collaboration → Policies & rules → Threat policies → Anti-spam。
- 创建或编辑仅适用于明确获准账户的 Outbound spam filter policy。
- 经过批准后，在该限定策略中将 Automatic forwarding 设为 On - Forwarding is enabled。
不要直接修改组织全局默认策略来开放转发。全局开放会扩大账户被入侵后的风险。应限定适用账户，启用 MFA 并监控出站邮件量，同时检查其他仍然生效的转发限制。
2. 两个 DMARC 验证依据均缺失
这类故障容易被忽略。IP 改变可能导致 SPF 失败，但有效且对齐的 DKIM 签名仍能让 DMARC 通过。如果签名覆盖的内容或邮件头被修改，DKIM 也可能失效。是否失效取决于签名范围和规范化方式，不能笼统地说任何修改都会破坏签名。
可能影响 DKIM 的常见修改包括：
- 杀毒软件追加的页脚，例如 "已由 [产品名称] 扫描"
- 目标网关添加的主题标签，前提是主题被签名：
[EXT]或[EXTERNAL] - 插入 HTML 正文的 "外部发件人" 警告横幅
- 邮件列表软件改写已签名的邮件头或追加退订页脚
既没有成功且对齐的 SPF，也没有有效且对齐的 DKIM 签名时，DMARC (RFC 7489) 返回 FAIL。p=reject 表示发件域请求拒收。接收方仍可按自身策略处理，可能拒收并返回错误、隔离或采取其他措施。没有通知并不能证明邮件一定被静默删除。
3. 路由循环 (554 5.4.14)
服务器反复把邮件交回对方，直到达到跳数限制，就形成路由循环。循环可能产生 NDR，但不保证立即产生，也不保证每次都有报告。它还可能堵塞队列，延误其他邮件。
可能的触发条件：
- 用户 A 转发给用户 B，B 又通过规则转发回 A。
- A 转发给 B，B 的外出自动回复经 A 的转发规则再次送给 B。如果系统没有充分抑制自动回复，可能形成回复循环，但这并非必然。
- 全收地址转发给某个邮箱，该邮箱又转发至同域不存在的地址；是否形成循环取决于全收和路由规则。
554 5.4.14 Hop count exceeded - possible mail loop在生产环境启用转发前，应检查完整路由链，包括自动回复和全收地址的目标。
应对机制：SRS 与 ARC
两个服务器端机制可以改善转发，但不能保证投递。SRS 改写信封发件人；若转发域的 DNS 授权出站 IP，SPF 就有机会通过。ARC 记录之前的身份验证结果，使信任转发方的接收者可以按自身策略考虑 DMARC 例外。普通客户端规则本身无法实现这些服务器端机制。
SRS：Sender Rewriting Scheme
SRS 将信封发件人 (P1) 改写为你控制的域中的地址。转发服务器不再保留可能未授权你的 IP 的 alice@bank.com 作为信封发件人，而是生成类似下面的退信地址：
SRS0=Hash=Timestamp=bank.com=alice@your-forwarding-domain.comSPF 随后检查转发域。如果其 SPF 记录授权出站 IP，且没有其他 SPF 错误，检查就可能通过。但这本身不会建立与原始 From 域的 DMARC 对齐。
哈希和时间戳有助于受控的退信路由：发往有效 SRS 地址的 NDR 可以被解码并转交给真正的 Alice。这些地址有时间限制且专用于此用途。不过，保护 SRS 密钥并不足以防止开放中继；还必须配置独立的中继访问控制，并验证退信收件地址。
ARC：Authenticated Received Chain
SRS 可以帮助转发域通过 SPF，但不消除信封域与原始 From 域之间的对齐差异。ARC (RFC 8617) 也不消除该差异。它提供加密保护的身份验证记录，相当于转发方声明："这是我收到邮件时观察并验证的结果。"
Google、Microsoft 等接收方可以在投递决策中考虑可信转发方的有效 ARC 链。是否信任签章，以及是否对 DMARC 策略作例外处理，由接收方自行决定。良好的 IP 声誉和有效 ARC 链都不保证接收邮件或将其放入收件箱。
可以把 ARC 理解为交接记录。每个参与转发的节点都会添加关于当时身份验证状态的签名记录。下游接收方可以验证链条，并按自身策略决定是否采信，即使当前 DMARC 检查没有找到成功且对齐的 SPF 或 DKIM 结果。
Gmail 和 Microsoft 365 在某些邮件流程中支持 ARC。应检查实际邮件头与最新文档，不要假定所有路径都会自动加签。没有 ARC 只是缺少这份额外记录，并不意味着 DMARC 必然失败；原始有效且对齐的 DKIM 签名仍可能足够。
实施：两条路径
你可以自行管理 MTA，也可以使用为目标转发路径提供 SRS 及可用 ARC 支持的平台。托管方案同样需要正确的 DNS、规则和投递测试。两种方式都无法排除所有投递故障。
方案 A：自主管理 Postfix + postsrsd
在运行 Postfix 的 Linux 服务器上，可以使用 postsrsd 进行信封改写。以下是旧版 TCP 映射接口的示例，不能原样用于采用 socketmap 接口的版本。请先核对安装版本及其文档中的配置要求。这里没有执行此示例：
# /etc/postfix/main.cf
sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipient你需要承担的工作包括：
- 管理 SRS 密钥。泄露可能让攻击者伪造 SRS 退信地址；无论密钥是否安全，都需要中继访问控制。
- 正确排除本地域。过度改写可能影响内部邮件投递。
- 维护出站 IP 声誉，它与其他因素共同影响 Gmail 和 Outlook 的投递决策。
- 另外配置 ARC；仅有 postsrsd 并不能实现 ARC 签名。
正确配置的系统可以工作，但需要持续维护。专门的邮件平台可以承担其中一部分运营工作。
方案 B：TrekMail 托管转发
请针对所选 TrekMail 套餐和实际转发路径，确认自动 SRS 改写、ARC 签名与托管 SMTP 中继的当前可用性。这些能力可以减少自行配置服务器和管理密钥的工作，但付费套餐是否包含 ARC、具体路径是否使用某类中继，都应在购买前核实。中继声誉并不保证投递。
| 能力 | 自托管 Postfix | TrekMail |
|---|---|---|
| SRS 信封改写 | 安装并配置 postsrsd | 若目标路径支持，则自动处理 |
| ARC 签名 | 需要额外配置 | 请确认所选付费套餐的支持情况 |
| SPF/DKIM/DMARC 设置 | 逐域修改 DNS | 请确认设置向导的可用性 |
| 发送声誉 | 取决于你的 IP 历史 | 托管 SMTP 中继 (Starter+)，需核对套餐和路由 |
| 多域规则管理 | 逐服务器配置 | 根据当前功能提供集中式域管理 |
对于独立创业者，如果每个邮箱每月支付 $6 只是为了把 info@yourdomain.com 转发至个人收件箱，不妨比较按域计费的方案。本文提到的 Starter 每月 $3.50、最多 50 个域且不按用户收费的条件，需要在签约前核对最新价格及转发限制。参见 TrekMail 邮箱转发的工作方式。
对于管理多个客户域的机构，排查 SPF 问题可能消耗大量成本。如果所需功能可用，集中管理转发规则可以简化运营。邮件别名转发指南详细介绍了别名与邮箱规则之间的取舍。
启用转发前的检查清单
启用生产转发规则前，请检查全部四项。它们有助于排查上述故障，但不能替代使用实际发件方和接收系统的测试。
- SRS 已启用。检查已投递测试邮件的
Return-Path。若该路径应使用 SRS，其中应显示转发域；还要单独确认该域的 SPF 授权出站 IP。 - 尽量保留签名内容。避免会影响 DKIM 的页脚、主题标签和正文警告横幅。不要关闭杀毒或其他安全扫描；使用不修改签名内容的等效保护，并检查规范化方式及签名覆盖的邮件头。
- 防止循环。检查反向转发、外出自动回复、全收目标及抑制自动回复循环的机制。
- M365 出站策略。使用 Exchange Online 时检查生效策略。仅在经过批准且限定必要账户的策略中允许自动外部转发，不要全局开放。
什么时候不宜采用邮件转发
如果多个域的邮件都要进入同一个本地托管邮箱，域别名可能避免额外的外部转发。但如果别名最终仍向外转发，就不能绕过 SPF、DKIM 或 DMARC；关键在实际投递路径。
域邮件别名与邮箱比较介绍了适用场景。迁移历史邮件时，IMAP 迁移工具可能比实时转发更合适。请确认 TrekMail 工具的当前可用性；通过 IMAP 复制历史邮件不能替代为新邮件切换投递路由。
总结
外部转发后，接收方看到的是你的服务器 IP。如果原始信封域未授权该 IP，SPF 可能失败。如果也没有保留有效且对齐的 DKIM 签名，DMARC 就会失败。邮件如何处理由接收方决定，静默删除或没有退信都不是必然结果。
相关措施需要在服务器端实施：SRS 将信封发件人改写为受控域，并在 SPF 配置正确时提供帮助；ARC 记录先前的身份验证结果，供接收方作信任判断，但不会建立 DMARC 对齐。你可以自行部署两者，也可以选择支持所需路径的平台。
如果不想自己管理 SRS 密钥、ARC 配置和 SMTP 中继，请核对 TrekMail 是否提供所需功能。本文提到的 Starter 每月 $3.50、最多 50 个域且不按用户收费的条件，需要与当前套餐及转发限制核对。查看所有套餐。
