DANE / TLSA で SMTP の TLS を堅牢化する｜Web 担当者向け導入ガイド

この記事でわかること

• DANE / TLSA が SMTP TLS の信頼を強化する仕組み
• DNSSEC が前提となる理由（DANE は DNSSEC 無しでは成立しない）
• TLSA レコードの 4 つのフィールド（Cert Usage / Selector / Matching Type / 証明書データ）
• MTA-STS との比較と、両方併用するメリット

DANE / TLSA とは

DANE（RFC 6698 / 7671）は、TLS 証明書の正当性を DNSSEC で署名された DNS レコード経由で検証する仕組みです。SMTP の場合は _25._tcp.<MX ホスト名> に TLSA レコードを置き、送信側 MTA が「この鍵 / 証明書でない限り TLS 接続しない」と強制できます。中間者が STARTTLS を剥がしたり別証明書に差し替えたりする攻撃を防げます。

DNSSEC が必須な理由

TLSA レコード自体が攻撃者に書き換えられたら無意味です。DANE は DNSSEC で署名されたゾーンに置かれた TLSA レコードしか信頼しない設計。DNSSEC 未対応ドメインでは DANE は機能しません。DNSSEC の基礎はDNSSEC 入門を参照。

TLSA レコードの構成

_25._tcp.mx1.example.com. IN TLSA 3 1 1 <hex>

4 つのフィールドの意味:

• Certificate Usage: 0=PKIX-TA / 1=PKIX-EE / 2=DANE-TA / 3=DANE-EE。SMTP では 3（DANE-EE、サーバ証明書自体を直接固定）が一般的
• Selector: 0=完全な証明書 / 1=公開鍵（SPKI）のみ。鍵を変えずに証明書だけ更新する運用では 1
• Matching Type: 0=データそのもの / 1=SHA-256 / 2=SHA-512。通常 1
• 証明書データ: ハッシュ値（16 進）

つまり 3 1 1 は「SubjectPublicKeyInfo の SHA-256 ハッシュをサーバ証明書として直接ピン留め」を意味します。

MTA-STS との比較

観点	DANE	MTA-STS
信頼基盤	DNSSEC	Web PKI（HTTPS 証明書）
配信	DNS TLSA レコード	HTTPS のポリシーファイル
適用	送信 MTA が DANE 対応必要	送信 MTA が MTA-STS 対応必要
普及度	DNSSEC 普及率が壁	比較的導入しやすい
強さ	強い（証明書ピン留め）	中（CA 経由の信頼）

両者は排他ではなく、可能なら DANE + MTA-STS の併設が推奨されます。gov.uk や .de の一部 ISP は DANE 採用が進んでいます。

導入の判断材料

• DNSSEC が前提。未対応なら先にそちらから（DNSSEC 入門 参照）
• 鍵更新のたびに TLSA も更新が必要。証明書更新オペレーションと連携した運用設計が必須
• TLS-RPT（RFC 8460）でレポートを受け取り、検証失敗を早期検知できる体制が前提

まずは現状を把握しましょう

DANE は SPF / DKIM / DMARC / MTA-STS が整った後の次の打ち手です。まず無料のドメイン診断で現状を確認しましょう。導入判断はお問い合わせからご相談ください。SSL や DNS の単発チェックは無料ツール一覧で。

関連記事: DNSSEC 入門 / MTA-STS 導入手順 / MTA-STS と TLS-RPT の基礎