故障排查
判断问题在哪一层
按这个顺序查：
1. 域名 NS 是否委派到 Cloudflare
2. MX 是否指向 route*.mx.cloudflare.net
3. DNSSEC/DS 是否导致 SERVFAIL
4. Cloudflare Email Routing 是否启用
5. Destination address 是否 verified
6. Routing rules 是否命中
7. Activity Log 是否有记录
8. 目标邮箱是否拒收或进垃圾箱不要一开始就改转发规则。DNS 不通时，转发规则不会生效。
Cloudflare Activity Log 没记录
这通常说明邮件根本没有到 Cloudflare。
优先查：
dig NS example.com +short
dig MX example.com +short
dig DS example.com +short
dig MX example.com +dnssec常见原因：
NS 不是 Cloudflare
MX 不是 Cloudflare
域名状态异常
DNSSEC/DS 错误
发件方没有真正发出邮件
发件方拒绝给该域名后缀发送邮件Activity Log 有记录但转发失败
这说明 Cloudflare 收到了邮件，但后续转发失败。
优先查：
Destination address 是否 verified
Routing rule 是否 enabled
目标邮箱是否拒收
邮件是否命中安全策略
目标邮箱垃圾箱如果目标邮箱是 QQ 邮箱、163 邮箱这类，有时会被更严格过滤。可以先换 Gmail/Outlook 做对照测试。
.top 解析不过来，.cloud 正常
这次实际经验是：
.top 域名 DNS 解析不过来
.cloud 域名 DNS 能解析过来
换成 .cloud 后 Cloudflare 邮箱转发正常这个现象不等于 Cloudflare Email Routing 不支持 .top。更合理的判断是：
.top 那个具体域名的 DNS 链路有问题重点排查：
注册商 NS 是否真的改成 Cloudflare
注册商是否要求实名或邮箱验证
域名是否 clientHold/serverHold
是否残留错误 DS 记录
是否注册商后台保存了但注册局未生效检查命令：
dig NS old-domain.top +short
dig MX old-domain.top +short
dig DS old-domain.top +short
dig NS old-domain.top +trace如果 .top 不重要，直接使用能稳定解析的 .cloud 更省时间。邮箱、机器人、服务绑定这种长期用途，DNS 稳定性比域名价格更重要。
DNSSEC 导致 SERVFAIL
表现：
dig NS 能看到 Cloudflare
但 dig MX / dig A 出现 SERVFAIL高概率是注册商 DS 记录和 Cloudflare DNSSEC 不匹配。
处理方式二选一：
关闭 DNSSEC：去注册商删除 DS，等待生效
正确开启 DNSSEC：在 Cloudflare 开启 DNSSEC，把 Cloudflare 给的 DS 填到注册商自用场景下，优先先关闭 DNSSEC 把解析恢复，后面再慢慢配。
MX 被其他邮箱服务占用
如果以前配过企业邮、腾讯企业邮箱、阿里邮箱、Zoho、Google Workspace，MX 可能还指向旧服务。
检查：
dig MX example.com +short如果不是：
route1.mx.cloudflare.net
route2.mx.cloudflare.net
route3.mx.cloudflare.net就说明邮件不会进入 Cloudflare Email Routing。
发信能力不要和转发能力混淆
Cloudflare Email Routing 只负责收信转发，不负责 SMTP 发信。
如果要从自定义域名发信，需要另配：
Gmail alias + SMTP
Outlook alias
企业邮箱
Resend / Mailgun / Postmark 等邮件服务
其他 SMTP 服务发信还需要单独配置：
SPF
DKIM
DMARC不要把“能收邮件”理解成“能用这个域名完整收发邮件”。