用與主機名不匹配的 CNAME 替換 MX 記錄
今天我們有 5 家公司都使用 Google 提供電子郵件服務
example1.com. 3w IN MX 10 mail.Google.com. example2.com. 3w IN MX 10 mail.Google.com. example3.com. 3w IN MX 10 mail.Google.com. example4.com. 3w IN MX 10 mail.Google.com. example5.com. 3w IN MX 10 mail.Google.com.下週我們將使用另一家供應商（思科）。我們可以在 MX 中指向 A 或 CNAME 嗎？
example1.com. 3w IN MX 10 myCNAMEToCisco.example.com. example2.com. 3w IN MX 10 myCNAMEToCisco.example.com. example3.com. 3w IN MX 10 myCNAMEToCisco.example.com. example4.com. 3w IN MX 10 myCNAMEToCisco.example.com. example5.com. 3w IN MX 10 myCNAMEToCisco.example.com.我的想法是我可以更改
myCNAMEToCisco.example.com為任何其他供應商。helo domain.com我擔心的是，當客戶端說並且 220 響應可能包含意外的主機或域名時，可能會有一些奇怪的驗證。以這種方式在電子郵件中使用 CNAME 或 A 記錄有什麼問題嗎？
如果您將
MX記錄指向記錄，那肯定會產生問題，CNAME因為它違反了標準。RFC2181 §10.3提供了最清晰的解釋：10.3. MX 和 NS 記錄
用作NS資源記錄值的域名，或MX資源記錄值的一部分，不能是別名。不僅規範在這一點上很清楚，而且在這兩個位置中使用別名既不能達到預期的效果，也不能很好地實現可能導致這種方法的雄心。該域名必須具有一個或多個地址記錄作為其值。目前，這些將是 A 記錄，但將來可能會接受其他提供定址資訊的記錄類型。它也可以有其他 RR，但不能有 CNAME RR。
搜尋 NS 或 MX 記錄會導致“附加部分處理”，其中與所搜尋記錄的值關聯的地址記錄被附加到答案中。這有助於避免在進行第一次查詢時很容易預料到的不必要的額外查詢。
其他部分處理不包括 CNAME 記錄，更不用說可能與從別名派生的規範名稱相關聯的地址記錄了。因此，如果將別名用作 NS 或 MX 記錄的值，則不會返回帶有 NS 或 MX 值的地址。這可能會在每個查詢上導致額外的查詢和額外的網路負擔。DNS 管理員只需在更新或安裝時解析別名並將規範名稱直接放在受影響的記錄中一次即可避免這種情況。在某些特定的困難情況下，NS 查找結果中缺少額外的部分地址記錄可能會導致請求失敗。
您可能可以通過搜尋引擎找到一些DNS 和 MTA 軟體支持這一點的軼事證據，但這應該被視為例外而不是規則。大多數軟體作者不會將缺乏這種支持視為錯誤。始終避免將
MX記錄指向CNAME.您現在面臨的最大問題是
MX範例中記錄的 TTL 都是三週，而您的更改是下週。我強烈建議您請求延遲此切換，並將您的 TTL 降低到十分鐘左右的某個地方。切換完成後，您可以再次提高 TTL。