域名邮件转发到 Gmail：配置与验证指南

你将 contact@yourdomain.com 的域名邮件转发到 Gmail。客户发送合同，银行发送安全提醒，两封邮件都没有出现。

垃圾邮件文件夹也没有记录。在这个场景中，你没有看到邮件、错误或通知，但原始发件人仍可能收到了你看不到的退信。

这可能是验证问题，而不是 Gmail 界面的问题。将域名邮件转发到 Gmail 时，你的服务器用自己的 IP 转发其他域名的邮件。如果保留原始信封发件人，而该域名的 SPF 不授权这个 IP，SPF 就会失败。如果发件人使用严格 DMARC 策略（p=reject），且没有有效、对齐的 DKIM 验证通过，Gmail 可能以 550-5.7.26 等代码拒收。SMTP 拒收可能向发件人产生退信，并不必然意味着邮件被永久删除且双方都没有通知。

SRS（Sender Rewriting Scheme）重写信封发件人，ARC（Authenticated Received Chain）保留带签名的验证结果。它们可能改善转发，但不保证投递成功，也不是所有场景都必须同时具备两者。保留下来的有效、对齐 DKIM 签名也可能让 DMARC 通过。

本文介绍 SRS 重写、循环预防和 Gmail 的“以此地址发送”设置。有关 SPF、DKIM、DMARC 的相互作用和 SRS 的原理，请参阅完整邮件转发设置与故障排查指南。

Gmail 为什么可能拒收转发邮件？

原始 SPF 可能失败，因为信封发件人的域名没有授权转发服务器 IP。SRS 可让接收方按转发服务的域名检查 SPF，前提是该域名授权服务器。这并不保证与原始 From: 满足 DMARC 对齐；DKIM、ARC、过滤器和接收策略也影响结果。

将 client@bank.com 的邮件转发给 you@gmail.com 时，可能出现以下失败：

1. bank.com 将邮件送到你的转发服务器
2. 你的服务器将其转交给 Gmail
3. Gmail 检查保留的信封发件人 client@bank.com 的 SPF
4. bank.com 的 SPF 不授权你的服务器 IP：SPF FAIL
5. DMARC 策略为 p=reject，且没有对齐的 DKIM 验证通过：Gmail 可能返回 550-5.7.26
6. 邮件被拒收。你可能收不到通知，但发件人可能收到退信。邮件保留情况取决于服务器。

如果签名覆盖的数据没有改变，DKIM 可以在转发后继续有效。应避免添加页脚或改写已签名的主题。即使 SPF 失败，有效且对齐的 DKIM 仍可能让 DMARC 通过。aspf=s 仅影响 SPF 对齐，不影响 DKIM。修改已签名内容可能使 DKIM 失效，但并非任何修改都会如此。请检查两种机制；SRS 不是保证 DMARC 成功的办法。

将域名邮件转发到 Gmail 的三种方式

不同转发设置的风险不一样。启用前应按用途选择合适架构。

catch-all 可能影响投递能力。垃圾邮件发送者会尝试 abc123@yourdomain.com、junk@yourdomain.com 等地址。如果服务器接收并转发，也会把垃圾邮件送往 Gmail。原文中的 90% 是场景示例，不是 Gmail 的固定封禁阈值。发送 IP 信誉可能下降，正常邮件可能进入垃圾邮件；恢复并没有固定期限。

要进一步了解取舍，请阅读邮件别名转发的利弊。如果要为新地址选择别名或独立邮箱，域名邮件别名与邮箱对比介绍了判断标准。

SRS：转发到 Gmail 时为什么应评估它？

SRS 有助于处理转发跳点的 SPF 失败。它将信封发件人的域名改为转发服务的域名；该地址在投递时体现在 Return-Path 中，也用于退信。服务器被授权时，Gmail 可能按新域名验证 SPF。这不保证 DMARC 或投递，也不是所有转发的普遍强制要求。

没有 SRS，失败场景：
信封发件人：client@bank.com
发送 IP：203.0.113.10（示例转发服务器）
SPF：bank.com 记录 → FAIL（203.0.113.10 未获授权）
DMARC：没有有效、对齐 DKIM 时为 FAIL（p=reject）→ 可能拒收，并非必然删除

使用 SRS，示例中的 SPF 已修正：
信封发件人：SRS0=HASH=TT=bank.com=client@yourdomain.com
发送 IP：203.0.113.10（示例转发服务器）
SPF：yourdomain.com 记录 → PASS（203.0.113.10 已获授权）
邮件头 From:：client@bank.com（未改变，保留原始可见发件人）

SRS 使用的域名必须通过适当 SPF 机制授权发送 IP 或服务。如果没有授权，重写并不足够：即使新地址属于你的域名，SPF 仍可能失败。

转发基础设施还可以添加 ARC（Authenticated Received Chain）邮件头。ARC 用签名链记录验证结果。Gmail 是否采信取决于对转发服务的信任和接收策略。这需要正确的 ARC 签名配置，而不只是普通 DKIM 签名。由服务器运营者实施；如果不是你管理服务器，请确认服务商支持范围。

SPF 在 RFC 7208 中定义。记录多个跳点验证结果的 ARC 在 RFC 8617 中定义。

预防循环：上线前的四项检查

转发循环可能导致 5.4.14 Hop count exceeded 等错误，阻止正常投递。投入使用前应进行以下检查。

1. 避免循环路由。确认 you@gmail.com 没有过滤规则把邮件送回 you@yourdomain.com，然后再次转向 Gmail。这种路线可能持续循环，直到触发服务器限制。
2. 管理外出自动回复。职能地址（team@domain.com → 多个 Gmail 账号）应检查自动回复和循环预防。Precedence: bulk 在部分系统可能有帮助，但不能替代完整的自动回复抑制策略。
3. 从第三个账号测试。Gmail 可能对邮件去重。从目标账号向别名发送测试，可能只在已发送中出现而不进入收件箱。请使用其他账号，例如 Yahoo 或 Outlook，并检查日志。
4. 检查 M365 出站策略。如果使用 Microsoft 365，应由获授权的管理员检查出站垃圾邮件策略是否允许所需转发。阻断可能产生 550 5.7.520；不要未经批准修改保护，也不要假定所有路径策略相同。

这些是首次配置时的常见问题。仅凭错误代码不一定能找到具体设置原因。

通过 TrekMail 将域名邮件转发到 Gmail

原文描述 TrekMail 在 MTA 层为转发邮件处理 SRS 重写和 ARC 签名，并在控制台选择目标地址。请在文档中核实当前实现和覆盖范围。自动处理并不保证 Gmail 接受每封邮件。

源快照将邮箱转发列为 Pro 与 Agency 套餐功能，而非 Free、Starter 的功能。升级前请确认当前要求。原文步骤见 TrekMail 邮箱转发文档：

1. 在控制台打开邮箱（Mailboxes）
2. 在目标邮箱点击管理（Manage）
3. 开启启用转发（Enable forwarding）
4. 在转发至（Forward to）输入 Gmail 地址
5. 初始配置期间开启保留副本（Keep a copy）
6. 点击保存转发设置（Save Forwarding Settings）

“保留副本”很重要。在所述配置中，系统会尝试投递到 Gmail，并在配额和本地投递正常时保留本地副本。关闭后，外部拒收可能让你无法在邮箱访问副本。检查邮件和邮件头期间应保持开启，但它不等于有保证的备份。

原文也描述了批量操作：勾选多个邮箱后应用同一目标地址，包括在一百个域名上操作。用于客户域名前应确认当前功能和范围，并测试、查看结果，不要假定一个动作会在所有域名成功。

完成收发流程：Gmail 的“以此地址发送”

转发处理入站邮件，不会配置回复身份。如果没有设置“以此地址发送”，回复可能来自个人 @gmail.com，而不是 ceo@yourdomain.com，实际取决于客户端设置。

需要时，应使用已获授权的外部 SMTP 凭据配置“以此地址发送”。检查发送方式及“视为别名”选项：一个复选框本身不能决定所用服务器，也不保证 DMARC 对齐。请测试 From:、Return-Path 和验证结果。

Gmail 中的参考路径为：设置 → 账号和导入 → 用这个地址发送邮件 → 添加其他电子邮件地址。应检查“视为别名”在当前配置中的作用，而不是一律取消勾选。

原文所述 Starter、Pro、Agency 的 TrekMail SMTP 设置：

SMTP Server:  smtp.trekmail.net
Port:         587
Security:     TLS (STARTTLS)
Username:     your-mailbox@yourdomain.com
Password:     Your mailbox password

原文中的 Nano：自备外部 SMTP（SES、SendGrid、Mailgun 等）：

SMTP Server:  email-smtp.us-east-1.amazonaws.com  (Amazon SES example)
Port:         587
Security:     TLS
Username:     Your SMTP credentials from your provider

以上是示例，请核实当前连接参数和凭据。Gmail 添加地址时可能发送验证码。完成验证，并按需要设置默认发件地址，随后检查实际回复所选的身份。

验证配置：查看 Gmail 验证邮件头

收到外部账号的测试邮件后，应查看完整邮件头，再将重要邮件交给这套配置。

在 Gmail：打开邮件 → 三点菜单 → 显示原始邮件。查找 Authentication-Results。

原文提供以下示例，但它本身不能证明 DMARC 与原始发件人对齐：

Authentication-Results: mx.google.com;
  spf=pass (google.com: domain of SRS0=hash=tt=bank.com=client@yourdomain.com
    designates 203.0.113.10 as permitted sender)
    smtp.mailfrom=SRS0=hash=tt=bank.com=client@yourdomain.com;
  dkim=pass header.i=@yourdomain.com;
  arc=pass (i=1 spf=pass dkim=pass)

spf=softfail 或 spf=fail 可能提示 SRS、SPF 授权或其他检查问题。arc=fail 可能来自已签名内容被改动、密钥、签名或链无效，并不能指定唯一原因。还应检查 From:、DKIM、DMARC 和 ARC 信任。Google 关于转发到 Gmail 的官方建议可帮助检查信封发件人的处理。

自行管理还是托管服务：实际取舍

在自管 Postfix 上，一种方案是配置 postsrsd，保护并管理 srs_secret，规划轮换，并为 OpenARC 配置适当 ARC 签名密钥。适用时也应通过 Google Postmaster Tools 关注 IP 信誉。具体步骤取决于架构。更新、错误轮换或新策略都可能需要排查，即使已经是晚上 11 点。

原文描述 TrekMail 在设置目标后，由 MTA 管理 SRS 和 ARC。仍应确认当前要求、DNS 授权和投递结果，并持续检查配置。

开始使用

原文将无需信用卡的 Nano 介绍为连接、测试域名的起点，而不是包含邮箱转发的套餐。该功能被列在 Pro，固定费用起价每月 $10，不按用户收费，但受套餐限额约束。订购前请确认当前功能和价格。

源快照描述付费套餐提供 14 天免费试用，需要信用卡，而 Nano 不需要。请到 trekmail.net/pricing 核实现行条款。

应检查四个方面：需要时使用 SRS 重写信封、ARC 签名结果、SPF 对转发服务器的授权，以及“以此地址发送”的出站身份。这些是有用的控制措施，不保证多年无故障。DKIM、过滤器、接收策略和监测同样重要，失败也并非总是没有通知。

完成配置，验证邮件头，并持续关注结果。