A CNAME 使一個DNS名稱成為另一個 DNS 名稱的別名。它通常用於提供者管理的電子郵件設置，但它不會像 NS 委派那樣傳輸整個子網域。在建立別名之前，請確定已佔用該確切名稱的內容以及控制目標的人。
保持別名所有者的獨佔性
參考： RFC 2181 §10.1, RFC 1034 §4.2.1.
在CNAME所有者處，普通TXT 、 MX 、 A 等資料不能與別名共存。 DNSSEC 元資料是一個特例；它不會使 TXT-plus-CNAME 配置有效。別名有一個規範目標。區域 apex 已經需要 SOA 和 NS 記錄，因此傳統的 apex CNAME與區域結構衝突。
稱為扁平化或 ALIAS 的提供者功能可以合成普通地址答案，而不是發布CNAME 。他們的行為是特定於實現的。不要假設此類功能可以合成任意身份驗證TXT資料或充當基於標準的委託。檢查消費協議所需的實際記錄類型的答案。
遵循依賴關係直至結束
參考： RFC 1034 §3.6.2, RFC 6376 §3.6.2.1.
對於提供者支援的 DKIM 別名， TXT查找 選擇器 可以跟隨別名到提供者的金鑰。保留別名所有者、每個目標和終端TXT結果。指向另一個CNAME CNAME添加了另一個依賴項；循環或缺少目標會阻止有用的最終答案。
這種安排使目標操作員能夠影響透過別名解析的資料。這不是編輯區域其餘部分的權限，但它對於配置的服務來說是重要的。驗證經過驗證的提供者設定流程中產生的目標，記錄服務所有權並透過計畫停用刪除過時的依賴項。
練習綜合選擇器查找
夾具 A 發布 s1._domainkey.example.com 。 300 IN CNAME s1.keys.example.net 。 和終端TXT值 s1.keys.example.net.。對於此僅 DNS 測試使用 “夾具=終端資料”，故意不是有效的DKIM鑰。預期的TXT解析遵循別名並傳回該標記。這僅證明了查找依賴性，而不是加密身份驗證。
夾具 B 增加了一個 TXT記錄 在 s1._domainkey.example.com. 同時保留其CNAME 。預期的配置驗證是共存衝突；不要發布它來測試接收者的容忍度。夾具 C 將目標變更為未配置的名稱。預期結果是沒有可用的終端數據，精確的回應取決於該名稱是否存在（沒有TXT或根本不存在。
在隔離測試環境中，查詢擁有者的CNAME和TXT並查詢目標的TXT 。記錄回應代碼、權限和別名鏈。對於真正的DKIM測試，請將標記替換為提供者的真實產生的配置，並單獨驗證簽名訊息。
避免在路由目標中使用別名
參考： RFC 2181 §10.3, RFC 5321 §5.1, RFC 8767 §4.
MX目標和 NS 目標必須使用位址記錄而不是別名來命名主機。正在尋找郵件的網域本身可以涉及SMTP解析規則下的CNAME ，但這不允許CNAME作為儲存在MX資料中的交換主機名稱。讀取跡線時，請保持這兩個位置不同。
在停用外部服務之前，請檢查另一個活動服務是否仍在使用選擇器或目標。刪除別名可能會在一段時間內對快取的讀取器不可見，並且恢復它並不是立即回滾。驗證DNS和預期服務行為後關閉變更。
保持證據範圍明確
終端設備標記僅顯示計劃的DNS依賴性，而不是可用的DKIM鑰。不要發布故意衝突的所有者來測試容忍度。本次審核中未執行CNAME部署、解析或加密驗證。