Microsoft 365 Exchange Onlineで始めるSMTP DANEデーン

メール転送経路の中間者攻撃・ダウングレード攻撃をDNSSECとTLSAレコードで防ぐ

2026年3月19日
著者: 竹洞 陽一郎

SMTP DANEデーン（DNS-based Authentication of Named Entities）は、メールサーバー間の転送経路を守る認証技術です。
（RFC 7672）。
DNSレコードの改竄を防ぐDNSSECと、サーバー証明書の正当性をDNSで公開するTLSAレコードを組み合わせることで、中間者攻撃（MITM）やTLSのダウングレード攻撃を防ぎます。

主要なメールサービスの中でExchange Onlineが初めてSMTP DANEに対応しました。
送信DANEは2022年3月に、受信DANEは2024年10月に一般提供（GA）が開始されています。
本ページでは、Exchange Onlineの管理者が実際に設定する手順を中心に解説します。

1. Exchange OnlineにおけるSMTP DANEの役割分担

Exchange OnlineでのSMTP DANEには、「送信」と「受信」の2つの側面があり、必要な作業量が大きく異なります。

Exchange Onlineからメールを送信する際のDANE検証は、追加設定なしで全テナントが恩恵を受けています。
宛先ドメインがDANE対応していれば、自動的にTLSAレコードを照合してから送信します。

DNSSECはどちらの側に必要か

SMTP DANEの効果を得るためには、保護したい方向に応じて異なるドメインのDNSSECが必要です。

送信側のDANE効果は、宛先ドメインがDNSSECとTLSAレコードを正しく設定して初めて発揮されます。
宛先がDNSSECを有効にしていない場合、TLSAレコードが信頼できないためDANE検証はスキップされ、通常のOpportunistic TLSで送信されます。
SMTP DANEの普及には、ビジネスパートナー側の対応も重要です。
メールをやり取りする取引先にSMTP DANEの導入を促すことで、双方向の保護が実現します。

2. Microsoftが先行対応した背景と意義

Exchange OnlineがSMTP DANEに対応したことは、単なる機能追加にとどまらず、企業間メールのセキュリティ水準を底上げする出来事です。
GmailなどのコンシューマーサービスがまだDANEに対応していない中で、エンタープライズ向けサービスのMicrosoftが先行したことには明確な理由があります。

対応の経緯

Microsoftが先行した理由

Exchange Onlineは世界の企業向けメール市場で圧倒的なシェアを持ちます。
送信側のDANEをデフォルトで全テナントに有効化したことは、「世界の企業間メールトラフィックの大部分が、DANE検証を行う送信者になった」ことを事実上意味します。
個々の企業が意識しなくても、Exchange Onlineを使っている時点で送信DANEの恩恵を受けています。

Googleがまだ対応していない中でMicrosoftが先行した背景には、エンタープライズ市場を主戦場とするMicrosoftならではの判断があると考えられます。
金融・医療・製造といった機密性の高い情報をメールでやり取りする企業顧客に対して、転送経路の完全性を保証することは、クラウドサービスへの信頼を裏付ける競争上の差別化にもなります。

サプライチェーン攻撃への効果

サプライチェーン攻撃においてメールが悪用されるパターンは主に2つあります。

差出人偽装

取引先になりすましたメールを送る。
SPF・DKIM・DMARCで対処できる。

転送経路での改竄

本物のドメインから送られたメールを、転送途中で書き換える。
SPF・DKIM・DMARCでは検出できない。

後者の典型例がBEC（ビジネスメール詐欺）です。
仕入れ先から届く請求書メールの振込口座番号が転送経路で書き換えられ、送金先が攻撃者の口座にすり替えられる手口は、国内外で多数の被害が報告されています。
SMTP DANEが普及すると、この転送経路での改竄リスクが大幅に低下します。

Exchange Online同士ではすぐに双方向DANEが成立する

送信側のDANEはExchange Onlineが自動対応済みです。
受信側（自社ドメイン）が本ページの手順でDANEを有効化すれば、Exchange Online同士のメールやり取りで双方向のDANE保護が即座に成立します。
Microsoft 365を使う企業が取引先も多くMicrosoft 365であれば、比較的容易に双方向DANEを実現できます。
これはMicrosoftのエンタープライズ顧客基盤がもたらすネットワーク効果です。

Googleがいずれ対応した際には、GmailとExchange Online間でも双方向のDANE保護が成立することになります。
SMTP DANEは今後の企業間メールセキュリティの標準となる可能性が高く、早期に受信側の設定を整えておくことが推奨されます。

3. SMTP DANEで何が良くなるのか

SPF・DKIM・DMARCは「差出人のなりすまし」を防ぐ技術ですが、メール転送経路そのものは守れません。
SMTPはもともとセキュリティを前提とせず設計されており、現在のTLS暗号化（Opportunistic TLS）にも強制力がなく、ダウングレード攻撃・DNS詐称・中間者攻撃（MITM）に対して脆弱なままです。
SMTP DANEが追加で防ぐのは、転送経路を狙った以下の3つの攻撃です。

MXレコードの乗っ取り

DNSキャッシュポイズニングなどでMXレコードを書き換えられると、攻撃者のサーバーにメールが届いてしまいます。
SPF/DKIM/DMARCはこれを検出できません。
DANEがあれば、送信側が接続前にTLSAレコードと証明書を照合するため、偽サーバーへの誘導を検知して配送を拒否します。

TLSダウングレード攻撃

STARTTLSコマンドは平文で送信されるため、経路上の攻撃者がこのコマンドを改竄し、送信側を平文通信に誘導することができます。
DANE（またはMTA-STS）はTLSを強制するため、暗号化なしでの配送を拒否します。

中間者攻撃による盗聴・改竄

TLSで暗号化されていても、証明書の検証がなければ攻撃者が偽の証明書を使って通信に割り込めます。
DANEはDNSSECで保護されたTLSAレコードと証明書を照合するため、偽の証明書を使ったMITM攻撃を防ぎます。

これらの攻撃は現在も使われているか？

はい、いずれも現在進行形の脅威です。

DNSキャッシュポイズニング

2025年10月にBIND 9（世界で最も広く使われているDNSサーバーソフトウェア）にCVSSスコア8.6の脆弱性（CVE-2025-40778・CVE-2025-40780）が公開され、攻撃者がDNSキャッシュに偽のレコードを注入できることが判明しています。
また2024年には国家系アクターがDNSスプーフィング能力を悪用したサイバースパイ活動を世界規模で展開したと報告されています。

TLSダウングレード攻撃

USENIX 2021のセキュリティカンファレンスで発表された研究でSTARTTLSの実装に40以上の脆弱性が発見され、接続を平文に落とす攻撃やメール内容の改竄が実証されています。

MITMによる改竄

Microsoftが公式に「ダウングレード攻撃によってSTARTTLSレスポンスが削除されメッセージが平文になること、および攻撃者のサーバーにメールを誘導するMITM攻撃が可能であること」を認めたうえで、MTA-STSとSMTP DANEへの対応を進めた経緯があります。

関連技術との位置づけ

各技術が「何を守るか」を整理すると以下のようになります。

SPF・DKIM・DMARCが「偽の差出人からのメールを防ぐ」のに対し、SMTP DANEは「正規のメールが安全に届く経路を確保する」役割を担います。
両者は補完関係にあり、組み合わせて使うことで多層防御が実現します。

4. メールセキュリティ成熟度モデル

メールセキュリティは、導入している技術の組み合わせによって段階的に成熟度が上がります。
以下はSpelldataが定義するレベル分類です。
自社のドメインが現在どのレベルにあるかを確認し、次のステップへの参考にしてください。

Level 4（BIMI）とLevel 5（SMTP DANE）は独立しており、どちらを先に実装しても構いません。
BIMIは視覚的認証認知、SMTP DANEは転送経路の保護という役割の違いがあります。
Level 2をベースに、両方を目指すことを推奨します。

5. 受信側の設定手順：DNSSEC + SMTP DANEを有効化する

Exchange Onlineで自ドメイン宛のメールをDANEで保護するには、以下の手順を順番に実施します。
Exchange Online PowerShellへのアクセス権限が必要です。

前提：DNSSECの信頼チェーンと作業の全体像

受信DANEを有効化したときのDNS構造は以下のようになります。

contoso.com.  MX  0  contoso-com.o-v1.mx.microsoft.        ← 顧客のDNSゾーン
_25._tcp.contoso-com.o-v1.mx.microsoft.  TLSA  3 1 1 ...   ← Microsoftのゾーン

送信側メールサーバーがDANE検証を行う際、この2段階を順番に検証します。
TLSAレコード（下段）はMicrosoftが管理・署名するゾーンにあるため、Microsoft側のDNSSECは自動で完結します。

問題はMXレコード（上段）です。
これは顧客のDNSゾーンに置かれるため、そのゾーン自体がDNSSECで署名されていないと、MXレコードの真正性が保証されず、DANE検証の信頼チェーンが途切れます。

MXレコードの変更を伴う作業です。
既存のTTL値が大きい場合は切り替えに時間がかかります。
MTA-STSを使用している場合は、先にポリシーモードを「test」に変更し、現在のmax_age設定値の時間だけ待機してから作業を開始してください。
（enforceモードでmax_ageを最大値の31,536,000秒＝1年に設定している場合は特に注意が必要です）

1. DNSレジストラーで自社ドメインのDNSSECを有効化する

まずDNSレジストラーの管理画面で、対象ドメインのDNSSECを有効にします。
これにより自社のDNSゾーンが暗号学的に署名され、DANE信頼チェーンの起点が確立されます。
DNSSECの伝播には最大48時間かかる場合があります。
DNSレジストラーがDNSSECに対応していない場合、このあとの手順は実施できません。
DNSSECの伝播完了を待たずにステップ2（MXレコードのTTL変更）に進んでも構いません。
DNSSECとMXレコードの変更は独立した作業です。
ただし最終的にDANE検証が正常に動作するためには、DNSSECの伝播が完了している必要があります。

2. 既存MXレコードのTTLを最小値（30秒以下）に下げる

変更前のTTLが1時間（3600秒）であれば、TTLを下げた後に1時間待機してから次のステップに進みます。

3. Exchange OnlineのDNSSECインフラをプロビジョニングする

以下のコマンドを実行します（contoso.com を実際のドメイン名に置き換えてください）。

Enable-DnssecForVerifiedDomain -DomainName contoso.com

成功すると DnssecMxValue が返されます（例：contoso-com.o-v1.mx.microsoft）。
この値が、新しいMXレコードの向き先になります。
このコマンドはDNSレジストラー側のDNSSEC設定とは独立したMicrosoft側のプロビジョニング処理です。

4. 新しいMXレコードを追加する（優先度20、TTL 30秒以下）

DNSレジストラーの管理画面で、手順3で得た DnssecMxValue の値を使って新しいMXレコードを追加します。
既存のMXレコード（mail.protection.outlook.com で終わるもの）はこの時点ではまだ残します。

5. 新しいMXレコードの動作確認

Microsoft Remote Connectivity Analyzer（受信SMTPテスト）で、mx.microsoft で終わるMXレコードが正常に動作していることを確認します。
DNSキャッシュによっては再試行が必要な場合があります。

6. MXレコードの優先度を切り替える

新しいMXレコード（mx.microsoft で終わるもの）を優先度0（最高優先）に変更します。
既存のMXレコードは優先度30に下げます。

7. 旧MXレコードを削除し、TTLを3600秒に戻す

mail.protection.outlook.com（または mail.eo.outlook.com）で終わる旧MXレコードを削除します。
新しいMXレコードのTTLを3600秒に更新します。

8. SMTP DANEを有効化する

DNSSECの有効化が完了したら、引き続き同じドメインに対してSMTP DANEを有効化します。

Enable-SmtpDaneInbound -DomainName contoso.com

TLSAレコードの伝播には15〜30分程度かかります。
Microsoft Remote Connectivity Analyzerの「DANE検証（DNSSECを含む）」で確認できます。

Exchange Onlineは、SMTP DANE検証の信頼性を高めるために複数のTLSAレコードをホストします。
一部のTLSAレコードが検証に失敗しても、1つでも検証を通過すれば正しく動作しています。

6. TLSAレコードとは（Exchange Online管理者が知っておくべき最低限）

Exchange OnlineではTLSAレコードの内容はMicrosoft側が自動的に設定するため、管理者がTLSAレコードを手動で作成する必要はありません。
ただし、送信エラー発生時の読み解きに必要な知識として構造を説明します。

TLSAレコードは次の4フィールドで構成されます。

<使用法> <セレクタ> <照合型> <証明書関連データ>

RFC実装ガイダンスでの推奨構成は 「3 1 1」 です。
Exchange Onlineもこの組み合わせを前提として動作します。

7. 問題が発生したときの切り戻し手順

受信メールフローに問題が発生した場合、以下のコマンドで個別に無効化できます。

Disable-SmtpDaneInbound -DomainName contoso.com

Disable-DnssecForVerifiedDomain -DomainName contoso.com

8. 送信時のエラーコードと対処法

Exchange Onlineから外部ドメインへの送信がDANEエラーで失敗した場合、以下のNDRコードが返されます。
いずれも宛先側の設定問題であり、宛先ドメインの管理者へ連絡して対処を依頼することになります。

現時点では、宛先ドメインがDNSSECをサポートしていることを宣言しながらDNSSECチェックに失敗した場合、4/5.7.324 ではなく汎用的な 4/5.4.312 DNS query failed が返されるケースがあります（Microsoftの既知の制限）。
このエラーが出た場合は、Microsoft Remote Connectivity AnalyzerでDANE検証テストを実行し、DNSSECの問題か否かを切り分けてください。

9. よくある質問

Q. テナント全体でDANEをオプトアウトできますか？

できません。
Exchange Onlineの送信DANEはすべてのテナントに適用されており、テナントレベルの例外は提供されていません。
Microsoftは、ほとんどのエラーは宛先側の設定問題であるとしています。

Q. MTA-STSとDANEは併用すべきですか？

はい、併用を強く推奨します。
両者は役割がほぼ同じに見えますが、信頼の根拠と守れる範囲が異なるため補完関係にあります。

DANEがあってもMTA-STSが必要な理由

送信側がDANEに対応していない場合、受信側がDANEを設定していても効果がありません。
現時点でDANEに対応している送信側はExchange Onlineなど一部に限られます。
MTA-STSはDNSSECが不要で導入が容易なため、DANEに未対応の送信側からのメールに対してもTLS強制とダウングレード防止が機能します。

MTA-STSがあってもDANEが必要な理由

MTA-STSはパブリックCAを信頼の根拠にしています。
CAが侵害された場合（過去にも複数の事例があります）、偽の証明書が発行されてMITM攻撃が成立する可能性があります。
DANEはCAに依存せずDNSSECで証明書を検証するため、この弱点を補います。

MTA-STSは「DANEに未対応の送信者も含めて広くカバー」し、SMTP DANEは「CAに依存しない強い保証強度」を提供します。
両方を設定することで、対応している送信者には強い保証、未対応の送信者に対してもTLS強制という多層防御が実現します。
なお、MTA-STSとDANEを同時に設定する場合は、作業の前後にMTA-STSポリシーを「test」モードにする手順が必要です。

Q. DANEの受信設定は、どのドメインに適用できますか？

MXレコードがExchange Onlineを向いており、DNSSECを有効化できるドメインに適用できます。
onmicrosoft.com ドメインおよびセルフサービスサインアップ形式のドメインは現時点では非対応です。
サードパーティのメールゲートウェイを経由する構成の場合は、そのゲートウェイ自体がDNSSEC検証付きのSMTP DANEをサポートしているかを確認する必要があります。

Q. TLS-RPTとは何ですか？

TLS Reporting（RFC 8460）は、DANEやMTA-STSの成功・失敗を送信者から受け取るレポート機能です。
以下のようなDNS TXTレコードを追加することで受信できます。

_smtp._tls.example.com. IN TXT "v=TLSRPTv1;rua=mailto:tlsrpt@example.com"

PowerDMARCをご利用の場合は、ホスト型MTA-STSを設定すると、この設定も含まれており、TLSレポートも受信できます。

Q. SMTP DANEを実装すると、メールの到達率やレピュテーションが上がりますか？

現時点では、GmailやYahooのフィルタリングアルゴリズムにおいてSMTP DANEは評価シグナルとして使われておらず、到達率やレピュテーションへの直接的な効果は確認されていません。
SMTP DANEは「送信元の信頼性」ではなく「転送経路の安全性」を担保する技術であり、レピュテーション評価とは別のレイヤーです。
ただし、以下の間接的・将来的な効果は期待できます。

特に重要なのは「MX乗っ取りによるドメイン評判毀損の防止」です。
自社ドメインのMXレコードが乗っ取られてスパム配信に悪用されると、ドメインレピュテーションが深刻なダメージを受けます。
DANEでMX乗っ取りを防ぐことは、レピュテーション保護の観点からも有効です。

Q. Google WorkspaceはSMTP DANEに対応していますか？

現時点では、Google WorkspaceはSMTP DANEに対応しておらず、公式な実装計画も発表されていません。
GoogleはMTA-STSをサポートしており、DANEの代わりにMTA-STSによる転送経路の保護を推進しています。

ただし部分的な対応は進んでいます。
GoogleはDNSSEC署名済みのMXレコード（mx1〜4.smtp.goog）を提供しており、このMXレコードを使用するよう設定することでDNSSECの恩恵は得られます。
しかしTLSAレコードは公開されておらず、DANE検証には対応していません。

Googleが対応していない主な理由として、GmailはコンシューマーサービスとしてMTA-STSで十分と判断している可能性があること、またDANEの実装にはMicrosoftが行ったような大規模なDNSインフラ再設計が必要で、優先度が低い状態にあると考えられます。

現時点でSMTP DANEの送信側効果が最大限に発揮されるのは、宛先がExchange Onlineを含むDANE対応サービスの場合です。
Googleがいずれ対応した際には、GmailとExchange Online間の双方向DANE保護が成立し、企業間メールセキュリティが大きく前進することになります。
DANEへの早期対応はその準備でもあります。

関連情報

• RFC 7672 – SMTP Security via Opportunistic DANE TLS
• RFC 8461 – SMTP MTA Strict Transport Security (MTA-STS)
• RFC 8460 – SMTP TLS Reporting (TLS-RPT)
• Microsoft Remote Connectivity Analyzer
• メールを送信しないドメインの防御設定