スキャナーを止めずに Direct Send を閉じる

Direct Send は、もともと巧妙な仕組みとして作られたものではありません。スキャナーや小さなアプリケーションが、どこにもサインインせずに、自社のアドレスを送信者としてテナントの MX エンドポイントに直接メールを送り込めるようにするためのものです。Microsoft はこれを「mimics incoming anonymous emails from the internet, apart from the sender domain」と説明しています。穏やかな言い方ですが、要するに、スキャナーとインターネット上のほかの誰かを区別する手がかりは、名乗っているアドレスしかないということです。

2025 年 5 月、これを悪用する者が現れました。Varonis は、70 を超える組織（その大半は米国）に届いたキャンペーンを追跡しました。そのメールは社内から送られたように見えましたが、Exchange Online から見れば実際に社内のメールでした。テナントのスマートホストに対して PowerShell を 1 行実行し、被害者自身のアドレスを送信者にして、偽の Microsoft サインインページに誘導する QR コード付きの PDF を送るだけです。おとりは不在着信や FAX の通知で、複合機が毎日送っている種類のメールでした。だからこそ、誰も疑わなかったのです。

Microsoft が追加したスイッチ

2025 年 4 月から、実際にオフにできるスイッチがあり、必要なのは 1 行だけです。

Set-OrganizationConfig -RejectDirectSend $true

反映までは 30 分ほどです。それ以降、エンベロープの送信者に自社ドメインを使う匿名メールは、設定済みの受信コネクタ経由で届いたものでない限り入口で拒否され、送信側には次のメッセージが返ります。

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

Microsoft は、新しいテナントではこれを既定で有効にし、そのテナントでは無効にできないようにする意向も示しています。日付は決まっていませんが、方向ははっきりしています。

まず誰が使っているかを調べる

ほとんどのテナントがまだスイッチを入れていない理由は単純で、入れたときにほかに何が止まるのか誰にもわからないからです。Microsoft は SPF レコードから始めることを勧めています。Direct Send で送信していながら SPF レコードに載っていないものは、すでに配信に問題を抱えているからです。実際のトラフィックについては、Microsoft が Exchange 管理センターでプレビューとして公開した Change Optics レポートに、この設定で拒否されるメッセージの例が表示されます。コネクタを経由せずに受信したすべてのメールを対象にした履歴メッセージ追跡では、最大 90 日前までさかのぼれます。

Start-HistoricalSearch -ReportTitle "Direct Send" -ReportType ConnectorReport `
  -ConnectorType NoConnector -Direction Received `
  -StartDate (Get-Date).AddDays(-89) -EndDate (Get-Date) `
  -NotifyAddress admin@contoso.com

Defender for Office 365 Plan 2 があれば、Advanced Hunting で EmailEvents のうちコネクタフィールドが空のものを検索すると、同じメールが見つかります。結果を読む前に知っておくべきことが 1 つあります。これらのレポートが最も役に立つのは、MX が独自のコネクタ経由で届くゲートウェイを指している場合です。MX が Exchange Online を直接指している場合は、通常の受信メールもすべてコネクタなしで届くため、自社ドメインを送信者とするものに絞り込む必要があります。

見つかるものに驚きはあまりありませんが、リストは予想より長くなります。複合機、ビル管理システム、倉庫のラベルプリンター、そしてときには自社の名義で請求書を送るクラウドサービスです。確定する前に影響を確認したい場合、Microsoft 自身が示す中間策は、この種のメールを拒否する代わりに検疫するメールフロールールです。何も失うことはなく、1 週間後にはスイッチが何を止めていたかが正確にわかります。

スキャナーを別の経路に移す

正当な送信者に対する Microsoft の答えは、オフィスのパブリック IP アドレス、または証明書を信頼する Partner タイプの受信コネクタです。ただし、実際に証明書を持っているスキャナーはほとんどありません。費用はかからず、固定アドレスを持つ単一拠点であれば機能します。注意点もあります。そのアドレスを組織外の誰とも共有してはならず、独自のインターネットブレイクアウトを持つ拠点ごとにエントリが必要で、IP アドレスが唯一の鍵になります。その背後にあるものは何でも、ドメイン内の誰の名義でも送信できます。間違った FAX 通知をクリックした経理部のノート PC も例外ではありません。

サインインでき、同僚にしかメールを送らないデバイスは High Volume Email に移行できます。これについては SMTP AUTH に関する記事で取り上げました。残りのデバイスがそもそも Direct Send を使っていたのは TLS もログインも使えないからで、こうしたデバイスには、デバイスにできることを受け入れつつ、誰が誰の名義で送信できるかを判断するリレーが必要です。

今週やるべきこと

1. コネクタなしのメッセージ追跡を実行し、Change Optics レポートを開いて、見つかった送信元をすべて書き出します。
2. 正当な送信元には適切な経路を用意します。既知の IP アドレスには Partner コネクタ、社内にしかメールを送らないデバイスには High Volume Email、それ以外にはリレーです。
3. 検疫ルールを 1 週間設定し、そこに何が入るかを確認します。
4. そのうえで RejectDirectSend を設定し、数日間は 5.7.68 のバウンスに注意します。

Sendman はそのリレーとして作りました。スキャナーはサインインするか、許可したアドレス範囲から送信し、scan@contoso.com としては送信できても、CEO の名義では送信できません。

出典

• Microsoft Exchange Team: Introducing more control over Direct Send in Exchange Online、2025 年 4 月 28 日（その後更新）
• Microsoft Exchange Team: Direct Send vs sending directly to an Exchange Online tenant、2025 年 8 月 4 日
• Microsoft Learn: How to set up a multifunction device or application to send email using Microsoft 365
• Varonis Threat Labs: Ongoing Campaign Abuses Microsoft 365's Direct Send to Deliver Phishing Emails、2025 年 6 月 26 日