Apply Defender for Office 365 preset policies without overprotecting the wrong users

Source fact: what Microsoft documents

Microsoft documents three preset email-protection profiles in cloud organizations: Built-in protection, Standard protection, and Strict protection. Preset policies combine recommended settings across multiple threat policies. Most Standard and Strict settings are not individually configurable because Microsoft maintains the profile. Standard is intended to balance protection and disruption, while Strict uses more aggressive settings for highly targeted or higher-risk users.

Built-in protection provides baseline Safe Links and Safe Attachments coverage for eligible cloud-mailbox recipients who are not otherwise covered by Standard, Strict, or custom Safe Links and Safe Attachments policies. Policy precedence determines which settings apply when assignments overlap. Microsoft documents up to 350 protected users for user-impersonation protection in Standard or Strict. Mailbox intelligence provides other impersonation protection, but previous sender-recipient communication can affect user-impersonation behavior.

Licensing and applicability

Built-in and Exchange Online Protection features apply to cloud mailboxes as documented, while Defender for Office 365 features require Plan 1, Plan 2, or another subscription that includes them. If only part of the organization is licensed, Microsoft directs administrators to target eligible recipients and exclude recipients who are not eligible. Available settings, trials, government-cloud behavior, unified RBAC, Exchange role groups, and policy precedence should be confirmed in the current tenant.

DSE recommendation: production-safe operational steps

1. Export existing anti-malware, anti-spam, anti-phishing, Safe Links, Safe Attachments, quarantine, transport, and allow/block settings with owners and assignments.
2. Map each recipient to current Defender licensing. Do not use portal availability as proof that every targeted mailbox has the required entitlement.
3. Identify high-risk users who need Strict and the administrators who will review and release false positives. Place ordinary pilot users in Standard.
4. Review policy precedence before assignment. Remove overlapping or contradictory custom targeting only after the effective result is verified.
5. Configure impersonation targets and trusted senders narrowly. Avoid broad allowlisting that bypasses other detection.
6. Test legitimate automated senders, partner mail, bulk mail, attachments, links, quarantine notifications, user submissions, administrator release, and message trace.
7. Measure false positives, quarantine volume, release time, user reports, and confirmed detections before expanding. Maintain a rollback assignment and staffed support path.

DSE recommends documenting why a custom policy remains when a preset profile is available. Some applications have valid delivery needs, but a customization should be the narrowest supported exception with an owner and review date. Because Microsoft can update preset recommendations, revalidate business-critical mail flows after documented service changes.

A successful rollout protects every intended licensed recipient, keeps high-impact review work supportable, and retains evidence that important business mail still flows. A higher quarantine count by itself is not proof of better protection.

Official reference

Preset security policies in cloud organizations — profiles, permissions, licensing targeting, configuration, precedence, and validation.