Defender for Office 365 presets: Standard vs Strict, and why custom policies seem ignored

You turned on the Standard preset, kept your carefully tuned custom anti-spam policy, and now users complain that newsletters land in Junk even though your policy allows them. Nothing is broken: presets always win. In this post I'll explain what each preset actually enforces, where the line between Exchange Online Protection and Defender for Office 365 sits, the order of precedence that makes custom policies look ignored, the impersonation settings presets leave for you, and how to prove which policy handled a message.

How it works#

Preset security policies are Microsoft-maintained bundles of threat policies with fixed values. Three exist:

• Built-in protection (Defender for Office 365 only). On by default for every recipient, it provides baseline Safe Links and Safe Attachments and nothing else. You can only add exceptions to it.
• Standard protection. Microsoft's recommended baseline for most users. Off until you turn it on and choose recipients.
• Strict protection. A more aggressive profile for high-value targets such as executives, finance and IT admins. Also off by default.

Each of Standard and Strict is really two halves, and that's where licensing comes in:

The wizard asks for recipients separately for each half, so if only some users are licensed for Defender for Office 365, scope that half to them. Outbound spam policies aren't part of presets at all.

What differs between Standard and Strict#

Anti-malware, Safe Links and Safe Attachments settings are identical in both. The differences are in anti-spam and anti-phishing:

Built-in protection is deliberately softer than the Safe Links policy in Standard and Strict: it lets users click through to the original URL, doesn't rewrite URLs (checks happen through the Safe Links API), and doesn't scan internal mail.

Order of precedence#

When a recipient is covered by more than one policy of the same type, the first match in this order wins and the rest are never evaluated:

1. Strict preset security policy
2. Standard preset security policy
3. Defender for Office 365 evaluation policies
4. Custom threat policies, by priority (lower number first)
5. Built-in protection for Safe Links and Safe Attachments; the default anti-spam, anti-malware and anti-phishing policies

So if a user is in Standard and in your custom anti-spam policy, the Standard anti-spam settings apply and your allowed senders, custom bulk threshold and quarantine policy are never consulted. The policy pages in the Defender portal list policies in this applied order, which is the quickest way to see who really wins.

Step-by-step: turning on a preset without surprises#

1. Decide who gets what#

Microsoft's advice is to use unambiguous groups: one group for Strict, one for Standard, and custom policies only for recipients in neither. If overlap is unavoidable, add exceptions on the higher-ranked policy: exclude the "custom policy" users from Standard, and exclude the "Standard" users from Strict.

2. Assign recipients#

Go to Email & collaboration › Policies & rules › Threat policies › Preset security policies, switch Standard or Strict to On and select Manage protection settings. Conditions can be users, groups (distribution groups, mail-enabled security groups or Microsoft 365 Groups; dynamic groups aren't supported) or accepted domains. Different condition types combine with AND, so a user plus a group condition applies only to users who match both; exceptions combine with OR. Domain conditions include subdomains automatically unless you exclude them.

3. Configure impersonation protection#

This is the part admins skip. Presets automatically protect all your accepted domains against domain impersonation and turn on mailbox intelligence, but the users to protect list (the CEO, CFO, payroll contact, key suppliers) is empty until you fill it, up to 350 entries, each a display name plus email address. You can also add up to 50 custom domains (partners, your brands on other domains) and a list of trusted senders and domains that should never be flagged. Trusted domain entries don't include their subdomains, so add each one. Note that user impersonation detection doesn't trigger between a sender and recipient who have previously exchanged email.

4. Leave Built-in protection alone#

Exceptions to Built-in protection are only sensible for recipients who don't have a Defender for Office 365 licence. Everyone in Standard, Strict or a custom Safe Links or Safe Attachments policy is already handled before Built-in protection is reached.

Verify#

Microsoft's own test is behavioural: send a message that will be classed as spam (not high-confidence spam) to a Standard user and a Strict user; it should land in Junk Email for the first and in quarantine for the second. For bulk mail, BCL 6 or higher goes to Junk under Standard while BCL 5 or higher is quarantined under Strict.

Message headers tell you how a delivered message was filtered. In X-Forefront-Antispam-Report, CAT is the verdict category (SPM spam, HSPM high-confidence spam, BULK, PHSH phishing, SPOOF, and the Defender-only UIMP, DIMP and GIMP for user, domain and mailbox-intelligence impersonation), and SFV shows filtering overrides such as SKA (allowed sender in an anti-spam policy) or SKN (mail flow rule bypass). The bulk complaint level is in X-Microsoft-Antispam as BCL. Don't read SCL as the decision; in cloud organisations CAT and DIR are what matter.

To see the scope of each preset from Exchange Online PowerShell (V3 module):

Connect-ExchangeOnline
Get-EOPProtectionPolicyRule -Identity "Standard Preset Security Policy" |
    Format-List Name, State, SentTo, SentToMemberOf, RecipientDomainIs, ExceptIfSentTo, ExceptIfSentToMemberOf
Get-ATPProtectionPolicyRule -Identity "Strict Preset Security Policy" |
    Format-List Name, State, SentTo, SentToMemberOf, RecipientDomainIs, ExceptIfSentTo
Get-ATPBuiltInProtectionRule | Format-List Name, State, ExceptIfSentTo, ExceptIfSentToMemberOf, ExceptIfRecipientDomainIs

The rules only exist once a preset has been turned on at least once; turning it off disables the rule but doesn't delete it. To inspect the values a preset enforces, list the policies it created, for example Get-HostedContentFilterPolicy | Where-Object RecommendedPolicyType -eq "Standard".

Tips and gotchas#

• Use the configuration analyzer at Email & collaboration › Policies & rules › Threat policies › Configuration analyzer to compare your custom policies with Standard and Strict and apply individual recommendations. The Configuration drift analysis and history tab (requires unified auditing) shows who changed what in the last 90 days and whether security went up or down.
• When to stay with custom policies. Preset values can't be edited. If you need sender or domain allow lists, a different bulk threshold, different quarantine policies and notifications, or Safe Links behaviour the preset doesn't offer, keep those recipients out of the presets and use the analyzer to keep your custom values close to Standard.
• Don't edit the generated policies. The policies named Standard Preset Security Policy and Strict Preset Security Policy are managed by the preset. Change scope through the rules, not the policies, and never create them manually.
• Quarantine volume rises under Strict. Spam, bulk, spoof and impersonation all go to quarantine instead of Junk, so brief those users on quarantine notifications before you move them.
• Strict isn't "more of everything". Malware, Safe Attachments and Safe Links behave the same in both; Strict mainly tightens spam, bulk and phishing thresholds.

References#

• Preset security policies in cloud organizations
• Configuration analyzer for threat policies
• Anti-spam message headers in cloud organizations