Microsoft 365のAnti-phishing policies設定確認ガイド｜Defender for Office 365のなりすまし保護を実務で見直す

Microsoft 365のAnti-phishing policiesでなりすまし保護を設定する場合、最初に確認すべき結論は「Microsoft DefenderポータルのAnti-phishing画面で、既定ポリシーだけでなく、プリセットセキュリティポリシー、カスタムポリシー、除外設定、ユーザー側の許可設定まで確認する」ことです。
特にMicrosoft Defender for Office 365では、ユーザーなりすまし、ドメインなりすまし、メールボックスインテリジェンス、スプーフィング検出、DMARCの扱いが複数の設定に分かれています。管理画面で有効にしただけでは、実際の配信結果と一致しないことがあります。

この記事では、2026年6月23日に更新されたMicrosoft Learnの「Email entity pageにおけるoverrideの理解」も踏まえ、Anti-phishing policiesの設定場所、利用条件、確認手順、ユーザー周知で押さえるべきポイントを実務向けに整理します。Microsoft 365のメールなりすまし対策を「設定したつもり」で終わらせず、誤検知・見逃し・問い合わせ対応まで見据えて確認できる内容です。 (Microsoft Learn)

Microsoft 365のAnti-phishing policiesとは

Microsoft 365のAnti-phishing policiesは、フィッシングメール、送信者のなりすまし、ドメインのなりすまし、スプーフィングなどを検出・制御するためのメール保護ポリシーです。

Microsoft Learnでは、すべてのクラウドメールボックスに基本的なアンチフィッシング機能が提供され、Microsoft Defender for Office 365ではさらに高度ななりすまし保護やしきい値設定、レポート機能が利用できると説明されています。Anti-phishing policiesの管理場所は、Microsoft Defenderポータルの Email & collaboration > Policies & rules > Threat policies > Anti-phishing です。 (Microsoft Learn)

ここで注意したいのは、日本語で「なりすまし保護」と言うと、次の2種類が混同されやすい点です。

用語	何を検出するか	例
スプーフィング保護	表示上のFromアドレスと実際の送信元が一致しない、認証に問題があるメール	自社ドメインを勝手に名乗る外部メール
なりすまし保護（Impersonation protection）	正規ユーザーや正規ドメインに似せた表示名・アドレス・ドメイン	contoso.com に似せた contosososo.com、役員名を使った外部送信者

スプーフィングはSPF、DKIM、DMARC、複合認証などと関係します。一方、Defender for Office 365のなりすまし保護は、正規ドメインに似たドメインや、役員・経理担当者・外部取引先などの名前を装ったメールを検出する考え方です。攻撃者が似たドメインを取得し、SPFやDKIMを正しく設定している場合、単純な認証チェックだけでは見抜けないことがあります。 (Microsoft Learn)

設定場所はMicrosoft DefenderポータルのAnti-phishing画面

Anti-phishing policiesは、Microsoft 365管理センターではなく、主にMicrosoft Defenderポータルから確認します。

管理画面での基本的な確認経路は次のとおりです。

確認項目	場所
Anti-phishing policies一覧	Microsoft Defenderポータル > Email & collaboration > Policies & rules > Threat policies > Anti-phishing
直接アクセス	https://security.microsoft.com/antiphishing
プリセットセキュリティポリシー	Microsoft Defenderポータル > Email & collaboration > Policies & rules > Threat policies > Preset security policies
隔離メッセージ	Microsoft Defenderポータル > Email & collaboration > Review > Quarantine
ユーザー報告メッセージ	Microsoft Defenderポータル > Email & collaboration > Submissions > User reported
Tenant Allow/Block List	Microsoft Defenderポータル > Email & collaboration > Policies & rules > Threat policies > Tenant Allow/Block Lists

Microsoft Learnでは、Anti-phishing policiesの設定はMicrosoft DefenderポータルまたはExchange Online PowerShellで行えるとされています。ポータルで確認する場合は、一覧画面でポリシー名、状態、優先順位を確認し、各ポリシーの詳細フライアウトから設定を編集します。 (Microsoft Learn)

利用条件と権限を先に確認する

Anti-phishing policiesを確認する前に、ライセンスと管理権限を整理しておく必要があります。ここを曖昧にしたまま作業すると、「画面が見えない」「設定は見えるが保存できない」「想定した項目が表示されない」といった問題が起きます。

Microsoft Defender for Office 365向けのAnti-phishing policiesは、Defender for Office 365 Plan 1、Plan 2、Microsoft Defender XDRが対象です。基本的なアンチスプーフィング機能はクラウドメールボックス全体で利用できますが、ユーザーなりすまし保護、ドメインなりすまし保護、フィッシングしきい値などの高度な設定はDefender for Office 365側の機能として扱われます。 (Microsoft Learn)

確認項目	実務での見方
ライセンス	Microsoft Defender for Office 365 Plan 1/Plan 2、または対象プランに含まれるか確認する
管理権限	Security Administrator、Organization Managementなど、ポリシー変更に必要な権限を確認する
読み取り専用権限	Security Reader、Global Readerなどでは確認はできても変更できない場合がある
PowerShell利用	Exchange Online PowerShellへの接続権限と実行ロールを確認する
反映時間	新規作成・変更後、適用まで最大30分程度かかる前提で確認する

Microsoft Learnでは、ポリシーの追加・変更・削除にはOrganization ManagementまたはSecurity Administratorロールグループなどが必要で、読み取り専用にはGlobal Reader、Security Reader、View-Only Organization Managementなどが挙げられています。また、最小権限の原則に基づき、Global Administratorは緊急時などに限定することが推奨されています。 (Microsoft Learn)

既定ポリシー、カスタムポリシー、プリセットポリシーの違い

Anti-phishing policiesの確認でよくある失敗は、既定ポリシーだけを見て「有効になっている」と判断してしまうことです。実際には、既定ポリシー、カスタムポリシー、Standard/Strictのプリセットセキュリティポリシーが関係します。

種類	特徴	確認ポイント
既定のAnti-phishing policy	すべての受信者に自動適用される。無効化できない	基本設定は入っているが、高度ななりすまし保護が未設定の場合がある
カスタムポリシー	特定のユーザー、グループ、ドメインに適用できる	優先順位、対象、除外、保護対象ユーザーを確認する
Standard/Strict preset security policies	Microsoft推奨値に近い保護をまとめて適用する	対象ユーザーが含まれている場合、個別ポリシーより優先されることがある
PowerShellで作成・管理したポリシー	GUIでは見え方が分かりにくい場合がある	Get-AntiPhishPolicy と Get-AntiPhishRule で確認する

Microsoft Learnでは、StandardまたはStrictのプリセットセキュリティポリシーに受信者が含まれている場合、既定またはカスタムAnti-phishing policiesの設定が無視されると説明されています。つまり、実務では「Anti-phishingの一覧だけを見る」のではなく、「対象ユーザーがプリセットポリシーに含まれていないか」まで確認する必要があります。 (Microsoft Learn)

設定確認で見るべき主要項目

Anti-phishing policiesの設定確認では、画面を上から順に眺めるだけでは不十分です。実務では、次の順番で確認すると抜け漏れを減らせます。

対象ユーザー、グループ、ドメイン

カスタムポリシーでは、どの受信者にポリシーを適用するかを指定します。指定できるのは、ユーザー、グループ、ドメインです。

特に注意したいのは、条件の組み合わせです。Microsoft Learnでは、同じ種類の条件はOR、異なる種類の条件はANDとして扱われる例が示されています。たとえば「ユーザーA」と「役員グループ」を同時に条件指定した場合、ユーザーAが役員グループにも所属している場合にのみ適用されます。 (Microsoft Learn)

実務では、次のようなミスがよくあります。

よくあるミス	起きる問題
ユーザー条件とグループ条件を同時に入れる	想定より対象が狭くなる
除外設定を過去の検証用のまま残す	本番ユーザーに保護がかからない
動的配布グループを使おうとする	対応していない条件があり、期待どおりに適用されない
ドメイン単位で適用しているつもりで一部サブドメインを見落とす	特定部門・子会社のメールボックスだけ設定差分が出る

ポリシー名には「対象」「目的」「強度」を入れておくと、後から調査しやすくなります。たとえば、AntiPhish-Executives-Strict、AntiPhish-Finance-Standard のような命名にすると、問い合わせ時に判断しやすくなります。

Phishing email threshold

Phishing email thresholdは、フィッシング判定の感度を調整する設定です。Defender for Office 365では、Standard、Aggressive、More aggressive、Most aggressiveの4段階が用意されています。感度を高くすると検出力は上がりますが、正規メールを悪意あるメールと判定する可能性も高くなります。 (Microsoft Learn)

しきい値	使いどころ	注意点
1 – Standard	まず全社に適用する標準設定	検出強度は控えめ
2 – Aggressive	役員、経理、人事など狙われやすい部門	誤検知の問い合わせ増加に備える
3 – More aggressive	重要部門の検証環境や段階導入	正規メールの隔離が増える可能性がある
4 – Most aggressive	特にリスクが高い一部対象で慎重に検証	全社一律適用は避けたい

実務では、いきなり全社で高いしきい値にするより、役員・経理・情報システム・採用担当など、標的型メールを受けやすい部門から段階的に適用する方が安全です。隔離件数、誤検知、ユーザー報告数を見ながら調整しましょう。

ユーザーなりすまし保護

ユーザーなりすまし保護では、特定の内部または外部メールアドレスを「保護対象」として登録します。代表例は、社長、役員、経理責任者、情報システム責任者、よく狙われる外部取引先の担当者です。

Microsoft Learnでは、1つのAnti-phishing policyでユーザーなりすまし保護に指定できるユーザー数は最大350人とされています。また、既定では保護対象の送信者アドレスは構成されていません。つまり、Defender for Office 365を導入しているだけでは、役員や経理担当者が自動的に保護対象として登録されるとは限りません。 (Microsoft Learn)

実務での登録候補は次のとおりです。

保護対象	登録理由
CEO、代表取締役、役員	承認依頼、送金依頼、緊急指示を装われやすい
経理・財務責任者	請求書、口座変更、振込依頼の標的になりやすい
人事・採用担当	履歴書、応募書類、外部候補者を装う攻撃が来やすい
情報システム管理者	パスワード、MFA、アカウント確認を装われやすい
主要取引先の担当者	請求書差し替え、ドメイン類似攻撃のリスクがある

登録時は、表示名だけでなくメールアドレスも確認してください。役員の表示名が複数表記されている場合、たとえば「山田 太郎」「Taro Yamada」「T. Yamada」など、社内外で使われる表記を棚卸ししておくと検知の抜けを減らせます。

ドメインなりすまし保護

ドメインなりすまし保護では、自社が所有するドメインや、保護したい外部ドメインに似たドメインを使う攻撃を検出します。たとえば、自社ドメインが example.co.jp の場合、似た文字列、別TLD、余分な文字を含むドメインが攻撃に使われる可能性があります。

設定では、次の2つを確認します。

設定	確認内容
Include the domains I own	Microsoft 365テナントに登録済みの自社ドメインを保護対象にする
Include custom domains	主要取引先、グループ会社、ブランドドメインなどを追加する

ただし、信頼済みドメインとして登録した場合、サブドメインは自動的には含まれません。Microsoft Learnでは、Trusted domain entriesは指定したドメインのサブドメインを含まないため、必要に応じてサブドメインごとに追加する必要があると説明されています。 (Microsoft Learn)

たとえば、example.com を信頼済みドメインにしても、mail.example.com や notice.example.com を別途確認しなければならないケースがあります。取引先のメール配信システムやマーケティングツールを許可する場合は、ドメイン単位で雑に許可せず、送信元、DKIM署名、Return-Path、配信経路を確認してから最小限で登録しましょう。

Mailbox intelligence

Mailbox intelligenceは、受信者と送信者の過去の通信関係をもとに、通常とは異なる送信者やなりすましの可能性を判断する機能です。Microsoft Learnでは、この設定は既定で選択されており、有効のままにすることが推奨されています。 (Microsoft Learn)

ただし、Mailbox intelligenceには実務上の注意点があります。Microsoft Learnでは、送信者と受信者が以前にメールでやり取りしている場合、ユーザーなりすまし保護やMailbox intelligence protectionが機能しない場合があると説明されています。これは、過去の通信関係が「通常の相手」と判断されるためです。 (Microsoft Learn)

そのため、次のようなケースでは、Mailbox intelligenceだけに頼らない運用が必要です。

ケース	追加で確認すべきこと
取引先アカウントが侵害された	URL、添付ファイル、本文の不自然さ、送金先変更を別途確認する
過去にやり取りした相手から急な請求書変更が来た	電話や別チャネルで確認する
役員本人のメールアカウントが侵害された	Anti-phishingだけでなくサインインログ、MFA、条件付きアクセスも確認する

Spoof intelligenceとDMARCの扱い

Spoof intelligenceは、送信者のスプーフィングを検出する機能です。Microsoft Learnでは、Spoof intelligenceは既定で有効であり、有効のままにすることが推奨されています。 (Microsoft Learn)

確認すべき項目は次のとおりです。

項目	推奨される確認
Enable spoof intelligence	原則オンにする
If the message is detected as spoof by spoof intelligence	迷惑メールフォルダー移動か隔離かを運用方針で選ぶ
Honor DMARC record policy	送信者のDMARCポリシーを尊重するか確認する
p=quarantine時のアクション	隔離または迷惑メールフォルダー移動を選ぶ
p=reject時のアクション	隔離または拒否を選ぶ

DMARCの扱いは、単に「拒否すれば安全」とは言い切れません。正規の外部サービスがメール認証を正しく構成していない場合、正規メールが隔離・拒否されることがあります。逆に、DMARCを軽視すると、なりすましメールが届きやすくなります。

特にMXレコードがMicrosoft 365ではなく、前段にメールゲートウェイやサードパーティフィルターを置いている場合は、Enhanced Filtering for Connectorsの確認が重要です。Microsoft Learnでは、MXレコードがMicrosoft 365を指していない場合、Spoof intelligenceを無効化するのではなく、Enhanced Filtering for Connectorsを有効化する旨が案内されています。 (Microsoft Learn)

アクション設定は「検出後にどう扱うか」を決める重要項目

なりすまし保護を有効化しても、アクションが「何もしない」になっていると、ユーザーに届く可能性があります。設定確認では、検出条件だけでなく、検出後のアクションまで必ず確認します。

Microsoft Defender for Office 365のAnti-phishing policiesでは、ユーザーなりすまし、ドメインなりすまし、Mailbox intelligenceによるなりすまし、Spoof intelligenceによる検出ごとにアクションを指定できます。選択肢には、何もしない、リダイレクト、迷惑メールフォルダーへ移動、隔離、Bcc追加、配信前削除などがあります。 (Microsoft Learn)

検出対象	実務での推奨判断
ユーザーなりすまし	役員・経理などは隔離を基本に検討
ドメインなりすまし	自社・主要取引先の類似ドメインは隔離を検討
Mailbox intelligence検出	誤検知状況を見ながら隔離または迷惑メール移動
Spoof intelligence検出	初期は迷惑メール移動、重要部門は隔離を検討
DMARC p=reject失敗	可能なら拒否または隔離。ただし業務影響を検証する

最初から「削除」を選ぶと、後から調査しにくくなることがあります。導入初期は隔離を中心にし、セキュリティ担当者がQuarantineとSubmissionsで検証できる状態にしておくと安全です。

ユーザーに表示される安全ヒントも確認する

Anti-phishing policiesは、管理者だけの設定ではありません。ユーザーの画面に表示される安全ヒントや警告表示を理解してもらわないと、保護効果が下がります。

確認すべき主な表示は次のとおりです。

表示・ヒント	ユーザーに伝えるべきこと
First contact safety tip	初めて、またはあまり連絡のない送信者からのメールで表示される。急な依頼は確認する
User impersonation safety tip	送信者が過去の相手や保護対象ユーザーに似ている可能性がある
Domain impersonation safety tip	自社や関連ドメインに似たドメインからの可能性がある
Unusual characters safety tip	文字化けではなく、似た文字を使ったなりすましの可能性がある
?アイコン	SPF、DKIM、DMARC、複合認証に問題がある可能性がある
viaタグ	表示上のFromとDKIM署名またはMAIL FROMのドメインが異なる可能性がある

Microsoft Learnでは、First contact safety tipは初めてメールを受け取る送信者、またはあまりメールを受け取らない送信者からのメールで表示されると説明されています。また、?アイコンやviaタグはSpoof intelligenceがオンの場合に利用できる表示です。 (Microsoft Learn)

ユーザー周知では、単に「警告が出たら注意してください」では不十分です。次のように、行動ベースで伝えましょう。

状況	ユーザーに求める行動
役員名で送金・ギフトカード・口座変更を依頼された	メールに返信せず、Teamsや電話など別経路で確認する
via表示がある請求書メールを受け取った	送信元ドメイン、過去の請求書、取引先担当者に確認する
初回連絡の相手から添付ファイルが届いた	添付を開く前に業務上の妥当性を確認する
警告が出たが正規メールに見える	Reportボタンで報告し、必要なら情報システム部門へ連絡する
隔離通知が届いた	自己判断でリリースせず、社内ルールに従う

2026年6月23日の更新で特に確認したい「override」の考え方

2026年6月23日に更新されたMicrosoft Learnの「Understanding overrides within the email entity page」では、Email entity pageで確認できるoverrideの種類と、想定外の配信結果を調査するための観点が整理されています。ここは、Anti-phishing policiesの設定確認でも重要です。 (Microsoft Learn)

overrideとは、簡単に言えば「本来の検出や配信判断に影響を与えた別の設定」です。たとえば、Anti-phishing policyでは隔離されるはずのメールが受信トレイに届いた場合、ユーザーの安全な差出人リスト、管理者の許可リスト、トランスポートルール、サードパーティフィルターなどが影響している可能性があります。

overrideの例	実務での確認ポイント
Sender address list（User override）	ユーザーがOutlookで安全な差出人またはブロック済み差出人に登録していないか
Sender domain list（Admin Override）	管理者がアンチスパムポリシーでドメイン許可を入れていないか
Tenant Allow/Block List spoof	Tenant Allow/Block Listでスプーフィング判定を上書きしていないか
Exchange transport rule	メールフロールールでSCL変更、許可、転送などをしていないか
Third Party Filter	MXがサードパーティサービスを指し、Microsoft 365のフィルターを迂回していないか
Quarantine release	管理者またはユーザーが隔離から解放していないか
Phishing simulation	フィッシング訓練用メールとして扱われていないか

Microsoft Learnでは、overrideは状況によって必ずしも尊重されるわけではなく、たとえばマルウェアを含むメールはユーザーが安全な差出人に設定していても自動的にブロックされる例が示されています。つまり、overrideは「すべてを無効化する万能の許可」ではなく、メールの種類や脅威判定によって扱いが変わります。 (Microsoft Learn)

実務では、ユーザーから「このメールはなぜ届いたのか」「なぜ隔離されたのか」と問い合わせを受けたら、Anti-phishing policyだけで判断しないことが大切です。Email entity page、メッセージトレース、Quarantine、Submissions、Tenant Allow/Block List、ユーザーのJunk email設定をセットで確認しましょう。

設定確認の実務手順

ここからは、管理者が実際に確認する手順を整理します。新規設定時だけでなく、既存環境の棚卸しにも使えます。

Microsoft Defenderポータルで確認する手順

手順	確認内容
1	Microsoft Defenderポータルを開く
2	Email & collaboration > Policies & rules > Threat policies > Anti-phishing に移動する
3	既定ポリシー、カスタムポリシー、Standard/Strict関連ポリシーを確認する
4	各ポリシーのStatus、Priority、対象ユーザーを確認する
5	Phishing thresholdを確認する
6	Enable users to protectで保護対象ユーザーを確認する
7	Enable domains to protectで自社・カスタムドメインを確認する
8	Trusted senders and domainsに過剰な例外がないか確認する
9	Enable mailbox intelligenceとimpersonation protectionの状態を確認する
10	Enable spoof intelligence、DMARCの扱い、検出後アクションを確認する
11	Safety tips & indicatorsの表示設定を確認する
12	変更後、最大30分程度の反映時間を考慮して検証する

Microsoft Learnでは、Anti-phishingページからポリシー一覧、Status、Priorityを確認でき、ポリシーを選択して詳細フライアウトから設定を編集できると説明されています。設定後の確認方法として、ポータル上でポリシー一覧と詳細を確認する方法に加え、Exchange Online PowerShellで Get-AntiPhishPolicy と Get-AntiPhishRule を実行する方法も示されています。 (Microsoft Learn)

PowerShellで確認する手順

GUIだけでは、複数ポリシーの比較や棚卸しが面倒です。複数テナントを管理している場合や、監査証跡を残したい場合はExchange Online PowerShellで確認すると効率的です。

代表的な確認コマンドは次のとおりです。

Get-AntiPhishPolicy | Format-Table Name,Enabled,PhishThresholdLevel,EnableSpoofIntelligence,EnableMailboxIntelligence

Get-AntiPhishRule | Format-Table Name,State,Priority

特定ポリシーの詳細を確認する場合は、次のように実行します。

Get-AntiPhishPolicy -Identity "ポリシー名" | Format-List

Get-AntiPhishRule -Identity "ルール名" | Format-List

PowerShellで確認する際は、AntiPhishPolicyとAntiPhishRuleの違いに注意してください。ポリシーは保護設定の本体、ルールは対象者や優先順位を管理する要素です。Microsoft Learnでも、PowerShellではポリシーとルールを分けて確認・変更する手順が示されています。 (Microsoft Learn)

誤検知・見逃しが起きたときの確認ポイント

Anti-phishing policiesを設定しても、誤検知や見逃しは完全には避けられません。重要なのは、発生時にどこを見ればよいかを決めておくことです。

正規メールが隔離された場合

正規メールが隔離された場合、すぐに広範囲の許可設定を入れるのは危険です。まず、なぜ隔離されたのかを確認します。

確認場所	見るポイント
Quarantine	どのポリシー・どの判定で隔離されたか
Email entity page	検出技術、override、配信位置
Submissions	Microsoftへ送信済みか、判定結果はどうか
Tenant Allow/Block List	一時許可が必要か、恒久許可にすべきか
送信元DNS	SPF、DKIM、DMARCが正しく構成されているか

正規メールを救済する場合は、まず送信元にSPF、DKIM、DMARC、送信ドメイン整合性の修正を依頼するのが基本です。安易にドメイン全体を許可すると、本物の攻撃メールまで通してしまう可能性があります。

なりすましメールが届いた場合

なりすましメールが受信トレイに届いた場合は、ポリシーが無効だったとは限りません。ユーザーや管理者のoverride、トランスポートルール、前段フィルター、プリセットポリシーの優先順位が影響していることがあります。

確認順は次のとおりです。

順番	確認内容
1	対象ユーザーがどのAnti-phishing policyに一致しているか
2	プリセットセキュリティポリシーに含まれていないか
3	送信者・ドメインがTrusted senders/domainsに入っていないか
4	Tenant Allow/Block Listで許可されていないか
5	ユーザーのSafe senders設定が影響していないか
6	Exchange transport ruleでSCLや配信先を変更していないか
7	MX前段のサードパーティフィルターで判定が上書きされていないか
8	Email entity pageでoverrideを確認する

この確認を定型化しておくと、問い合わせ対応が属人化しにくくなります。

ユーザー報告の運用もセットで整える

Anti-phishing policiesを強化するだけでは、メールセキュリティ運用は完成しません。ユーザーが不審メールを見つけたときに、どこへ、どの方法で報告するかを明確にする必要があります。

Microsoftは、Outlookの対応バージョンで利用できる組み込みのReportボタンを提供しており、管理者はユーザー報告メッセージをMicrosoft、指定した報告用メールボックス、またはその両方に送るよう構成できます。報告されたメッセージは、DefenderポータルのSubmissionsページのUser reportedタブで確認できます。 (Microsoft Learn)

ユーザー周知では、次のルールを明文化しておくと効果的です。

周知項目	伝える内容
不審メールの報告方法	OutlookのReportボタンを使う
転送での報告を避ける理由	ヘッダーやメタデータが欠け、調査精度が落ちる場合がある
緊急依頼への対応	返信ではなく、別経路で本人確認する
隔離通知への対応	自己判断で解放せず、社内ルールに従う
誤検知の報告	「正規メールが届かない」だけでなく、送信者、件名、時刻を添えて報告する
安全な差出人登録	個人判断で広範囲に許可しない

特に「安全な差出人に入れれば解決」という文化がある組織では注意が必要です。2026年6月23日更新のMicrosoft Learnでも、ユーザーや管理者の許可設定がoverrideとして配信結果に影響することが示されています。正規メールが届かない問題を短期的に解決できても、長期的にはなりすましメールの通過リスクを高める場合があります。 (Microsoft Learn)

設定後に実施したいチェックリスト

Anti-phishing policiesの設定確認は、一度だけで終わらせるものではありません。人事異動、ドメイン追加、外部サービス導入、取引先変更によって、適切な設定は変わります。

タイミング	確認すること
初回導入時	既定ポリシー、カスタムポリシー、プリセットポリシーの関係を整理する
役員交代時	保護対象ユーザーを更新する
新ドメイン追加時	ドメインなりすまし保護とDNS認証を確認する
メール配信サービス導入時	SPF、DKIM、DMARC、via表示、許可設定を確認する
誤検知が増えた時	しきい値、Trusted senders/domains、隔離ポリシーを確認する
なりすまし被害が発生した時	対象ポリシー、override、Tenant Allow/Block List、ユーザー設定を確認する
四半期ごと	PowerShellで設定をエクスポートし、前回との差分を確認する

設定値だけでなく、「なぜその設定にしているのか」を記録しておくことも重要です。例外設定は特に放置されやすいため、登録理由、依頼者、承認者、期限を残しておきましょう。

実務でおすすめの初期方針

多くの組織では、次の方針から始めると運用しやすくなります。

項目	初期方針
Spoof intelligence	オンのままにする
Mailbox intelligence	オンのままにする
ユーザーなりすまし保護	役員、経理、人事、情シス、重要取引先から登録する
ドメインなりすまし保護	自社ドメイン、主要ブランド、グループ会社、重要取引先を登録する
Phishing threshold	全社はStandard、重要部門は段階的にAggressiveを検証する
検出時アクション	導入初期は隔離中心。削除は慎重に使う
Trusted senders/domains	最小限にし、期限付きで管理する
ユーザー周知	Reportボタン、警告表示、送金依頼時の本人確認を重点的に案内する
定期確認	四半期ごと、または役員・ドメイン・配信サービス変更時に見直す

Microsoft Learnでも、カスタムAnti-phishing policiesを個別に作成・管理する代わりに、StandardまたはStrictのプリセットセキュリティポリシーにユーザーを追加することが一般的に推奨されています。ただし、役員や経理など特にリスクが高い対象には、カスタムポリシーで保護対象ユーザーやドメインを明示する運用が有効です。 (Microsoft Learn)

まとめ：Anti-phishing policiesは「有効化」より「適用確認」が重要

Microsoft 365のAnti-phishing policiesでなりすまし保護を設定する際は、Microsoft DefenderポータルのAnti-phishing画面で設定を確認するだけでなく、対象ユーザー、優先順位、プリセットポリシー、除外、Trusted senders/domains、Tenant Allow/Block List、ユーザー側のSafe senders設定まで確認する必要があります。

特に2026年6月23日のMicrosoft Learn更新で整理されたoverrideの観点は、実務上とても重要です。ポリシー上は隔離されるはずのメールが届いたり、正規メールが隔離されたりする場合、Anti-phishing policy単体ではなく、Email entity pageで配信結果に影響した要素を確認しましょう。

次に取るべき行動は、現在の設定を棚卸しすることです。まずはDefenderポータルでAnti-phishing policies一覧を開き、既定ポリシー、カスタムポリシー、Standard/Strictプリセットポリシーの対象を確認してください。そのうえで、役員・経理・人事・情報システムなどの重要ユーザーが保護対象に入っているか、過剰な許可設定が残っていないか、ユーザーがReportボタンを使える状態になっているかを確認しましょう。