用 Cloudflare Email Routing 做轻量域名邮箱转发
这篇文章记录的是 993216.xyz 域名邮箱转发方案。它不是完整邮箱托管服务，而是在已经托管到 Cloudflare 的域名上，加一层轻量收信转发能力：
Cloudflare Email Routing + catch-all + 已验证的个人邮箱最终效果是：只要使用 任意名称@993216.xyz 作为收件地址，邮件就会先进入 Cloudflare Email Routing，再被转发到我已经验证过的个人邮箱。日常注册网站、接收验证码、隔离主邮箱、追踪邮件来源时，就不需要到处暴露同一个主邮箱地址。
一、项目作用和功能
这个项目的核心作用，是把一个自有域名变成一组可随手派生的收信地址。
例如可以这样使用：
github-main@993216.xyz
notion-202607@993216.xyz
shopping-a7k9@993216.xyz
newsletter-test@993216.xyz这些地址不需要提前逐个创建。只要 catch-all 规则保持启用，发往 @993216.xyz 的邮件都会被 Cloudflare 捕获，并转发到指定的个人邮箱。
它主要解决三个问题：
- 隔离主邮箱：不同网站使用不同地址，减少主邮箱直接暴露。
- 追踪来源：某个地址收到垃圾邮件时，可以反推它最初给过哪个网站或服务。
- 降低管理成本：不用维护多个真实邮箱账号，也不用为每个地址设置独立密码。
它也有明确边界：
- 这是 receive-only 的收信转发方案，不是完整邮箱。
- 默认不能从
@993216.xyz主动发信。 - 直接在个人邮箱里回复时，对方通常会看到个人邮箱地址，而不是
xxx@993216.xyz。 - Cloudflare Email Routing 负责路由转发，不适合作为长期邮箱归档系统。
- 银行、支付、证券、政府服务、合同沟通、账号申诉等高风险场景，不建议只依赖这类转发地址。
所以我把它定位为“收信别名层”：适合注册、验证、通知和来源隔离，不适合承担严肃业务邮箱的全部职责。
二、配置思路
配置前提是域名已经在 Cloudflare 中管理 DNS。Email Routing 依赖邮件 DNS 记录，尤其是 MX 记录；如果这个域名已经接入了其他邮箱服务，需要先确认不会和现有 MX、SPF、DKIM 配置冲突。
整体流程可以压缩成五步。
第一步，启用 Email Routing。
在 Cloudflare Dashboard 中进入对应域名，打开 Email Routing。按官方当前文档路径，入口通常在：
Compute
-> Email Service
-> Email Routing启用时，Cloudflare 会为域名准备收信所需的 DNS 记录，包括 MX、SPF 和 DKIM。MX 负责把邮件投递到 Cloudflare，SPF 和 DKIM 用于邮件认证相关声明。
第二步，添加并验证转发目的邮箱。
在 Destination Addresses 中添加个人邮箱。Cloudflare 会向这个邮箱发送验证邮件；只有点过验证链接后，指向这个邮箱的规则才会真正启用。这个步骤不能省略，否则路由规则会保持 disabled。
第三步，设置路由规则。
可以先给重要地址创建明确规则，例如：
github-main@993216.xyz -> 已验证的个人邮箱
cloudflare-main@993216.xyz -> 已验证的个人邮箱然后开启 catch-all，让所有没有单独规则的地址也能收信：
*@993216.xyz -> 已验证的个人邮箱具体地址规则适合长期重要账号，catch-all 适合临时地址和低成本派生地址。如果后续某个地址泄露，可以新增更具体的 drop 规则来丢弃它。
第四步，补充 DMARC 记录。
当前阶段以收信为主，可以先使用温和的观察策略：
_dmarc.993216.xyz TXT "v=DMARC1; p=none; pct=100"p=none 表示声明 DMARC 策略，但暂不要求接收方拒收或隔离邮件。如果以后要从这个域名正式发信，就需要重新检查 SPF、DKIM、DMARC 的整体策略，不能只沿用这条记录。
第五步，真实测试。
不要只看控制台状态。建议从另一个邮箱发一封测试邮件到一个新的地址，例如：
test-20260701-a1b2@993216.xyz确认个人邮箱能收到后，再认为链路闭环。也可以用 PowerShell 做 DNS 自检：
Resolve-DnsName 993216.xyz -Type MX
Resolve-DnsName 993216.xyz -Type TXT
Resolve-DnsName _dmarc.993216.xyz -Type TXTCloudflare 官方文档提示，DNS 变更全局传播最多可能需要 24 小时；如果域名使用 Cloudflare DNS，通常会在几分钟到十几分钟内完成。刚配置完收不到邮件时，不要立刻反复乱改，先确认目的邮箱验证、路由规则状态和 MX 记录。
三、使用说明
日常使用时，不需要进入 Cloudflare 创建每一个邮箱地址。直接按用途写一个新的地址即可。
我建议只使用小写字母、数字、短横线和点号：
a-z
0-9
-
.虽然 Email Routing 支持加号地址这类 subaddressing 能力，但很多网站自己的邮箱校验规则不统一。为了兼容更多网站，日常命名优先用短横线。
常用命名方式如下。
长期账号使用稳定别名：
github-main@993216.xyz
cloudflare-main@993216.xyz
notion-main@993216.xyz临时注册使用时间或随机码：
forum-202607@993216.xyz
trial-20260701@993216.xyz
shop-a7k9@993216.xyz
verify-8k3m@993216.xyz不同邮件类型也可以分开：
login-github@993216.xyz
notify-cloudflare@993216.xyz
newsletter-tech@993216.xyz建议维护一张地址用途表，放在本地笔记、表格或密码管理器备注里：
| 服务/用途 | 使用邮箱 | 创建日期 | 重要程度 | 状态 | 备注 |
|---|---|---|---|---|---|
| GitHub | github-main@993216.xyz | 2026-07-01 | 高 | 使用中 | 长期账号 |
| 临时论坛 | forum-20260701@993216.xyz | 2026-07-01 | 低 | 可废弃 | 测试注册 |
| 购物网站 | shop-a7k9@993216.xyz | 2026-07-01 | 中 | 使用中 | 观察营销邮件 |
如果某个地址开始收到垃圾邮件，处理顺序通常是：
- 到对应网站更换绑定邮箱。
- 在 Cloudflare 中给泄露地址新增 drop 规则。
- 在记录表里标记这个地址已泄露或已废弃。
如果垃圾邮件不是来自某一个固定地址，而是大量随机地址，可以考虑关闭 catch-all，改成白名单模式：只保留明确配置过的 Routing Rules。这样更严格，但会失去“随手派生任意地址”的便利。
更换转发目的邮箱时，不要直接删除旧邮箱。先添加新 destination address，完成验证，再把 catch-all 和重要规则改到新邮箱。确认新邮箱能收到测试邮件后，再移除旧目的邮箱。
收不到邮件时，优先检查这些点：
- 个人邮箱收件箱、垃圾箱、广告邮件、订阅邮件分类。
- 收件地址是否拼错。
- Destination address 是否 verified。
- Catch-all 是否仍为 Active。
- MX 记录是否仍指向 Cloudflare。
- DNS 是否还处在缓存传播期。
这套方案的最佳使用习惯可以概括成一句话：每个服务一个地址，重要服务稳定命名，临时服务可丢弃命名，所有地址都要留一份本地记录。