一个域名，无限个邮箱：Cloudflare 免费配置教程

完整链路#

1
flowchart LR
2
    accTitle: Cloudflare 通用域名邮箱链路
3
    accDescr: 外部发件人将邮件发到任意域名别名，Cloudflare Email Routing 匹配 catch-all 规则后转发到已验证的目标邮箱。
4
    A[外部发件人] --> B[任意别名 @example.com]
5
    B --> C[Cloudflare Email Routing]
6
    C --> D[已验证目标邮箱]

配置分为三层：

1. 域名由 Cloudflare 托管 DNS。
2. MX 记录把入站邮件交给 Cloudflare Email Routing。
3. catch-all 规则把未单独定义的地址转发给已验证的目标邮箱。

第一步：把域名接入 Cloudflare#

在 Cloudflare 中添加域名后，平台会扫描现有 DNS 记录，并给出两个专属 Nameserver。然后需要在域名注册商中把 Nameserver 替换为 Cloudflare 提供的值。

修改前先导出或记录现有 DNS，至少核对：

WARNING

Nameserver 切换后，Cloudflare 区域中缺失的记录会立即变成生产故障。不要仅依赖自动扫描，必须人工对照注册商或旧 DNS 控制台。

等待 Cloudflare 中的域名状态变为 Active 后，再继续邮件配置。

Cloudflare 官方的完整接入流程见 Set up a full zone。

第二步：开启 Email Routing#

进入 Cloudflare 控制台的 Email Routing，选择需要接入的域名。首次开启时，Cloudflare 会列出所需的 MX 和 SPF TXT 记录。

优先使用控制台的自动配置，不要从其他教程复制可能已过期的值。完成后应同时看到：

• Email Routing 状态已启用。
• DNS 记录已启用或已锁定。
• Cloudflare 要求的 MX 和 SPF TXT 记录存在。
• 不再保留与新邮件入口冲突的旧 MX。

官方入门文档见 Get started with Email Routing。

第三步：验证目标邮箱#

目标地址是最终接收转发邮件的真实邮箱，例如 inbox@example.net。在 Destination addresses 中添加它后，Cloudflare 会发送验证邮件。

只有完成验证的地址才能作为路由目标。如果没有收到验证邮件，先检查垃圾邮件、地址拼写和目标邮箱的过滤规则，不要反复创建多个相似地址。

目标地址的管理方法见 Email Routing addresses。

第四步：配置 catch-all#

打开 Routing rules，编辑顶部的 Catch-all 规则：

1. 把操作从 Drop 改为 Send to an email。
2. 选择已验证的目标地址。
3. 保存规则。
4. 确认 catch-all 状态为 Active。

显式地址规则仍然有用。例如，可以把 security@example.com 单独转发给安全联系人，其他地址继续由 catch-all 处理。

怎么使用这些别名#

建议按用途选择前缀：

不要把别名当作独立身份边界。如果所有别名都转发到同一邮箱，那么目标邮箱一旦失守，所有别名都会受影响。

端到端验证#

不要只看 Cloudflare 控制台的配置状态。正确的验收需要三段证据：

1. 使用与目标邮箱不同的发件账户。
2. 向一个全新前缀发送带唯一主题的测试邮件，例如 routing-test-20260803@example.com。
3. 确认发件端成功、Cloudflare Activity log 已记录，且目标邮箱真正找到同一封邮件。

NOTE

用目标 Gmail 给自己的域名别名发信，然后再转回同一 Gmail 账户，可能被 Gmail 去重。这种自发自收不是有效的端到端测试。

“Cloudflare 已转发”和“目标邮箱已收到”是两个不同的验收点。如果只有前者，还要检查目标服务商的垃圾邮件、过滤规则、限流或退信信息。

安全与回滚#

catch-all 让别名更方便，也让任意人可以尝试向任意前缀发信。这会扩大垃圾邮件入口。建议：

• 在目标邮箱中使用过滤器和独立标签。
• 不在文章、截图或代码中公开真实目标邮箱。
• 对银行、域名注册商和管理账户等高价值服务，优先使用独立邮箱和强制多因素认证。
• 定期检查 Cloudflare 活动日志与目标邮箱的退信。

需要回滚时：

1. 先禁用 catch-all，阻止新的任意前缀继续转发。
2. 如果仍保留显式路由，分别检查它们的目标地址。
3. 需要停用 Email Routing 时，按 Cloudflare 控制台提示停用服务。
4. 如果恢复原有邮件服务，使用事先备份的 MX 和 TXT 值，而不是凭记忆重建。
5. 等待 DNS TTL 和邮件重试窗口，期间同时监控新旧服务。

给其他 AI 的通用配置提示词#

下面这段提示词不依赖特定 AI 工具。将占位符替换为自己的值后，可以交给支持浏览器操作的 AI 执行。

1
你是我的 Cloudflare 域名与邮件路由协作助手。
2

3
目标：
4
- 将 <DOMAIN> 的 DNS 统一交给 Cloudflare 管理。
5
- 开启 Cloudflare Email Routing。
6
- 将任意合法前缀的 <anything>@<DOMAIN> 转发到
7
  <DESTINATION_EMAIL>。
8

9
环境：
10
- 域名注册商：<REGISTRAR>
11
- 域名：<DOMAIN>
12
- 目标邮箱：<DESTINATION_EMAIL>
13

14
必须遵守的流程：
15
1. 先只读盘点注册商 Nameserver、现有 DNS 记录、MX/TXT、
16
   Cloudflare 区域状态、Email Routing、目标地址和路由规则。
17
2. 列出当前值、拟修改的精确值、影响范围和逐项回滚方案。
18
3. 在修改 Nameserver、删除或替换 DNS、创建 MX/TXT、
19
   添加目标地址、点击验证或启用 catch-all 之前，
20
   显示将要执行的精确操作并等待我确认。
21
4. 不读取、显示、保存或上传密码、Token、Cookie、恢复信息和
22
   完整个人邮箱；日志与截图必须脱敏。
23
5. 不修改未授权的子域名、网站解析、DKIM、DMARC 或其他服务记录。
24
6. 完成后，使用与 <DESTINATION_EMAIL> 不同的发件账户，
25
   向唯一测试别名发信。
26
7. 分别验证：发件端成功、Cloudflare 活动日志已记录、
27
   目标邮箱已真正收到。不得把“Cloudflare 已转发”
28
   直接宣称为“目标邮箱已收到”。
29
8. 最后输出修改摘要、验证证据、未触碰的记录和可执行回滚步骤。
30

31
如果缺少登录、验证邮件、验证码或明确的变更授权，
32
停在当前页面并告诉我需要完成什么，不要绕过限制。

这段提示词的重点不是“一键修改”，而是把盘点、确认、回滚和端到端验收都变成 AI 必须执行的步骤。

完结#

通过上面的操作，我们就可以实现“无限个邮箱”：每个网站用一个不同的前缀，收件时全部转发到同一个目标邮箱。不用批量创建账户，也不用记一堆密码，一个域名就能把所有别名统统接住。

但这不是一个完整邮箱服务的替代品。将它视为“域名收件入口”，并用不同账户完成端到端测试，才能确认这条邮件链路真正可用。