换上腾讯云 CDN 后发现自己的域名邮无法正常收信，想到可能是腾讯云 CDN 提供的 CNAME 是多层嵌套导致的，遂写此篇记录解决方案。

TL; DR

1. 确实是 CDN 提供的 CNAME 多层嵌套导致
2. 手动调整解析为最末级 CNAME 即可

起因

正如 Sukka 所言，“大部分 CDN 服务商内部的 GSLB 系统会导致多个 CNAME 递归……一旦递归 DNS 缓存了 CNAME 记录，就会沿着 CNAME 域名继续向下请求解析，就会导致邮件丢件。”¹

腾讯云 CDN 提供的 CNAME 便是如此，比如 licaoz.com 域对应提供的 CNAME 地址为 licaoz.com.cdn.dnsv1.com.cn，而 licaoz.com.cdn.dnsv1.com.cn 又 CNAME 解析至 c2q7003o.slt-dk.sched.tdnsv8.com；在此过程中，发信方服务器便无法获取到正确的 MX 记录。

咱也尝试过工单联系腾讯云 CDN 支持，对方直接表明“因为 CNAME 与 MX、TXT 记录，冲突，所以相同主机记录、相同线路，不同记录类型只能创建一条。”

话是这么说，但下面的方案咱亲测可以正常收信（大陆方向发信网易邮箱测试正常，国际方向谷歌邮箱测试正常；邮件服务器位于俄罗斯）。

解决方案

此方案 2022 年 05 月 14 日测试有效，使用 DNSPod 作为域名解析系统、Yandex 作为邮件系统。

知道了起因（CDN 提供的 CNAME 多层嵌套），咱就可以对症下药啦。

一般来说，Ping 返回的主机名应为最后一级 CNAME 地址。

提示：如果条件允许，请尽可能在更多的地方进行 Ping 检测以确认得到的 CNAME 的一致性与准确性。

举个栗子：

licaoz.com 使用了腾讯云 CDN，腾讯云 CDN 控制台提供的 CNAME 地址为 licaoz.com.cdn.dnsv1.com.cn。

通过 ping licaoz.com.cdn.dnsv1.com.cn 得到下图：

其中，c2q7003o.slt-dk.sched.tdnsv8.com 就是最末级 CNAME 地址（不信的话你可以再 ping c2q7003o.slt-dk.sched.tdnsv8.com，应该是冒不出新域名来了）

然后去 DNSPod 添加 @ 的 CNAME 记录，记录值为 c2q7003o.slt-dk.sched.tdnsv8.com，像这样：

之后再使用 163 和 Gmail 测试，应该是能正常收信了；不过腾讯云 CDN 控制台处记录值左侧会有红色感叹号。

适用于 DNS 服务商支持 CNAME 拉平的站长

恭喜！您无需折腾，直接拉平即可。不过正如 Sukka 所说，“使用这类服务将 CNAME 变成 A/AAAA 的方案的确可以解决冲突的问题，但是 Flatten CNAME 又要保留 GeoDNS，就会高度依赖于权威 DNS 服务商的节点分布，所以最终得到的 GeoDNS 结果一定会非常不精确。”¹

总结

此方法同样适用于其他多层 CNAME 嵌套的 CDN 提供商（例如 七牛、又拍等一水用域名做 CNAME 地址的 CDN 提供商，CloudFlare 虽然用域名做 CNAME 地址但并没有做 CNAME 嵌套，所以不在此范围内），理论来说保留一层 CNAME 地址再和 MX 记录共存可以正常收信，但不排除后续规则变更导致收信又一次崩坏。

[1]  “也来谈谈关于 CNAME 和 MX 冲突的一些事”