Microsoft Defender for Office 365の「高度な配信ポリシー」は、サードパーティ製のフィッシング訓練メールや、SecOpsメールボックスに届く分析用メールを、通常の迷惑メール・フィッシング判定とは別枠で扱うための設定です。結論から言うと、管理者は「送信元ドメインと送信IP」「SecOps用メールボックス」「メールルーティング」「Safe Linksとの整合性」を必ず確認する必要があります。設定範囲を広げすぎると、訓練メールだけでなく、本物の攻撃メールまで通過しやすくなるおそれがあります。
2026年5月9日に確認対象となった公式情報では、Microsoft Defender for Office 365の高度な配信ポリシーについて、非Microsoft製フィッシングシミュレーションとSecOpsメールボックスの扱いが整理されています。対象は、すべてのクラウドメールボックス向けの組み込みセキュリティ機能、Microsoft Defender for Office 365 Plan 1 / Plan 2、Microsoft Defender XDRです。(Microsoft Learn)
高度な配信ポリシーは「安全な例外」を作るための設定
Microsoft 365では、既定で組織を保護するため、マルウェアや高信頼フィッシングとして識別されたメッセージに対して、単純な許可リストやフィルターバイパスを認めない設計になっています。ただし、フィッシング訓練やセキュリティ分析のように、あえてフィルターされていないメッセージを扱う必要がある場面があります。高度な配信ポリシーは、その例外を管理された形で作るための機能です。(Microsoft Learn)
対象になる主なシナリオは、次の2つです。
| シナリオ | 目的 | 管理者が注意すべき点 |
|---|---|---|
| 非Microsoft製フィッシングシミュレーション | サードパーティ製の訓練メールを正しく配信し、ユーザー教育に使う | 送信元ドメインと送信IPを正確に登録する |
| SecOpsメールボックス | セキュリティチームが良性・悪性を問わず未加工に近いメールを収集、分析する | 専用メールボックスに限定し、通常業務用の宛先を登録しない |
ここで重要なのは、高度な配信ポリシーが「危険なメールを安全にする」機能ではない点です。あくまで、条件に一致したメールを訓練や分析目的の例外として扱う設定です。運用上は、許可リストの代替ではなく、セキュリティ部門が管理する限定的な例外設定として扱うべきです。
影響範囲：どの防御機能が動作しなくなるのか
高度な配信ポリシーに一致したメッセージでは、Microsoft 365側の一部の保護アクションが実行されません。公式情報では、フィルター処理、ZAP、Safe Links、Safe Attachments、既定のシステムアラート、AIRやクラスタリングなどへの影響が説明されています。(Microsoft Learn)
| 影響を受ける機能 | 高度な配信ポリシー適用時の動作 | 実務上の意味 |
|---|---|---|
| スパム・フィッシングフィルター | 対象メッセージに対してアクションしない | 訓練メールが隔離されにくくなる |
| マルウェアフィルター | SecOpsメールボックスではバイパスされる | 分析用メールボックスの厳格な管理が必要 |
| ZAP | スパム・フィッシングのZAPはアクションしない。マルウェアZAPはSecOpsメールボックスでのみバイパス | 後から自動削除される挙動を期待しない |
| Safe Links | 指定URLをクリック時にブロック・デトネーションしない。URLのラップは継続 | 訓練用URLのクリック結果を確認しやすい |
| Safe Attachments | 添付ファイルをデトネーションしない | 添付型訓練や分析メールの扱いに注意 |
| アラート・AIR | 既定のシステムアラートや自動調査が発生しない | SOC側で「検知されない」ことを前提に運用する |
フィッシングシミュレーションメールをユーザーがOutlookの組み込みレポートボタンで報告した場合も、アラート、調査、インシデントは生成されません。ただし、メッセージはSubmissionsページのUser reportedタブに表示されます。つまり、訓練結果の確認と実インシデント対応の流れを混同しないように、運用手順を分ける必要があります。(Microsoft Learn)
管理画面で確認できるシステムオーバーライド
高度な配信ポリシーで識別されたメッセージは、セキュリティ上の脅威ではなく、システムオーバーライドとして扱われます。管理画面では「Phishing simulation」または「SecOps mailbox」として表示され、Threat Explorer、Real-time detections、Email entityページ、Threat protection status report、Advanced hunting、Campaign Viewsなどで確認できます。(Microsoft Learn)
管理者が最初に確認すべき場所は、次の3つです。
| 確認場所 | 見るべきポイント |
|---|---|
| Threat Explorer / Real-time detections | System override sourceでPhishing simulationまたはSecOps Mailboxを絞り込む |
| Email entityページ | Tenant override欄で、組織ポリシーにより許可された理由を確認する |
| Advanced hunting | EmailEventsのOrgLevelPolicyで、対象メッセージを調査する |
運用でよくある失敗は、「訓練メールが検知されなかった」と判断してしまうことです。高度な配信ポリシーに一致したメールは、検知漏れではなく、意図的な例外処理として扱われる場合があります。訓練や検証の前に、SOC、ヘルプデスク、メール管理者の間で確認方法を共有しておくと、不要なエスカレーションを減らせます。
非Microsoft製フィッシングシミュレーションで登録する項目
サードパーティ製フィッシングシミュレーションを高度な配信ポリシーで構成するには、少なくとも1つのドメインと、少なくとも1つの送信IPが必要です。電子メール以外のシミュレーション、たとえばTeamsメッセージ、Word文書、Excelファイル内のリンクについては、必要に応じて許可するSimulation URLも登録できます。(Microsoft Learn)
| 設定項目 | 必須 / 任意 | 登録時の判断基準 |
|---|---|---|
| Domain | 必須 | MAIL FROMのドメイン、またはフィッシングシミュレーションベンダーが指定するDKIMドメイン |
| Sending IP | 必須 | 実際にMicrosoft 365へ到達する送信元IP |
| Simulation URLs to allow | 任意 | メール以外のシミュレーションで、クリック時に脅威扱いしたくないURL |
ドメインは、SMTP送信で使われるMAIL FROMアドレスのドメイン、またはベンダー指定のDKIMドメインを使います。国際化ドメイン名を使う場合はPunycodeを使用します。ポータルではドメインを最大50件、送信IPv4アドレスを最大10件、許可するシミュレーションURLを最大30件登録できます。(Microsoft Learn)
特に注意したいのは、ドメインと送信IPの組み合わせが1対1で関連付けられない点です。少なくとも1つのDomainと1つのSending IPに一致する必要がありますが、登録した値同士の関連付けは保持されません。たとえば、複数ベンダーのドメインとIPをまとめて登録すると、意図しない組み合わせまで許可される可能性があります。ベンダーごと、訓練基盤ごとに値を棚卸しし、不要なドメインや広すぎるIP範囲を登録しないことが重要です。(Microsoft Learn)
SecOpsメールボックス設定で確認すべきこと
SecOpsメールボックスは、セキュリティチームが未加工に近いメールを収集・分析するための専用メールボックスです。Microsoft Defenderポータルでは、既存のExchange OnlineメールボックスをSecOpsメールボックスとして指定します。配布グループは許可されません。(Microsoft Learn)
SecOpsメールボックスを設定する際は、次の基準で対象を絞ると安全です。
| 判断項目 | 推奨される考え方 |
|---|---|
| メールボックスの用途 | 分析専用にする。一般ユーザーの通常業務用メールボックスを登録しない |
| アクセス権 | SOCやメールセキュリティ担当者など、必要最小限に限定する |
| 保管ルール | 分析後の削除、保持、転送禁止などの運用ルールを決める |
| 監査 | 誰がアクセスし、どのメールを処理したか確認できる状態にする |
SecOpsメールボックスでは、マルウェアフィルターやマルウェアZAPもバイパスされるため、通常の共有メールボックスと同じ感覚で扱うのは危険です。添付ファイルやURLを開く前提の分析環境、サンドボックス、隔離された端末など、SOC側の作業環境も合わせて見直してください。
必要な権限：グローバル管理者に頼りすぎない
高度な配信ポリシーの作成、変更、削除には、Microsoft DefenderポータルやExchange Online側の権限が必要です。公式情報では、Defender XDRの統合RBAC、Email & collaboration RBAC、Exchange Online RBAC、Microsoft Entraのロールが示されています。設定変更には、Email & collaboration RBACのSecurity Administratorロールグループと、Exchange Online RBACのOrganization Managementロールグループなどが関係します。読み取り専用であれば、Global ReaderやSecurity Readerなどのロールが候補になります。(Microsoft Learn)
Microsoftは最小権限の原則を推奨しており、グローバル管理者は非常に強い権限を持つため、緊急時や他のロールで対応できない場合に限定すべきとされています。運用では、日常的な設定変更用の管理者ロールと、緊急時用の高権限アカウントを分けて管理するのが現実的です。(Microsoft Learn)
展開前に確認するチェックリスト
高度な配信ポリシーは、設定自体は難しくありません。しかし、メールルーティングやサードパーティ製セキュリティサービスとの組み合わせで、意図しない動作になりやすい設定です。展開前に、次の順番で確認してください。
| 手順 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| 1 | フィッシング訓練ベンダーから、MAIL FROMドメイン、DKIMドメイン、送信IPを取得する | 古いIPや別環境のIPを登録してしまう |
| 2 | MXレコードとメールルーティングを確認する | Microsoft 365に直接届いていない構成を見落とす |
| 3 | SecOpsメールボックスを専用化する | 既存の共有メールボックスを流用してしまう |
| 4 | Defenderポータルで最小限の値だけ登録する | ドメインやCIDR範囲を広くしすぎる |
| 5 | テストメールを送信し、System override sourceを確認する | 「検知されない＝異常」と誤解する |
| 6 | 訓練後に不要な値を見直す | 使わなくなったベンダー設定が残る |
設定画面は、Microsoft Defenderポータルの「Email & collaboration > Policies & rules > Threat policies > Advanced delivery」から開きます。SecOpsメールボックスはSecOps mailboxタブ、非Microsoft製フィッシングシミュレーションはPhishing simulationタブで構成します。(Microsoft Learn)
メールルーティングで特に注意すべき構成
MXレコードがMicrosoft 365を指していない場合、Authentication-resultsヘッダーのIPアドレスが、高度な配信ポリシーに登録したIPアドレスと一致する必要があります。一致しない場合は、Enhanced Filtering for Connectorsの構成が必要になることがあります。(Microsoft Learn)
特に危険なのは、次のような「イン・アンド・アウト」のメールルーティングです。
Internet
↓
Microsoft 365
↓
オンプレミス環境またはMicrosoft以外のセキュリティサービス
↓
Microsoft 365へ戻るこの構成では、Microsoft 365がメッセージ送信元の真のIPアドレスを識別できません。公式情報では、この制限を回避するために、オンプレミス環境や非Microsoft製送信基盤のIPアドレスをフィッシングシミュレーション設定へ追加しないよう注意しています。そうすると、指定したドメインを偽装するインターネット送信者に対しても、スパムフィルターが実質的にバイパスされる可能性があるためです。(Microsoft Learn)
ハイブリッド環境と同一組織内シミュレーションの注意点
Microsoft以外のフィッシングシミュレーションに対する高度な配信ポリシーは、現時点で同じ組織内のシミュレーション、つまりDIR:INTのシナリオをサポートしていません。特に、ハイブリッドメールフローでMicrosoft 365の前にExchange Serverゲートウェイを経由する構成では注意が必要です。(Microsoft Learn)
回避策としては、フィッシングシミュレーションメッセージを内部として認証しない専用の受信コネクタを作成する、またはExchange Server基盤をバイパスしてMicrosoft 365のMXレコードへ直接配送する方法が示されています。一方で、組織内メッセージスキャンを「なし」にすることは、他のメールにも影響するため推奨されていません。(Microsoft Learn)
ハイブリッド環境では、「訓練メールだけを通したい」という要件が、内部配送、認証、コネクタ、スキャンポリシーにまたがります。メール管理者だけで完結させず、SOC、Exchange管理者、ネットワーク担当者、フィッシング訓練ベンダーを含めて事前レビューするのが安全です。
Safe Linksとの組み合わせで誤検知を増やさない
Safe Linksの設定にも注意が必要です。組み込みの保護プリセットセキュリティポリシー、またはカスタムSafe Linksポリシーで「URLを書き換えず、SafeLinks APIでのみチェックする」設定を使っている場合、対応するOutlookクライアントでは、電子メール内のフィッシングシミュレーションリンクをクリック時の脅威として扱いません。古いOutlookを使っている場合は、この設定を無効にすることを検討するよう案内されています。(Microsoft Learn)
また、フィッシングシミュレーションURLをSafe Linksポリシーの「電子メールで次のURLを書き換えない」セクションへ追加すると、URLクリックに対する不要なアラートが発生する可能性があります。メール内のフィッシングシミュレーションURLは、メールフロー中とクリック時の両方で自動的に許可されるため、Safe Links側に二重で例外を入れないようにしてください。(Microsoft Learn)
PowerShellで管理する場合のポイント
ポータル操作だけでなく、PowerShellでも高度な配信ポリシーを管理できます。SecOpsメールボックスでは、SecOps override policyとSecOps override ruleを扱います。PowerShellでは、先にポリシーを作成し、その後にポリシーへ適用するルールを作成します。ポリシーを削除すると対応するルールも削除されますが、ルールだけを削除してもポリシーは削除されません。(Microsoft Learn)
SecOpsメールボックスを作成する基本的な流れは次の通りです。
New-SecOpsOverridePolicy -Name SecOpsOverridePolicy -SentTo [email protected]
New-ExoSecOpsOverrideRule -Name SecOpsOverrideRule -Policy SecOpsOverridePolicy設定確認には、次のコマンドを使います。
Get-SecOpsOverridePolicy
Get-ExoSecOpsOverrideRule
Get-ExoSecOpsOverrideRule | Format-Table Name,Mode非Microsoft製フィッシングシミュレーションでは、PhishSimOverridePolicy、ExoPhishSimOverrideRule、TenantAllowBlockListItemsを使います。PowerShellでは、送信元IPv4またはIPv6アドレスを指定できます。なお、IPv6アドレスは現時点でPowerShellのみ対応とされています。(Microsoft Learn)
New-PhishSimOverridePolicy -Name PhishSimOverridePolicy
New-ExoPhishSimOverrideRule `
-Policy PhishSimOverridePolicy `
-Domains fabrikam.com,wingtiptoys.com `
-SenderIpRanges 192.168.1.55電子メール以外のフィッシングシミュレーションURLを許可する場合は、Tenant Allow/Block ListのAdvancedDeliveryサブタイプを使います。
New-TenantAllowBlockListItems `
-Allow `
-ListType Url `
-ListSubType AdvancedDelivery `
-Entries "*.fabrikam.com" `
-NoExpiration開発者や運用自動化担当者は、PowerShellで登録作業を自動化する前に、設定値のレビュー工程を入れるべきです。特に、CIDR範囲、ワイルドカードURL、複数ベンダーのドメイン混在は、意図しないバイパスの原因になります。スクリプト化する場合も、変更前のGet-ExoPhishSimOverrideRuleとGet-TenantAllowBlockListItemsの結果を保存し、変更後に差分を確認できるようにしておくと安全です。
既存の許可リストやメールフロールールからの見直し
過去に、フィッシング訓練メールを通すためにメールフロールール、IP許可、URL許可、コネクタ設定を積み重ねてきた環境では、高度な配信ポリシーへの整理を検討すべきです。ただし、すべてを一度に削除するのではなく、次の順番で進めると影響を抑えられます。
| フェーズ | 作業内容 |
|---|---|
| 現状確認 | 既存のメールフロールール、許可IP、許可ドメイン、Safe Links例外を棚卸しする |
| 影響調査 | どの設定がフィッシング訓練、SecOps分析、その他の業務要件に使われているか分類する |
| 並行検証 | 高度な配信ポリシーを最小範囲で設定し、訓練メールの配送とSystem override表示を確認する |
| 段階的削除 | 重複する古い例外設定を削除し、ログとユーザー報告の変化を見る |
| 定期レビュー | ベンダー変更、送信IP変更、訓練終了後の不要設定を見直す |
公式情報でも、False Positiveの調査中に一時的な許可が必要になる場合はあるものの、すべてのオーバーライドは一時的なものとして扱うことが強く推奨されています。高度な配信ポリシーも、設定したら終わりではなく、定期的に棚卸しする対象です。(Microsoft Learn)
管理者がすぐ確認すべきポイント
高度な配信ポリシーを安全に運用するには、次の項目を確認してください。
| チェック項目 | 確認すべき内容 |
|---|---|
| フィッシング訓練ベンダー情報 | MAIL FROMドメイン、DKIMドメイン、送信IPが最新か |
| 登録範囲 | 不要なドメイン、広すぎるIP範囲、使っていないURLが残っていないか |
| SecOpsメールボックス | 専用メールボックスになっているか。配布グループを使っていないか |
| メールルーティング | MX、コネクタ、サードパーティ製メールセキュリティの経路が整理されているか |
| Safe Links | 不要な「URLを書き換えない」例外を追加していないか |
| 検証方法 | Threat ExplorerやAdvanced huntingでSystem overrideを確認できるか |
| 権限 | グローバル管理者に頼らず、最小権限で管理しているか |
| 運用ルール | 訓練後やベンダー変更後に設定を見直す手順があるか |
まず行うべきことは、現在の訓練メールとSecOps分析メールの経路を可視化することです。そのうえで、サードパーティ製フィッシングシミュレーションには必要最小限のドメインと送信IPだけを登録し、SecOpsメールボックスは専用化します。最後に、Threat ExplorerやAdvanced huntingでシステムオーバーライドとして想定通り表示されるか確認してください。
高度な配信ポリシーは、正しく使えばフィッシング訓練とセキュリティ分析を安定させる有効な機能です。一方で、例外設定である以上、範囲を広げすぎると防御の穴になります。管理者は「誰のために、どのメールを、どの条件で例外にするのか」を明確にし、設定値・権限・ログ確認を定期的に見直すことが重要です。
コメント