DANE/TLSAレコードチェッカー
ドメインのメールサーバー（MXホスト）が公開するTLSAレコードを複数の公開DNSリゾルバーへ問い合わせ、DANEによる証明書検証が設定されているかを診断します。
Tips
- TLSAレコードは通常のドメイン名ではなく、MXホストの `_25._tcp.{ホスト名}` という特殊な名前に配置されます。ドメイン名だけでTLSAを調べても見つからないのはこのためです。
- 「DANE未設定」は異常ではありません。DANEはメール暗号化の追加防御層で、多くのメールサーバーは今も導入していません。
- DANEはDNSSECの署名チェーンによって初めて信頼できる情報になります。TLSAレコードが見つかっても、そのドメインがDNSSECに対応していなければ、姉妹ツールの「DNSSEC検証チェッカー」も併せて確認しましょう。
- MXホストが複数ある場合、優先度（数値が小さいほど優先）が最も高いホストから最大3件までチェックします。
- リゾルバー間で結果が割れる場合、TLSAレコードを更新した直後でキャッシュが混在している可能性があります。しばらく待って再確認してください。
よくある質問
「DANE未設定」自体は危険ではありません。現在も大多数のメールサーバーがDANEなしで運用されています。ただしSTARTTLSの中間者攻撃対策として、可能であれば導入を検討する価値はあります。
両方とも「メール転送時のTLS暗号化を強制する」という同じ目的を持ちますが、信頼の根拠が異なります。MTA-STSは認証局（CA）の証明書検証チェーンに依存し、DANEはDNSSECの署名チェーンに依存します。DNSSECをすでに導入済みならDANE、そうでなければまずMTA-STSの導入が現実的です。両方を併用することも可能です。
Usageは証明書の検証方式（CA検証を要求するか、証明書自体を直接固定するか）、Selectorは証明書全体か公開鍵部分かのどちらをハッシュ化するか、MatchingTypeはハッシュアルゴリズム（SHA-256・SHA-512等）の指定です。組み合わせにより複数の運用パターンに対応します。
確実な保護のためには、送信先として選ばれうるすべてのMXホストにTLSAレコードを設定することが推奨されます。一部のホストにのみ設定されている場合、そのホストが選ばれなかったメールは保護されません。
このツールはTLSAレコードの公開有無という表層的な状態のみを確認します。証明書associationデータの内容が実際のサーバー証明書と一致しているかまでは検証しないため、厳密な検証が必要な場合は専門ツールを併用してください。
余談ですが ― メールの暗号化を「盗聴」ではなく「証明書」で守る発想
SMTP（メール転送プロトコル）における暗号化（STARTTLS）には長らく弱点がありました。多くのメールサーバーは「相手が暗号化に対応していなければ平文で送る」という日和見暗号化（Opportunistic TLS）を採用しており、攻撃者が中間者攻撃でSTARTTLSコマンドを消し去る「STRIPTLS攻撃」によって、暗号化を無効化されたまま気づかれずに通信を傍受されるリスクがありました。
DANE（DNS-based Authentication of Named Entities、RFC 6698）は、この問題への対策としてTLSAレコードをDNS上に公開する方式です。メールサーバーの証明書（またはその公開鍵ハッシュ）をあらかじめDNSに固定しておくことで、接続先が本当に想定通りの証明書を提示しているかを検証できます。認証局（CA）の証明書検証チェーンに依存せず、DNSSECによる署名チェーンだけを信頼の根拠にする点が、通常のSSL/TLS証明書検証との大きな違いです。
DANEの弱点は、これが機能するためにドメイン自体がDNSSECで署名されている必要があることです。DNSSEC未導入のドメインでは、TLSAレコード自体が改ざんされる可能性を排除できないため、DANEの保証は無意味になってしまいます。このためDANEの普及は、DNSSECの普及率に強く依存しており、欧州の一部レジストリ（.nl・.cz等）で先行して採用が進んでいます。