DANE/TLSA 記錄檢測工具
向多個公共 DNS 解析器查詢域名郵件伺服器（MX 主機）釋出的 TLSA 記錄，檢測是否已配置 DANE 證書鎖定。
使用提示
- TLSA 記錄並不位於普通域名下，而是位於特殊名稱 `_25._tcp.{MX 主機名}` 下，這就是為什麼直接查詢域名本身找不到 TLSA 記錄的原因。
- 「未配置 DANE」並非異常。DANE 是郵件加密的額外防護層，目前大多數郵件伺服器仍未啟用。
- DANE 的可信度依賴於該域名的 TLSA 記錄本身受到 DNSSEC 簽名鏈的保護。即使找到了 TLSA 記錄，也建議配合姊妹工具「DNSSEC 驗證檢測工具」確認該域名是否已啟用 DNSSEC。
- 如果存在多個 MX 主機，本工具會按優先順序（數值越小優先順序越高）檢測最多 3 個主機。
- 如果各解析器結果不一致，可能是記錄剛剛更新、快取尚未統一所致。請稍後重新檢測。
常見問題
「未配置 DANE」本身並不危險，目前絕大多數郵件伺服器仍在沒有 DANE 的情況下執行。不過，若條件允許，作為防範 STARTTLS 中間人攻擊的措施，值得考慮啟用。
兩者的目標都是強制郵件傳輸使用 TLS 加密，但信任基礎不同：MTA-STS 依賴證書頒發機構（CA）的驗證鏈，DANE 依賴 DNSSEC 簽名鏈。如果已經啟用了 DNSSEC，DANE 是自然的選擇；否則先部署 MTA-STS 更為現實。兩者也可以同時使用。
Usage 指定驗證方式（是否仍需 CA 驗證，或直接鎖定證書本身），Selector 指定對完整證書還是僅公鑰部分進行雜湊，Matching Type 指定雜湊演算法（如 SHA-256、SHA-512）。不同組合適用於不同的運維模式。
為確保完整保護，建議所有可能被選為投遞目標的 MX 主機都配置 TLSA 記錄。若只有部分主機配置了記錄，投遞到未配置主機的郵件將得不到保護。
本工具僅確認 TLSA 記錄是否已釋出這一表層狀態，不會驗證證書關聯資料是否與伺服器實際證書一致。如需嚴格驗證，請配合專業工具使用。
閒話 ― 用「證書」而非僅靠「不被竊聽」來保護郵件加密
SMTP（郵件傳輸協議）的加密方式 STARTTLS 長期存在一個弱點：多數郵件伺服器採用「機會性加密」（Opportunistic TLS），即對方不支援加密時便退回明文傳輸，這為「STRIPTLS 攻擊」打開了大門——中間人攻擊者可以悄悄剝除 STARTTLS 指令，使連線在雙方都未察覺的情況下降級為明文。
DANE（基於 DNS 的命名實體認證，RFC 6698）通過在 DNS 中釋出 TLSA 記錄來應對這一問題。預先將郵件伺服器的證書（或其公鑰雜湊）鎖定在 DNS 中，傳送方伺服器便可驗證所連線的主機是否確實提供了預期的證書。與普通 SSL/TLS 證書驗證不同，DANE 完全不依賴證書頒發機構（CA）的信任鏈，只信任 DNSSEC 簽名鏈。
DANE 的弱點在於，只有當域名本身經過 DNSSEC 簽名時才能生效。若未啟用 DNSSEC，則無法排除 TLSA 記錄本身在傳輸過程中被篡改的可能，DANE 的保證也就失去意義。因此 DANE 的普及程度與 DNSSEC 的普及程度密切相關，歐洲部分註冊局（如 .nl、.cz）已率先推廣採用。