Direct Send

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

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

2025年10月26日
著者: 竹洞 陽一郎

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

背景

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

Direct Sendとは?

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

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

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

攻撃の概要

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」機能により、アカウント侵害なしで社内ユーザーを装ったメール送信が可能となり、内部送信と見なされるケースが確認された。

影響と検知状況

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

対策

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

Reject Direct Sendの実装

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

デフォルトでは、「Reject Direct Send」は無効になっています。
「Reject Direct Send」機能を有効にするには、Exchange Onlineで、以下のPowerShellコマンドレットを実行します。 


Set-OrganizationConfig -RejectDirectSend $true

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


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

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

PowerSPFを採用する

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を隠蔽化できるため、メール配信プラットフォームが含んでいる脆弱性を突かれた攻撃を防ぐことが可能です。