Microsoft 365のAnti-phishing policiesでなりすまし保護を設定したい場合、まず確認すべき場所はMicrosoft Defenderポータルの「Email & collaboration > Policies & rules > Threat policies > Anti-phishing」です。デフォルトポリシーは全受信者に自動適用されますが、役員・経理・人事・管理者など狙われやすいユーザーには、Microsoft Defender for Office 365のなりすまし保護を明示的に設定することが重要です。(Microsoft Learn)
この記事では、2026年6月23日時点で確認できるMicrosoft Learnの公式情報をもとに、Anti-phishing policiesで何ができるのか、誰が対象になるのか、設定が見えない・使えない時にどこを確認すべきかをQ&A形式で整理します。設定画面だけを追うのではなく、「どのユーザーを守るべきか」「誤検知をどう抑えるか」「標準ポリシーとカスタムポリシーをどう使い分けるか」まで実務目線で解説します。
Microsoft 365のAnti-phishing policiesでできること
Microsoft 365のAnti-phishing policiesは、フィッシングメールや送信者の偽装、なりすまし攻撃を検出・制御するためのメール保護ポリシーです。Microsoft 365のクラウドメールボックスには基本的ななりすまし対策が用意されていますが、Microsoft Defender for Office 365では、ユーザーなりすまし、ドメインなりすまし、メールボックスインテリジェンス、フィッシング判定しきい値など、より細かい制御が可能になります。(Microsoft Learn)
特に混同しやすいのが「スプーフィング」と「なりすまし」です。どちらも送信者を信頼させる攻撃ですが、見るべきポイントが異なります。
| 項目 | 主な意味 | 典型例 | Anti-phishing policiesでの主な対策 |
|---|---|---|---|
| スプーフィング | 表示上のFromアドレスと実際の送信元が一致しない、または認証に問題がある状態 | 自社ドメインから送られたように見えるが、実際は別の送信基盤から送られている | Spoof intelligence、DMARCポリシーの尊重、未認証送信者の表示 |
| なりすまし | 実在するユーザーやドメインに似せた名前・アドレス・ドメインでだます攻撃 | contoso.comに似た別ドメイン、役員名と似た表示名を使うメール | User impersonation protection、Domain impersonation protection、Mailbox intelligence |
重要なのは、攻撃者が似たドメインを取得し、SPF・DKIM・DMARCを整えて送信してくる場合があることです。この場合、単純なメール認証だけでは「認証済みの別ドメイン」として扱われる可能性があるため、Defender for Office 365のなりすまし保護が効いてきます。(Microsoft Learn)
Anti-phishing policiesは誰が設定すべきですか？
Anti-phishing policiesを設定すべきなのは、Microsoft 365のメール保護を管理するセキュリティ管理者、Exchange Online管理者、Microsoft 365管理者です。設定の追加・変更には権限が必要で、Microsoft Learnでは、Defender XDRのRBAC、Exchange OnlineのOrganization ManagementまたはSecurity Administrator、Microsoft EntraのSecurity Administratorなどが関連する権限として説明されています。(Microsoft Learn)
実務上は、次のような組織ほど優先度が高くなります。
| 対象組織・担当者 | 優先して確認したい理由 |
|---|---|
| 経理・財務部門がある組織 | 請求書、振込依頼、口座変更依頼を装った攻撃を受けやすい |
| 役員・管理職が外部と頻繁にメールする組織 | 役員名を使った社内向け依頼メールが悪用されやすい |
| 人事・総務・採用担当 | 個人情報、雇用契約、添付ファイルのやり取りが多い |
| 取引先・委託先とのメールが多い組織 | 取引先ドメインに似せたなりすましを受けやすい |
| Microsoft 365を標準設定のまま使っている組織 | デフォルト保護だけでは、なりすまし保護の詳細設定が不足する場合がある |
小規模な組織でも、「社長」「経理」「管理者」「採用窓口」など、狙われるメールアドレスは限られることが多いです。最初から全社員を細かく分けるより、被害時の影響が大きいユーザーから保護対象に入れる方が現実的です。
どこから設定しますか？
Microsoft Defenderポータルで、次の順に進みます。
| 手順 | 操作 |
|---|---|
| 1 | Microsoft Defenderポータルを開く |
| 2 | 「Email & collaboration」を開く |
| 3 | 「Policies & rules」を選ぶ |
| 4 | 「Threat policies」を開く |
| 5 | 「Anti-phishing」を選択する |
| 6 | 既存ポリシーを編集するか、「Create」から新しいポリシーを作成する |
新しいAnti-phishing policyを作成する場合は、ポリシー名、適用対象のユーザー・グループ・ドメイン、フィッシングしきい値、ユーザーなりすまし保護、ドメインなりすまし保護、メールボックスインテリジェンス、スプーフィング時のアクション、警告表示などを順番に設定します。(Microsoft Learn)
ただし、まずStandardまたはStrictのプリセットセキュリティポリシーを使う選択肢もあります。Microsoft Learnでは、カスタムポリシーを個別に作り込む代わりに、StandardまたはStrictのプリセットセキュリティポリシーを有効化してユーザーを追加する方法も推奨されています。(Microsoft Learn)
デフォルトポリシーだけで十分ですか？
デフォルトポリシーだけでは不十分な場合があります。デフォルトのAnti-phishing policyは全受信者に自動で適用されますが、Defender for Office 365のデフォルトポリシーでは、スプーフィング保護とメールボックスインテリジェンスは提供される一方で、ユーザーなりすまし保護、ドメインなりすまし保護、フィッシングメールしきい値などは既定では十分に構成されていません。(Microsoft Learn)
そのため、次のいずれかの対応を検討します。
| 状況 | おすすめの対応 |
|---|---|
| まず標準的な保護を整えたい | Standardプリセットセキュリティポリシーを検討する |
| 役員・経理などを強めに守りたい | StrictプリセットまたはカスタムAnti-phishing policyを検討する |
| 特定部門だけ誤検知を抑えたい | 対象者を絞ったカスタムポリシーを作る |
| 取引先ドメインのなりすましを検知したい | Domain impersonation protectionにカスタムドメインを追加する |
| 既存運用への影響を確認したい | 少人数のパイロットグループで先に検証する |
「全社に一気に最強設定を入れる」よりも、影響が大きいユーザーから段階的に適用し、隔離や誤検知の状況を見ながら広げる方が安全です。
なりすまし保護では誰を「保護対象ユーザー」に入れるべきですか？
User impersonation protectionでは、なりすまされやすい送信者を保護対象として指定します。ここで指定するのは、ポリシーを適用する受信者ではなく、「なりすまされる可能性が高い送信者」です。この違いを間違えると、思ったように保護が働きません。
優先して追加したいのは、次のようなユーザーです。
| 優先度 | 保護対象にしたいユーザー例 | 理由 |
|---|---|---|
| 高 | CEO、代表、役員、CFO | 振込依頼、緊急承認、機密情報要求に悪用されやすい |
| 高 | 経理責任者、財務担当、購買責任者 | 請求書・支払い関連の攻撃対象になりやすい |
| 高 | 人事責任者、採用担当 | 履歴書・契約書・個人情報を扱う |
| 中 | 情報システム管理者、Microsoft 365管理者 | アカウント確認や権限変更を装う攻撃に使われやすい |
| 中 | 外部の重要取引先担当者 | 取引先を装った依頼メールの検知に役立つ |
User impersonation protectionでは、1つのAnti-phishing policyにつき最大350ユーザーを指定できます。全社員を追加する用途ではなく、狙われやすい重要人物を選んで保護する設計です。(Microsoft Learn)
ドメインなりすまし保護では何を入れるべきですか？
Domain impersonation protectionでは、自社ドメインや重要な外部ドメインに似た送信元を検出しやすくします。自社で保有している承認済みドメインを保護するだけでなく、頻繁にやり取りする取引先、金融機関、クラウドサービス、委託先などのドメインをカスタムドメインとして追加する運用が考えられます。
ただし、カスタムドメインは1つのAnti-phishing policyにつき最大50件です。何でも追加するのではなく、「なりすまされた時の業務影響が大きいドメイン」に絞る必要があります。(Microsoft Learn)
実務では、次のような基準で選ぶと管理しやすくなります。
| 追加候補 | 判断基準 |
|---|---|
| 自社の主要ドメイン | 顧客・社内向けの公式メールで使う |
| グループ会社ドメイン | 社内に近い信頼関係があり、指示メールに見えやすい |
| 主要取引先ドメイン | 請求、発注、契約、納品のやり取りがある |
| 金融機関・決済関連ドメイン | 支払い変更や認証誘導に悪用されると影響が大きい |
| クラウド・SaaSベンダー | アカウント通知やログイン誘導を装いやすい |
なお、信頼済みドメインとして例外登録する場合、サブドメインは自動的に含まれません。必要なサブドメインは個別に追加する必要があります。(Microsoft Learn)
Mailbox intelligenceはオンにするべきですか？
Mailbox intelligenceは、ユーザーの通常のメールやり取りを学習し、頻繁に連絡している相手かどうかを判断材料にする機能です。Microsoft Learnでは、Enable mailbox intelligenceは既定でオン、Enable intelligence for impersonation protectionは既定ではオフと説明されています。メールボックスインテリジェンスによるなりすまし検知でアクションを取らせるには、両方の設定を意識する必要があります。(Microsoft Learn)
実務上は、Mailbox intelligenceを活用すると、同姓同名の外部担当者や、過去にやり取りのある正当な送信者を過剰にブロックしにくくなります。一方で、過去にやり取りがある送信者と受信者の組み合わせでは、なりすましとして扱われない場合があります。攻撃者が取引先アカウントを侵害して送信してきたケースまで完全に防ぐ設定ではないため、Safe Links、Safe Attachments、ユーザー教育、報告フローと組み合わせて考える必要があります。(Microsoft Learn)
Phishing email thresholdはどのレベルにすべきですか？
Phishing email thresholdは、機械学習モデルによるフィッシング判定の感度を調整する設定です。1がStandard、2がAggressive、3がMore aggressive、4がMost aggressiveです。数値を上げるほど検出は厳しくなりますが、正当なメールを悪いメールとして扱う誤検知の可能性も高くなります。(Microsoft Learn)
Microsoftの推奨設定では、Defender for Office 365のStandard構成で「3 – More aggressive」、Strict構成で「4 – Most aggressive」が示されています。(Microsoft Learn)
| 設定 | 向いているケース | 注意点 |
|---|---|---|
| 1 – Standard | まず影響を抑えて運用を始めたい | 検出感度は控えめ |
| 2 – Aggressive | 標準より少し強めたい | 誤検知確認が必要 |
| 3 – More aggressive | 役員・経理など高リスク部門を守りたい | 隔離レビュー体制を用意したい |
| 4 – Most aggressive | 厳格な組織、攻撃を強く警戒する部門 | 正当メールの隔離が増える可能性がある |
全社一律で最初から4にするより、まず高リスク部門に絞って適用し、隔離されたメール、ユーザーからの問い合わせ、誤検知の傾向を確認するのが現実的です。
Spoof intelligenceとDMARCの設定はどう考えればよいですか？
Spoof intelligenceは、スプーフィングされた送信者を検出し、許可またはブロックの判断に利用する機能です。Microsoft Learnでは、この設定は既定でオンになっており、オンのままにすることが推奨されています。(Microsoft Learn)
また、Anti-phishing policiesでは、送信者側のDMARCポリシーを尊重するかどうかを制御できます。DMARCポリシーがp=quarantineの場合は隔離、p=rejectの場合は拒否といった動作を指定できます。(Microsoft Learn)
注意したいのは、MXレコードがMicrosoft 365ではなく、前段のメールゲートウェイや別サービスを向いている構成です。この場合、スプーフィング保護をオフにするのではなく、Enhanced Filtering for Connectorsを検討する必要があります。(Microsoft Learn)
Safety tipsや「via」表示は有効にするべきですか？
基本的には有効化を検討すべきです。First contact safety tipは、初めて受信する、またはあまり受信しない送信者からのメールに注意喚起を表示する機能です。この設定はSpoof intelligenceやなりすまし保護に依存せず利用できます。(Microsoft Learn)
また、未認証送信者の「?」表示や「via」タグは、Spoof intelligenceがオンの時に利用できます。ユーザーが送信者の違和感に気づく助けになりますが、業務上正当な外部配信サービスやマーケティングメールでも表示される場合があります。その場合は、まずSPF、DKIM、DMARCなどのメール認証を整え、それでも必要なものだけTenant Allow/Block Listや信頼済み送信者で調整します。(Microsoft Learn)
ただし、S/MIME署名されたメッセージや、組織設定で許可されたメッセージにはSafety tipsが表示されない場合があります。(Microsoft Learn)
信頼済み送信者・ドメインはどこまで追加してよいですか？
信頼済み送信者・ドメインは、なりすまし保護の例外です。追加した送信者やドメインは、そのポリシーでなりすまし攻撃として分類されなくなります。最大1,024件まで追加できますが、便利だからといって広く登録しすぎると、保護を弱める原因になります。(Microsoft Learn)
追加を検討してよいのは、次のようなケースです。
| 追加してよいケース | 運用上の注意 |
|---|---|
| Microsoft 365の正規通知が誤検知される | 公式に案内されている送信者か確認する |
| 業務上必須の外部サービス通知が継続的に誤検知される | ドメイン全体ではなく送信者単位で許可できないか検討する |
| 取引先メールが正当なのに隔離される | まずメール認証設定の修正を依頼する |
| 一時的な誤検知対応 | 期限や見直し日を管理台帳に残す |
信頼済みドメインに追加してもサブドメインは含まれません。たとえばexample.comを追加しても、mail.example.comやnews.example.comを別途考慮する必要があります。(Microsoft Learn)
Anti-phishing policiesが見えない・設定できない時の確認ポイント
Anti-phishing policiesが表示されない、設定が保存できない、項目がグレーアウトしている場合は、ライセンス、権限、ポリシーの優先順位、プリセットセキュリティポリシーの影響を確認します。
| 症状 | 主な確認ポイント | 対応の考え方 |
|---|---|---|
| Anti-phishingの画面が見つからない | Defenderポータルの「Email & collaboration > Policies & rules > Threat policies」を確認 | 管理センターではなくDefenderポータルで探す |
| なりすまし保護の項目が見えない | Defender for Office 365 Plan 1/Plan 2または該当アドオンの有無を確認 | 基本保護とDefender for Office 365の追加機能を分けて確認する |
| 保存時に403やCmdletAccessDeniedExceptionが出る | RBAC、Exchange Onlineロール、Security Administrator権限を確認 | 権限が正しい場合でもRBAC構成の更新が必要なことがある |
| デフォルトポリシーを無効化できない | デフォルトポリシーは常に有効 | 無効化ではなく設定変更で対応する |
| Standard/Strictのポリシーを直接編集できない | プリセットセキュリティポリシーに紐づくAnti-phishing policyは直接編集できない | Preset security policies側で変更する |
| カスタムポリシーが効かない | 対象ユーザーがStandardまたはStrictプリセットに含まれていないか確認 | プリセットが優先される場合、カスタムや既定ポリシーの設定は無視される |
| グループを指定したのに対象にならない | 動的配布グループやEntra IDの動的メンバーシップグループはサポート対象外 | メール有効セキュリティグループやMicrosoft 365グループの仕様を確認する |
| 設定直後に反映されない | 新規または更新したポリシーの適用に時間がかかる | 最大30分程度の反映待ちを見込む |
Microsoft Learnでは、新規または更新したポリシーの適用には最大30分を見込むよう説明されています。また、StandardまたはStrictプリセットセキュリティポリシーの対象ユーザーでは、既定またはカスタムのAnti-phishing policy設定が無視される点にも注意が必要です。(Microsoft Learn)
ポリシーの優先順位で失敗しやすいポイント
Anti-phishing policiesは、上から順にすべて適用されるわけではありません。対象受信者に最初に一致した最も優先度の高いポリシーが適用され、その受信者に対するAnti-phishing protectionの処理はそこで止まります。(Microsoft Learn)
優先順位はおおむね次の順で考えます。
| 優先順位 | ポリシー |
|---|---|
| 1 | Strict preset security policyに関連するAnti-phishing policy |
| 2 | Standard preset security policyに関連するAnti-phishing policy |
| 3 | カスタムAnti-phishing policies |
| 4 | デフォルトAnti-phishing policy |
カスタムポリシーでは、優先度の数値が小さいほど優先順位が高くなります。0が最も高い優先度です。デフォルトポリシーは常に最下位で、優先順位を変更できません。(Microsoft Learn)
「役員向けの厳しいカスタムポリシーを作ったのに効かない」という場合、役員がすでにStandardまたはStrictプリセットの対象になっている、または別の高優先度カスタムポリシーに先に一致している可能性があります。
条件設定で間違えやすいこと
カスタムAnti-phishing policyでは、ユーザー、グループ、ドメインを使って適用対象を指定できます。ただし、条件の組み合わせ方には注意が必要です。同じ種類の条件に複数値を入れた場合はOR条件として扱われますが、異なる種類の条件を組み合わせるとAND条件になります。(Microsoft Learn)
たとえば、条件に「ユーザーA」と「Executivesグループ」を両方指定した場合、ユーザーAがExecutivesグループのメンバーである時だけポリシーが適用されます。「ユーザーAまたはExecutivesグループ全員」という意味にはなりません。
実務では、次のように分けるとトラブルを減らせます。
| やりたいこと | 設定の考え方 |
|---|---|
| 役員全員に同じ設定を適用したい | 役員用グループだけを条件にする |
| 特定ユーザー数名にだけ適用したい | Usersに対象者をまとめて追加する |
| 全社に適用し、一部だけ除外したい | ドメイン条件と例外を組み合わせる |
| 部門ごとに異なる強度にしたい | 部門別にカスタムポリシーを分ける |
設定後はどう確認すればよいですか？
設定後は、DefenderポータルのAnti-phishingページで、ポリシーのStatus、Priority、対象条件を確認します。詳細を開けば、各セクションの設定内容も確認できます。PowerShellを使う場合は、Get-AntiPhishPolicyとGet-AntiPhishRuleでポリシーとルールの内容を確認できます。(Microsoft Learn)
確認時は、単に「ポリシーが存在するか」だけでなく、次の観点で見ます。
| 確認項目 | 見るべきポイント |
|---|---|
| 対象者 | 守りたいユーザーが実際に対象条件に入っているか |
| 優先順位 | より高い優先度の別ポリシーに先に一致していないか |
| アクション | 検出時に隔離、迷惑メール移動、削除、リダイレクトなど意図した動作になっているか |
| Quarantine policy | 隔離通知やユーザー操作権限が運用に合っているか |
| 例外 | 信頼済み送信者・ドメインを広く許可しすぎていないか |
| 誤検知 | 正当な取引先メールが隔離されていないか |
設定変更後すぐにテストして結果が出ない場合は、反映待ちの可能性もあります。焦って複数の設定を連続変更すると原因が分かりにくくなるため、変更内容、日時、対象者、期待する動作を記録してから確認するのがおすすめです。
実務でおすすめの設定順序
Anti-phishing policiesは、画面上の項目を上から埋めるだけではなく、先に「何を守るか」を決めると失敗しにくくなります。
| 順序 | 作業 | 目的 |
|---|---|---|
| 1 | SPF、DKIM、DMARCなどメール認証を確認する | 正当メールの誤判定を減らす |
| 2 | 役員、経理、人事、管理者など高リスクユーザーを洗い出す | User impersonation protectionの対象を決める |
| 3 | 自社・グループ会社・重要取引先ドメインを整理する | Domain impersonation protectionの対象を決める |
| 4 | StandardまたはStrictプリセットの利用可否を決める | Microsoft推奨値をベースにする |
| 5 | 必要に応じてカスタムAnti-phishing policyを作る | 部門やリスクに合わせて調整する |
| 6 | 検出時のアクションを決める | 迷惑メール移動、隔離、拒否などの運用を合わせる |
| 7 | 隔離レビューと問い合わせ対応を決める | 誤検知時の業務停止を防ぐ |
| 8 | 数週間ごとに隔離・許可・ブロックの状況を見直す | 攻撃傾向と業務変化に追従する |
Microsoftの推奨設定では、Defender for Office 365のStandardまたはStrict構成を基準に、ユーザーなりすまし保護、ドメインなりすまし保護、Mailbox intelligence protection、安全ヒントなどを有効化する方向が示されています。(Microsoft Learn)
よくある疑問への答え
Anti-phishing policiesはExchange Online Protectionだけでも使えますか？
Microsoft 365のクラウドメールボックス向けには基本的なAnti-phishing protectionがあります。ただし、ユーザーなりすまし保護、ドメインなりすまし保護、フィッシングメールしきい値などの高度な機能はDefender for Office 365側の機能として整理されています。(Microsoft Learn)
外部ユーザーも保護対象ユーザーにできますか？
User impersonation protectionでは、内部ユーザーだけでなく外部の送信者メールアドレスも保護対象に追加できます。たとえば、取締役会メンバー、顧問、重要取引先担当者など、社内ユーザーが信頼しやすい外部人物を保護対象にする使い方があります。(Microsoft Learn)
なりすまし検出時のアクションは何が安全ですか？
最初は「Quarantine the message」を中心に考えるのが実務的です。削除はユーザーにも管理者にも気づきにくく、リダイレクトやBccは監視目的には便利ですが、通常運用では管理が複雑になります。MicrosoftのStandardおよびStrict推奨では、ユーザーなりすましとドメインなりすましの検出時に隔離が示されています。(Microsoft Learn)
迷惑メールフォルダー移動と隔離はどちらがよいですか？
ユーザーが自分で確認できる利便性を重視するなら迷惑メールフォルダー移動、被害防止を重視するなら隔離が向いています。役員なりすましや請求書詐欺のように被害額が大きくなりやすい攻撃では、隔離を基本にし、管理者またはセキュリティ担当がレビューする運用が安全です。
設定を強くするとメールが届かなくなりますか？
設定を強くすると、正当なメールが隔離されたり迷惑メールに振り分けられたりする可能性は上がります。特にPhishing email thresholdを上げる、Strict設定を適用する、なりすまし検出時に隔離を選ぶ場合は、隔離通知、リリース申請、管理者レビューの流れを事前に決めておくことが重要です。(Microsoft Learn)
まず何から始めるべきか
Anti-phishing policiesでなりすまし保護を設定する時は、最初に「守る受信者」と「なりすまされる送信者」を分けて考えることが大切です。受信者はポリシーの適用対象であり、なりすまされる送信者はUser impersonation protectionやDomain impersonation protectionで指定する対象です。この2つを混同すると、設定したつもりでも期待した検出になりません。
最初の一歩としては、次の順で進めるのが現実的です。
- Microsoft DefenderポータルでAnti-phishingページを確認する
- StandardまたはStrictプリセットセキュリティポリシーの対象者を確認する
- 役員・経理・人事・管理者など、高リスクユーザーを一覧化する
- 自社ドメインと重要取引先ドメインを整理する
- 小さな対象範囲でカスタムAnti-phishing policyを作成する
- 隔離、誤検知、問い合わせ状況を見ながら全社展開を判断する
Microsoft 365のメール保護は、オンにして終わりではありません。Anti-phishing policiesは、組織の人事異動、取引先変更、メール配信サービスの追加に合わせて見直すことで効果を保てます。特に、役員交代、経理担当変更、新しい外部サービスの導入があった時は、保護対象ユーザー、ドメイン、信頼済み送信者の棚卸しを行うことが重要です。
コメント