DANE — SMTP TLS用のDNSベース認証

Standards Track Transport Security Published March 2026

ELI5: ウェブサイトにアクセスすると、ブラウザは数百の認証局を信頼してサイトのアイデンティティを保証します。DANEを使うと、ドメイン所有者は仲介者を排除できます。「私のメールサーバーが使用する正確な証明書（またはCA）はこちらです。DNSSECで署名したDNSに公開しているので、自分で検証できます。」CA信頼は不要です。

このサイトが存在する理由

SMTP with STARTTLS には2つの根本的な問題があります:

認証がない。 送信サーバーが受信サーバーのTLS証明書が正当であることを確認する信頼できる方法がありません。SMTPはウェブのCA信頼モデルを使用していません — 歴史的に、ほとんどのメールサーバーは自己署名証明書を使用していたため、送信者は何でも受け入れるように学びました。
ダウングレード攻撃。 アクティブなネットワーク攻撃者がEHLO応答からSTARTTLS広告を削除して、平文配信を強制できます。

MTA-STS (RFC 8461) はHTTPSとWeb PKIを使用してこれらの問題を解決します。DANEはDNSSECとTLSAレコードを使用してそれらを解決します。2つのアプローチは相補的です: DANEは暗号学的に強い (CA信頼が不要) 一方、MTA-STSはデプロイが簡単です (DNSSECは不要)。

動作方法

SMTP向けDANE (RFC 7672で定義され、RFC 6698のベースDANE仕様の上に構築) は3つのステップで動作します:

ステップ1: DNSSEC署名済みゾーン

受信ドメインのDNSゾーン — およびMXターゲットのゾーン — はDNSSECで署名されている必要があります。これは交渉の余地がありません。DNSSECなしでは、攻撃者がTLSAレコードを偽造でき、DANEが役に立たなくなるどころか悪化します。

ステップ2: TLSAレコードを公開

ドメインは各MXホストのSMTPポート用のTLSAレコードを公開します。TLSAレコードはTLS証明書 (またはその公開鍵、またはそのCA) を特定のサービスにバインドします。

; TLSAレコード形式: _port._protocol.hostname TLSA usage selector matching-type data _25._tcp.mail.example.com. IN TLSA 3 1 1 a]b2c3d4e5f6...sha256hash...

TLSAレコードフィールド

フィールド	値	説明
用途	`0` — CA制約 (PKIX-TA) `1` — 証明書制約 (PKIX-EE) `2` — トラストアンカーアサーション (DANE-TA) `3` — ドメイン発行証明書 (DANE-EE)	検証に証明書データがどのように使用されるか。
セレクタ	`0` — 完全な証明書 `1` — SubjectPublicKeyInfo	マッチする証明書のどの部分。
マッチングタイプ	`0` — 完全一致 `1` — SHA-256 `2` — SHA-512	データがどのように表現されるか。

ステップ3: 送信者が検証

DANE対応の送信サーバーが example.com にメールを配信する場合:

example.com のMXレコードをDNSSEC検証で解決します。
各MXホスト (例: mail.example.com) に対して、DNSSEC検証で _25._tcp.mail.example.com TLSA を検索します。
DNSSEC検証済みTLSAレコードが存在する場合: 接続し、STARTTLSを実行し、サーバー証明書をTLSAデータに対して検証します。
検証に失敗した場合: 配信しません。 メッセージは再試行のためキューに入ります。
TLSAレコードが存在しない場合 (またはDNSSECがデプロイされていない場合): 前のように機会的TLSにフォールバックします。

主なテクニカルディテール

推奨TLSA設定

SMTPサーバーの場合、RFC 7672は DANE-EE(3) SPKI(1) SHA-256(1) を推奨しています:

_25._tcp.mail.example.com. IN TLSA 3 1 1 <sha256-of-public-key>

これは最も堅牢な選択です。理由:

用途3 (DANE-EE) はCA検証を完全にバイパスします。証明書は公開CAに署名されている必要がありません — 自己署名で問題ありません。
セレクタ1 (SPKI) は完全な証明書ではなく公開鍵をマッチします。キーペアが同じままでいる限り、TLSAレコードを更新せずに証明書を更新 (シリアル番号、有効期限を変更) できます。
マッチングタイプ1 (SHA-256) は完全なキーではなくハッシュを保存し、DNSレコードをコンパクトに保ちます。

TLSAレコードを生成

# サーバーの公開鍵のSHA-256ハッシュを抽出
openssl x509 -in server.crt -noout -pubkey | \
  openssl pkey -pubin -outform DER | \
  openssl dgst -sha256 -hex
(stdin)= 2a9f8e3b1c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f

# 生成されたTLSAレコード:
_25._tcp.mail.example.com. IN TLSA 3 1 1 2a9f8e3b1c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f

DANE vs. MTA-STS

	DANE	MTA-STS
信頼モデル	DNSSEC (CAは不要)	Web PKI (CA発行証明書)
DNSSECが必要	はい (必須)	いいえ
自己署名証明書	サポート (用途3)	非サポート
初回使用セキュリティ	初回使用時から安全	初回使用を信頼 (TOFU)
デプロイメント障壁	DNSSEC (重大)	HTTPSホスティング (低)
採用	オランダ、ドイツ、チェコで強い; その他の地域では限定的	広くサポート

一般的な間違い

DNSSECなしでTLSAを公開。 ゾーンがDNSSEC署名されていない場合、TLSAレコードは無視されます。さらに悪いことに、一部の実装は未署名TLSAを TLSを必須としない シグナルとして扱い、セキュリティを低下させます。
キーローテーション時にTLSAを更新し忘れ。 セレクタ0 (完全な証明書) を使用して새로운 キーで証明書を更新する場合、TLSAレコードは新しい証明書がライブになる前に更新されている必要があります。セレクタ1 (SPKI) を使用してキーペアを更新する際に同じに保つことを避けます。
ドメインではなく、MXホストのTLSA。 TLSAレコードはドメイン自体ではなく、MXターゲットホスト名 (例: _25._tcp.mail.example.com) に配置します。MXがサードパーティホストを指す場合、TLSAレコードはそのゾーンに配置されている必要があります。
TLSAレコードを不正にローリング。 キーをローテーションする場合、古い鍵と新しい鍵の両方のTLSAレコードを同時に公開します。証明書がローテーションされDNSキャッシュが期限切れになった後にのみ、古いレコードを削除します。
DNSSEC信頼チェーンを無視。 ルートからTLSAレコードへのチェーン内のすべてのゾーンはDNSSEC署名されている必要があります。どこかでの中断がチェーン全体を無効にします。

配信可能性への影響

最も強いTLS保証。 DANEはDNS単体からサーバーのIDの暗号学的証明を提供します。CA侵害なし、TOFUウィンドウなし — 最初の接続から安全です。
ヨーロッパで広くデプロイ。 オランダ、ドイツ、チェコ共和国は政府および機関メールのDANE採用が高い。これらの地域に配信する場合、DANE対応は大きなメリット。
Postfixネイティブサポート。 Postfixには組み込みDANEサポートがあります (smtp_tls_security_level = dane)。Postfixを使用する送信者では、受信ドメインがTLSAレコードを持つ場合、DANEは「すぐに機能します」。
MTA-STSと相補的。 両方をデプロイ。DANEをサポートする送信者がそれを使用 (より強い保証); MTA-STSのみをサポートする送信者がそれを使用。両方が機会的TLS単体よりも優れています。