換上騰訊雲 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 衝突的一些事」