A 和 AAAA 記錄將主機名稱對應到IPv4和IPv6位址。它們是郵件服務的依賴項，而不是服務已準備好或已授權發送的聲明。發布位址可以公開用戶端實際嘗試的路由，因此請驗證每個公佈的系列和端點。
遵循協議使用的名稱
參考： RFC 5321 §5.1, RFC 7208 §5.3, RFC 7208 §5.4.
對於入站SMTP ，解析MX傳回的交換主機名稱。當明確交換無法使用時，收件者網域的網站位址不能取代。如果不存在MX ，則SMTP的隱式 MX 規則可以使收件者網域本身的 A 或 AAAA 記錄相關。
對於出境 SPF，檢查實際政策並評估身分。一個 a 機制可以授權為其指定名稱傳回的位址；一個平原 一個記錄 本身不授權任何事情。同樣，更改SPF使用的主機名 MX 機制可以更改評估為授權的位址。在將DNS地址編輯視為僅網站更改之前，記錄這些引用。
將雙堆疊視為兩條操作路徑
參考： RFC 1035 §3.4.1, RFC 3596 §2.1, RFC 3596 §2.3.
一個主機名稱可以有多個 A 記錄和多個 AAAA 記錄。它們的存在並不保證可及性、 SMTP服務、正確的憑證或等效策略。健康的IPv4端點並不能證明IPv6可以正常運作。相反，一個客戶端路徑上的故障並不能證明每個發送方都使用該路徑。
擷取實際嘗試的目標位址、位址族、連線結果和SMTP響應。如果調查出站流量，請擷取外部觀察到的來源位址，而不是假設它與應用程式內部使用的位址相符。 NAT 和提供者出口池可以使這些值不同。
重現地址族故障
合成夾具： example.com. MX 10 mx.example.com.; mx.example.com. A 192.0.2.10; mx.example.com 。 AAAA 2001:db8::10。在實驗室中，將IPv4端點設定為接受連接埠 25 上的 TCP 連接，並使IPv6端點無法存取。預期的DNS檢查對於兩種記錄類型都成功，而特定於系列的連線測試僅對於IPv4成功。
詢問 挖掘@AUTH mx.example.com 。 A+無遞迴 然後使用相同的命令 AAAA。將 AUTH 替換為隔離的權限。記錄兩個答案。使用您認可的實驗室SMTP用戶端獨立固定每個目標，記錄連線和協定結果。該裝置說明了為什麼DNS成功並不意味著服務成功；它沒有聲明特定寄件者的回退時間。
第二個夾具僅更改 A 位址 192.0.2.10 到 192.0.2.20 而SPF策略是 v=spf1 a:mx.example.com -all。對於具有其他成功查找的IPv4 SPF評估，位址有資格匹配 a 機制變化。明確的 ip4:192.0.2.10 相反，機制將保持與該文字網路的聯繫，直到策略本身發生變化。
使地址更改可逆
參考： RFC 8767 §4.
清點主機名的所有使用者，包括郵件路由、 SPF引用、監控和憑證期望。在公佈端點之前準備好端點。保留舊服務，同時適當的快取仍然可以將流量引導到那裡，基於實際的遷移計劃而不是普遍的等待期。
更改後，將權威答案與遞歸觀察和訊息層級證據進行比較。故障的IPv6端點應透過核准的變更進行修復或刪除，而不是透過削弱不相關的身份驗證策略來隱藏。僅當預期地址和操作路徑與記錄的服務設計相符時才結束工作。
保持證據範圍明確
對於兩個家庭的場景，在測試之前將預期的IPv4成功和IPv6失敗保留為建議的實驗室觀察結果。 SPF位址變更範例假定查找成功並採用規定的策略；它不會為任何真正的寄件者建立目前授權。