DANEとは？DNSベースの命名エンティティ認証の解説 (2026)

DNSベースの命名エンティティ認証（DANE）は、DNSを利用してTLS証明書を検証する手法です。これはDNSSECおよびTLSAレコードを活用し、暗号化された接続が傍受されたり、セキュリティレベルが低下したりしないことを保証します。

DANEが解決するために設計された課題

SMTP（Simple Mail Transfer Protocol）による電子メールの送信では、接続を暗号化するためにSTARTTLSが使用されることがよくあります。問題は、STARTTLSが「機会主義的」である点にあります。つまり、暗号化に失敗した場合、接続が平文に戻ってしまう可能性があるということです。このダウングレードは黙って行われるため、攻撃者がこの挙動を悪用して電子メールを傍受しやすくなってしまいます。

通常の経路：

攻撃経路：

従来のTLSには、もう1つ問題があります：

TLS証明書は、商用認証局（CA）を通じて検証されます。これらのCAは侵害されたり、誤って証明書を発行したりする可能性があります。攻撃者がドメインの有効な証明書を入手した場合、そのサーバーになりすますことが可能になります。

これら2つの問題により、TLSを使用している場合でも中間者攻撃が可能となります。DANEは、証明書の検証をDNSSECによって保護されたDNSに移行させることで、これら両方の問題に対処します。これにより、外部のCAへの依存がなくなり、サイレントダウングレード攻撃を防ぐことができます。

DANEとは何ですか？

DANEは、ドメイン所有者がTLSAレコードを使用して、TLS証明書に関する情報をDNSに直接公開できるようにするインターネットセキュリティプロトコルです。

これらのレコードはDNSSECによって保護されており、これにより以下のことが保証されます：

• 転送中は記録を変更することはできません
• クライアントは、その応答が正当なものであることを確認できます

サードパーティのCAを信頼する代わりに、クライアントはドメイン側が公開している情報に基づいて証明書の有効性を確認します。

DANEの仕組み：手順解説

手順 1：ドメイン所有者が DNS に TLSA レコードを登録する

ドメイン管理者は、TLSA（Transport Layer Security Authentication）リソースレコードを作成し、自身のDNSゾーンに公開します。このレコードには、クライアントが後で検証に使用する証明書データが含まれています。

ステップ 2: DNS ゾーンを DNSSEC を使用して署名する

DNSSEC（DNSセキュリティ拡張）は、新しいTLSAレコードを含むDNSゾーン全体に暗号的な署名を付与します。これにより、ルートDNSゾーンからドメインのレコードに至るまでの信頼の連鎖が形成され、改ざんが防止されます。

ステップ3：クライアントがサーバーに接続し、TLSAレコードを照会する

クライアント（メールサーバーやブラウザなど）がサーバーとのTLS接続を確立しようとする場合、まずDNSに対してそのドメインのTLSAレコードを問い合わせます。

ステップ4：クライアントはDNSSECを使用してDNS応答を検証します

TLSAレコードを信頼する前に、クライアントのリゾルバーは信頼チェーンを遡ってDNSSEC署名を検証します。

ステップ 5：サーバーが自身の TLS 証明書を提示します

TLSハンドシェイクの過程で、サーバーは自身のTLS証明書をクライアントに送信し、証明書チェーンを提示することで自身の身元を証明します。

手順 6：クライアントは証明書とTLSAレコードを照合します

これがDANEチェックの最も重要な部分です。このステップでは、クライアントはサーバーの証明書から関連する部分を抽出し、TLSAレコードに保存されているデータと照合します。

ステップ7：一致した場合、接続が進行します

証明書のデータがTLSAレコードと一致すると、DANE検証が成功し、TLS接続が正常に確立されます。

ステップ8：一致しない場合、接続は拒否されます

証明書がTLSAレコードと一致しない場合、クライアントはこれをセキュリティ上の問題とみなして、TLSハンドシェイクの完了を拒否します。これにより、中間者攻撃がそもそも成功するのを防ぐことができます。

TLSAレコードとは何ですか？

TLSAレコードとは、DANEがTLS証明書の検証方法を定義するために使用するDNSレコードのことです。

The format looks like this: <usage> <selector> <matching-type> <certificate-data>

TLSAレコードの例：

_25._tcp.mail.example.com. IN TLSA 3 1 1 (

2A3F5C7D8E9B1A2C3D4E5F67890123456789ABCDEF1234567890ABCDEF123456
)

各フィールドにはそれぞれ特定の役割があります：

• 使用方法：証明書の照合および信頼の方法を定義します
• セレクタ：証明書のどの部分を使用するかを指定します（完全な証明書または公開鍵）
• 照合タイプ：データの保存方法（完全値またはハッシュ）を示します
• 証明書データ：照合対象となる実際の値またはハッシュ

証明書の使用状況

使用方法は4種類あります：

0 (PKIX-TA): 従来のPKIを用いたトラストアンカーの制約
1 (PKIX-EE): PKIを介して検証されたエンドエンティティ証明書
2 (DANE-TA): DNSによって定義されたトラストアンカー
3 (DANE-EE): DNSに直接定義されたエンドエンティティ証明書

電子メールのセキュリティに関しては、利用方法の2と3が最も重要である。なぜなら、これらは公的CAへの依存を排除するからである。

TLSAレコードの公開場所

TLSAレコードは、特定のサービスに基づくサブドメインの下で公開されます。SMTPの場合、通常は次のような形式になります：_25._tcp.mail.example.com

メール用DANE：SMTPをどのように保護するか

DANEは、送信サーバーが受信サーバーの証明書の真正性を確認するのを支援します。この確認により、STARTTLSのダウングレード攻撃や中間者攻撃を防ぐことができ、SMTP通信のセキュリティ確保に寄与します。

DANEは電子メールの送信においてTLSを強制するため、メッセージが平文で送信されたり、転送中に改ざんされたりするのを防ぎます。

DANEにDNSSECが必要な理由

DANEは、DNSレコードの完全性に完全に依存しています。DNSSECがなければ、TLSAレコードが偽装される可能性があり、攻撃者がクライアントを悪意のある証明書へとリダイレクトしてしまう恐れがあります。この依存関係は次のように機能します。DNSSECは暗号鍵を使用してDNS応答に署名します。これにより、クライアントは応答が改ざんされておらず、データが真正であることを確認できます。したがって、DNSSECがなければ、DANEは実質的なセキュリティ上の利点を提供しません。

DANEは誰が利用していますか？

DANEの導入状況は世界的にばらつきがあり、欧州の政府機関や米国の組織での導入率が最も高い。電子メールの機密性が極めて重要とされる分野では、導入が進んでいる。DANEの主な利用者は以下の通りである：

• 認証とセキュリティの層としてのメール管理者
• 欧州諸国および米国の政府機関は、公共部門における電子メール通信のセキュリティを確保するために（例：ドイツのT-OnlineはDANEを実際に導入している企業の一つである）
• ComcastやProtonmailなどのメールプロバイダー
• マイクロソフトは、2024年7月よりDANEインバウンドSMTPのサポートを開始すると発表した。

DANEとMTA-STS：その違いは？

DANEもMail Transfer Agent – Strict Transport Security（MTA-STS）も、SMTP接続のセキュリティを確保するために設計されていますが、採用している信頼モデルは異なります。MTA-STSはHTTPSと認証局（CA）に依存しているのに対し、DANEはDNSSECとDNSに依存しています。両者の主な違いは以下の通りです：

MTA-STSについて詳しく知りたい方は、「MTA-STSとは」の完全ガイドをご覧ください。ご自身のドメインでMTA-STSを実装する方法については、MTA-STS実装ガイドをご参照ください。

TLS-RPTがDANEおよびMTA-STSと連携して機能する仕組み

TLS-RPTは、DANEやMTA-STSの設定ミスに起因するTLSネゴシエーションの失敗や配信の問題を可視化するレポートプロトコルです。TLS-RPTは、DANEやMTA-STS（セキュリティ層）の上に構築された可視化レイヤーと捉えることができます。DANEもMTA-STSも、電子メールの送信を保護するためにTLSの適用を支援しますが、配信がいつ、なぜ失敗するのかという点については、明確さに重大な欠如があります。

そこでTLS-RPTの出番となります。SMTP TLSレポート（TLS-RPT）プロトコルは、以下の内容について、受信サーバーに対して毎日の集計フィードバックレポートを送信します：

• TLSネゴシエーションの失敗
• 証明書の検証に関する問題
• ポリシーの不一致（MTA-STS または DANE）
• TLSの強制適用による配信失敗

ドメインにDANE/TLSAレコードがあるか確認する方法

DANEの設定を確認するには、以下の点を確認する必要があります：

• お使いのメールサーバーにTLSAレコードが存在するか
• DNSSECが有効かつ有効期限内かどうか
• 証明書がTLSAレコードと一致するか

PowerDMARCの無料DANEレコードチェッカーを使えば、設定をすばやく確認できます。

電子メール向けにDANEを実装する方法

メールにDANEを導入するには、以下の手順に従ってください：

手順 1: DNSSEC を有効にする

DANEはDNSSECなしでは機能しないため、まずはDNSプロバイダーまたはレジストラを通じてDNSSECを設定する必要があります。当社のDNSSECチェッカーツールを使用すれば、お使いのドメインでDNSSECがすでに設定されているかどうかを確認できます。

ステップ 2: TLS 証明書データを取得する

メールサーバーから証明書または公開鍵のハッシュ値を抽出してください。

ステップ3：TLSAレコードを作成する

正しい使用方法、セレクター、および照合タイプを定義し、適切なサブドメインの下にTLSAレコードを公開してください。

ステップ4：レコードの検証

当社のDANEチェッカーツールを使用して、レコードが正しく設定されており、DNSSECが正常に機能していることを確認してください。

ステップ5：証明書の変更を監視する

TLS証明書が更新または変更された場合は、TLSAレコードを更新する必要があります。これを怠ると、メールの配信に支障をきたす可能性があります。

まとめ

まだMTA-STSを使用してメールのトランスポート層のセキュリティ対策を実施していない場合は、DANEが最適な第一歩となるでしょう。特に金融機関や公的機関など、機密データを扱う分野においては、メッセージの傍受を防ぐためのセキュリティ対策が極めて重要です。

ただし、DANEでは、ご自身のドメイン名を利用したなりすましやフィッシング攻撃を防ぐことはできません。そのためには、DMARCが不可欠です。メール認証を最初から最後まで包括的に管理できるフルスタックのドメインセキュリティスイートをお探しですか？今すぐ当社のエキスパートによるデモをご予約ください。

よくあるご質問

DANEはDNSSECと同じものですか？

いいえ、DANEとDNSSECは同じものではありませんが、DANEが機能するためにはDNSSECが必要です。DNSSECはDNSレコードのセキュリティを確保するものであり、一方、DANEはDNSSECを利用して証明書情報を安全に公開するものです。

DANEとMTA-STSの両方が必要ですか？

必ずしもそうとは限りませんが、両方を併用することで、より幅広い互換性と強力な保護が得られます。全体として、MTA-STSの採用率はDANEよりも高くなっています。

DANEはSPF、DKIM、またはDMARCに取って代わるものですか？

いいえ。DANEはトランスポート層のセキュリティを確保する一方、SPF、DKIM、DMARCは電子メールの認証となりすまし防止を担当します。包括的な電子メールセキュリティを実現するには、これらすべてのプロトコルを組み合わせた多層的なアプローチに加え、継続的な監視と更新が不可欠です。

TLSAの記録に誤りがあった場合はどうなりますか？

TLSAレコードに誤りがある場合、DANEを適用しているメールサーバーは接続を拒否します。これにより、メールの配信に失敗する可能性があります。問題のトラブルシューティングを行うには、DANEの設定（TLSAレコードの有効性を含む）を確認することが重要です。

どのメールプロバイダーがDANEに対応していますか？

DANEへの対応状況は世界各国でまちまちです。一部の欧州のプロバイダーやセキュリティ重視の組織ではこれを義務付けていますが、世界的な普及はまだ限定的です。

• について
• 最新記事

Ahona Rudra

ドメインおよびメールセキュリティの専門家（所属： PowerDMARC

AhonaはPowerDMARCのマーケティングマネージャーで、サイバーセキュリティのトピックについて5年以上の執筆経験があり、ドメインと電子メールのセキュリティを専門としている。ジャーナリズムとコミュニケーションの卒業後学位を取得し、2019年からセキュリティ分野でキャリアを固めている。

最新記事 by Ahona Rudra(全て見る)

• 2026年のベストDMARC MCPサーバー：メール認証データにAIを活用しよう - 2026年7月9日
• DMARC MSP 事例紹介：The Great Geek、PowerDMARCを活用して中小企業向けメールセキュリティサービスを拡充 - 2026年6月25日
• 「メールなりすましサービス（Spoofing-as-a-Service）」の仕組みと対策 - 2026年6月24日