Cloudflare 无限邮箱简易教程
这里的“无限邮箱”更准确地说是自定义域名别名 + Catch-all 转发：可以临时使用很多不同的 xxx@yourdomain.com 地址，但它们不是各自独立、带容量的邮箱账户。
Cloudflare Email Routing 负责把发到这些地址的邮件转发到你已经验证的真实收件箱。到 2026 年，Cloudflare 还提供了独立的 Email Sending 能力，所以“Cloudflare 只能收、完全不能发”已经不是绝对结论；具体是否使用 Cloudflare 发信，要看当前账户和 Email Service 配置。
第一部分：先理解“无限邮箱”是什么
Email Routing 本质上是邮件转发，不是给每个地址创建一个独立邮箱。
例如启用 Catch-all 后，可以直接使用：
support@yourdomain.com
shop.example@yourdomain.com
forum.test@yourdomain.com这些地址收到的邮件都会按规则转发到你已经验证的真实邮箱。这样做比较适合注册不同网站时使用不同地址，也方便以后判断某个地址是从哪里泄露出去的。
如果需要真正独立的收件箱、IMAP、日历或企业协作功能，仍然要使用完整的邮箱服务。
第二部分：把域名接入 Cloudflare
Email Routing 要求这个域名使用 Cloudflare DNS。如果域名还没接入 Cloudflare：
- 在 Cloudflare 添加根域名，例如
yourdomain.com； - 核对扫描出的 DNS 记录，特别是网站正在使用的 A / AAAA / CNAME 记录；
- 到域名注册商修改 Nameserver，换成 Cloudflare 分配的两条 NS；
- 等 Cloudflare 显示域名已经激活后，再配置 Email Routing。
切换 Nameserver 前最好把原 DNS 记录留一份备份，避免漏掉正在使用的解析。这里改变的是整个域名的权威 DNS，不只是邮件配置，所以网站相关记录也要一起核对。
第三部分：开启 Email Routing
域名激活后，在 Cloudflare 的 Email Routing 页面开启服务。让 Cloudflare 自动添加需要的邮件 DNS 记录，比手工照抄旧教程里的 MX / TXT 值更稳。
如果域名之前已经在使用其他邮件服务，先检查现有 MX 记录。不要在不清楚用途时直接删除原邮件服务的记录，否则原邮箱可能停止收信。
创建转发地址
- 添加一个自定义地址，例如
hello@yourdomain.com； - 选择真实的目标邮箱；
- 第一次添加目标邮箱时，按 Cloudflare 发来的验证邮件完成确认；
- 验证通过后再测试实际收信。
目标邮箱必须先验证，未验证的地址不能正常作为转发目标。
第四部分：开启 Catch-all
Catch-all 会接收所有没有命中特定规则的地址。例如没有单独创建 shop123@yourdomain.com，只要 Catch-all 已开启，这个地址仍然可以收信并转发到指定目标邮箱。
在 Email Routing 的路由规则中找到 Catch-all / 全域地址，启用后把动作设置为转发到已经验证的目标邮箱即可。
之后注册不同网站时可以直接使用不同地址，例如：
site-a@yourdomain.com
site-b@yourdomain.com
newsletter-1@yourdomain.com不需要每次先去 Cloudflare 建一条新规则。
注意：某个专用地址开始收到垃圾邮件，只能说明这个地址已经被泄露、猜中或共享，不能据此百分之百确定是哪一家服务主动泄露。Catch-all 也会接住发送到 admin@、test@ 等随机猜测地址的垃圾邮件，因此重要地址建议单独建规则，临时注册地址再用 Catch-all。
第五部分：发送与回复
Email Routing 解决的是入站转发。如果只启用了 Routing，那么直接回复邮件时，发件地址通常仍取决于你的真实邮箱或邮件客户端配置。
到 2026 年，Cloudflare 已经提供独立的 Email Sending，可以通过 SMTP、REST API 或 Workers 发送邮件。当前向任意收件人发送需要 Workers Paid；发送到账号中已验证的目标地址则可免费使用。若账户中已经开放并配置 Email Sending，优先按 Cloudflare 当前控制台生成的 SPF、DKIM、DMARC 记录来配置，不要手工照抄旧教程中的固定 DNS 值。
如果改用其他 SMTP 服务商，也应让该服务商为你的自定义域名提供正确的 SPF / DKIM 配置，并确认 From 域名能够通过 DMARC 对齐。只把 include:_spf.google.com 塞进 SPF，并不能保证自定义域名通过 DMARC，因为 DMARC 还要求 SPF 或 DKIM 的认证域与 From 域对齐。
关于 Gmail “用这个地址发送邮件”
过去常见的做法是用 Gmail 的 “Send mail as” 配合第三方 SMTP 发送自定义域名邮件。但 Google 已宣布从 2027 年 1 月起停止对第三方邮箱地址的这类支持，因此现在不建议再把它作为这篇教程的长期方案。
如果只是临时使用现有 Gmail 配置，可以继续按 Google 当前帮助文档操作；新配置更适合直接选择支持自定义域名认证的邮件发送服务，或者使用 Cloudflare Email Sending。
DNS 记录不要手工套模板
启用 Email Routing 时，让 Cloudflare 自动创建当前所需的 MX、SPF、DKIM 等记录。启用发送服务时，也按实际发送服务商给出的 SPF / DKIM / DMARC 配置添加。
同一域名的 SPF 应合并为一条有效策略，不要同时创建多条互相独立的 v=spf1 ... TXT 记录。修改邮件 DNS 后，再用实际收发测试和邮件头中的 SPF、DKIM、DMARC 结果确认配置是否正确。
第六部分：限制与使用建议
“无限邮箱”主要来自 Catch-all：你可以直接使用不同的本地部分，例如 shop1@yourdomain.com、forum2@yourdomain.com，而不需要提前为每个地址创建规则。它不代表 Cloudflare 允许无限创建独立路由规则。
当前 Email Routing 需要注意：
- 路由规则：每个域名最多 200 条；
- 已验证目标地址：每个账户最多 200 个；
- 单封入站邮件大小：最大 25 MiB。
所以日常使用最方便的方式通常是：重要地址单独建规则，一次性注册地址交给 Catch-all。
如果还需要用自定义域名发信，就单独配置 Email Sending 或其他支持域名认证的 SMTP 服务，并按实际服务商给出的 SPF、DKIM、DMARC 记录配置。不要同时保留多条独立 SPF，也不要只看“邮件发出去了”就认为认证正确，最好检查收到邮件的 Authentication-Results。
Catch-all 很方便，但也会接住别人随机猜测出来的地址，因此垃圾邮件可能更多。如果某个临时地址开始收到垃圾邮件，可以直接停止使用它，重要业务地址则继续使用明确的路由规则。
评论将在接近此处时加载，也可点击立即加载。