Microsoft Defender for Office 365の「Preset security policies」は、メール保護を一から細かく設計するのではなく、Microsoft推奨の保護レベルをStandard、Strict、Built-in protectionとして適用するための仕組みです。2026年6月2日時点で管理者が最初に確認すべきポイントは、既存のカスタムポリシーよりプリセットが優先されること、Standard/Strictの対象ユーザーを誤って重複させないこと、そしてBuilt-in protectionの除外を安易に増やさないことです。公式ドキュメントのGitHub履歴では2026年6月1日に対象ファイルを含む更新があり、本文メタデータ上は2026年5月22日更新として確認できます。この記事では、その公式情報をもとに、変更点、影響範囲、管理者や運用自動化担当者が確認すべき設定を実務目線で整理します。(GitHub)
Preset security policiesとは何か
Preset security policiesは、Microsoft Defender for Office 365やクラウドメールボックス向けの保護設定を、Microsoftの推奨値に基づいてまとめて適用するためのテンプレート型ポリシーです。カスタム脅威ポリシーのように細かな値を自由に変更する設計ではなく、多くの設定は固定され、Microsoft 365のデータセンターでの観測や推奨に基づいて管理されます。(Microsoft Learn)
利用できるプリセットは、主に次の3つです。(Microsoft Learn)
| 種類 | 主な用途 | 向いている対象 |
|---|---|---|
| Standard preset security policy | 多くのユーザーに適した標準的な保護 | 一般社員、通常業務ユーザー |
| Strict preset security policy | より厳格な検出・隔離を行う保護 | 経営層、財務、人事、IT管理者、標的型攻撃を受けやすいユーザー |
| Built-in protection preset security policy | Safe LinksとSafe Attachmentsの基本保護 | Standard/StrictやカスタムSafe Links/Safe Attachmentsに含まれないユーザー |
実務上は、「全員にStandardを適用し、役員・管理者・財務などの高リスクユーザーだけStrictへ上げる」設計が分かりやすい出発点です。Microsoftの展開ガイドでも、特別な業務要件がなければStandardから始め、必要に応じてStrictやカスタムポリシーを組み合わせる考え方が示されています。(Microsoft Learn)
2026年6月時点で押さえるべき変更点
今回の公式情報で重要なのは、「新しいボタンを押せば防御力が上がる」という話ではありません。管理者が見落としやすい適用対象、優先順位、除外、PowerShell運用の注意点が整理されている点です。
| 確認ポイント | 変更・整理された内容 | 実務への影響 |
|---|---|---|
| 受信者指定のUsers | 公式ソース上で、Usersの説明からmail contactsが外れ、mailboxesまたはmail usersとして整理 | メール連絡先を対象に含める前提の設計や手順書は見直しが必要 |
| Standard/Strictの扱い | 有効化するまでユーザーには割り当てられない | 「ライセンスがあるから自動でStandard適用」と誤解しない |
| Built-in protection | 既定で広範囲にSafe Links/Safe Attachmentsを提供 | 除外を増やす前に、対象外にする業務上の理由を確認 |
| 優先順位 | Strict、Standard、評価ポリシー、カスタム、Built-in/defaultの順で適用 | カスタムポリシーが効かない原因になりやすい |
| PowerShell運用 | 個別の脅威ポリシーを直接作成・変更・削除しないよう警告 | 自動化スクリプトはルールの有効化・無効化、対象条件の確認中心にする |
GitHub上の差分では、Preset security policiesの受信者条件に関するUsersの説明が「mailboxes, mail users, or mail contacts」から「mailboxes, or mail users」へ変わっています。メール連絡先をポリシー適用対象として扱っていた運用メモや社内手順がある場合は、最新の画面表示・公式記述に合わせて修正してください。(GitHub)
影響範囲はメール保護全体に及ぶ
Preset security policiesは、単体の迷惑メール設定ではありません。Exchange Online Protectionの組み込み保護と、Microsoft Defender for Office 365の保護機能をまたいで適用されます。対象には、スパム、マルウェア、フィッシング、なりすまし、Safe Links、Safe Attachmentsなどが含まれます。(Microsoft Learn)
特に影響が大きいのは、次のような組織です。
- 既に複数のカスタム脅威ポリシーを運用している
- VIPや役員だけ別ポリシーにしている
- サードパーティのメールセキュリティ製品からDefender for Office 365へ移行中
- PowerShellでポリシー確認や展開を自動化している
- Safe LinksやSafe Attachmentsの例外を多く設定している
Preset security policiesの設定値の多くは変更できません。そのため、「既存のカスタム設定をそのまま生かしつつ、上からプリセットを追加する」という発想で進めると、意図しない隔離や、逆にカスタムポリシーが効かない問題が起きやすくなります。Microsoftは、プリセットより細かな要件がある場合にはカスタム脅威ポリシーを使う判断基準も示しています。(Microsoft Learn)
StandardとStrictの違いを実務目線で理解する
StandardとStrictは、すべての設定が大きく異なるわけではありません。Safe AttachmentsやSafe Linksでは差がない項目もあります。一方で、迷惑メール、バルクメール、スプーフィング、メールボックスインテリジェンス、フィッシングしきい値では、Strictのほうが強い処理になります。(Microsoft Learn)
| 項目 | Standard | Strict | 判断基準 |
|---|---|---|---|
| 通常のスパム | 迷惑メールフォルダーへ移動 | 検疫 | 誤検知時にユーザー自己解決を許すか、管理者確認を挟むか |
| バルクメールのしきい値 | BCL 6以上 | BCL 5以上 | メルマガや通知メールが多い部署では影響を確認 |
| スプーフィング検出時の処理 | 迷惑メールフォルダーへ移動 | 検疫 | 外部委託先や代理送信が多い組織では事前確認が必要 |
| フィッシングしきい値 | More aggressive | Most aggressive | 役員、経理、人事、IT管理者はStrict候補 |
| Safe Links/Safe Attachments | StandardとStrictで大きな差はない | StandardとStrictで大きな差はない | 差が出るのは主にリンク・添付以外の判定処理 |
Strictは「全員に強くすれば安全」という単純なものではありません。検疫が増えると、管理者やヘルプデスクの確認作業が増えます。役員や経理のように被害時の影響が大きいユーザーにはStrictが有効ですが、通知メールや外部パートナーとのやり取りが多い部署では、誤検知対応の体制まで含めて判断する必要があります。
優先順位を理解しないとカスタムポリシーが効かない
最もトラブルになりやすいのが、ポリシーの優先順位です。公式情報では、同じ受信者が複数のポリシーに含まれる場合、Strict、Standard、Defender for Office 365評価ポリシー、カスタム脅威ポリシー、Built-in protectionまたは既定ポリシーの順に適用されると説明されています。(Microsoft Learn)
つまり、あるユーザーがStandard preset security policyとカスタム迷惑メールポリシーの両方に含まれている場合、そのユーザーにはStandard側の設定が優先され、カスタム側の期待した処理が適用されないことがあります。(Microsoft Learn)
よくある失敗例
| 失敗例 | 起きること | 対応策 |
|---|---|---|
| 全員をStandardに入れた後、一部ユーザーにカスタムポリシーを作る | カスタムポリシーが期待通りに効かない | カスタム対象者をStandardの例外にする |
| StrictとStandardに同じグループを含める | Strictが優先され、想定より厳しい処理になる | Strict用、Standard用のグループを明確に分ける |
| ドメイン条件とグループ条件を混在させる | AND条件になり、想定より対象が狭くなる場合がある | 条件の組み合わせを最小限にする |
| Built-in protectionを不要に除外する | Safe Links/Safe Attachmentsの基本保護が抜ける | ライセンスや例外理由がある場合だけ除外する |
ポリシー設計では、「誰にどの保護を適用するか」より先に、「誰を重複させないか」を決めることが重要です。特に大規模テナントでは、Standard用グループ、Strict用グループ、カスタムポリシー用グループを別々に管理し、棚卸ししやすい命名規則にしておくと運用ミスを減らせます。
管理者が最初に確認すべき設定
Microsoft Defenderポータルでは、Email & collaboration、Policies & rules、Threat policies、Preset Security Policiesの順に進み、Standard protectionまたはStrict protectionを有効化して対象を指定します。公式手順では、Exchange Online Protectionの適用対象とDefender for Office 365保護の適用対象を、それぞれ受信者条件として指定できます。(Microsoft Learn)
確認すべき項目は次の順番で進めると安全です。
| 順番 | 確認項目 | 見るべきポイント |
|---|---|---|
| 1 | 現在のStandard/Strictの状態 | On/Off、対象ユーザー、例外 |
| 2 | Built-in protectionの除外 | 除外が本当に必要か |
| 3 | 受信者条件 | ユーザー、グループ、ドメインの重複 |
| 4 | グループ種別 | 動的配布グループや動的メンバーシップグループを前提にしていないか |
| 5 | なりすまし保護 | 保護対象ユーザー、ドメイン、信頼済み送信者 |
| 6 | カスタムポリシー | プリセットに上書きされていないか |
| 7 | 検疫運用 | 管理者が確認・リリースできる体制があるか |
受信者条件では、配布グループ、メールが有効なセキュリティグループ、Microsoft 365グループを指定できますが、動的配布グループやMicrosoft Entra IDの動的メンバーシップグループはサポート対象外として説明されています。グループ運用で自動メンバーシップを前提にしている組織は、ここで設計を誤りやすいので注意してください。(Microsoft Learn)
Built-in protectionは安易に除外しない
Built-in protection preset security policyは、Defender for Office 365のSafe LinksとSafe Attachmentsの基本保護を広く提供する位置づけです。StandardやStrict、またはカスタムSafe Links/Safe Attachmentsポリシーに含まれていないユーザーが対象になります。(Microsoft Learn)
公式情報では、Built-in protectionはDefender for Office 365のライセンス数にかかわらず広く適用される考え方が説明されており、通常は除外を推奨しないとされています。除外が必要になる代表例は、Defender for Office 365ライセンスの対象外ユーザーをSafe Links/Safe Attachments保護から外したい場合です。(GitHub)
実務では、次のような除外は慎重に扱うべきです。
| 除外したくなるケース | 推奨判断 |
|---|---|
| 特定ユーザーから「リンクの動作が変わった」と問い合わせがある | まずSafe Linksの挙動と対象ポリシーを確認し、すぐ除外しない |
| 外部システム通知メールのURLが誤検知される | Tenant Allow/Block Listや提出機能で原因を確認 |
| 検証用メールボックスで生メールを確認したい | SecOpsメールボックスや高度な配信ポリシーなど、用途に合った方法を検討 |
| ライセンス対象外ユーザーが含まれる | 例外設定の理由を記録し、棚卸し対象にする |
Built-in protectionを広く外すと、StandardやStrictから漏れたユーザーの最低限のリンク・添付ファイル保護も弱くなります。例外は「一時的」「理由付き」「棚卸し可能」にするのが安全です。
なりすまし保護で確認すべき上限と例外
StandardまたはStrictを構成する際は、ユーザー偽装保護とドメイン偽装保護の対象を追加できます。公式情報では、ユーザー偽装保護に指定できるユーザーは最大350人、ドメイン偽装保護に指定できるカスタムドメインは最大50個とされています。(Microsoft Learn)
また、所有している承認済みドメインは、プリセットセキュリティポリシーでドメイン偽装保護を自動的に受けます。一方、信頼済みドメインとして追加したエントリにはサブドメインが含まれないため、example.comを追加してもmail.example.comまで自動で信頼されるとは考えないでください。(Microsoft Learn)
なりすまし保護の設計例
| 対象 | 推奨する扱い |
|---|---|
| CEO、CFO、役員秘書 | Strictに含め、ユーザー偽装保護の対象にする |
| 経理、給与、人事 | 標的型攻撃が多いためStrict候補にする |
| 自社の主要ブランドドメイン | ドメイン偽装保護の確認対象にする |
| 外部委託先やSaaS通知ドメイン | 誤検知時は信頼済み追加ではなく、認証状態や送信元を確認 |
| 過去にやり取りのある外部担当者 | メールボックスインテリジェンスの挙動も踏まえて判断 |
注意したいのは、信頼済み送信者やドメインの追加は「安全宣言」ではないことです。公式情報でも、信頼済みとして追加された送信者のメッセージは偽装攻撃としてはフラグされませんが、Microsoft 365やDefender for Office 365の他のフィルターによるスキャン対象には残ると説明されています。(Microsoft Learn)
PowerShellと自動化でやってはいけないこと
PowerShellでPreset security policiesを扱う場合、個別の脅威ポリシーを直接作成、変更、削除しないことが重要です。公式情報では、StandardまたはStrictに関連付けられた個別の脅威ポリシーを直接操作しようとしないよう警告されています。作成のサポートされた方法は、初回にMicrosoft Defenderポータルでプリセットをオンにすることです。(Microsoft Learn)
PowerShell運用で確認すべき対象は、主にルールの状態とスコープです。Defender for Office 365がある組織では、EOP側のルールとDefender for Office 365保護側のルールを両方確認・有効化・無効化する必要があります。(Microsoft Learn)
Get-EOPProtectionPolicyRule -Identity "Standard Preset Security Policy" |
Format-List Name,State,SentTo,SentToMemberOf,RecipientDomainIs,ExceptIfSentTo,ExceptIfSentToMemberOf,ExceptIfRecipientDomainIs
Get-ATPProtectionPolicyRule -Identity "Standard Preset Security Policy" |
Format-List Name,State,SentTo,SentToMemberOf,RecipientDomainIs,ExceptIfSentTo,ExceptIfSentToMemberOf,ExceptIfRecipientDomainIs
Get-ATPBuiltInProtectionRule |
Format-List Name,ExceptIfSentTo,ExceptIfSentToMemberOf,ExceptIfRecipientDomainIs自動化スクリプトを作る場合は、次の方針にすると安全です。
| 自動化対象 | 推奨 | 理由 |
|---|---|---|
| ルール状態の確認 | 推奨 | 有効・無効、対象範囲の棚卸しに有効 |
| 対象グループの一覧化 | 推奨 | 重複や例外漏れを検出しやすい |
| 例外の一括削除 | 慎重に実施 | 業務影響が大きいため事前レビューが必要 |
| 個別脅威ポリシーの直接変更 | 非推奨 | 公式にサポートされない操作になり得る |
| Standard/Strictの自動切り替え | 慎重に実施 | 検疫増加やヘルプデスク負荷につながる |
開発者やSREがMicrosoft 365運用を自動化している場合、設定値そのものを「望ましい状態」として強制するより、プリセットの対象範囲、例外、状態、重複を検査する監査スクリプトから始めるほうが現実的です。
移行・展開時の注意点
サードパーティのメールセキュリティ製品からMicrosoft Defender for Office 365へ移行する場合、Preset security policiesをいきなり全社適用するより、パイロットユーザーで段階的に確認するほうが安全です。Microsoftの移行ガイドでは、パイロット用配布グループを作り、Safe Attachments、Safe Links、Standard相当、Strict相当などを段階的に検証する考え方が示されています。(Microsoft Learn)
特に注意したいのが、SCL=-1のメールフロールールです。既存の外部メールセキュリティ製品をMicrosoft 365の前段に置いている場合、スパムフィルタリングをバイパスするためにSCL=-1を設定していることがあります。移行時には、このルールの例外や解除タイミングを誤ると、Defender for Office 365の保護が期待通りに働かない可能性があります。(Microsoft Learn)
また、既存サービスがURLを書き換えている場合、Safe Linksの検証で二重書き換えが問題になります。公式移行ガイドでは、すでにラップまたは書き換えられたリンクをさらにラップ・書き換えすることはサポートされないと説明されています。(Microsoft Learn)
展開前チェックリスト
| チェック | 確認内容 |
|---|---|
| 対象ユーザー | Standard、Strict、カスタム対象が重複していないか |
| 例外 | 例外の理由、期限、責任者が記録されているか |
| 既存メールゲートウェイ | SCL=-1ルールやコネクタ設定を把握しているか |
| Safe Links | 既存製品のURL書き換えと競合しないか |
| 検疫運用 | 管理者がリリース判断できる体制があるか |
| ユーザー報告 | 誤検知・見逃しをユーザーが報告できる導線があるか |
| ヘルプデスク | 「メールが届かない」問い合わせ時の確認手順があるか |
適用後は「効いているか」を確認する
Preset security policiesは、オンにして終わりではありません。公式情報では、StandardとStrictの動作確認例として、通常のスパムがStandardでは迷惑メールフォルダーへ配信され、Strictでは検疫されること、バルクメールではStandardがBCL 6以上、StrictがBCL 5以上で異なる処理になることが示されています。(Microsoft Learn)
運用開始後は、最低限次の観点で確認しましょう。
| 観点 | 確認方法 |
|---|---|
| 誤検知 | 検疫、ユーザー報告、管理者提出を確認 |
| 見逃し | Threat Explorer、Email entity、ユーザー報告を確認 |
| ポリシー重複 | Standard/Strict/カスタムの対象グループを棚卸し |
| 例外の増加 | 例外理由と期限を定期レビュー |
| 管理者負荷 | Strict対象者の検疫件数を確認 |
| 高リスクユーザー | 役員、財務、人事、IT管理者が適切にStrictまたは優先保護されているか確認 |
Microsoftの移行ガイドでも、ユーザー報告メッセージ、検疫、Threat Explorer、メールセキュリティレポート、Mail flow insightsなどを使って監視と調整を続けることが示されています。(Microsoft Learn)
カスタムポリシーを残すべきケース
Preset security policiesは強力ですが、すべての組織でカスタムポリシーが不要になるわけではありません。たとえば、特定の国や言語からのメールを制御したい、検疫通知やエンドユーザー操作を細かく変えたい、業務システムの通知メールに特殊な扱いが必要といった場合は、カスタムポリシーを使う理由があります。Microsoftの展開ガイドでも、プリセットでは変更できない設定や、プリセットに含まれない要件がある場合はカスタム脅威ポリシーを検討する考え方が示されています。(Microsoft Learn)
ただし、カスタムポリシーを残すなら、Preset security policiesとの棲み分けを明確にする必要があります。
| 方針 | 向いている組織 | 注意点 |
|---|---|---|
| Standardのみ | 中小規模、複雑な例外が少ない組織 | 高リスクユーザーへの追加対策を別途検討 |
| Standard + Strict | 多くの組織に向く基本形 | Strict対象者の検疫対応体制が必要 |
| Preset + カスタム | 部署や業務システムごとの要件がある組織 | 対象ユーザーを重複させない |
| カスタム中心 | 厳格な業務要件や既存運用がある組織 | Configuration analyzerなどで推奨値との差分を定期確認 |
「とりあえず全員Standard、問題が出たらカスタムで上書き」は失敗しやすい進め方です。カスタムが必要なユーザーは、最初からStandardやStrictの例外にするか、専用グループで分けて管理しましょう。
次に取るべき行動
Microsoft Defender for Office 365のPreset security policiesは、メール保護を推奨値に寄せるうえで有効ですが、導入効果は「誰に」「どの順序で」「どの例外を許すか」で大きく変わります。まずは現在のStandard、Strict、Built-in protection、カスタムポリシーの対象者を一覧化し、重複と例外を確認してください。
そのうえで、一般ユーザーはStandard、高リスクユーザーはStrict、特殊要件はカスタムという形に整理すると、運用ミスを減らしやすくなります。PowerShellや自動化を使う場合も、個別の脅威ポリシーを直接変更するのではなく、ルール状態、対象範囲、例外の監査から始めるのが安全です。次の作業として、DefenderポータルでPreset Security Policies画面を開き、Standard/Strictの対象グループ、Built-in protectionの除外、カスタムポリシーとの重複を確認しましょう。
コメント