想在不支付任何邮箱费用的前提下，在 Gmail 上使用独立域名（例如 [email protected]）的邮件，这样的场景应该很多。实际用 Cloudflare 与 Gmail 的组合试过后发现，「收信」与「发信」完全是两套不同的机制在运作，两者的难度也相差甚远。本文依据官方文档与 RFC 的定义，整理这套步骤，以及为何唯独发信一侧在邮件认证的原理上无论如何都需要一定的取舍。

结论 — 收信完全免费闭环，发信也能做到，但唯独认证需要取舍

  • 收信简单，且确实能免费闭环。 Cloudflare Email Routing 会把发往域名的邮件转发到你现有的收件箱（Gmail）。它可免费使用，所需的 DNS 记录会自动创建。不过件数并非无限，根据 Email Routing 的限制一览，每个域名的路由规则（自定义地址）上限为 200 条，每个账户已验证的转发目标地址上限也是 200 个。
  • 发信可以免费实现，但残留一个结构性的制约。 通过 Gmail 的「以其他地址发送」（Send mail as），可以用独立域名作为发件人来发送。但个人 Gmail 账户无法为自己的域名打上 DKIM 签名，因此从独立域名的视角看，DMARC 认证在原理上无法凑齐。若在不理解这一点的情况下给独立域名设置了严格的 DMARC 策略（如 p=reject），你自己发出的邮件可能会被自己域名的策略拦下。

也就是说，「免费在 Gmail 上承载独立域名邮件」这一前提是正确的，200 条的上限在个人使用的范围内也不成问题。在此之上，唯独发信一侧的认证需要取舍——这正是本文的主题。

全局：收信与发信是两回事

邮件的「接收路径」与「发出路径」是相互独立的。在这套配置中，两者由不同的服务负责。

负责方费用难度
收信Cloudflare Email Routing（转发）免费低
发信Gmail「以其他地址发送」＋ Gmail SMTP免费中（需要理解认证）

Cloudflare Email Routing 明确专用于收信（转发），无法从这个功能本身发送邮件（Email routing rules and addresses）。所以发信另行交给 Gmail 一侧。下面按收信 → 发信 → 认证的顺序来搭建。

1. 搭建收信一侧（Cloudflare Email Routing）

前提条件

Email Routing 必须满足域名的 DNS 由 Cloudflare 管理（即域名服务器指向 Cloudflare）（Email Routing — Cloudflare）。如果尚未把域名添加到 Cloudflare，请先完成域名服务器的迁移。

设置步骤

  1. 在 Cloudflare 控制台中选择目标域名，打开 Email Routing。
  2. 在 转发目标地址（Destination Address） 中登记想要汇集收信的 Gmail 地址。Cloudflare 会发来一封确认邮件，请在 Gmail 收件箱中点击链接完成验证。在验证完成之前，路由规则不会被启用（以防止垃圾邮件滥用）。
  3. 创建 路由规则（Routing Rule）。把 [email protected] 这样的自定义地址与已验证的 Gmail 绑定（Email routing rules and addresses）。
  4. 启用 Email Routing 后，Cloudflare 会自动添加 MX、SPF、DKIM 的 DNS 记录（Domain configuration）。请注意，这里自动添加的 SPF/DKIM 仅仅是为了让转发路径得到正确认证（并非用于发信）。

值得记住的实用功能

  • 通配收信（Catch-all）：包括本地部分并不存在的收件地址在内，可以把发往该域名的所有邮件都汇入一个收件箱。对挽救拼写错误很方便，但垃圾邮件也会全部收进来，因此运营需谨慎（Email routing rules and addresses）。
  • 子地址（加号地址）：可以依据 RFC 5233 处理 [email protected] 这类带 + 的地址。+ 之后的部分会被忽略、按 user@ 的规则接收，同时可在日志或 Worker 中用于识别用途。
  • Worker 联动／Drop：可以用 Worker 对收到的邮件进行程序化处理，或丢弃发往特定地址的邮件（让其看起来存在却将其扔掉）。

陷阱

  • 启用 Email Routing 后，该域名的 MX 会指向 Cloudflare。若之后又在同一域名上接入 Google Workspace 或 Microsoft 365，它们签发的新 MX 会覆盖 Cloudflare 的 MX，转发随之停止。切换邮件服务商时，请先禁用 Email Routing，或注意 MX 的优先级（Domain configuration）。
  • 由于这是收信专用，如果你直接从 Gmail 回复，发件人会是 @gmail.com。收件人会看到你的个人地址。要让这里显示为独立域名，就需要接下来的发信设置。

到这一步，「收信」已经完全免费闭环。对许多人来说，做到这里可能就已经足够了。

2. 搭建发信一侧（Gmail 的「以其他地址发送」）

Gmail 有一项「以其他地址发送（Send mail as）」功能，可以用你所拥有的另一个地址作为发件人来发送。我们用它把 [email protected] 设为发件人。

事前准备：两步验证与应用专用密码

要把个人 Gmail 账户当作发信服务器使用，需要向 Gmail 的外部 SMTP（smtp.gmail.com）提供认证信息。为此：

  1. 在 Google 账户上启用两步验证（2-Step Verification）。
  2. 签发应用专用密码（myaccount.google.com/apppasswords）。若未启用两步验证，应用专用密码这一项不会出现。

这个应用专用密码就成为 SMTP 认证的密码。

在 Gmail 中的设置

  1. 在 Gmail 的 设置 → 账户和导入 → 用作发件人的其他电子邮件地址 中点击「添加另一个电子邮件地址」。
  2. 输入名称，以及想设为发件人的独立域名地址（[email protected]）。
  3. 输入 SMTP 服务器信息：
    • SMTP 服务器：smtp.gmail.com
    • 端口：587（TLS）或 465（SSL）
    • 用户名：你的 ～@gmail.com（※是 Gmail 地址，而非独立域名）
    • 密码：刚才签发的应用专用密码
  4. 为确认所有权，Gmail 会向 [email protected] 发送一个确认码。

这时收信设置就派上用场了。确认码会送达 [email protected]，经 Cloudflare Email Routing 转发到你的 Gmail。输入该码即可通过所有权确认，收信与发信的闭环就此合拢。此后，就能在 Gmail 的撰写界面里把 From 选为独立域名了。

3. 核心：为何唯独「发信」的认证棘手

这是本文最需要准确性的部分。上述配置是能跑通的。但「从独立域名视角看的邮件认证」在原理上无法凑齐。下面回到 SPF、DKIM、DMARC 的定义来解说其原因。

SPF 并不看「From 头」

SPF（Sender Policy Framework，RFC 7208）所认证的，是 SMTP 的信封发件人（MAIL FROM / Return-Path）与 HELO 标识，而不是收件人在界面上看到的 From: 头。RFC 7208 本身就把用 SPF 验证除这两者之外的标识列为「NOT RECOMMENDED（不推荐）」。

经 smtp.gmail.com 发送时，发信基础设施是 Google，因此信封发件人（Return-Path）会是你的 @gmail.com。于是 SPF 验证的是「Google 的服务器以 gmail.com 之名在发送」，作为 gmail.com 是合格的。即便表面上的发件人是 [email protected]，SPF 所比对的也并非那里。

DKIM 会变成「gmail.com 的签名」

DKIM（DomainKeys Identified Mail，RFC 6376）是这样一种机制：发信一侧用私钥对消息签名，收信一侧用 d= 所示域名 DNS 上的公钥进行验证。Gmail 会以 d=gmail.com 对发出的邮件签名。在个人 Gmail 账户中，无法把独立域名（example.com）用的 DKIM 私钥设置进 Gmail 的 SMTP。用独立域名进行 DKIM 签名，是 Google Workspace（付费）的功能。

DMARC 所要求的「对齐」凑不齐

DMARC（RFC 7489）的核心概念是标识符对齐（Identifier Alignment）。直接引用 RFC 7489（3.1 节）的定义：当 RFC5322.From 地址的域名，与经 SPF 或 DKIM（或两者）验证过的域名一致时，即具有标识符对齐。要让 DMARC 合格，必须是 SPF 或 DKIM 其中一方「合格，且与 From 域名对齐」。

把这套配置代入其中：

项目实际值与 From 的 example.com 一致？
From:（人看到的发件人）[email protected]—
SPF 验证的域名（Return-Path）gmail.com不一致
DKIM 签名的域名（d=）gmail.com不一致

SPF 以 gmail.com 合格，DKIM 也以 gmail.com 合格。但两者都不与 example.com 对齐。结果，从 example.com 的视角看，DMARC 失败（fail）。

实务上会怎样

DMARC 失败时如何处理，取决于该域名所公开的 DMARC 策略（p=）。

  • example.com 未设置 DMARC／p=none 的情况：多数收信一侧会放行邮件。作为日常运营是能送达的（不过某些收信方可能会对垃圾邮件判定更严格）。
  • example.com 设置了 p=quarantine / p=reject 的情况：收信一侧可能按策略进行隔离或拒收。也就是说，会出现一种自相矛盾：你为自己域名施加的防伪造措施，把你自己从 Gmail 发出的邮件拦下了。

因此，若采用这套免费配置，现实的解法是不要把独立域名的 DMARC 弄得严格（停留在 p=none，或者干脆不放 DMARC 记录）。「能免费发送」与「严格认证独立域名」这两件事，在这套配置里无法兼得。

补充：收件人可见的痕迹

  • 视收件人的邮件软件而定，发件人旁边可能会显示「via gmail.com」。
  • 邮件的源头头信息（Return-Path 等）中会残留发信所用的 Gmail 地址。懂技术的收件人是能够追溯到的。

4. 想「规规矩矩」做时的选项

如果想严格运营 DMARC、让防伪造措施生效，就需要准备一条能用独立域名进行 DKIM 签名的发信路径。若无法接受免费配置的取舍，可以考虑以下方案。

  • 使用支持 DKIM 的外部 SMTP 中继（有免费额度）：Brevo 等邮件投递服务，会先用 DKIM/SPF 认证独立域名，再提供 SMTP 中继。只要在 Gmail 的 SMTP 服务器栏里填入该中继（例如 smtp-relay.brevo.com）与签发的认证信息，就能以独立域名进行对齐成立的发送，DMARC 也随之成立。免费额度对发送数量有上限，这点需要确认。
  • Google Workspace（付费）：包括在域名上进行 DKIM 签名在内，可以把收发正式地统一起来。虽是按月计费，但在认证与运营方面是最省心的。
  • Cloudflare Email Sending（面向应用）：Cloudflare 除了收信用的 Email Routing 之外，还有通过 Workers、REST API、SMTP 从域名发送的 Email Sending。不过这主要着眼于从应用程序发送事务性邮件，与在 Gmail 界面上日常「回复」的用途，设计思路并不相同。

小结

  • 用 Gmail 接收发往独立域名的邮件，靠 Cloudflare Email Routing 就能完全免费闭环（不过路由规则与转发目标地址均以 200 为上限）
  • 用独立域名作为发件人从 Gmail 发送，也能免费做到（Gmail 的「以其他地址发送」＋应用专用密码）
  • 让发出的邮件通过独立域名的 DMARC，用个人 Gmail 是不可能的。原因在于无法用自己的域名打 DKIM
  • 因此，给独立域名施加严格的 DMARC（p=reject）与这套配置相性不佳，会背上自己发信被拦下的风险

收信一侧，这是一套可以毫不犹豫地采用 Cloudflare Email Routing 的配置。发信一侧，也能用 Gmail 的「以其他地址发送」免费实现。但发信一侧——因为邮件认证的原理是：SPF 看信封发件人、DKIM 看 d= 域名、DMARC 看这两者与 From 的对齐——独立域名的认证无法凑齐。要么在理解这一取舍的前提下使用，要么把发信升级到支持 DKIM 的路径，这就是需要做的判断。

参考资料