Exchange Online mail flow securityを担当する管理者が今回まず押さえるべき結論は、DNSSEC・SMTP DANE・MTA-STSが、Exchange Onlineのメール配送設計でより現実的な運用テーマになったという点です。2026年4月23日にMicrosoftが公開した更新では、DNSSEC有効化ウィザードの予定、送信コネクタ単位のDANE/MTA-STS制御、mail.protection.outlook.comの扱い、mx.microsoftへの移行計画の見直しが示されました。(TECHCOMMUNITY.MICROSOFT.COM)
ただし、これは「すべての組織が今すぐMXを切り替えるべき」という意味ではありません。security admins、identity teams、compliance teamsが最初にやるべきことは、Accepted Domain、MXレコード、MTA-STSポリシー、Outbound connector、サードパーティメールゲートウェイの依存関係を棚卸しし、どのドメインからDNSSEC/SMTP DANE対応を進めるかを決めることです。
Exchange Online mail flow securityの2026年4月更新で押さえるべきこと
今回のMicrosoft公式ブログ「Exchange Online modernizes DNS security for mail flow」は、Exchange OnlineのメールフローにおけるDNSセキュリティ近代化の進捗を整理したものです。DNSは標準では暗号化・認証されないため、なりすまし、改ざん、中間者攻撃のリスクがあり、MicrosoftはDNSSEC、SMTP DANE、MTA-STSを使って、検証済みかつ改ざんに強いメール配送を広げる方針を示しています。(TECHCOMMUNITY.MICROSOFT.COM)
| 更新ポイント | 予定・状態 | 管理者への意味 |
|---|---|---|
| DNSSEC Enablement Wizard | 2026年Q3予定 | Exchange Admin CenterでDNSSEC有効化の導入作業をガイドし、MX移行時の設定ミスを減らす狙いがあります。SMTP DANEの完全な有効化は、DNSSEC有効化後もPowerShellが選択肢として残ります。(TECHCOMMUNITY.MICROSOFT.COM) |
| Outbound connector単位のDANE/MTA-STS制御 | 2026年2月下旬からロールアウト開始 | MtaStsModeとSmtpDaneModeにより、送信コネクタごとに検証の厳格さを調整できます。既定はOpportunisticです。(TECHCOMMUNITY.MICROSOFT.COM) |
| DNSSEC対応メールフローレコードの自動プロビジョニング | 2026年下半期へ延期 | 新しいAccepted DomainのAレコードをmx.microsoft配下へ段階的に切り替える計画は継続していますが、当初想定より遅れています。(TECHCOMMUNITY.MICROSOFT.COM) |
mail.protection.outlook.comのDNSSEC対応 | 現時点で予定なし | 受信メールでDNSSECを必要とする場合は、DNSSEC対応のmx.microsoft専用サブドメインへ移行する必要があります。(TECHCOMMUNITY.MICROSOFT.COM) |
mail.protection.outlook.comのTCP/EDNS対応 | 2026年Q3初期予定 | DNS応答の信頼性向上と、将来のセキュリティ拡張の土台として位置づけられています。(TECHCOMMUNITY.MICROSOFT.COM) |
重要なのは、Exchange Online mail flow securityの焦点が「迷惑メール対策」や「認証ヘッダー」だけではなく、メールサーバーを見つけるDNSレイヤーそのものの信頼性に広がっていることです。SPF、DKIM、DMARCが送信者認証に関わるのに対し、DNSSECやSMTP DANEは、相手のメールサーバー情報やTLS証明書の正当性を検証する領域を担います。(Microsoft Learn)
DNSSEC・SMTP DANE・MTA-STSは何を守るのか
Exchange Onlineの更新を正しく判断するには、DNSSEC、SMTP DANE、MTA-STSの違いを押さえる必要があります。名前が似ていますが、守る対象は同じではありません。
| 技術 | 主な役割 | 実務上の見方 |
|---|---|---|
| DNSSEC | DNSレコードが改ざんされていないことを暗号学的に検証する | MXやA/AAAAなど、メール配送に使うDNS情報の信頼性を高める |
| SMTP DANE | TLSAレコードを使い、接続先メールサーバーの証明書が期待どおりかを検証する | DNSSECを前提に、TLSのダウングレードや不正なMX誘導に対抗する |
| MTA-STS | HTTPSで公開されたポリシーにより、TLS必須化や期待するMXホストを送信側に伝える | DNSSECなしでも使えるが、ポリシーファイルとHTTPS証明書の運用が必要 |
Microsoft Learnでは、SMTP DANEはTLSAレコードを使ってドメインとメールサーバーがDANEをサポートしていることを示し、DNSSECに依存してDNSレコードの正当性を確認すると説明されています。Exchange Onlineでは、宛先ドメインがDNSSECを示しているのにレコードが真正でない場合や、TLSAレコードと証明書が一致しない場合などに配送がブロックされる可能性があります。(Microsoft Learn)
一方、MTA-STSは、メールサーバー間でTLSを常に使うこと、受信側サーバーの証明書が信頼できることを送信側が検証するための仕組みです。Exchange OnlineからMTA-STS対応ドメインへ送信する場合、送信側のExchange OnlineはMTA-STSの検証を行います。スマートホストを使うOutbound connectorでは、最終宛先ドメインではなくスマートホストドメインに対してMTA-STS検証が行われる点に注意が必要です。(Microsoft Learn)
影響を受けやすい組織
今回の更新は、Exchange Onlineを使うすべての組織に関係しますが、特に影響が大きいのは次のような環境です。
| 環境 | 影響度 | 確認すべきこと |
|---|---|---|
| 独自ドメインを複数持つMicrosoft 365テナント | 高 | Accepted DomainごとのMX、DNSSEC対応状況、DNS管理者の責任範囲 |
| 海外拠点や買収企業のドメインを統合している組織 | 高 | レジストラ、DNSホスティング、MTA-STSポリシー、メールゲートウェイの差異 |
| サードパーティのメールセキュリティゲートウェイを受信経路に置く組織 | 高 | ゲートウェイからExchange Onlineへの配送経路がDANE/DNSSECを使えるか |
| 特定パートナー向けOutbound connectorを使う組織 | 中〜高 | SmtpDaneModeとMtaStsModeを厳格化できる相手か |
| MXレコード作成を自動化しているMSP・大規模IT部門 | 高 | mail.protection.outlook.com固定の前提が残っていないか |
過去のMicrosoftの案内では、将来的なmx.microsoft配下への移行に備え、MXの自動プロビジョニングでmail.protection.outlook.comを固定参照しないこと、Microsoft Graph APIのserviceConfigurationRecordsなどで正しいmailExchange情報を取得することが推奨されていました。2026年4月の更新で自動プロビジョニングの切り替え時期は後ろ倒しになりましたが、方向性自体は変わっていません。(TECHCOMMUNITY.MICROSOFT.COM)
管理者が今すぐ確認すべきメールフロー設定
Accepted DomainとMXレコードを棚卸しする
最初に確認すべきなのは、Microsoft 365テナントに登録されているAccepted Domainと、そのドメインのMXレコードです。DNSSEC/SMTP DANE対応はドメイン単位で進めるため、「代表ドメインだけ把握している」状態では変更計画を立てられません。
確認すべき項目は次のとおりです。
| 確認項目 | 見るべきポイント |
|---|---|
| Accepted Domainの一覧 | 本番利用、旧ブランド、海外拠点、買収企業ドメインを含める |
| 現在のMX参照先 | mail.protection.outlook.comか、mx.microsoft配下か |
| MXの優先度 | 余計なフォールバックMXや同一優先度のMXがないか |
| DNSSEC対応 | DNSプロバイダー側でDNSSECを有効化できるか |
| TTL | 切り替え時に短縮できるか。低くしすぎる場合はDNS事業者の制限も確認する |
| DNS変更の承認者 | security adminsだけでなく、identity teamsやドメイン管理者の承認が必要か |
Microsoft Learnの手順では、受信SMTP DANE with DNSSECの前提として、対象ドメインがAccepted Domainとして追加され、Microsoft 365管理センターでHealthyであること、DNSSECを有効化すること、Exchange Online PowerShellを使える権限があることが示されています。(Microsoft Learn)
MTA-STSポリシーを確認する
MTA-STSをすでに使っている場合、MX変更時の最大の落とし穴は、ポリシーファイル内のmx:行が古いMXを指したままになることです。Microsoft Learnでは、MTA-STSポリシーを変更した後はTXTレコードのidを更新しないと、送信側がキャッシュ済みポリシーを使い続ける可能性があると説明されています。(Microsoft Learn)
DNSSEC/SMTP DANE移行中は、MTA-STSをenforceのままにしてMXだけを変更すると、外部送信者からの配送に影響が出る可能性があります。Microsoftの手順でも、MTA-STS利用時は移行作業中にポリシーモードをtestingへ変更し、ポリシーIDを更新してmax_ageの期限を考慮する流れが示されています。(Microsoft Learn)
Outbound connectorを確認する
2026年4月更新で実務的に重要なのが、Outbound connector単位でSMTP DANEとMTA-STSの検証モードを制御できる点です。Set-OutboundConnectorにはMtaStsModeとSmtpDaneModeがあり、Microsoft Learnでは、MTA-STSはOpportunisticまたはNone、SMTP DANEはOpportunistic、Mandatory、Noneを指定できると説明されています。(Microsoft Learn)
まずは既存コネクタを一覧化し、どのコネクタがパートナー宛て、オンプレミス宛て、スマートホスト宛てなのかを分けてください。
Get-OutboundConnector |
Format-Table Name, ConnectorType, RecipientDomains, UseMXRecord, SmartHosts, SmtpDaneMode, MtaStsMode次に、例外的にNoneが設定されていないかを確認します。Noneは互換性のための逃げ道ですが、DANE/MTA-STSによるダウングレード攻撃や不正なMXリダイレクトへの保護を外す設定です。Microsoft Learnでも、Noneはメールのセキュリティを低下させる可能性がある設定として説明されています。(Microsoft Learn)
サードパーティゲートウェイの経路を分けて考える
受信経路にサードパーティのメールセキュリティゲートウェイがある場合、「インターネット → ゲートウェイ」と「ゲートウェイ → Exchange Online」は別の配送区間です。Microsoft Learnでは、サードパーティゲートウェイを使う構成では、そのゲートウェイがSMTP DANE with DNSSEC検証をサポートしている場合に、ゲートウェイからExchange Onlineへの区間を保護できると説明されています。(Microsoft Learn)
このため、単にExchange Online側でDNSSEC/SMTP DANEを有効化しても、外部送信者からゲートウェイまでの経路が同じように保護されるとは限りません。ゲートウェイ事業者に、DANE、DNSSEC、MTA-STS、TLS-RPTの対応範囲を確認し、契約・SLA・監査証跡に反映する必要があります。
DNSSEC/SMTP DANEをどのドメインから進めるべきか
DNSSEC/SMTP DANEはセキュリティ価値が高い一方で、DNS、証明書、MTA-STS、メールゲートウェイが絡むため、全ドメイン一括移行よりも段階導入が現実的です。
| 優先度 | 対象ドメイン | 理由 |
|---|---|---|
| 高 | 役員、法務、財務、顧客連絡に使う主要ドメイン | なりすましや通信経路の改ざんが事業リスクに直結する |
| 高 | 規制業界・監査対象の業務ドメイン | メール配送の暗号化・認証強化を統制証跡として説明しやすい |
| 中 | 海外拠点やグループ会社のドメイン | DNS管理者やレジストラが分散しており、事前調整が必要 |
| 中 | パートナー専用コネクタで配送するドメイン | 相手側のDANE/MTA-STS対応状況に応じて厳格化しやすい |
| 低 | 廃止予定、受信量が少ない、用途が限定的な旧ドメイン | まずは棚卸しと廃止判断を優先する |
判断基準は「技術的に有効化できるか」だけではありません。失敗時にどの業務メールが止まるか、DNS変更を誰が承認するか、海外拠点の時差を考慮して作業できるか、監査チームにどの証跡を残すかまで含めて決めるべきです。
受信側DNSSEC/SMTP DANE有効化の作業イメージ
DNSSEC Enablement Wizardが2026年Q3に予定されているため、将来的にはExchange Admin Center上での導入が進めやすくなる見込みです。ただし、MicrosoftはDNSSEC有効化後にSMTP DANEを完全に有効化する場合、PowerShellが引き続き選択肢になると説明しています。(TECHCOMMUNITY.MICROSOFT.COM)
現在のMicrosoft Learnの手順を踏まえると、作業の流れはおおむね次のようになります。実際の本番作業では、対象ドメイン、DNSプロバイダー、MTA-STS利用有無、サードパーティゲートウェイの有無に合わせて変更計画を作成してください。
| 手順 | 作業 | 失敗しやすいポイント |
| -: | ——————————————– | ————————————– |
| 1 | 対象ドメインのAccepted Domain状態を確認する | Microsoft 365上でHealthyでないドメインを対象にしてしまう |
| 2 | 既存MXのTTLを短くし、旧TTLの期限を待つ | TTLを下げても、すぐに全世界で反映されると思い込む |
| 3 | MTA-STS利用中ならtestingへ変更し、TXTのidを更新する | max_ageの期限を待たずにMXを切り替える |
| 4 | Exchange Online PowerShellでDNSSEC対応のMX値を取得する | 返されたDnssecMxValueをメモせず、誤ったMXを登録する |
| 5 | 新しいMXを低優先度で追加し、配送テストする | いきなり旧MXを削除して受信停止リスクを作る |
| 6 | 新MXを最優先にし、旧MXを段階的に外す | 同じ優先度のMXを残して予期しない配送経路にする |
| 7 | SMTP DANEを有効化し、TLSA伝播を確認する | TLSAの一部失敗を即障害と誤解する |
| 8 | MTA-STSを検証後にenforceへ戻し、idを更新する | ポリシー更新後のキャッシュを考慮しない |
Microsoft Learnでは、Enable-DnssecForVerifiedDomainの成功時に新しいMX値が返され、その値をDNS側のMXに設定する流れが示されています。また、SMTP DANE有効化後のTLSAレコード伝播には15〜30分かかる可能性があり、Exchange Onlineは信頼性向上のため複数のTLSAレコードをホストするため、一部のTLSA検証が失敗しても少なくとも1つ通れば構成として正しいとされています。(Microsoft Learn)
PowerShellでの代表的な確認・有効化のイメージは次のとおりです。
Connect-ExchangeOnline
Enable-DnssecForVerifiedDomain -DomainName example.com
Enable-SmtpDaneInbound -DomainName example.com
Get-SmtpDaneInboundStatus -DomainName example.comこのコマンド例は流れを示すものです。本番では、DNSSECをDNSプロバイダー側で有効化できるか、MTA-STSポリシーのmx:値をどう更新するか、サードパーティゲートウェイのスマートホスト設定をどう変えるかを事前に確認してください。
送信側コネクタのDANE/MTA-STSモード選定
Outbound connectorの新しい制御は、グローバル企業や規制業界で特に使いどころがあります。すべてを厳格化するのではなく、相手先の対応状況と業務重要度でモードを分けるのが現実的です。
| モード | 対象 | 使いどころ | 注意点 |
|---|---|---|---|
| Opportunistic | SMTP DANE、MTA-STS | 既定値として使う。相手が対応していれば検証し、未対応なら通常配送する | セキュリティと到達性のバランスが良い |
| Mandatory | SMTP DANEのみ | 金融、法務、医療、政府系など、相手側がDANE/DNSSECを正しく運用している重要経路 | 相手が未対応、または検証失敗するとキュー後に配送失敗する可能性がある |
| None | SMTP DANE、MTA-STS | 一時的な互換性対応、相手側の誤設定が解消されるまでの例外 | 恒久設定にすると保護を下げるため、期限・責任者・理由を記録する |
Microsoft Learnでは、SmtpDaneMode Mandatoryは送信コネクタ経由のすべてのメールにSMTP DANE with DNSSECを強制し、宛先が未対応または検証失敗した場合にキュー後、最終的に配送失敗となる可能性があると説明されています。MtaStsMode NoneやSmtpDaneMode Noneは、検証を行わず配送を試みるため、セキュリティ低下につながる設定です。(Microsoft Learn)
設定例は次のように考えます。
Set-OutboundConnector "High Trust Partner" -SmtpDaneMode Mandatory
Set-OutboundConnector "Temporary Compatibility Exception" -SmtpDaneMode None -MtaStsMode NoneNoneを使う場合は、チケット番号、対象ドメイン、解除予定日、相手先の修正状況を記録してください。compliance teamsの視点では、「なぜ保護を下げたのか」「誰が承認したのか」「いつ戻すのか」を説明できる状態にすることが重要です。
運用監視ではTransit Security reportを見る
DANEやMTA-STSは、有効化して終わりではありません。配送失敗、TLS非対応ドメイン、検証エラーを継続的に見て、パートナーやDNS設定の問題を早めに見つける必要があります。
Exchange Admin Centerの「Outbound messages in Transit Security report」では、Exchange Onlineから送信されたメールについて、SMTP DANE、MTA-STS、Opportunistic TLSの利用状況を確認できます。レポートには、ブロックされたメッセージ、送信済みメッセージ、TLS非対応の宛先ドメインなどのセクションがあり、データには24時間の遅延があるとされています。(Microsoft Learn)
運用で見るべき指標は次の3つです。
| 指標 | 見る理由 | 次のアクション |
|---|---|---|
| Messages Blocked | DANE/MTA-STS検証失敗で配送が止まっていないかを確認する | 宛先ドメイン、エラー詳細、コネクタ設定を確認する |
| Messages SentのSecurity type | DANE、MTA-STS、TLS-only、No TLSの比率を見る | 重要パートナーをDANE/MTA-STS対応へ誘導する |
| Recipient Domains Not Supporting TLS | 平文配送が発生している宛先を把握する | 業務上必要な相手か、代替経路や契約要件を見直す |
特にMandatoryを使うコネクタでは、変更直後の24〜48時間は通常より細かく監視してください。配送失敗が出た場合、相手側DNS、TLS証明書、TLSAレコード、MTA-STSポリシー、スマートホスト設定のどこで不整合が起きているかを切り分ける必要があります。
よくある失敗と回避策
mail.protection.outlook.comにDNSSECが付くと思い込む
今回の更新で明確なのは、mail.protection.outlook.com自体にDNSSECを有効化する予定は現時点でないという点です。DNSSECを必要とする受信メールフローでは、mx.microsoft配下のDNSSEC対応サブドメインへ移行する必要があります。(TECHCOMMUNITY.MICROSOFT.COM)
既存のMXがmail.protection.outlook.comを指していること自体は直ちに障害ではありません。しかし、DNSSEC/SMTP DANEを前提にした設計へ進むなら、将来的な移行計画を持つべきです。
MTA-STSのmx:行を更新し忘れる
MXをmx.microsoft配下に変えても、MTA-STSポリシーが古い*.mail.protection.outlook.comだけを許可していると、MTA-STS対応の送信者が期待するMXと実際のMXが合わなくなる可能性があります。MTA-STSのポリシー更新では、ポリシーファイルだけでなくTXTレコードのid更新も必要です。(Microsoft Learn)
DNSの反映時間を甘く見る
DNS変更は、TTLを下げても即時に全世界で反映されるとは限りません。Microsoft Learnでも、DNSレコードのプロビジョニングや更新には時間がかかり、複数階層のキャッシュにより反映が遅れる可能性があると説明されています。(Microsoft Learn)
グローバル組織では、地域ごとに利用しているDNSリゾルバーやメールゲートウェイが異なることがあります。切り替え当日は、日本、北米、欧州など複数地域からMX解決と受信テストを行うと、地域差のある問題を見つけやすくなります。
Noneを恒久的な例外にする
Outbound connectorのNoneは、相手先の一時的な誤設定や互換性問題を回避するためには役立ちます。しかし、DANE/MTA-STS検証を無効化するため、攻撃耐性は下がります。Microsoft Learnでも、Noneはダウングレード攻撃や不正なMXリダイレクトへの保護を外し、セキュリティを低下させる可能性がある設定として説明されています。(Microsoft Learn)
例外を作る場合は、少なくとも次の情報を残してください。
| 記録項目 | 例 |
|---|---|
| 対象コネクタ | Partner-A-Outbound |
| 対象ドメイン | partner.example |
| 例外理由 | 相手側TLSAレコード不整合のため |
| 承認者 | Security owner、Business owner |
| 解除予定日 | 30日後に再評価 |
| 監視方法 | Transit Security reportとNDR確認 |
チーム別の役割分担
Exchange Online mail flow securityは、Exchange管理者だけで完結しません。DNS、ID、コンプライアンス、ネットワーク、外部パートナーが関わるため、責任分界を明確にしておく必要があります。
| チーム | 主な役割 |
|---|---|
| security admins | DANE/MTA-STSの適用方針、Outbound connectorの厳格化、例外承認、監視 |
| identity teams | Microsoft 365のVerified Domain、Accepted Domain、ドメイン所有権、DNS変更承認の管理 |
| compliance teams | 変更証跡、例外理由、監査説明、規制要件との整合性確認 |
| messaging admins | MX変更、Exchange Online PowerShell操作、メールフローテスト、NDR調査 |
| network/DNS teams | DNSSEC、TTL、レジストラ設定、ファイアウォール・ACL確認 |
| vendor management | サードパーティゲートウェイや重要パートナーのDANE/MTA-STS対応確認 |
特にcompliance teamsは、技術的な詳細をすべて理解する必要はありませんが、「どのドメインで保護を強化したか」「どの経路に例外があるか」「例外はいつ見直すか」を把握できる形にしておくと、監査対応が楽になります。
2026年4月更新後に取るべき次の一手
今回のExchange Online mail flow security更新は、DNSSEC/SMTP DANE/MTA-STS対応が本格的な運用テーマに近づいたことを示しています。とはいえ、最初にやるべきことは大規模な切り替えではなく、自社のメールフローがDNSSEC対応へ進める状態かを可視化することです。
まず、Accepted DomainとMXレコードを一覧化し、mail.protection.outlook.com固定の自動化や古いMTA-STSポリシーが残っていないか確認してください。次に、Outbound connectorのSmtpDaneModeとMtaStsModeを棚卸しし、Noneがある場合は理由と解除計画を記録します。重要ドメインについては、DNSプロバイダー、サードパーティゲートウェイ、MTA-STSポリシー、監視レポートまで含めた小さな移行計画を作るのが現実的です。
2026年Q3に予定されるDNSSEC Enablement Wizardは、導入作業のハードルを下げる可能性があります。しかし、ウィザードが出てから慌てるのではなく、いまのうちにドメイン、DNS、コネクタ、ゲートウェイ、監査証跡を整理しておくことが、Exchange Online mail flow securityを安全に強化する近道です。(TECHCOMMUNITY.MICROSOFT.COM)
コメント