Microsoft 365のAnti-phishing policiesでなりすまし保護を設定するときに迷いやすい点は、「どこで設定するのか」よりも、「既定のポリシーで十分なのか」「Standard/Strictの事前設定ポリシーとカスタムポリシーのどちらを使うべきか」「保護するユーザーと適用先ユーザーの違いをどう理解するか」です。結論から言うと、まず Microsoft Defender ポータルの [メールとコラボレーション] > [ポリシーとルール] > [脅威ポリシー] > [フィッシング詐欺対策] を確認し、全社的には Standard または Strict の事前設定セキュリティポリシーを優先、例外的な部署・役員・経理・情シスなどはカスタムのAnti-phishing policyで細かく調整するのが現実的です。Microsoft Learnでも、カスタムポリシーを個別に管理する代わりに、通常はStandardまたはStrictの事前設定セキュリティポリシーを有効化してユーザーを追加することが推奨されています。(Microsoft Learn)
この記事では、2026年6月23日時点で確認するMicrosoft Learnの公式情報を前提に、Microsoft Defender for Office 365のAnti-phishing policiesで迷いやすい使い方、設定場所、導入前に確認すべき前提条件を、管理画面に不慣れな人にも分かるように整理します。専門用語としては「スプーフィング」「偽装」「なりすまし」が混在しますが、実務では「送信元を偽る攻撃」と「似た名前・似たドメインでだます攻撃」を分けて考えると設定ミスを防ぎやすくなります。
Microsoft 365のAnti-phishing policiesで最初に確認すべきこと
Microsoft Defender for Office 365のAnti-phishing policiesは、フィッシングメール、送信者のなりすまし、ユーザーやドメインの偽装を検出・制御するためのポリシーです。基本的なスプーフィング対策はMicrosoft 365のクラウドメールボックスにも提供されますが、ユーザー偽装、ドメイン偽装、フィッシングメールのしきい値などの高度な設定はDefender for Office 365側の機能として扱われます。(Microsoft Learn)
まず押さえるべきポイントは、既定のフィッシング対策ポリシーが存在していても、それだけで高度ななりすまし保護がすべて有効になるわけではないことです。Microsoft Learnでは、Defender for Office 365の既定のフィッシング対策ポリシーは、すべての受信者にスプーフィング保護とメールボックスインテリジェンスを提供する一方、その他の偽装保護やフィッシングメールのしきい値は既定では構成されていないと説明されています。(Microsoft Learn)
つまり、「Defender for Office 365を契約しているから、役員なりすまし対策も自動で万全」と考えるのは危険です。役員、経理担当、採用担当、外部取引が多い部署などを守りたい場合は、保護対象のユーザーやドメインを明示的に設定する必要があります。
設定場所はMicrosoft Defenderポータルのフィッシング詐欺対策
Anti-phishing policiesの設定場所は、Microsoft Defenderポータルです。管理画面では、次の順番で開きます。
| 確認したいこと | 操作場所 |
|---|---|
| フィッシング対策ポリシーの一覧を確認する | Microsoft Defenderポータル |
| 新しいポリシーを作成する | [メールとコラボレーション] > [ポリシーとルール] > [脅威ポリシー] > [フィッシング詐欺対策] |
| 既存ポリシーを編集する | フィッシング詐欺対策ポリシーの一覧から対象ポリシーを選択 |
| PowerShellで確認する | Exchange Online PowerShellの Get-AntiPhishPolicy、Get-AntiPhishRule |
Microsoft Learnでは、Microsoft Defenderポータルから [メールとコラボレーション] > [ポリシーとルール] > [脅威ポリシー] > [フィッシング詐欺対策] に進む手順が案内されています。新規作成する場合は、フィッシング詐欺対策ページで [作成] を選び、ポリシー名、適用先、保護設定、アクションを順に設定します。(Microsoft Learn)
実務では、いきなり新規作成する前に、まず既存のポリシー一覧を確認してください。StandardまたはStrictの事前設定セキュリティポリシーにユーザーが含まれている場合、既定またはカスタムのフィッシング対策ポリシー設定が無視されることがあるためです。(Microsoft Learn)
導入前に確認したい前提条件
Anti-phishing policiesを設定する前に、次の4点を確認しておくと、途中で「保存できない」「効いているはずなのに反映されない」といったトラブルを減らせます。
| 確認項目 | 見るべきポイント | 迷ったときの判断 |
|---|---|---|
| ライセンス | Defender for Office 365 Plan 1またはPlan 2があるか | 高度な偽装保護を使うならDefender for Office 365の対象ライセンスを確認 |
| 権限 | セキュリティ管理者、組織管理、必要なRBAC権限があるか | 変更できない場合は読み取り専用権限の可能性を疑う |
| 既存ポリシー | Standard/Strictの事前設定ポリシーに含まれていないか | 事前設定ポリシーが優先される可能性を確認 |
| 反映時間 | 変更後すぐ結果が出るとは限らない | 新規または更新ポリシーの適用に最大30分かかる前提で確認 |
Microsoft Learnでは、ポリシーの追加・変更・削除にはExchange Onlineの「組織管理」または「セキュリティ管理者」などの権限が必要と説明されています。また、新しいポリシーや更新されたポリシーが適用されるまで最大30分かかる点も明記されています。(Microsoft Learn)
特に注意したいのは、権限不足です。管理センターには入れるのに保存時に403やCmdletAccessDeniedExceptionが出る場合、単純な操作ミスではなく、Exchange Online RBAC構成が関係している可能性があります。必要な権限を持っているか、ロールが最新状態で反映されているかを確認しましょう。(Microsoft Learn)
「スプーフィング」と「偽装」の違いで迷わない
Anti-phishing policiesで最も混乱しやすいのが、「スプーフィング」と「偽装」の違いです。日本語ではどちらも「なりすまし」と言われることがありますが、設定画面上では意味が異なります。
| 用語 | ざっくりした意味 | 例 | 対策の考え方 |
|---|---|---|---|
| スプーフィング | 差出人アドレスやドメインを偽る | 実際の送信元とFromアドレスのドメインが一致しない | SPF、DKIM、DMARC、スプーフィングインテリジェンス |
| 偽装・インパーソネーション | 似た名前や似たドメインで本物に見せる | contoso.com に似せた ćóntoso.com を使う | ユーザー偽装保護、ドメイン偽装保護、メールボックスインテリジェンス |
Microsoft Learnでは、スプーフィングは送信者のメールアドレスやドメインを偽造して信頼できる送信元に見せる攻撃、偽装は信頼できるユーザーやドメインを模倣して受信者をだます攻撃として説明されています。また、偽装は攻撃者が類似ドメインを作り、有効なDNSレコードを公開している場合、SPF、DKIM、DMARCなどのメール認証を通過する可能性があります。(Microsoft Learn)
ここが重要です。メール認証を整備していても、似たドメインや似た表示名を使った攻撃は別の観点で検出する必要があります。したがって、Anti-phishing policiesでは、スプーフィングインテリジェンスだけでなく、ユーザー偽装保護、ドメイン偽装保護、メールボックスインテリジェンスを組み合わせて考えます。
既定ポリシー、事前設定ポリシー、カスタムポリシーの使い分け
Anti-phishing policiesで迷ったら、まず「全社標準」と「重点保護」を分けて考えると整理しやすくなります。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| 既定のフィッシング対策ポリシー | まず全ユーザーに基本的な保護を適用したい | 名前や適用先は変更できず、既定のままでは高度な偽装保護が未構成の部分がある |
| Standard事前設定セキュリティポリシー | Microsoft推奨に近い標準的な保護を全社に適用したい | カスタムポリシーより優先される場合があるため対象ユーザーを確認する |
| Strict事前設定セキュリティポリシー | 役員、経理、管理者など高リスクユーザーに強めの保護をかけたい | 誤検知や業務影響を事前に確認する |
| カスタムAnti-phishing policy | 部署、グループ、ドメイン単位で細かく制御したい | 適用先条件、例外、優先順位の設計が必要 |
Microsoft Learnでは、Defender for Office 365のAnti-phishing policiesは既定ポリシーがすべての受信者に自動適用され、必要に応じて特定のユーザー、グループ、ドメイン向けのカスタムポリシーを作成できると説明されています。(Microsoft Learn)
実務では、まずStandardの事前設定セキュリティポリシーを基本線として検討し、より強い保護が必要なユーザーにStrict、細かい例外が必要な場合にカスタムポリシーを使う流れが扱いやすいです。全社にいきなりStrict相当の設定を入れると、取引先からの正当なメールが検疫されるなど、ヘルプデスクへの問い合わせが増える可能性があります。
カスタムポリシー作成時の基本手順
カスタムのAnti-phishing policyを作る場合は、次の順番で進めます。
| 手順 | 設定内容 | 実務上のポイント |
|---|---|---|
| ポリシー名を決める | 名前、説明 | 「Finance-HighRisk」「Executives-Strict」など対象が分かる名前にする |
| 適用先を選ぶ | ユーザー、グループ、ドメイン | 受信者側の条件を指定する |
| 保護対象を選ぶ | 保護するユーザー、保護するドメイン | 送信者として偽装されると困る人物・ドメインを指定する |
| 信頼する送信者を設定する | trusted senders/domains | 誤検知を避ける例外として最小限にする |
| アクションを選ぶ | 迷惑メール、検疫、リダイレクト、削除など | 最初は検疫中心にしてログ確認しやすくする |
| 安全性ヒントを有効にする | 初回連絡先、ユーザー偽装、ドメイン偽装など | ユーザー教育と組み合わせると効果が出やすい |
| 確認する | ポリシー一覧、状態、優先度、PowerShell | 反映に最大30分かかる前提で確認する |
Microsoft Learnでは、作成ウィザードでポリシー名、適用先ユーザー・グループ・ドメイン、フィッシングしきい値、偽装保護、アクションを順に構成する流れが示されています。(Microsoft Learn)
ここでよくあるミスは、「適用先」と「保護対象」を混同することです。適用先は、そのポリシーで守られる受信者です。一方、保護対象のユーザーやドメインは、攻撃者に偽装されると困る送信者側の人物・ドメインです。たとえば、経理部に届く「社長を名乗るメール」を検出したい場合、適用先は経理部、保護対象ユーザーは社長や役員です。
ユーザー偽装保護で迷うポイント
ユーザー偽装保護は、特定の人物が送信者として偽装されるのを防ぐ設定です。役員、経理責任者、情報システム管理者、人事担当、外部向け窓口など、名前を悪用されると被害が大きいユーザーから登録すると効果的です。
Microsoft Learnでは、ユーザー偽装保護により、特定の内部または外部メールアドレスがメッセージ送信者として偽装されるのを防げると説明されています。また、1つのフィッシング対策ポリシーごとに、ユーザー偽装保護に指定できるユーザーは最大350人です。(Microsoft Learn)
設定時の判断基準は次のとおりです。
| 登録候補 | 優先度 | 理由 |
|---|---|---|
| 代表者、役員、部門長 | 高 | 承認依頼、送金依頼、機密情報要求に悪用されやすい |
| 経理、財務、購買担当 | 高 | 請求書、口座変更、支払い依頼に直結する |
| 情報システム管理者 | 高 | パスワード、MFA、アカウント確認を装う攻撃に使われやすい |
| 人事、採用担当 | 中 | 添付ファイルや個人情報のやり取りが多い |
| 全社員 | 低〜中 | 上限や運用負荷を考えると、最初から全員登録は現実的でない場合がある |
注意点として、メールボックスインテリジェンスと偽装保護のインテリジェンスが有効な場合、送信者と受信者が過去にメールでやり取りしていると、ユーザー偽装保護が働かないケースがあります。これは、普段からやり取りしている正当な送信者を誤って止めないための挙動として理解しておく必要があります。(Microsoft Learn)
ドメイン偽装保護で迷うポイント
ドメイン偽装保護は、自社ドメインや取引先ドメインに似たドメインを使う攻撃を検出するための設定です。たとえば、自社が example.co.jp を使っている場合、見た目が似た別ドメインから「請求先口座を変更してください」と届くような攻撃を想定します。
Microsoft Learnでは、ドメイン偽装保護により、所有する承認済みドメインや特定のカスタムドメインが、送信者のメールアドレス内で偽装されるのを防ぐと説明されています。各フィッシング対策ポリシーでは、ドメイン偽装保護用のカスタムドメインを最大50個まで指定できます。(Microsoft Learn)
登録候補としては、次のようなドメインが実務向きです。
| 登録するドメイン | 例 | 目的 |
|---|---|---|
| 自社の主要ドメイン | example.co.jp | 自社を装う外部送信を検出する |
| グループ会社のドメイン | example-holdings.jp | グループ会社名を使った詐欺を防ぐ |
| 重要取引先のドメイン | 主要ベンダー、銀行、決済代行会社など | 口座変更、請求書、契約更新を装う攻撃に備える |
| ブランド用ドメイン | サービスサイト、採用サイト用ドメイン | 顧客対応や採用窓口を装う攻撃に備える |
ただし、信頼できるドメインとして例外登録する場合は注意が必要です。Microsoft Learnでは、信頼されたドメインのエントリにはサブドメインが含まれず、サブドメインごとに追加が必要とされています。(Microsoft Learn)
メールボックスインテリジェンスは何をしているのか
メールボックスインテリジェンスは、ユーザーごとのメールのやり取りパターンをもとに、正当な送信者と偽装された送信者を見分けるための機能です。たとえば、同姓同名の外部ベンダーと以前から頻繁にやり取りしている場合、その送信者をすぐに偽装と判断しないようにする、といった使われ方をします。
Microsoft Learnでは、メールボックスインテリジェンスはAIを使用して、ユーザーの頻繁な連絡先などのメールパターンを判断すると説明されています。また、「メールボックスインテリジェンスを有効にする」は既定でオン、「偽装に対する保護のインテリジェンスを有効にする」は既定でオフです。検出したメッセージに対してアクションを実行するには、両方の設定をオンにする必要があります。(Microsoft Learn)
ここで迷うのは、「メールボックスインテリジェンスがオンなら、なりすまし対策も自動で動くのか」という点です。答えは、完全にはそうではありません。メールボックスインテリジェンス自体は判断材料を提供しますが、偽装保護としてアクションを実行させるには、偽装保護のインテリジェンスを有効にし、検出時のアクションを選ぶ必要があります。
フィッシングメールのしきい値は上げすぎない
フィッシングメールのしきい値は、機械学習モデルによるフィッシング判定の感度を調整する設定です。1がStandard、4がMost aggressiveに相当し、数値を上げるほど低い信頼度の判定でも強いアクションが適用されやすくなります。
Microsoft Learnでは、しきい値を上げると誤検知、つまり本来は問題ないメールが不適切なメールとして扱われる可能性が高くなると説明されています。(Microsoft Learn)
実務では、次のように段階的に考えると安全です。
| しきい値 | 向いている対象 | 注意点 |
|---|---|---|
| 1 – Standard | 一般社員、全社標準 | 業務影響を抑えやすい |
| 2 – Aggressive | 経理、購買、人事、外部窓口 | 誤検知の監視が必要 |
| 3 – More aggressive | 役員、特権管理者、高リスク部署 | 検疫レビュー体制が必要 |
| 4 – Most aggressive | 限定的な高リスクユーザー | 全社適用は慎重に判断 |
「強ければ強いほど安全」と考えて全社的に最大値にするのは避けた方が無難です。正当な請求書、契約書、採用応募メール、問い合わせメールが検疫されると、セキュリティよりも業務停止の問題として扱われてしまいます。まずは標準または一段階強めから始め、検疫ログやユーザー報告を見ながら調整しましょう。
アクションは「削除」より「検疫」から始める
ユーザー偽装、ドメイン偽装、メールボックスインテリジェンス、スプーフィングインテリジェンスでは、検出時のアクションを選びます。代表的な選択肢は、何もしない、迷惑メールフォルダーへ移動、検疫、リダイレクト、Bcc追加、配信前削除です。
Microsoft Learnでは、ユーザー偽装やドメイン偽装の検出時に、迷惑メールフォルダーへの移動、検疫、リダイレクト、Bcc追加、配信前削除などのアクションを選択できると説明されています。検疫を選んだ場合は、検疫ポリシーを指定でき、ユーザーが検疫済みメッセージに対して何をできるか、通知を受け取るかを制御できます。(Microsoft Learn)
初期導入では、いきなり「配信前に削除」を選ぶより、検疫を中心にした方が原因調査しやすくなります。特に取引先メールが多い組織では、削除にするとユーザーも管理者も「何が止まったのか」を追いにくくなります。
おすすめの考え方は次のとおりです。
| 状況 | 推奨しやすいアクション |
|---|---|
| 初期導入・検証中 | 検疫、または迷惑メールフォルダーへ移動 |
| 役員なりすましなど影響が大きい攻撃 | 検疫 |
| 明確に悪性と判断できる送信者 | ブロックまたは削除を検討 |
| SOCや管理者が詳しく追跡したい | リダイレクトやBcc追加を限定的に活用 |
| ユーザー通知も含めて運用したい | 検疫ポリシーと通知設定を確認 |
検疫を使う場合は、ユーザーが自分で解放できるのか、管理者承認が必要なのかを事前に決めておきましょう。誤検知が多い状態でユーザーに解放権限を広く与えると、危険なメールが再び開かれる恐れがあります。
初めての連絡先に関する安全性のヒントは有効化を検討する
「初めての連絡先に関する安全性のヒント」は、送信者から初めてメールを受け取る場合や、あまりやり取りのない送信者からメールが届いた場合に、受信者へ注意を促す機能です。スプーフィングインテリジェンスや偽装保護の設定に依存せず利用できます。(Microsoft Learn)
この機能は、管理者側の検出だけでなく、ユーザー自身の判断を助ける点で有効です。特に、請求書、パスワード再設定、Microsoft 365通知風のメール、採用応募メールなど、ユーザーが開封判断に迷いやすい場面で役立ちます。
ただし、複数受信者がいるメールでは、受信者の通信習慣に関するヒント表示が気になるケースもあります。Microsoft Learnでは、複数受信者のメッセージでは多数派モデルに基づいてヒント表示が決まること、通信習慣が他の受信者に見える懸念がある場合はこの安全性ヒントを有効にしない選択肢も示されています。(Microsoft Learn)
認証されていない送信者の「?」や「via」タグで迷う場合
Anti-phishing policiesでは、認証されていない送信者に対してOutlook上で疑問符を表示したり、FromアドレスとDKIM署名またはMAIL FROMアドレスのドメインが異なる場合に「via」タグを表示したりできます。
Microsoft Learnでは、疑問符や「via」タグを特定の送信者に表示させたくない場合、スプーフィングインテリジェンスの分析情報またはテナントの許可/ブロックリストで送信者を許可する方法や、送信者ドメインのメール認証を構成する方法が説明されています。(Microsoft Learn)
ここで安易に例外登録を増やすと、保護の抜け穴になります。まずは送信者側のSPF、DKIM、DMARCが正しく設定されているかを確認し、それでも業務上必要な場合に限って、送信者単位で許可するのが安全です。
信頼できる送信者とドメインは「最小限」にする
信頼できる送信者とドメインは、偽装保護の例外です。指定された送信者やドメインからのメッセージは、ポリシーによって偽装ベースの攻撃として分類されません。
Microsoft Learnでは、信頼された送信者とドメインのリスト上限は1,024エントリであり、信頼されたドメインの指定にはサブドメインが含まれないため、サブドメインごとに追加が必要とされています。(Microsoft Learn)
例外登録は、問い合わせ削減のために便利ですが、セキュリティ上は慎重に扱うべきです。特にドメイン単位の許可は影響範囲が広くなります。まずは送信者単位、次に必要最小限のサブドメイン単位で検討しましょう。
| 例外登録の対象 | 推奨度 | 理由 |
|---|---|---|
| 特定のMicrosoft 365通知送信者 | 中 | Microsoft Learnにも例示があり、誤検知時の対応として使える |
| 重要取引先の個別送信者 | 中 | 業務継続上必要な場合に限定する |
| 取引先ドメイン全体 | 低〜中 | 攻撃者が侵害済みアカウントを使う可能性がある |
| フリーメールドメイン全体 | 低 | 例外範囲が広すぎる |
| 自社ドメイン全体を安易に信頼 | 低 | 内部侵害や誤設定を見逃す可能性がある |
DMARC関連の設定はメール経路を見てから判断する
DMARC関連の設定では、送信者のDMARCポリシーが p=quarantine または p=reject の場合に、それをMicrosoft 365側でどのように扱うかを制御できます。
Microsoft Learnでは、メッセージがスプーフィングとして検出され、DMARCポリシーが p=quarantine の場合は検疫または迷惑メールフォルダーへの移動、p=reject の場合は検疫または拒否を選択できると説明されています。(Microsoft Learn)
注意したいのは、メールの受信経路です。MXレコードがMicrosoft 365を直接指しておらず、手前にメールセキュリティゲートウェイや別サービスがある場合、スプーフィングインテリジェンスをオフにするのではなく、Exchange Onlineのコネクタの拡張フィルター処理を検討する必要があります。Microsoft Learnでも、MXレコードがMicrosoft 365を指していない場合はスプーフィングインテリジェンスをオフにする必要はなく、代わりにコネクタの拡張フィルター処理を有効にすると説明されています。(Microsoft Learn)
よくある設定ミスと対策
| よくあるミス | 起きること | 対策 |
|---|---|---|
| 既定ポリシーだけで十分だと思う | 高度な偽装保護が未構成のままになる | 事前設定ポリシーまたはカスタムポリシーで保護対象を設定 |
| 適用先と保護対象を混同する | 守りたい受信者にポリシーが効かない | 適用先は受信者、保護対象は偽装される送信者と整理する |
| しきい値を最初から最大にする | 正常なメールが検疫されやすくなる | 高リスクユーザーから段階導入 |
| 信頼済みドメインを広く登録する | 攻撃メールを見逃す可能性がある | 送信者単位・最小範囲で例外化 |
| 変更直後に効かないと判断する | 反映前に誤った切り戻しをする | 最大30分の反映時間を見込む |
| 事前設定ポリシーの対象を見落とす | カスタムポリシーが効かないように見える | Standard/Strictの対象ユーザーを確認 |
| 検疫通知を確認していない | ユーザーが必要メールを見つけられない | 検疫ポリシーと通知設定を設計する |
特に多いのは、カスタムポリシーを作ったのに効かないという相談です。この場合、適用先条件のAND/ORの理解、Standard/Strict事前設定ポリシーとの優先関係、ポリシーの状態、反映時間を順に確認しましょう。
小規模組織でのおすすめ設定例
小規模組織では、複雑なカスタムポリシーを増やしすぎると管理しきれません。まずはStandardの事前設定セキュリティポリシーを基本にし、役員や経理だけを重点的に保護する構成が扱いやすいです。
| 対象 | 設定例 |
|---|---|
| 全ユーザー | Standard事前設定セキュリティポリシーを検討 |
| 代表者、経理担当 | ユーザー偽装保護の保護対象に追加 |
| 自社ドメイン | ドメイン偽装保護に追加 |
| 初回連絡先の注意喚起 | 有効化を検討 |
| 検出時アクション | まずは検疫中心 |
| 例外 | 必要最小限の送信者単位で登録 |
小規模組織では、IT担当者が1人または兼任であることも多いため、検疫メールを毎日確認できる運用にすることが重要です。強い設定にしても、誤検知を誰も見ない状態では業務影響が大きくなります。
中〜大規模組織でのおすすめ設定例
中〜大規模組織では、部署やリスクレベルごとにポリシーを分けた方が運用しやすくなります。
| 対象 | 設定例 |
|---|---|
| 一般社員 | Standard相当の保護 |
| 役員・秘書 | Strictまたはカスタムポリシーで高めのしきい値 |
| 経理・購買 | ドメイン偽装、ユーザー偽装、検疫を強化 |
| 情シス・管理者 | 管理者名の偽装、Microsoft 365通知風メールへの対策を強化 |
| 人事・採用 | 外部添付ファイルや初回連絡先ヒントと組み合わせる |
| 監査・SOC | 検疫、アラート、メッセージ追跡の確認手順を整備 |
この規模では、ポリシー名、対象グループ、例外、検疫ポリシー、運用責任者を一覧化しておくことが大切です。属人的に例外を追加していくと、半年後には「なぜ許可されているのか分からない送信者」が増えます。例外には必ず理由、申請者、登録日、見直し日を残しましょう。
設定後の確認方法
設定後は、Microsoft Defenderポータルのフィッシング詐欺対策ページで、ポリシーの一覧、状態、優先度を確認します。PowerShellを使える場合は、Get-AntiPhishPolicy と Get-AntiPhishRule で設定値を確認できます。Microsoft Learnでも、ポリシーが正常に構成されたことを確認する方法として、Defenderポータルでの状態・優先度確認と、Exchange Online PowerShellによる確認が案内されています。(Microsoft Learn)
確認時は、次の順番で見ると原因を切り分けやすくなります。
- ポリシーが有効か
- 対象ユーザーが正しいか
- Standard/Strictの事前設定ポリシーに含まれていないか
- 保護対象ユーザー・ドメインが登録されているか
- 検出時アクションが「何もしない」になっていないか
- 検疫ポリシーと通知設定が意図どおりか
- 変更から30分以上経過しているか
「テストメールを送っても検出されない」場合でも、すぐに設定ミスとは限りません。メールの内容、送信元認証、過去のやり取り、メールボックスインテリジェンス、ポリシーの適用順序が影響します。テストする場合は、実在ドメインを悪用せず、検証用ドメインや管理された環境で行いましょう。
まず実施すべきチェックリスト
Microsoft 365のAnti-phishing policiesでなりすまし保護を設定するなら、最初に次の順番で進めると失敗しにくくなります。
| 順番 | やること | 完了の目安 |
| -: | ————————————— | —————— |
| 1 | Defender for Office 365のライセンスと管理権限を確認する | ポリシーを閲覧・変更できる |
| 2 | 既存のStandard/Strict事前設定ポリシーの対象を確認する | カスタムポリシーとの競合を把握できる |
| 3 | 役員、経理、情シスなど保護すべきユーザーを決める | 保護対象リストができている |
| 4 | 自社・グループ会社・重要取引先のドメインを整理する | ドメイン偽装保護の候補が決まる |
| 5 | 初期アクションを検疫中心に決める | 誤検知時に追跡できる |
| 6 | 初回連絡先ヒントや安全性ヒントを有効化するか判断する | ユーザー通知方針が決まる |
| 7 | 検疫確認の担当者と頻度を決める | 業務メールの滞留を防げる |
| 8 | 変更後に状態、優先度、ログを確認する | 設定が反映されている |
Anti-phishing policiesは、一度設定して終わりではありません。人事異動で役員や経理責任者が変わったとき、主要取引先が増えたとき、新しいドメインを追加したときには、保護対象ユーザー、保護ドメイン、信頼済み送信者、例外設定を見直す必要があります。
最初の一歩としては、Microsoft Defenderポータルで現在のフィッシング詐欺対策ポリシーを開き、既定ポリシー、Standard/Strict事前設定ポリシー、カスタムポリシーの対象を確認してください。そのうえで、役員・経理・管理者など被害が大きいユーザーから、ユーザー偽装保護とドメイン偽装保護を段階的に設定していくのが安全です。
コメント