```html Microsoft 365のExchange Onlineを使っている場合は「Direct Send」を無効化しましょう | MailData
Direct Send

Microsoft 365のExchange Onlineを使っている場合は「Direct Send」を無効化しましょう

要点：Direct Send（認証不要の送信経路）は、条件次第で「社内から送られたように見える」なりすましに悪用されます。Direct Sendを使っていない組織は、Exchange Onlineの設定で経路を遮断し、あわせてSPFを最適化することで防御力を上げられます。

脆弱性を正しく理解し、正しく対処する


著者: 竹洞 陽一郎

最近、Microsoft 365環境を悪用した「Direct Send」経由のなりすまし攻撃が急増しています。
デフォルトのままでは、自社ドメインから偽装メールが送られ、取引先を巻き込む深刻な被害につながる恐れがあります。
本記事では、背景・攻撃手法・即時にとれる対策と、運用強化のための追加防御策を一次情報とともに解説します。

この記事で扱う前提：本記事は「Microsoft 365（Exchange Online）を利用している組織」を対象に、Direct Sendを悪用したなりすまし（内部ユーザー偽装）への対処を扱います。プリンター／スキャナー／業務システムの通知などでDirect Sendを利用している場合は、影響範囲を確認した上で代替方式（認証あり送信やコネクタ等）を検討してください。

一次情報・仕様の参照先（公式/標準）

背景

要点：Direct Sendは「認証なしに送れる」利便性がある一方で、攻撃者にとっても悪用しやすい経路です。近年はExchange Onlineの送信経路に見せかけることで、受信側の判定をすり抜ける攻撃が報告されています。

2025年に入り、spf.protection.outlook.com（Microsoft 365 / Exchange Onlineの送信中継ノード）」を悪用してDMARCをすり抜ける攻撃が検出されています。
これらは「Direct Send」機能を踏み台にした攻撃キャンペーンとして複数のセキュリティ研究機関によって報告されています。

Direct Sendとは?

要点：Direct Sendは、テナント内（同一ドメイン）の受信者へ、認証なしでSMTP送信できる方式です。設計上「簡便さ」を優先するため、運用での制御（許可・遮断）と監視が重要になります。

Direct Send（ダイレクト送信）とは、Microsoft 365（Exchange Online）が提供するメール送信方式の一つです。
プリンターやスキャナー、業務システムなどの「デバイスやアプリケーション」が自社のMicrosoft 365メールサーバーを経由し、認証なしで自社テナント（同一ドメイン）のユーザーにメールを送るために設計された機能です。

用語補足：この記事内での「同一ドメイン／同一テナント」は、Microsoft 365の組織（Tenant）と、そこで運用している受信者（ユーザー／グループ等）を指します。
Direct Sendは一般に「社内向け通知」に使われますが、外部からの接続で社内送信に見せかけられる点がリスクになります。

主な特徴
  • 認証（アカウントやパスワード）が不要で、メールをMicrosoft 365/Exchange Onlineのドメイン宛てに直接送信できる。
  • 送信先は原則、同じテナント内のメールアドレス（社内ユーザー）に限定されている。
  • プリンターや業務システムの「通知メール」などで広く用いられる。
セキュリティリスク
  • 認証不要のため、攻撃者にも悪用されやすい（なりすましやフィッシング攻撃に利用されるケースが確認済み）。
  • 「送信元アドレス」を容易に偽装でき、社内からの正当なメールに見せかける攻撃が可能になる。

このように、Direct Sendは「便利だがリスクも高い」機能なので、設定や運用は十分注意が必要です。

攻撃の概要

要点：攻撃者はDirect SendのSMTP経路を利用し、送信元を社内ユーザーに偽装してフィッシングを成立させます。
受信側の評価や表示によっては「内部メール」のように見えるため、被害が拡大しやすい点が特徴です。

2025年6月から10月にかけて、Microsoft 365の「Direct Send」SMTPルートを悪用したフィッシングキャンペーンが確認されています。
攻撃者は次のような手法を利用していました。

1. spf.protection.outlook.com経由でメールを送信
攻撃者はMicrosoftのメール保護インフラ（mail.protection.outlook.com）に直接接続し、正規の中継経路を装って不正なメールを送信。
2. SPFおよびDMARC整合性を意図的に回避
外部IP（例: 185.101.38.62）からの接続でSPF/DMARC認証は失敗しているにも関わらず、Microsoft内部ルートの信頼度を利用して受信側で検知を回避。
3. 内部ユーザーなりすましメール
「Direct Send」機能により、アカウント侵害なしで社内ユーザーを装ったメール送信が可能となり、内部送信と見なされるケースが確認された。

検知・調査の観点：メールヘッダー（Authentication-Results、Received、ARC、X-MS-Exchange-Organization-* など）の確認により、どの経路で到達したか、SPF/DMARC整合がどう評価されたかを追跡できます。受信側製品により表示やスコアリングが異なるため、「内部扱い」になる条件の把握が重要です。

影響と検知状況

要点：複数ベンダーが「内部送信のように見える」フィッシング増加を報告しています。
メール訓練や注意喚起だけでは防げないため、経路遮断と送信ドメイン認証（SPF/DMARC）の整備が効果的です。

VaronisやGoSecureなどのセキュリティベンダーによると、これらの攻撃キャンペーンは2025年8月以降急増し、Microsoft環境内で「内部ユーザーからのように見える」形で検出されています。

対策

要点：まずは「Reject Direct Send」を有効化し、不要な認証なし送信経路を閉じます。
次に、SPFの最適化と可観測性向上（RUA分析など）で、なりすまし耐性と運用性を強化します。

Direct Sendの脆弱性を利用した攻撃を防ぐために推奨される対応策は以下の通りです。

実施優先度（おすすめ順）

最優先
Direct Sendを利用していないなら、Reject Direct Sendを有効化して経路を遮断
次点
SPFの整理（不要include削減、lookup回数の最適化）とDMARC運用の強化
継続
DMARC RUAの分析・監視により、送信元の棚卸しと異常検知をルーチン化

Reject Direct Sendの実装

結論：Direct Sendを業務で利用していない組織は、Reject Direct Sendを有効化することで、アカウント侵害なしの内部なりすまし攻撃を即時に遮断できます。

Microsoftは2025年4月にExchange Onlineに「Reject Direct Send」設定を導入し、組織側でこの経路をブロックできるようにしました。

デフォルトでは、「Reject Direct Send」は無効になっています。
この機能を有効にするには、Exchange Online PowerShellを使用して設定を変更する必要があります。手順は以下の通りです。

適用判断の目安

設定手順

前提：この手順はExchange Onlineの管理権限が必要です。
多要素認証（MFA）を有効にしている場合は、対話的サインインが求められます。
変更はテナント全体に影響するため、実施前に通知メールの送信元（複合機・業務アプリ等）の棚卸しを行ってください。

  1. Windowsのスタートメニューから「PowerShell」を検索し、右クリックして「管理者として実行」を選択します。
  2. 初めてExchange Online PowerShellを使用する場合は、以下のコマンドでモジュールをインストールします。
    
Install-Module -Name ExchangeOnlineManagement
  3. 以下のコマンドを実行し、Microsoft 365の管理者アカウントでサインインしてExchange Onlineに接続します。
    
Connect-ExchangeOnline
  4. 接続が完了したら、以下のコマンドレットを実行して「Reject Direct Send」を有効化します。
    
Set-OrganizationConfig -RejectDirectSend $true

検証（おすすめ）

設定後は、影響を受けそうな送信元（複合機・業務システム等）からテスト送信し、エラー（550 5.7.68）が発生するか、代替方式で送信できるかを確認してください。
社外向け送信ではなく「社内宛て通知」も含めて確認することが重要です。

この変更は30分以内にサービス全体に反映されます。
この機能を有効にすると、Direct Sendメッセージを受信した際に次のメッセージが表示されます。 


550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources

自社でMicrosoft365を利用していて、しかしDirect Sendを利用していないのであれば、必ず上記の設定を入れましょう。

PowerSPFを採用する

要点：攻撃者はSPFレコードから送信基盤（MTA/配信プラットフォーム）を推測し、関連する脆弱性や運用の穴を突くことがあります。
SPFの最適化と可観測性（統計分析）は、こうした攻撃面を減らすのに有効です。

PowerSPFは、DMARCのRUAレポートのデータと連動して機能する、PowerDMARCが提供する機能の一部です。

SPFのフラットニング
SPFは、RFCの仕様上、DNSに対するDoS攻撃を防御するため、DNS Lookup回数10回までという制限があります。
その制限を乗り越えるために、DNS側で事前に名前解決を行うことで、DNS Lookupプロセスを省略させることを、SPFのフラットニングといいます。
PowerSPFは、SPFのフラットニング機能を提供しています。
MTAの隠蔽化
Microsoftの「Direct Send」の脆弱性を利用した攻撃は、BreakSPFの派生型攻撃です。
BreakSPFとは、企業のDNSを、Googleのクローラーのように、SPFのTXTレコードをクローリングして、どのメール配信プラットフォームを使っているかを調べて、そのプラットフォームで使用されているIPの範囲を調べ、その範囲内でリリースされたIPを取得して攻撃する手法です。
現在では、上記のように、メール配信プラットフォームの脆弱性を突くために利用されます。
Webサイトについて、CDNを介することでオリジンサーバを隠蔽化するのと同様に、メールサーバについても隠蔽化することで防御力を向上できます。
PowerSPFは、SPFマクロ機能を実装することで、そのドメインがどのMTAを使っているかを隠蔽化することが可能です。
各メカニズムのメール送信数の統計分析
PowerSPFは、RUAレポートと連動し、SPFに含まれている各メカニズム（includeやaレコード、mxレコードなど）から送信されたメール通数の統計分析ができるようになっています。
これを使うことで、使っていないSPFのメカニズムを削除して、セキュリティリスクを下げることが可能です。
SPFのエラーを防ぐ
SPFは、自社のSPFが問題なくレスポンスを返したとしても、メカニズムに含めているサードパーティーのSPFのエラーによって、Temperrorになります。
PowerSPFは、以下の機能によって自社のSPFがTemperrorにならないようにします。
  • 文法エラーの自動修正機能
  • サードパーティーのSPFがDNSの遅延によってTemperrorになった場合にキャッシュを利用

PowerSPFを使うことで、自社で使っているMTAを隠蔽化できるため、メール配信プラットフォームが含んでいる脆弱性を突かれた攻撃を防ぐことが可能です。

PowerSPF導入を検討すべきチェックリスト

よくある質問（FAQ）

要点：Direct Sendを止めると業務影響が出る場合があります。
どの送信元がDirect Sendを使っているかを把握し、代替手段と検証計画を用意した上で進めるのが安全です。

Q. Direct Sendは完全に廃止すべきですか？
A. プリンター等で利用している場合は、代替手段（認証あり送信、許可されたコネクタ等）を検討した上で段階的に無効化するのが現実的です。
Q. Reject Direct Sendを有効にすると既存業務は止まりますか？
A. Direct Sendに依存する機器やアプリがある場合は影響が出ます。棚卸し→テスト→切替→監視の順で進めてください。
Q. Direct Sendを使っているか、どうやって確認できますか？
A. 通知メールの送信元（複合機・業務システム等）の設定確認に加え、受信メールのヘッダー（Received、Authentication-Results等）を分析すると経路特定に役立ちます。
Q. SPF/DMARCを設定しているのに、なりすましが届くことがありますか？
A. 受信側の評価や経路により期待通りにブロックされないケースがあります。Direct Sendのような経路自体の遮断と、RUA分析による継続的な送信元管理が重要です。
Q. まず何から着手すべきですか？
A. Direct Sendを業務で使っていないならReject Direct Sendの有効化が最優先です。使っている場合は、代替方式の設計と移行計画を作ってから有効化してください。
Q. この記事の情報はいつ時点のものですか？
A. 本記事は、時点で公開されている情報と、引用している一次情報（Microsoft公式・各ベンダー報告・RFC）に基づいています。運用前には、Microsoftの最新ドキュメント・更新情報も確認してください。