2026年4月29日のMicrosoft Defender公式ドキュメント更新「Add impersonation protection note to submissions-admin.md」で最も重要なのは、誤検知として“should not have been blocked”に送信しても、テナント内のなりすまし保護が自動的に上書きされるわけではないという点です。つまり、正当な送信者のメールが繰り返しブロックされる場合、単にMicrosoftへ再判定を依頼するだけでは不十分です。
今回の更新は、新機能追加というよりも、管理者の運用ミスを防ぐための明確化です。Security admins、compliance teams、enterprise IT readersは、Submissionsページの使い方だけでなく、Anti-phishing policy、Trusted senders and domains、Tenant Allow/Block Listの使い分けを確認しておく必要があります。公式コミットでは、submissions-admin.mdの更新日が04/29/2026に変更され、「Report good email to Microsoft」セクションへなりすまし保護に関するNOTEが追加されています。(GitHub)
今回のMicrosoft Defender公式ドキュメント更新で何が変わったか
今回の更新対象は、Microsoft Defender for Office 365のSubmissionsページに関する管理者向けドキュメントです。Submissionsページは、管理者が迷惑メール、フィッシング、URL、添付ファイル、誤ってブロックされた正当なメールなどをMicrosoftへ分析依頼するための場所です。Microsoft Learnの該当ページでは、管理者送信とユーザー報告メッセージの管理者送信という2種類の提出方法が説明されています。(Microsoft Learn)
今回追加されたNOTEの要点は次のとおりです。
| 確認項目 | 内容 |
|---|---|
| 更新日 | 2026年4月29日 |
| 対象ファイル | defender-office-365/submissions-admin.md |
| 追加箇所 | Report good email to Microsoftセクション |
| 変更の中心 | 正当なメールとして提出しても、なりすまし保護は自動的に上書きされない点を明記 |
| 管理者が取るべき対応 | 繰り返し誤検知される正当な送信者は、Anti-phishing policyのTrusted senders and domainsを更新するか、Tenant Allow/Block Listで許可エントリを作成する |
ここで誤解しやすいのは、「Microsoftへ正当なメールとして送信した＝今後必ず届くようになる」と考えてしまうことです。公式ドキュメントは、正当なメールとして提出しても、ドメインなりすまし保護やユーザーなりすまし保護を自動的に回避する設定にはならないと説明しています。(Microsoft Learn)
影響を受ける管理者の典型的なケース
今回の更新は、特に次のような運用をしている組織に影響します。
| ケース | 起こりやすい問題 | 確認すべき設定 |
|---|---|---|
| 取引先やSaaS通知メールが繰り返し隔離される | 毎回Submissionsで「正当」と報告しても再発する | Anti-phishing policyのTrusted senders and domains |
| 経営層名義に似た外部送信者がブロックされる | User impersonation protectionにより誤検知される | 保護対象ユーザー、検知ポリシー、例外設定 |
| 自社ドメインに似た外部ドメインからのメールが止まる | Domain impersonation protectionで疑わしいと判定される | 保護対象ドメイン、送信元ドメイン、許可範囲 |
| SOCが誤検知処理をSubmissionsだけで完結させている | 再発防止策が設定に反映されない | 運用手順書、承認フロー、許可リスト管理 |
| Compliance teamが例外設定の根拠を追跡できない | 監査時に「なぜ許可したか」を説明しにくい | 許可理由、期限、承認者、対象範囲 |
特に大企業では、メールセキュリティの一次対応をSOC、ポリシー変更をIT管理部門、例外承認をコンプライアンス部門が担当していることがあります。その場合、Submissionsでの報告とポリシー変更の責任が分断され、誤検知が何度も再発しやすくなります。
Submissionsは「再判定依頼」、ポリシー変更は「運用上の例外設定」
今回の更新を理解するには、Submissions、Anti-phishing policy、Tenant Allow/Block Listの役割を分けて考える必要があります。
| 機能 | 主な目的 | 向いている場面 | 注意点 |
|---|---|---|---|
| Submissions | Microsoftへ分析・再判定を依頼する | 判定が正しいか不明なメール、URL、添付ファイルを調査したい | なりすまし保護の例外が自動作成されるとは限らない |
| Anti-phishing policy | なりすまし、スプーフィング、フィッシングしきい値などを制御する | 特定のユーザー、ドメイン、部門向けに保護設定を調整したい | ポリシー優先順位と適用対象を誤ると意図しない範囲に影響する |
| Trusted senders and domains | なりすまし保護の例外として信頼する送信者・ドメインを指定する | 正当な送信者がなりすましとして継続的に検知される | 広すぎるドメイン許可はリスクを増やす |
| Tenant Allow/Block List | Microsoftのフィルタリング判定をテナント単位で手動上書きする | テナント全体で許可・ブロックの判断を明示したい | 不要なAllowは本来ブロックされるべき悪性メールを通す可能性がある |
Microsoft Learnでは、Anti-phishing policiesがスプーフィング、なりすまし、その他の欺瞞的なメール手法を検出するためのものだと説明しています。また、Defender for Office 365では、ユーザー、ドメイン、送信者のなりすまし保護や、信頼済み送信者・ドメインの定義が利用できます。(Microsoft Learn)
なぜ「正当なメールとして提出」だけでは再発防止にならないのか
正当なメールがブロックされた場合、管理者はSubmissionsページから「It appears clean」または「I’ve confirmed it’s clean」を選んでMicrosoftへ報告できます。公式ドキュメントでは、メールのネットワークメッセージIDや.msg、.emlファイルを使って提出でき、受信者を指定してポリシーチェックを行う流れが説明されています。(Microsoft Learn)
しかし、なりすまし保護は単純な「このメールは良い・悪い」だけで判断されません。送信者名、送信元ドメイン、過去の通信履歴、保護対象ユーザーや保護対象ドメインとの類似性などが関係します。
たとえば、次のようなケースです。
- 外部ベンダーの担当者名が、自社役員の表示名と同じ
- 取引先が自社ブランドに似たドメインを使ってキャンペーンメールを送る
- 正規SaaSの通知メールが、自社ドメインや保護対象ブランドに似た送信元として検知される
- グループ会社や海外法人が、似た名称の別ドメインからメールを送る
このようなメールを一度Microsoftへ「正当」と提出しても、次回以降のメールが同じなりすまし保護ルールに引っかかる可能性があります。だからこそ、今回の更新では、繰り返し発生する正当な送信者について、Anti-phishing policy側のTrusted senders and domains、またはTenant Allow/Block Listを見直すよう明記されたと考えられます。
Anti-phishing policyで確認すべきポイント
なりすまし保護に関する誤検知が発生した場合、最初に確認したいのは、どのAnti-phishing policyがそのメールを検知したかです。Microsoft Learnでは、Anti-phishing policiesはDefenderポータルのEmail & collaboration > Policies & rules > Threat policies > Anti-phishingから管理できると説明されています。(Microsoft Learn)
確認すべき設定
| 確認項目 | 見るべき内容 | 判断基準 |
|---|---|---|
| 適用されたポリシー | どのAnti-phishing policyが対象受信者に適用されたか | 部門別・役職別ポリシーがある場合は優先順位も確認 |
| User impersonation protection | 保護対象ユーザーに該当するか | 経営層、財務、法務、人事など高リスクユーザーを重点確認 |
| Domain impersonation protection | 保護対象ドメインに似た送信元か | グループ会社、委託先、マーケティング配信ドメインで誤検知が起きやすい |
| Mailbox intelligence | 過去の通信履歴が判定に影響しているか | 初回連絡や新規ベンダーで検知されやすい |
| Trusted senders and domains | 例外として登録すべき送信者か | 継続的な業務利用があり、認証や契約関係を確認できる場合のみ検討 |
| Policy priority | 複数ポリシーの優先順位 | 意図しないポリシーが先に適用されていないか確認 |
Anti-phishing policiesの優先順位にも注意が必要です。公式ドキュメントでは、Strict preset security policy、Standard preset security policy、カスタムポリシー、既定ポリシーの順で処理され、対象受信者には最初に一致したポリシーが適用されると説明されています。(Microsoft Learn)
つまり、あるポリシーにTrusted senders and domainsを追加しても、別の上位ポリシーが先に適用されている場合、期待した効果が出ない可能性があります。
Trusted senders and domainsを使うべき場面
Trusted senders and domainsは、なりすまし保護に対する例外設定です。公式ドキュメントでは、指定された送信者や送信者ドメインからのメッセージは、そのポリシーにおいてなりすましベースの攻撃として分類されないと説明されています。最大エントリ数は1,024件です。(Microsoft Learn)
ただし、これは便利な反面、慎重に扱うべき設定です。特にドメイン単位で登録すると、対象範囲が広くなります。
登録を検討しやすい例
- 契約済みSaaSから送信される定期通知メール
- グループ会社や海外法人の正式な送信ドメイン
- 業務上不可欠な取引先の送信者アドレス
- 役員・財務・調達部門と頻繁にやり取りする確認済みベンダー
- Microsoft 365関連の正規通知が誤ってなりすまし扱いされるケース
登録前に確認すべきこと
| 確認項目 | 確認内容 |
|---|---|
| 送信元の正当性 | 契約先、業務オーナー、ベンダー管理台帳で確認する |
| メール認証 | SPF、DKIM、DMARCの状態を確認する |
| 登録範囲 | ドメイン全体ではなく、可能なら送信者単位で許可する |
| サブドメイン | Trusted domain entriesはサブドメインを含まないため、必要なら個別に確認する |
| 期限と棚卸し | 永続的な例外にせず、定期的に見直す |
| 承認記録 | 誰が、なぜ、どの範囲で許可したかを残す |
公式ドキュメントでは、Trusted domain entriesは指定ドメインのサブドメインを含まないため、サブドメインごとにエントリが必要だと説明されています。たとえばexample.comを登録しても、mail.example.comやnews.example.comまで自動的に対象になるとは限りません。(Microsoft Learn)
Tenant Allow/Block Listを使うべき場面
Tenant Allow/Block Listは、Microsoft Defenderポータルでフィルタリング判定を手動で上書きするための仕組みです。公式ドキュメントでは、メールではメールフロー時、メール・Teams・Officeアプリではクリック時にリストが使われると説明されています。(Microsoft Learn)
Tenant Allow/Block Listは、次のような場合に検討します。
- テナント全体で同じ送信者やURLを明示的に許可・ブロックしたい
- Submissionsの結果を受けて、Allow this messageやAllow this URLを作成する必要がある
- 特定のURLやファイルが業務上必要で、誤検知が繰り返されている
- スプーフィング送信者を手動で許可またはブロックしたい
一方で、Tenant Allow/Block Listは強力な上書き手段です。Microsoft Learnでは、不要なallow entriesは、システムが本来フィルターする悪性メールに組織をさらす可能性があると説明しています。さらに、Block entriesはAllow entriesより優先されます。(Microsoft Learn)
Tenant Allow/Block Listで失敗しやすいポイント
| 失敗例 | リスク | 対策 |
|---|---|---|
| ドメイン全体を安易にAllowする | 不正利用された同一ドメイン配下のメールも通りやすくなる | 送信者単位、URL単位など最小範囲で許可する |
| 許可理由を記録しない | 監査やインシデント調査で説明できない | チケット番号、申請者、業務理由を記録する |
| 期限を設定しない | 古い例外が残り続ける | 定期レビュー日を決める |
| Submissions結果だけで即許可する | 根本原因を見逃す | メール認証、送信元、本文、URL、添付ファイルを確認する |
| BlockとAllowの競合を見落とす | 想定と異なる処理になる | 既存エントリと優先関係を確認する |
実務で使える対応フロー
正当なメールがMicrosoft Defenderでブロックされた場合は、次の順序で対応すると判断ミスを減らせます。
| 手順 | 作業 | 目的 |
|---|---|---|
| 1 | メールの検知理由を確認する | Phish、Spam、High confidence phish、impersonationなどを切り分ける |
| 2 | メールヘッダーと送信元を確認する | From、MAIL FROM、DKIM、SPF、DMARC、送信IPを確認する |
| 3 | 影響範囲を確認する | 単発か、複数ユーザー・複数部門で再発しているかを見る |
| 4 | SubmissionsでMicrosoftへ提出する | 判定への異議申し立てまたは分析依頼を行う |
| 5 | なりすまし保護が原因か確認する | User impersonation、Domain impersonation、Mailbox intelligenceを確認する |
| 6 | 再発する正当送信者なら例外設定を検討する | Trusted senders and domainsまたはTenant Allow/Block Listを選ぶ |
| 7 | 許可範囲と期限を決める | 最小権限・最小範囲の原則で設定する |
| 8 | 証跡を残す | チケット、承認者、理由、対象、期限を記録する |
| 9 | 定期的に棚卸しする | 不要な例外を削除し、攻撃面を減らす |
このフローのポイントは、Submissionsを「最初の対応」にしつつ、「最後の対応」にしないことです。Microsoftへ正当なメールとして報告するだけでは、テナント内のなりすまし保護設定まで整うとは限りません。
Security adminsが確認すべき運用チェックリスト
Security adminsは、今回の更新を受けて次の項目を確認しておくとよいでしょう。
- Submissionsで正当なメールを提出した後の再発確認手順があるか
- なりすまし保護による誤検知を見分ける手順があるか
- Anti-phishing policyの優先順位と適用対象を把握しているか
- Trusted senders and domainsの登録基準が明文化されているか
- Tenant Allow/Block ListのAllowが増えすぎていないか
- Allow登録時に期限、理由、承認者を記録しているか
- 高リスク部門向けポリシーと全社向けポリシーが混在していないか
- グループ会社、委託先、SaaS通知メールの送信ドメインを台帳化しているか
- メール認証の不備を例外設定だけで解決しようとしていないか
特に、役員名、財務担当者名、ブランド名、主要ドメインに関係する例外は慎重に扱うべきです。攻撃者が悪用しやすい領域だからです。
Compliance teamsが確認すべき監査・証跡の観点
Compliance teamsにとって重要なのは、「なぜその送信者を許可したのか」を後から説明できる状態にすることです。セキュリティ製品の例外設定は、業務継続のために必要な場合があります。しかし、根拠が残っていない例外は、監査やインシデント対応時のリスクになります。
最低限、次の情報は記録しておくべきです。
| 記録項目 | 例 |
|---|---|
| 申請者 | 業務部門、システム担当、SOC担当 |
| 承認者 | 情報セキュリティ責任者、メール基盤責任者 |
| 許可対象 | 送信者アドレス、ドメイン、URL、ファイルハッシュ |
| 許可理由 | 契約済みSaaS通知、取引先請求書メール、グループ会社連絡 |
| 確認した証拠 | 契約情報、送信元確認、メール認証結果、チケット番号 |
| 適用範囲 | 全社、特定部門、特定受信者 |
| 期限 | 一時許可か恒久許可か |
| レビュー予定日 | 四半期ごと、半年ごとなど |
許可リストは「一度作ったら終わり」ではありません。取引先の変更、SaaSの送信基盤変更、ドメイン移行、退職者の増加などにより、正当だった例外が不要になることがあります。
Enterprise IT readersが移行・運用準備で見るべき点
今回の更新は、システム移行やメール基盤変更のタイミングでも重要です。Microsoft 365への移行、サードパーティメールセキュリティ製品からの切り替え、グローバルテナント統合を行う場合、正当な送信者が新しいDefenderポリシーでなりすまし扱いされる可能性があります。
移行準備では、次の観点で確認しましょう。
| 準備項目 | 確認内容 |
|---|---|
| 既存許可リストの棚卸し | 旧メールゲートウェイや旧セキュリティ製品のAllowリストを確認する |
| 送信者台帳の作成 | SaaS、委託先、グループ会社、重要取引先を分類する |
| ポリシー設計 | 全社向け、役員向け、財務向けなど適用対象を分ける |
| 優先順位設計 | Strict/Standard preset、カスタムポリシー、既定ポリシーの関係を整理する |
| 検証期間の設定 | 本番前に代表ユーザーで誤検知を確認する |
| 例外承認フロー | 緊急許可と恒久許可の手順を分ける |
| 監査ログ・証跡 | 変更履歴をチケットや変更管理システムに残す |
移行時にありがちな失敗は、旧環境のAllowリストをそのまま新環境へ移すことです。古い例外の中には、すでに使われていない取引先、退役したSaaS、不要になった配信ドメインが含まれていることがあります。移行は、不要な例外を削除する良い機会でもあります。
判断基準：Trusted senders and domainsとTenant Allow/Block Listのどちらを使うか
どちらを使うべきか迷った場合は、原因と目的で判断します。
| 判断ポイント | Trusted senders and domainsが向く場合 | Tenant Allow/Block Listが向く場合 |
|---|---|---|
| 主な原因 | なりすまし保護による継続的な誤検知 | フィルタリング判定全体を手動で上書きしたい |
| 対象 | 特定のAnti-phishing policy内の送信者・ドメイン | テナント単位の送信者、URL、ファイルなど |
| 運用目的 | Impersonation protectionの例外管理 | Allow/Blockの集中管理 |
| リスク | 信頼範囲を広げすぎると、なりすまし検知が弱まる | 不要なAllowが悪性メールの通過につながる |
| まず確認すべきこと | どのAnti-phishing policyが検知したか | 既存のAllow/Block、判定カテゴリ、期限 |
実務では、なりすまし保護が原因なら、まずAnti-phishing policy側を確認します。Tenant Allow/Block Listは便利ですが、すべての誤検知をそこで解決しようとすると、例外が肥大化しやすくなります。
今回の更新を受けて今すぐ確認すべきこと
今回のMicrosoft Defender公式ドキュメント更新は、管理者に対して「Submissionsだけで誤検知対応を完了したつもりにならない」ことを求めています。
まず確認すべきことは、次の3つです。
1つ目は、誤ってブロックされた正当なメールをSubmissionsで提出した後、再発時の対応手順が明文化されているかです。
2つ目は、なりすまし保護による誤検知について、Anti-phishing policyのTrusted senders and domainsを確認する運用になっているかです。
3つ目は、Tenant Allow/Block ListのAllowエントリが、必要最小限の範囲、明確な理由、適切な期限で管理されているかです。
今回の更新は小さなNOTEの追加ですが、運用上の意味は大きいものです。Microsoft Defenderを企業メール防御の中核として使っている組織は、Submissions、Anti-phishing policy、Tenant Allow/Block Listの役割を整理し、誤検知対応の手順書に反映しておくべきです。
コメント