Email Routing 免费收信转发：把自有域名变成邮箱入口
买了域名却只有一个 Gmail 可用，对外留 xxx@gmail.com 总差点意思。Email Routing 解决的就是这一段：让 hello@yourdomain.com 能收信，收到后原样转到你已有的邮箱，不花钱，也不用架邮件服务器。读完这篇，你能判断自己的域能不能开这个功能，知道它会自动改哪几条记录，也清楚转发链上哪些验证会失效。
发信侧的配置（SPF、DKIM、DMARC）是另一件事，见 89-spf-dkim-dmarc.md；域要先接进 Cloudflare，见 49-add-domain-to-cloudflare.md。
1. 它能做什么，不能做什么
| 能力 | 支持情况 |
|---|---|
| 收信并转发到指定邮箱 | 支持，目的地址需要邮件验证 |
| 自定义地址（hello@、support@） | 支持，数量按账号限制 |
| catch-all（任意地址都收） | 支持，可开关 |
| 用自有域名发信 | 不支持，没有 SMTP/IMAP |
| 在 Cloudflare 里读信、存档 | 不支持，只有转发 |
| 用 Worker 处理来信 | 支持，属于 Email Workers |
一句话概括能力边界：它是收信入口，不是邮箱。想用 @yourdomain 主动发信，要么接第三方发信服务，要么用邮箱服务商的"自定义发信"功能。
2. 启用流程
下面这串操作本机没有 Zone 权限，未执行，按文档描述。
- 域名已接入 Cloudflare 且 NS 生效，在仪表盘左侧找 Email，再进 Email Routing。
- 首次进入会提示添加记录，确认后 Cloudflare 自动写入 MX 与 SPF。这一步会覆盖已有的 MX 记录，所以域上如果已经在收信，先看清楚再点。
- 在 Destination addresses 里填你的真实邮箱，去那个邮箱点验证链接，状态变成 Verified 才算可用。
- 在 Routes 里建自定义地址，把
hello@yourdomain.com指向刚验证的地址。 - 需要"任意前缀都收"时开 Catch-all，并给它一个默认目的地。
- 从外部邮箱发一封测试信，确认能收到，并检查信头里
Received链是否正常。
第 2 步是唯一有破坏性的动作。免费版一个域只有一套 MX，开了 Email Routing，原来指向 Google Workspace 或企业邮箱的 MX 就被替换掉，那些邮箱立刻收不到信。
3. 它会写入哪些记录
MX 指向 *.mx.cloudflare.net，优先级数字是随机分配的，不是固定模板。记录本身的写法和 TTL 选择见 50-dns-records-tutorial.md。本机实查两个在用 Email Routing 的域：
| 域名 | MX 主机 | 优先级 |
|---|---|---|
| qwik.dev | route1.mx.cloudflare.net | 27 |
| qwik.dev | route2.mx.cloudflare.net | 45 |
| qwik.dev | route3.mx.cloudflare.net | 49 |
| nuxt.com | amir.mx.cloudflare.net | 3 |
| nuxt.com | isaac.mx.cloudflare.net | 23 |
| nuxt.com | linda.mx.cloudflare.net | 41 |
主机名里的 route1、amir 这类前缀是 Cloudflare 侧的编号，照抄别人的记录没有意义，用自己面板里给出的那一组。优先级数字同样由系统生成，别人是 27/45/49，你可能是 3/23/41，收信方只按数字排序，不关心具体值。
SPF 记录会写成一条 include：
v=spf1 include:_spf.mx.cloudflare.net ~all这是 qwik.dev 的真实 TXT 记录，本机查到的原样值。它的含义是"允许 Cloudflare 的转发节点代表本域投递"，缺了这条，转发出去的邮件在收信方 SPF 检查里会失败。
开了 DMARC 管理的域还会多一条 _dmarc 记录，nuxt.dev 的实查值：
v=DMARC1; p=none; rua=mailto:e9df104954e9471289826db05040c24c@dmarc-reports.cloudflare.netrua 指向 Cloudflare 的报表地址，报告汇总在仪表盘里看。记录里 p=none 前有两个空格，解析器不在意这个，手工抄写时也不用刻意对齐。
4. 转发链上的 SPF 与 DMARC
这点最容易被误解：转发不改信封发件人，只在中转时新增一条 Received。原始邮件是别人发给你的，SPF 校验的是"发信服务器是否有权代表原域发信"，跟你的域无关；你的 SPF 记录只影响你自己发出去的邮件。
所以转发场景下真正承压的是 DMARC 对齐：邮件从你的域转发到 Gmail，Gmail 看到的是原始 From（比如某个客户的域），SPF 与 DKIM 都可能因为中转而失效，DMARC 判定为 fail 的邮件会被降级或拒收。Cloudflare 在中转时会做 ARC 封签，尽量把原始认证结果带过去，但不是所有收信方都采信 ARC。
实际影响：个人收信基本无感；把对外客服地址转到 Gmail、又要求零丢信的场景，要找能改信封发件人的方案，而不是纯转发。
5. 和现有邮箱共存的三种做法
| 场景 | 做法 |
|---|---|
| 域上还没有任何邮箱 | 直接开 Email Routing，最省事 |
| 域已在用 Google Workspace | 不要动主域 MX；改用子域（如 mail.yourdomain.com）单独开收信 |
| 只想多几个别名 | 先在现有邮箱服务商里加别名，别急着换 MX |
子域方案的具体写法是在 DNS 里给子域加 MX，指向 *.mx.cloudflare.net，再在 Email Routing 里把该子域添加为独立域。这样主域的 Workspace 不受影响，两条收信路径并存。
常见问题
收到的信能直接用自有域名回复吗？
不能。点回复时发件人是你转发到的那个邮箱，所以对外暴露的还是 Gmail 地址。要用自有域名发信，得配发信服务并加对应的 SPF 与 DKIM。
能不能转发到多个地址？
一条路由可以指向多个已验证目的地，也可以为不同地址配不同目的地。数量上限按账号的计划走，面板上会写清楚。
为什么 Gmail 里显示 "via" 字样？
因为信是经 Cloudflare 中转投递的，Gmail 把中转方标出来。这是转发链的正常表现，不代表配置错了。
小结
Email Routing 的价值在于把"域名"和"邮箱"解耦：域名提供身份，邮箱还在你顺手的地方，中间靠几条 MX 与一条 SPF 连起来。它的成本几乎为零，代价是只能收不能发，以及转发链上 SPF/DMARC 的天然弱点。
动手前只有一件事要想清楚：这个域的 MX 现在指向谁。指向空，随便开；指向在用的企业邮箱，先规划子域，别在主域上直接替换。换掉 MX 之后原有邮箱立刻停收，这类事故恢复起来比配置麻烦得多。
数据来源与检索时间
检索时间 2026-11-10。DNS 记录为本机 Resolve-DnsName 实查。
| 来源 | URL | 对应数据 |
|---|---|---|
| Cloudflare Email Routing 概览 | https://developers.cloudflare.com/email-routing/ | 功能范围、自定义地址、catch-all、仅收信 |
| Email Routing 启用与 DNS 记录 | https://developers.cloudflare.com/email-routing/get-started/enable-email-routing/ | 自动写入的 MX 与 SPF、目的地址验证 |
| Email Workers | https://developers.cloudflare.com/email-routing/email-workers/ | 用 Worker 处理来信的能力边界 |
| Email Routing 限制 | https://developers.cloudflare.com/email-routing/limits/ | 地址数量、路由数量上限 |
核验说明
- 实查：
qwik.dev的 MX（route1/2/3.mx.cloudflare.net，优先级 27/45/49）与 TXT（v=spf1 include:_spf.mx.cloudflare.net ~all）；nuxt.com的 MX（amir/isaac/linda.mx.cloudflare.net，优先级 3/23/41）；nuxt.dev的_dmarcTXT（p=none，rua指向dmarc-reports.cloudflare.net）。 - 依据文档：启用流程、目的地址验证、catch-all 与 Email Workers 的行为，以及转发链上 ARC 与 DMARC 对齐的处理方式。这部分需要真实 Zone 权限。
- 未执行：开启 Email Routing、写入 MX/SPF、建立路由、发送测试信，全部未在账号内执行。文中 MX 与优先级数字来自对现有生产域名的公开查询，不是我配置的结果。