DANE 和 MTA-STS 兩者都允許支援發送系統強制執行經過身份驗證的SMTP傳輸。它們的信任依賴性不同，而且這些差異在第一則訊息之前、 DNS出現問題期間以及憑證變更時很重要。在它們之間進行選擇需要了解接收運營商及其提供者可以維護的內容，而不僅僅是成功的TLS握手。
遵循一條接收路線
參考： RFC 7672 §2, RFC 8461 §3, RFC 8461 §4.
在 TCP 連接埠 25 上使用example.com和MX mx1.example.net 。在SMTP DANE下，寄件者需要適當的 DNSSEC 驗證路由和 TLSA 發現過程。對於這個簡單的無別名主機，TLSA 擁有者是_25._tcp.mx1.example.net 。可用的安全性 TLSA 關聯告訴支援發送者如何驗證TLS服務。一個 TXT記錄 在收件者網域中不是替代品。 RFC 7672第 2 節和第 3 節.
在MTA-STS下，收件者網域在_mta-sts.example.com上發布發現，並在mta-sts.example.com上透過經過驗證的 HTTPS 提供其策略。此策略授權預期的MX名稱以及供應模式和生命週期。對於 STS 驗證， SMTP伺服器必須滿足適用的公鑰基礎設施憑證檢查，包括RFC 8461 §4.2 下的符合 SAN DNS-ID。單獨的通用TLS主機名稱探測並不能建立完整的設定檔。策略主機憑證和郵件伺服器憑證保護不同的服務。 RFC 8461第 3 節和第 4 節.
比較首次接觸與失敗狀態
參考： RFC 7672 §2.1, RFC 8461 §2, RFC 8461 §3.3, RFC 8461 §10.2.
DANE可以透過以下方式驗證其策略發現 DNSSEC 第一次聯繫時，驗證鍊是安全的並且存在可用記錄。這與信任遞歸解析器返回的任何答案不同。虛假的驗證結果並不等於有效的不安全委託。記錄解析器信任關係以及每個相關答案的驗證狀態。
MTA-STS有一個引導限制：可以阻止沒有可用快取策略的傳送者取得策略。當無法獲得新的策略時，持有未過期執行策略的寄件者必須繼續應用它。因此，請分別比較空緩存和熱緩存情況。一台監控主機上成功的 HTTPS 並不能證明每個發送者都已了解該策略。
考慮四種明確的假設狀態。透過首次聯繫時安全可用的DANE發現，即使MTA-STS取得被抑制，支援的發送者也可以驗證服務。如果快取了未過期的強制MTA-STS策略，則失敗的檢索不會刪除該策略。即使新憑證滿足 PKIX，從 A 到 B 的金鑰變更也可能導致僅舊的 TLSA 關聯失敗；重疊可以覆蓋兩個鍵。移至由適用的快取 STS 策略排除的MX可能會導致MX檢查失敗，直到得知相容的策略為止。這些是基於標準的範例，未觀察DNSSEC 、快取或交付測試。
這些機制並不是普遍組合的，因為規則要求兩者都通過。 RFC 8461 §2 建立了特定的無幹擾要求：成功的MTA-STS驗證不得覆寫失敗的DANE驗證。堅持兩者都必須通過的通用比較模型不是規範的發送方演算法。
規劃兩次相同的展期
參考： RFC 7672 §4, RFC 8461 §8.
DANE-EE 用法 3 透過安全關聯進行驗證： RFC 7672 §3.1.1 不需要 STS 使用的 PKIX 身分或憑證過期檢查。請勿將此例外不加區別地應用於每次 TLSA 使用。對 DANE-EE 來說 選擇器 SPKI 和 SHA-256，更改公鑰會更改關聯摘要。在部署新金鑰之前發布新舊關聯，允許舊DNS快取和相關簽章記錄過期，並保持每個活動端點的覆蓋範圍。使用相同密鑰重新頒發憑證與輪換密鑰不同。 RFC 7672第 4 節.
對於MTA-STS ，保留有效MX身分和信任的普通憑證續約本身並不需要更改策略MX模式。 MX遷移的功能是：制定涵蓋新舊接收主機的策略，並為保留先前策略的寄件者帳戶。這兩種型號都不允許僅僅因為另一個檢查器報告為綠色而忽略損壞的路線。
按營運所有權決定
參考： RFC 8461 §2.
列出控制收件者DNS 、 MX 主機DNS 、 DNSSEC簽章、 SMTP憑證部署和 HTTPS 原則託管的團隊。託管提供者可以控制網域擁有者無法直接變更的依賴項。在向客戶承諾任一控制之前建立支援的流程。在部署兩種機制的情況下，成功的MTA-STS驗證不得覆寫失敗的DANE驗證。本指南沒有使用即時DNSSEC鍊或SMTP傳送；此比較是基於標準的，且其本地範例是明確綜合的。