## この記事でわかること

- 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 を剥がしたり別証明書に差し替えたりする攻撃を防げます。

![DANE による TLS 検証](/blog/tlsa-dane-smtp/dane-flow.svg)

## DNSSEC が必須な理由

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

## TLSA レコードの構成

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

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

![TLSA レコードの 4 フィールド](/blog/tlsa-dane-smtp/tlsa-fields.svg)

- **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 入門](/blog/dnssec-basics) 参照）
- 鍵更新のたびに TLSA も更新が必要。証明書更新オペレーションと連携した運用設計が必須
- TLS-RPT（RFC 8460）でレポートを受け取り、検証失敗を早期検知できる体制が前提

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

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

関連記事: [DNSSEC 入門](/blog/dnssec-basics) / [MTA-STS 導入手順](/blog/mta-sts-implementation-steps) / [MTA-STS と TLS-RPT の基礎](/blog/mta-sts-tls-rpt-basics)