A TLSA 記錄 將TLS服務與憑證或公鑰資料相關聯。它不是一個 TXT記錄，替代 MX記錄 或每個寄件者使用的證據 DANE。對於SMTP ，相關的發現和強制行為由RFC 7672定義。
以MX服務主機名稱開頭
參考： RFC 7672 §2.2, RFC 7672 §3.1.1, RFC 6698 §2.1.
對於 TCP 連接埠 25 上的服務 mx.example.com，傳統的 TLSA 所有者是 _25._tcp.mx.example.com。從實際SMTP交換主機名稱派生名稱，而不是自動從可見的寄件者域或區域頂點派生。檢查部署打算保護的每個MX端點以及 DNSSEC 沿發現路徑的狀態。
TLSA 資料欄位是憑證使用情況， 選擇器，匹配類型和關聯資料。對於這個簡單的非別名路由，顯示的擁有者就足夠了；別名需要RFC 7672 §2.2 中經過驗證的 TLSA 基域處理。通常推薦的SMTP DANE設定檔是 3 1 1：DANE-EE 使用、SubjectPublicKeyInfo 選擇和 SHA-256 匹配。這些數字是有意義的協定選擇，而不是任意憑證文字的通用前綴。 RFC 7672和RFC 7671描述了支援的用法和操作注意事項；將不受支援的組合排除在部署方案之外。
匯出確切的位元組
參考： RFC 6698 §2.1.2, RFC 6698 §2.1.3.
對於本機 PEM 憑證文件 證書.pem，在 Bash shell 中首先啟用 設定-o管道故障;然後是可重複的 SPKI 摘要管道 openssl x509 -in cert.pem -pubkey -noout | openssl x509 -in cert.pem -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256。要求每個階段都取得成功。當選擇選擇器 1 時，對 DER 公鑰表示進行雜湊處理，而不是對 PEM 文字、顯示的指紋或整個憑證進行雜湊處理。
構造 _25._tcp.mx.example.com. 300 IN TLSA 3 1 1 HEXDIGEST，用實際摘要替換 HEXDIGEST。這是一個模板，而不是可發布的記錄。透過受控的方式取得預期SMTP端點提供的憑證 STARTTLS 檢查並比較其選定的位元組。本地文件可能與伺服器實際提供的憑證不同。
在舊關聯退役之前測試關鍵更改
參考： RFC 7672 §4, RFC 7671 §8.
合成裝置 A 使用帶有金鑰 A 的測試憑證和從 A 派生的 TLSA 關聯。預期的位元組比較是匹配的。夾具 B 使用密鑰 B 提供證書，同時僅保留 A 的關聯；預期的比較是不匹配的。夾具 C 為計劃的轉換發布可接受的關聯，並在淘汰 A 之前根據 B 驗證預期端點。
計時必須考慮快取的 TLSA 資料和所有活動伺服器實例。使用相同公鑰更新的憑證可以保持相同 3 1 1 關聯，而新的密鑰會改變它。成功的摘要比較是本地加密檢查，而不是SMTP DANE互通性結果。即時DNSSEC和SMTP測試仍然是單獨的證據要求。
驗證傳輸而不是儀表板標籤
參考： RFC 7672 §2.2, RFC 7672 §3.
使用 DNSSEC 驗證路徑建立可用的 TLSA 數據，然後測試實際的SMTP握手以及與支援 DANE 的實施的關聯。保留DNS答案、驗證追蹤、憑證鏈、選定的關聯和寄件者的結果。支援的寄件者不應默默地將失敗的所需DANE身份驗證視為成功的安全傳遞。不要聲稱通用傳輸保護：寄件者支援和準確的經過身份驗證的發現結果很重要。
觀察關聯和發現檢查
參考： RFC 4035 §5.
保留的 2026 年 11 月 7 日簽署的固定裝置經過檢查但未重新運行以進行本次審查，它通過固定的父級、經過身份驗證的 DS 和子級 DNSKEY 來驗證 TLSA RRset。單獨的環回TLS服務實際上提供了測試憑證 A，然後提供了 B。從每個收到的握手證書中提取 SPKI 會產生 A 與 A 的匹配、B 與 A 單獨不匹配、A/B 重疊期間 B 匹配以及 A 退出後 B 匹配。記錄記錄時間戳記、環回端點、 TLS協定和摘要。這驗證了單獨的加密成分；該服務是普通TLS ，而不是SMTP STARTTLS ，並且沒有聲稱整合DANE郵件用戶端或即時DNS解析器測試。