域名邮箱实操：Cloudflare Email Routing 免费转发（2026）
一句话结论：Email Routing 是免费转发规则，不是邮箱：域名托管在 Cloudflare DNS 上后，发到域名下某地址的邮件会转到已验证的目标邮箱；发信另配，限制是每域名 200 条规则、每账号 200 个目标地址、单封入站 25MiB。
这是什么：转发不是邮箱
Email Routing 只做一件事：收到发往域名下某地址的邮件，按规则转到已验证的目标邮箱。它没有收件箱，不存邮件，没有可登录的网页邮箱；目标邮箱满了、被封了，转发的邮件就没有地方去。它也不管发信：官方文档写明，Email Routing 不支持从域名发信或回复，回复会从目标地址发出。收信与发信是两条分开的链路，分开配置。
这条路线适合对外地址挂在自有域名下、实际收信仍在已有邮箱、愿意自己维护 DNS 与规则的人；需要多人共用收件箱、长期存档，或直接以域名地址回信且不愿另配发信服务时，不适合。三种路线的对照，见海外邮箱对比文章。
前提：域名托管在 Cloudflare DNS 上
前提是域名使用 Cloudflare DNS：转发靠写入 DNS 记录实现，域名不在 Cloudflare DNS 上，入驻无法完成。还需要一个已有邮箱作为目标地址。域名注册费另付，转发在 Workers 免费与付费计划上都可用，入站邮件数量不限。
域名已有其他服务商的 MX 记录时，入驻会失败，报错为存在非 Cloudflare 的 MX 记录，错误代码 2008：Email Routing 要求独占根域名的 MX 记录，不能与另一家邮箱服务共用同一域名。切换前备份现有 DNS 记录，确认旧邮箱没有未处理的重要邮件，再入驻。
启用步骤：入驻域名
官方文档的入驻步骤只有四步。第一步，在 Cloudflare 控制台进入 Compute、Email Service、Email Routing。第二步，选择 Onboard Domain。第三步，从账号里选一个域名，可以复核 Cloudflare 将要写入根域名的 DNS 记录：MX 记录，把入站邮件引向 Cloudflare；SPF 的 TXT 记录，授权邮件转发；DKIM 的 TXT 记录，为转发邮件提供认证。第四步，选择 Done。域名入驻完成后，就可以开始配置转发。
记录由 Cloudflare 自动写入，不需要手工抄写；入驻后检查 DNS 记录页，确认三类记录都在，缺失时排障一节有补救步骤。域名解析与建站的关系，见Cloudflare 免费建站文章。
添加并验证目标地址
创建转发规则之前，必须先添加并验证至少一个目标地址。目标地址在账号级别管理，可以在账号下的所有域名间复用：验证一次，账号下每个域名都能用它作目标地址。添加步骤是：进入 Email Routing 的 Destination Addresses 页，在表单里输入目标地址并提交；Cloudflare 会向该地址发一封验证邮件，打开邮件并选择验证链接，地址才激活。
未验证的目标地址，指向它的规则都会保持停用，规则存在但不转发。目标地址页列出所有地址，包括待验证的，可在那里重发验证邮件或删除地址。验证邮件没收到时，先查垃圾文件夹，再重发。
创建自定义地址与 catch-all
规则由地址模式与动作组成：地址模式是域名下某地址的本地部分，动作决定邮件去向。创建步骤：选定域名，进入 Routing Rules 页，选择创建规则，填写地址模式，在动作下拉菜单里选择动作，在目标里选择已验证的地址或 Worker，保存。规则可随时停用、编辑与删除，停用后不再转发，重新启用后恢复。
动作有三种：发往邮箱，转到目标地址，最常用；发往 Worker，交给 Worker 程序处理，适合自定义逻辑；丢弃，直接删除匹配的邮件，适合想让某地址看起来有效、实际不收信的场景。
catch-all 是兜底规则：启用后，发往域名下所有地址的邮件都会被处理，包括拼错的本地部分；例如发件人拼错了一个字母，catch-all 启用时这封邮件仍会被处理。启用步骤：进入 Routing Rules 页，把 catch-all 设为启用，选好动作，保存。catch-all 也会接住发往从未创建过的地址的邮件，包括垃圾邮件，启用前想清楚是否需要兜底。
加号后缀是可选功能，在设置页开启。开启后，加号后缀地址匹配基础地址的规则：加号后部分不影响匹配，但保留在收件信息里，供 Worker 或活动日志查看；已存在具体加号后缀规则时，具体规则优先。加号后缀适合按来源区分地址，给不同服务各用一个带后缀的地址，收信仍走同一条规则。
一个地址转多人：用 Worker 逐个转发
每条转发规则只对应一个目标地址或一个 Worker，不能在一条规则里直接写多个目标地址。一个地址要转给多人时，官方文档给出的做法是：用一个 Worker，对每个目标地址逐个调用转发操作，所有目标地址必须事先验证。Worker 路由的配置方式是：创建规则时动作选择发往 Worker，再选择对应的 Worker 程序。
代价是多一层程序：Worker 代码要自己写、自己维护，出问题时多一个排查环节；免费计划的 Worker 有 CPU 与内存限制，复杂处理可能超限失败，失败记录在 Worker 日志里。人数不多时，每人一条规则更简单；确实需要同一地址多人收信时，再用 Worker 路线。
发信怎么解决：只收不发，发信另配
Email Routing 只管收信，不管发信：官方文档写明，它不支持从域名发信或回复；直接回复转发来的邮件时，回复从目标地址发出，对方看到的是目标地址。需要以域名地址发信时，有三条路。
第一条路是 Gmail 代发：在 Gmail 设置里添加自有地址并验证，写信时在发件人一栏选择该地址，最多 99 个。但这条路有时效：Google 已公告，自 2027 年 1 月起，Gmail 不再支持第三方邮箱地址的代发，Workspace 别名与本人拥有的其他 Gmail 地址不受影响；2026 年第三至第四季度为过渡期，可能限制新配置。域名地址按官方文字理解属于第三方地址，同样在终止范围内，动手前先看帮助页的当前状态，不要把长期发信押在这条路上。
第二条路是其他发信服务：用桌面邮件客户端或第三方发信服务，以域名地址发信。Google 帮助页给出的常见安全连接组合是 SSL 配 465 端口、TLS 配 25 或 587 端口；各服务商的 SMTP 设置、端口与认证方式不同，按服务商的文档填写，不要套用别家的参数。
第三条路是 Cloudflare 的 Email Sending 服务：2026 年 4 月进入公开测试，面向开发者发交易类邮件，需要 Workers 付费计划，含每月 3000 封，超出部分每 1000 封 0.35 美元；发给已验证目标地址的邮件在所有计划下免费，不计入配额与每日上限。Email Sending 是程序调用的发信服务，面向应用发通知类邮件，不是给人手写回信用的；未实测，以官方文档为准。
限制：200 条规则、200 个目标地址、25MiB
官方限制页列出的数字如下，核查日期 2026-11-13，与本站已发文章口径一致。
| 限制项 | 数值 | 说明 |
|---|---|---|
| 每域名转发规则数 | 200 条 | 每条规则对应一个地址模式与一个目标 |
| 每账号已验证目标地址数 | 200 个 | 账号下所有域名共用，须先验证 |
| 单封入站邮件大小 | 25MiB | 超过会被拒收，不是截断 |
| 每区配置域名数 | 30 个 | 转发与发信域名合计，含根域名 |
| 入站邮件数量 | 不限 | 免费与付费计划都一样 |
| 发信服务单封收件人数 | 50 人 | 收件、抄送与密送合计 |
25MiB 是入站硬上限：超过的邮件在收信阶段被拒收，目标邮箱里不会出现。大附件改用网盘链接或文件分享。规则数与目标地址数对个人使用很宽裕，200 条规则足够按服务、按用途拆分地址；地址拆得太细时，维护成本先于上限成为瓶颈。
SPF、DKIM、DMARC 与转发的关系
先讲入站检查：每封入站邮件都要经过 SPF、DKIM、DMARC 与 ARC 检查，按发件域名的 DMARC 政策，未通过认证的邮件会被拒收，来自实时黑名单地址的邮件也会被拒收。转发不是照单全收，发件域名的认证政策直接影响邮件能不能进入转发链路。
再讲转发时的处理：邮件从 Cloudflare 的服务器再次发出，目标服务器看到的发件服务器变了，不做处理时，原始发件域的 SPF 校验可能失败。Cloudflare 的做法分两步：给转发邮件加 ARC 封印，保留原始认证结果；用发件人重写方案重写信封发件人，改成 Cloudflare 控制的转发域名，让 SPF 在目标服务器上通过。ARC 让目标服务器在 SPF 或 DKIM 因转发失效时，仍能验证转发邮件的真实性。
SPF 记录方面，入驻时 Cloudflare 会写入一条 SPF 记录，内容为包含 Cloudflare 发信域名的授权记录，以软失败结尾。一个域名只能有一条 SPF 记录，多条会让邮件服务无法正常工作；已有其他服务的 SPF 记录时，把授权合并进同一条，不要并排写两条。SPF 记录的 DNS 查询次数上限为 10 次，合并时注意查询次数。
DKIM 记录方面，入驻时 Cloudflare 会写入 DKIM 记录，转发与发信服务用不同选择器，转发服务的选择器名称以 cf2024-1 开头。记录缺失时，到 Email Routing 设置页找到转发 DKIM 记录，再到 DNS 记录页补上。校验失败时，官方排障建议包括：确认记录存在、选择器名称正确、记录里没有多余空格或字符、等待 DNS 传播，最长 48 小时。
DMARC 方面，DMARC 要求 SPF 或 DKIM 其中一项对齐：SPF 对齐指信封发件域名与发件人域名一致，DKIM 对齐指签名域名与发件人域名一致。启用发信服务时，若域名下还没有 DMARC 记录，Cloudflare 会加一条拒绝策略的记录；已有则保持不变。收紧顺序是：先用仅观察策略，观察报告几周，再逐步收紧到隔离、拒绝；收紧前确认 SPF 与 DKIM 都已对齐。
排障：验证邮件、DNS 生效、垃圾过滤
验证邮件没收到：先查垃圾文件夹，再到目标地址页重发。规则已建但不转发时，先看目标地址是否已验证：未验证会让所有指向它的规则停用；规则本身被停用时，在规则页切回启用。
DNS 方面，记录缺失时到 DNS 记录页检查三类记录是否齐全；SPF 记录缺失时按官方排障页给出的内容补上，名称为根域名；DKIM 记录缺失时到设置页复制内容再补。DNS 改动需要传播时间，DKIM 校验最长等待 48 小时；等待期间不要反复改记录。
邮件被拒收时，分清发生在哪个阶段：超过 25MiB 的在收信阶段被拒收；未通过发件域名 DMARC 政策认证的在认证检查阶段被拒收；目标邮箱服务器的错误会在会话内传回发件服务器。活动日志里有每封邮件的最终状态，排查时先看日志，再看目标邮箱。
垃圾过滤方面，活动日志显示已送达，只说明目标服务器接受了邮件，之后进收件箱还是垃圾文件夹，由目标邮箱的信誉库、垃圾过滤器与用户反馈决定，认证全部通过也可能进垃圾文件夹。排查时查看邮件原始内容的认证结果标头；认证全部通过但仍被标记为垃圾时，问题出在域名信誉或邮件内容上，不是配置问题。
测试时用不同于目标地址的另一个邮箱账号发测试信：有些服务商会丢弃看起来发自同一账号的邮件，测试账号不要用目标地址本人。目标收件箱没看到时，先查垃圾文件夹，再查活动日志。
成本与取舍
现金成本只有域名注册费：转发免费，入站不限量，目标邮箱用免费邮箱时，全年成本就是域名续费。省下的钱换来多一层配置与多一个故障点：DNS 记录、转发规则、目标邮箱、发信配置，任何一环出问题，收发信都会受影响；不愿意维护 DNS 的人，实际成本并不低。
取舍的关键在发信：只收信、不回信的地址，转发路线够用；需要经常以域名地址回信时，发信服务要另外选好，并算上 2027 年 Gmail 代发终止的影响。重要验证码与通知类邮件，尽量直接发到独立收件箱，不要只经过一层转发。
局限与未核实清单
本文未实测，步骤与数字来自官方文档原文，核查日期 2026-11-13，Cloudflare 可能随时调整。未能核实：Email Sending 的实际表现与发信到达率；Email Routing 是否提供通用发信凭证（公开资料说法不一）；Gmail 代发在自定义域名地址上的完整表现；各目标邮箱的垃圾过滤表现；DNS 生效的具体时长（除 DKIM 校验最长 48 小时外，未核实到统一数字）；转发邮件在目标邮箱里的显示细节。配置前以官方文档为准，先用非关键地址测试收发。
2026-11-13：首发
相关：邮箱与电话号码 · Cloudflare 免费建站 · 方法论