DANE（DNS-based Authentication of Named Entities）とは、DNSSECで保護されたTLSAレコードを使い、TLS証明書や公開鍵の情報をドメイン名と結び付ける仕組みです。メール配送では、送信側が受信側SMTPサーバーとのTLS接続を検証するために利用できます。
導入にはDNSSECが正しく機能していることが前提となり、証明書や公開鍵を変更するときはTLSAレコードも同時に更新します。メールとDNSの担当者が異なる場合は、変更手順と障害時の対応方法を事前に決めておきます。
DANEとTLSAの関係
DANEは技術全体の名称で、TLSAは証明書や公開鍵との対応関係をDNSへ記録するためのレコードです。
SMTPで利用する場合、受信側のMXホストに対して、通常は次の名前でTLSAレコードを公開します。
_25._tcp.<mx-host>
たとえば、MXホストがmail.example.jpなら、_25._tcp.mail.example.jpと設定します。送信側メールサーバーはDNSSEC検証に成功したTLSAレコードを取得し、SMTPサーバーが提示する証明書や公開鍵と照合します。
DNSSECが前提となる理由
TLSAレコード自体が改ざんされると、誤った証明書や公開鍵を信頼させられる可能性があります。そのためDANEでは、DNSSECによってTLSAレコードの真正性を検証できることが前提となっています。
DNSSECの信頼の連鎖が成立していない場合、SMTP向けTLSAレコードが存在していても、DANEによる安全な検証には利用できません。導入時はTLSAだけでなく、DNSKEY、DS、署名期限、鍵更新などDNSSEC全体の適切な運用が必要です。
MTA-STSとの違い
DANEとMTA-STSは、どちらもメール配送時のTLSを保護しますが、信頼の基盤が異なります。
| 技術 | ポリシー・検証情報 | 信頼の基盤 |
|---|---|---|
| DANE | DNSのTLSAレコード | DNSSEC |
| MTA-STS | HTTPSで取得するポリシー | 公開認証局を基盤とするWeb PKI |
どちらも、送信側メールサーバーが対応して初めて配送判断に利用されます。すべての組織に一律に導入を推奨できるものではなく、既存のメール基盤、DNSSECを管理できる体制、設定不整合時の影響を踏まえて選択します。
DANE導入時に確認したいこと
- DNSSECの信頼の連鎖が正しく成立しているか
- DANEで保護するMXホストに必要なTLSAレコードがあるか
- 証明書や公開鍵の更新とTLSA更新を同期できるか
- DNSキャッシュとTTLを考慮した切り替え手順があるか
- バックアップMXを含めて検証できるか
- 対応する送信側からの配送結果を観測できるか
- 設定不整合時の切り戻しと障害対応の手順があるか
DANEでは、証明書とTLSAレコードの更新、DNSSECの鍵・署名管理が密接に関係します。個別のレコード追加ではなく、一連の変更作業として手順を定めます。
当社の調査で確認されたSMTP向けTLSAレコード
当社（Aioright Technologies）がSMTP向けTLSAレコードを調査したところ、中小企業では確認されず、大企業で2社確認されました。
| 指標 | 中小企業 | 大企業 |
|---|---|---|
| SMTP向けTLSA公開 | 0社 / 0.0% | 2社 / 0.7% |
調査時点では極めて限定的な利用状況であると言えます。大企業で確認された2社はいずれも外資系企業で、そのうち1社ではMTA-STSとTLS-RPTも確認されました。
この数値はTLSAレコードの公開状況を表しています。SMTP接続を行っていないため、実際に提示される証明書とTLSAレコードの照合データが一致するかまでは検証しておらず、「DANEが正常に機能している」と評価したものではありません。
当社は2026年8月1日から20日に公開情報を調査・分析しました。MXを確認できた中小企業475社、大企業278社を分母としています。これは調査対象ドメインにおけるTLSAレコードの公開状況であり、日本企業全体の推計値ではありません。詳しい調査条件と全体結果は調査報告書で確認できます。
自社のDNS・メール設定を確認するには
SecureScanでは、DNSSEC、メール、TLS/SSLなどの外部公開設定を横断して確認できます。DANEの導入判断や、DNSSEC・証明書・TLSAレコードを連動して更新する手順については、セキュリティ・ITコンサルティングへご相談ください。