Microsoft Defender for Office 365 Configuration Guide: Presets, Roles, Exceptions and Logging

Microsoft Defender for Office 365 tenants are usually breached through their exceptions rather than their defaults: users left outside the preset policies, allow lists and filtering bypasses added to fix one problem, and admin roles nobody reviews. Microsoft's preset security policies and CISA's Secure Cloud Business Applications (SCuBA) baseline give a strong starting point, but only if they cover everyone and the exceptions are controlled. This guide covers how access and licensing work in Defender for Office 365, the admin roles that matter, the integrations and API identities that touch mail filtering, what to log and alert on, a hardening baseline mapped to SCuBA, and the misconfigurations seen most often. It is for Microsoft 365 administrators and security engineers; for email security strategy across products see the Email Security Guide.

Key takeaways

• Put everyone in a preset. SCuBA policy MS.DEFENDER.1.1v1 to 1.5v1 require the Standard and Strict preset security policies to be enabled, all users added to Standard or Strict, and sensitive accounts added to Strict.
• Impersonation needs your input. Domain impersonation for accepted domains and mailbox intelligence are automatic, but protected users (up to 350) and partner domains (up to 50) must be added by hand.
• Use advanced delivery, not bypass rules. Third-party phishing simulations and SecOps mailboxes belong in the advanced delivery policy, which is scoped and tagged, rather than in mail flow rules that skip filtering.
• Roles live in four places. Entra ID roles, Email & collaboration roles, Defender Unified RBAC and Exchange Online permissions all grant power over mail filtering and need reviewing together.
• Logging is licence dependent. Plan 1 gives Real-time detections; Plan 2 adds Threat Explorer, automated investigation and response (AIR) and advanced hunting, and some default alerts need Plan 2.

How identity and access work in Defender for Office 365

Defender for Office 365 sits on top of Exchange Online Protection (EOP), which every Microsoft 365 subscription with cloud mailboxes includes. Microsoft describes three layers.

Policy assignment is identity based. Each threat policy applies to users, groups or domains, and when a recipient matches several, Microsoft applies them in this order: Strict preset, Standard preset, Defender for Office 365 evaluation policies, custom policies by priority, then Built-in protection with the default policies. Built-in protection gives basic Safe Links and Safe Attachments to all users when the tenant has any Defender for Office 365 licences, but with weaker Safe Links settings (no URL rewriting, click-through allowed, internal senders not covered). A user left out of Standard and Strict therefore gets materially less protection without any error showing.

Licensing also scopes protection: on the preset's Apply Defender for Office 365 protection page you can limit Defender features to licensed users. Keep licence groups and policy groups aligned so that a new joiner gets both.

Admin roles and privileged access

Four permission systems control Defender for Office 365, and an attacker who gains any of them can weaken mail filtering for the whole tenant.

• Least privilege: Microsoft advises limiting Global Administrator to emergencies. Give SOC analysts Security Operator or a Unified RBAC role scoped to investigation and quarantine, not Security Administrator.
• Just-in-time access: make Security Administrator and Exchange Organization Management eligible through privileged identity management rather than permanent. See the Privileged Identity Management (PIM) Guide.
• Plan the RBAC migration: import or recreate roles in Unified RBAC before activating it, because the legacy page is removed on activation.
• Protect the admins: tag administrators as priority accounts and put them in the Strict preset, since their mailboxes receive the most targeted phishing.

Integrations, API tokens and service accounts

Several non-human identities and integrations can change what Defender for Office 365 sees or does. Each is a place to look for drift.

• Advanced delivery policy: exempts third-party phishing simulation traffic (matched by sending domain and IP, up to 50 domains and 10 IPv4 sending IPs in the portal) and SecOps mailboxes from filtering. For SecOps mailboxes, malware filtering and malware ZAP are bypassed too. Changes need Security Administrator plus Exchange Organization Management. Review entries quarterly and remove vendors you no longer use.
• Inbound connectors and Enhanced Filtering for Connectors: when MX points to a third-party gateway, enhanced filtering lets Microsoft see the real sending IP. Without it, authentication checks and spoof detection degrade.
• Tenant Allow/Block List and mail flow rules: allow entries for domains, senders, URLs and files, and rules that set SCL to -1, are bypasses. Treat each as a change with an owner and an expiry.
• API applications: SIEM connectors, SOAR tools and reporting scripts use Entra app registrations with permissions to Defender XDR APIs, Microsoft Graph security APIs or the Office 365 Management Activity API. Grant read permissions only, prefer certificate or managed identity credentials, and assign an owner. See the Entra ID Applications and Consent Guide and the Azure Entra Client Secrets Security Guide.
• Third-party email security add-ons: API based mail security products often hold application permissions to read and move mail in every mailbox. Those permissions are as powerful as an Exchange administrator and need the same review.

Logging and detection

Alerts to route to the SOC

• A potentially malicious URL click was detected and A user clicked through to a potentially malicious URL (high severity, E5/G5 or Plan 2).
• Messages containing malicious entity not removed after delivery (medium): ZAP could not remove a threat.
• Suspicious email forwarding activity (high) and Creation of forwarding/redirect rule: common after mailbox takeover.
• User restricted from sending email (high) and Suspicious email sending patterns detected: often a compromised account sending spam or phishing.
• Configuration changes: build your own alerts from the audit log for changes to preset assignments, anti-phishing policies, Safe Links policies, advanced delivery entries and Tenant Allow/Block List allows.

Microsoft has replaced two legacy alerts (Email messages containing malware removed after delivery and Email messages containing phish URLs removed after delivery) and recommends disabling them. Send alerts to a monitored mailbox or SIEM, as SCuBA MS.DEFENDER.5.2v1 recommends. For audit log handling see the Microsoft 365 Unified Audit Log Guide for Detection.

A useful hunting query lists messages delivered despite a threat verdict, together with the policy that let them through:

EmailEvents | where Timestamp > ago(7d) | where DeliveryAction == "Delivered" and isnotempty(ThreatTypes) | summarize count() by OrgLevelPolicy, ThreatTypes

Any result where OrgLevelPolicy names an allow entry or a mail flow rule is an exception doing harm.

Hardening baseline

The Standard and Strict presets differ in action strength: Standard moves spam, spoof and bulk mail (bulk threshold 6) to Junk Email with phishing threshold 3, while Strict quarantines them, uses bulk threshold 5 and phishing threshold 4. Microsoft states that the individual policies behind presets should not be created or edited directly; turn the preset on in the Defender portal and manage membership.

Rolling out the baseline

1. Assess: run Microsoft's configuration analyzer and CISA's ScubaGear assessment tool against the tenant to list gaps. Export current custom policies, allow entries and mail flow rules that bypass filtering.
2. Pilot: assign the Standard preset to an IT pilot group for two weeks, monitor quarantine volume and user-reported false positives.
3. Expand in rings: all users to Standard, then sensitive accounts to Strict, with quarantine policies that let users request release where appropriate.
4. Configure impersonation lists for executives, finance approvers and top suppliers.
5. Retire bypasses: move phishing simulation and SecOps exceptions into advanced delivery, then remove the old mail flow rules and allow entries.
6. Rollback: if false positives spike, move the affected group from Strict back to Standard rather than adding allow entries, and use submissions to report misclassified mail.

Common misconfigurations

• Presets enabled but not assigned: Standard and Strict are off and unassigned until you turn them on and add users. Many tenants turn them on for a pilot and never widen them.
• Relying on Built-in protection: it covers only Safe Links and Safe Attachments, without URL rewriting and without internal senders, and does not add impersonation protection.
• Bypass rules for simulations and gateways: mail flow rules that set SCL to -1 for a vendor IP, or on-premises IPs added to advanced delivery, bypass spam filtering for anyone who can spoof that path. Microsoft warns specifically against adding on-premises IPs.
• Allow list sprawl: domain and sender allow entries added during a false positive and never removed. Review the Tenant Allow/Block List with expiry dates.
• Trusting the domain, not the request: lures hosted on genuine Microsoft domains defeat reputation checks. The CoPhish technique used a Copilot Studio agent on a real Microsoft domain to lead users into an OAuth consent prompt, so mail filtering must be paired with admin consent policies. See the Consent Phishing and Illicit OAuth Grants Guide.
• Unreviewed integration permissions: SIEM, SOAR and third-party mail security apps with tenant-wide mail permissions and long-lived client secrets.

Framework mapping

Practitioner checklist

• Enable Standard and Strict presets and confirm every licensed user is in one of them.
• Put admins, executives and finance approvers in Strict and tag them as priority accounts.
• Add protected users and key partner domains to impersonation protection.
• Turn on Safe Attachments for SharePoint, OneDrive and Teams.
• Move simulation and SecOps exceptions into the advanced delivery policy and remove bypass mail flow rules.
• Review Tenant Allow/Block List allow entries monthly with owners and expiry dates.
• Scope Defender, Entra and Exchange roles to least privilege with just-in-time elevation.
• Inventory API apps with mail or security permissions and remove unused secrets.
• Route default email threat alerts and audit-based configuration change alerts to the SIEM.
• Run ScubaGear or an equivalent assessment quarterly and track drift.

Standards and references

• CISA: Secure Cloud Business Applications (SCuBA) Project
• CISA: SCuBA Microsoft Defender for Office 365 baseline
• Microsoft Learn: Preset security policies in EOP and Microsoft Defender for Office 365
• Microsoft Learn: Microsoft Defender for Office 365 overview
• Microsoft Learn: Permissions in the Microsoft Defender portal for Defender for Office 365
• Microsoft Learn: Configure the advanced delivery policy
• Microsoft Learn: Alert policies in the Microsoft Defender portal
• Microsoft Learn: EmailEvents table in the advanced hunting schema

Related NHI Mgmt Group resources: Email Security Guide · Phishing Guide · Microsoft 365 Unified Audit Log Guide for Detection · SaaS Audit Log Retention and Licensing Guide