使用腾讯云 CDN 后邮箱无法正常收信的解决方案

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

TL; DR

  1. 确实是 CDN 提供的 CNAME 多层嵌套导致

  2. 手动调整解析为最末级 CNAME 即可

起因

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

腾讯云 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 结果一定会非常不精确。」1

总结

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