By the end of this you have the Standard preset security policy enabled and scoped to your organization, the impersonation lists that Microsoft cannot populate for you filled in by hand, one custom policy carved out as a deliberate exception, and quarantine notifications wired so users are told when their mail is held. Each step is given as the portal walk-through first and then as the equivalent Exchange Online PowerShell, and at the end you validate the whole thing with messages you send yourself. It is written against the mid-2026 portal and the current cmdlet set, and this surface moves, so confirm the labels and parameters before a production rollout.
Before Step 1: a mailbox holding the Security Administrator or Organization Management role, the ExchangeOnlineManagement PowerShell module installed if you intend to use the scripted path, and at least one Defender for Office 365 license in the tenant. The impersonation work in Step 3 has no PowerShell equivalent and is portal only by design, so budget for doing that step by hand regardless of how you handle the rest.
Step 1: Enable organization customization
This is the one step with no portal surface, and it is a genuine prerequisite rather than a formality. If your tenant has never had its consolidated security settings modified, the first preset or policy change will fail with an organization-customization error until you run this once. There is nothing to see in the portal; connect to Exchange Online and run the enablement.
Connect-ExchangeOnline -UserPrincipalName [email protected]
Enable-OrganizationCustomizationExpected result: the command completes silently. Failure mode to expect and ignore: if customization was already enabled, the cmdlet returns an error saying so, which is harmless. The real failure is skipping it, which surfaces later as a confusing rejection on a change that should have worked.
Step 2: Enable and scope the Standard preset
In the portal, open Email & collaboration, then Policies & rules, then Threat policies, and open Preset security policies. Turn on Standard protection and step through its wizard. The wizard assigns recipients twice, on the Apply Exchange Online Protection page and again on the Apply Defender for Office 365 protection page. For a first rollout, assign both to all recipients; scope tighter only if you are deliberately staging. Leave the impersonation pages for Step 3.
| Setting | Value | Why |
|---|---|---|
| Preset | Standard for the whole organization; Strict for a high-risk subset | Standard is Microsoft’s recommended baseline for all users. Strict raises spam and impersonation actions to quarantine and pushes the phishing threshold to its most aggressive setting, at the cost of more false positives for your team to work. |
| Exchange Online Protection recipients | All recipients | The built-in anti-spam, anti-malware, and anti-spoofing protections should cover every mailbox with no exceptions. |
| Defender for Office 365 recipients | All recipients, or a scoped group during a staged rollout | Safe Links, Safe Attachments, and impersonation can be scoped tighter while you pilot, but the destination is the whole population. |
The same in PowerShell, remembering that a preset’s on or off state is toggled only through the Enable and Disable cmdlets, never through Set, and that the two rules with the same identity are separate objects, one for the built-in layer and one for the Defender layer. Both must be enabled. Scope is applied with Set against each rule; a rule with no recipient condition covers everyone.
Enable-EOPProtectionPolicyRule -Identity "Standard Preset Security Policy"
Enable-ATPProtectionPolicyRule -Identity "Standard Preset Security Policy"
# Optional: scope both legs to a group rather than all recipients
Set-EOPProtectionPolicyRule -Identity "Standard Preset Security Policy" -SentToMemberOf "All-Staff"
Set-ATPProtectionPolicyRule -Identity "Standard Preset Security Policy" -SentToMemberOf "All-Staff"Failure mode: running Set to try to enable a preset does nothing to its state and leaves you convinced it is on when it is not. Enable is the only cmdlet that flips it. Verify with Get-EOPProtectionPolicyRule and confirm the State reads Enabled on both rules.
Step 3: Populate the impersonation lists, by hand
This step is portal only, and that is not an oversight to engineer around. The impersonation lists inside a preset are set exclusively through the wizard. The underlying preset policies are explicitly off limits to the policy cmdlets, and Microsoft’s own guidance is not to modify them directly, so there is no supported PowerShell path here. In the Standard preset wizard, work the Impersonation protection page and its three parts.
| Setting | Value | Why |
|---|---|---|
| Add email addresses to flag when impersonated by attackers | Executives, finance staff, anyone with signing or payment authority (up to 350) | Impersonation protection only fires on names you list. An empty list is protection that never triggers, which is the most common way this control is present and useless at once. |
| Add domains to flag when impersonated by attackers | Partner and vendor domains you transact with (up to 50 custom; your own accepted domains are added automatically) | Catches lookalike sends from domains your users already trust, which is where impersonation does its real damage. |
| Add trusted email addresses and domains to not flag as impersonation | Legitimate senders that trip the check, such as a newsletter service that sends under an executive’s display name | Prevents known-good mail from being quarantined as impersonation. Remember that a trusted domain does not cover its subdomains; each subdomain needs its own entry. |
There is no command to run here and no expected output to check other than the wizard saving. This is the step that turns a generic preset into protection aimed at your organization, and it is worth the deliberate time it takes.
Step 4: Carve out one deliberate custom exception
The presets wire quarantine in a fixed way, with no end-user notifications for ordinary spam and bulk mail. When a population needs a softer experience, a daily digest and the ability to request release, that is a legitimate reason to leave the preset for that group, and it is the cleanest illustration of the policy-and-rule pattern every custom object follows. In the portal you build this in three moves: a custom quarantine policy under Quarantine policy, an exception on the Standard preset so the group is no longer claimed by it, and a custom anti-spam policy under Anti-spam that assigns the new quarantine policy to that group.
The same as one runnable block. Note the shape that repeats across this whole product: the policy holds the settings, the rule holds the scope and priority, and the policy does nothing until a rule references it.
# 1. A quarantine policy that notifies users and lets them request release (Limited access = 43)
New-QuarantinePolicy -Name "QP-Notify-Bulk" -EndUserQuarantinePermissionsValue 43 -ESNEnabled $true
# 2. Exclude the opt-in group from the Standard preset so a custom policy can own them
Set-EOPProtectionPolicyRule -Identity "Standard Preset Security Policy" -ExceptIfSentToMemberOf "MDO-Scope-BulkNotify"
# 3. A custom anti-spam policy that assigns the notifying quarantine policy, plus its rule
New-HostedContentFilterPolicy -Name "MDO-AntiSpam-BulkNotify" -BulkSpamAction Quarantine -BulkQuarantineTag "QP-Notify-Bulk"
New-HostedContentFilterRule -Name "MDO-AntiSpam-BulkNotify" -HostedContentFilterPolicy "MDO-AntiSpam-BulkNotify" -SentToMemberOf "MDO-Scope-BulkNotify"Failure mode: create the policy without the rule and nothing happens, because an unreferenced policy never applies. The mirror mistake is to forget the exception in the second command, in which case the Standard preset still claims the group first, by precedence, and your custom policy is ignored exactly as the doctrine piece warned.
Step 5: Set the notification cadence
The per-policy setting decided whether users are notified. One global object decides how often and with what branding. In the portal this is the Global settings flyout on the Quarantine policy page; the frequency choices are Within 4 hours, Daily, and Weekly. In PowerShell the global object is addressed through its type rather than a name.
Get-QuarantinePolicy -QuarantinePolicyType GlobalQuarantinePolicy |
Set-QuarantinePolicy -EndUserSpamNotificationFrequency 1.00:00:00 -OrganizationBrandingEnabled $trueThe value 1.00:00:00 is a daily digest; 04:00:00 is every four hours and 7.00:00:00 is weekly. Daily is the sane default, frequent enough that held mail is not forgotten and rare enough that the notification is not itself noise.
Validation, and one end-to-end test
Confirm the baseline is live rather than merely saved. The spam path has a standard test message. Include the following string, on a single line with no extra spaces, in a message sent from an external source that does not itself scan outbound spam, which rules out most consumer mail services and points you at a raw sending tool.
XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34XThe end-to-end test that proves the impersonation work is the one worth doing, because it is the part unique to your tenant. From an external mailbox, set the display name to match one of the executives you listed in Step 3 and send a plain message to a test recipient. A correctly configured Standard preset acts on it, and you can confirm the verdict two ways: the message is handled per the impersonation action rather than delivered clean, and its header carries the user-impersonation category. Read the disposition from PowerShell and the category from the message header.
# Confirm the message was quarantined or actioned rather than delivered
Get-QuarantineMessage -RecipientAddress [email protected] |
Format-Table ReceivedTime,SenderAddress,Subject,QuarantineTypes
# In the delivered or quarantined item, read X-Forefront-Antispam-Report; CAT:UIMP confirms user impersonation
# (GIMP = mailbox-intelligence impersonation, DIMP = domain impersonation, SPOOF = spoofing)One caution that saves a false alarm: a newly enabled or changed policy takes time to apply, and an impersonation test run immediately after the wizard saves can read as a failure when it is only propagation. Give it time before you conclude the control is not working, and re-send rather than re-configuring.
Naming convention
Keep custom objects legible so that six months from now the estate still explains itself. Scope groups take the form MDO-Scope-<purpose>, as in MDO-Scope-BulkNotify or MDO-Scope-ExecProtection. Custom policies name the protection and the population, as in MDO-AntiSpam-BulkNotify, and their rule takes the identical name so the pairing is obvious. Quarantine policies take a QP- prefix and a purpose, as in QP-Notify-Bulk. The presets keep their Microsoft-given names untouched, which is how anyone reading the tenant can tell at a glance what is delegated and what you built.
A worked example
Take a firm with a twelve-person executive and finance group that is the obvious target for payment fraud. You create a group named MDO-Scope-ExecProtection and assign the Strict preset’s Defender leg to it, leaving the rest of the organization on Standard. In the Strict wizard you list all twelve as protected users, add your two accepted domains and the four partner domains you send payment instructions to as protected domains, and add your payroll provider’s sending domain as a trusted sender because it legitimately uses a finance manager’s name. High confidence phishing for this group stays on the admin-only quarantine the preset assigns, because these are exactly the people whose held mail you want an analyst to see rather than release themselves. The rest of the organization runs Standard with the notifying bulk exception from Step 4. Two populations, two postures, one preset each, and the impersonation lists doing the work that no preset could have done on its own.
The baseline is standing and aimed. What it does not yet cover is the protection stack itself, the Safe Links rewrite decision, the collaboration files sitting in SharePoint with a download door open, and the anti-phishing engine that has to be told to act on what it learns. That is the next build.
Defender XDR
‹ Previous: [D 4.1] Policy Architecture: Presets, Precedence, and the Work That Remains
Next: [D 4.2] The Protection Stack: What Safe Links, Safe Attachments, and Anti-Phishing Actually Do ›
