Microsoft 365 / Review phishing, malware and spam protection policies

To review Microsoft 365 phishing and malicious-email protection, check who each policy applies to, its priority, and the resulting quarantine and notifications—not just whether a switch is on. Default protection policies already exist. Standard and Strict preset security policies and custom policies provide additional configuration options depending on the available product features.

Distinguish the protection types

Microsoft's preset security policy guide explains the relationship between Default, Standard, Strict, and custom policies. In particular, when multiple policies apply to the same user, the priority may cause settings that differ from expectations to be selected. Not all features are included in every Microsoft 365 subscription.

Record available features and current settings

Distinguish between the basic email protection of Exchange Online and the additional features of Defender for Office 365. For example, if Safe Links, Safe Attachments, or certain impersonation-protection features are needed, you must check the service entitlements for the users to whom it will be applied. A visible menu does not prove that every recipient is entitled to every feature. Built-in protection is automatically applied in organizations with Defender for Office 365 licenses; that baseline does not mean all recipients are licensed for every Defender capability or custom-policy feature.

Permission to view policy settings does not necessarily grant permission to change them. Use approved security or email-administration access to record each policy’s name, enabled status, recipients, exclusions, priority and quarantine action. Read the actual tenant configuration rather than assuming defaults. Check that each existing business exception still has an owner and a documented purpose.

Understand which policy takes precedence

For a given protection type, policy settings are not merged: only the first matching policy applies to a recipient. The order is Strict → Standard → evaluation policies, if enabled → custom policies → default policies or Built-in protection. Evaluation policies cover the supported Defender for Office 365 features; they are not a separate evaluation policy for every protection type. Among custom policies of the same type, a lower priority number takes precedence. Built-in protection supplies the default Safe Links and Safe Attachments protection in Defender for Office 365; the default anti-malware, anti-spam and anti-phishing policies are separate policies.

For example, if a test user is included in both the Standard preset and a custom spam policy, even if you raise the priority of the custom policy to 0, the corresponding protection from Standard will be applied first. If a user receives unexpected results, first check the preset that the person is included in. You should also not confuse the inspection order of different types of protection like malware and spam with the priority of policies of the same type.

Use the policy precedence rules above to check one recipient’s effective policy for each protection type. Do not assume that the strongest settings from several policies will be combined: settings from a lower-priority policy of the same type can be ignored entirely.

Review the current policies

1. In the Microsoft Defender portal, open Email & collaboration → Policies & rules → Threat policies. Menus may vary depending on the screen language and license.
2. Check the activation status and application targets of preset security policies. Also check whether separate policies are being applied to executives or sensitive work accounts.

3. Review exceptions and allow lists for phishing, malware, and spam policies. Ensure that old business exceptions are not excessively broad.
4. If the same recipient is included in multiple policies, the actual applicable policy is determined according to Microsoft’s policy precedence guidance.
5. Check the expected results with actual quarantined messages or safely prepared test emails. Also, check whether notifications are sent to users and who can release a quarantined message.

Pilot Standard or Strict protection

Standard serves as a starting point for reviewing general protection standards, while Strict is a set of settings for targets requiring stricter protection. Strict does not mean it automatically fits all roles. Because most of the preset detail values are managed by Microsoft, unlike custom policies which users can freely adjust, evaluate whether the policy selection and target scope meet your requirements before looking for individual options.

1. Open Threat policies → Preset security policies and record the current Standard or Strict status, recipients and exclusions. To configure a profile, select Manage protection settings; if it is disabled, the documented setup flow first switches it On. Review the wizard’s recipient scope carefully before confirming changes.
2. For the protection you want to change, specify test users or groups and review exceptions. If the wizard shows the scope of basic protection and Defender protection separately, compare each with the targets and licenses.
3. Compare items that require entry, such as users and domains to be protected from impersonation, with actual organizational information. Check not only display names but also the accounts and domains you want to protect.
4. Check the review screen and apply it to the approved scope, then read the save status and target list again. When modifying existing presets, also verify that targets outside the pilot are not changed.
5. Check delivery, junk folder, quarantine, and notifications using emails sent through normal business-critical routes. Do not include malicious attachments or actual phishing sites in general test emails.

Simple tests of sending and receiving normal emails do not verify all attack detection capabilities. Actual security tests must be conducted separately using tools and within the scope approved by the organization. The purpose of this check is to confirm that policy targets, business impact, quarantine, and notifications match expectations.

Check quarantine and user notifications

Quarantine policies control which messages recipients can view and whether they can release them or request an administrator’s approval. A notification does not itself grant release permission. Users cannot directly release their own messages quarantined as malware by anti-malware policies, as malware or phishing by Safe Attachments, or as high-confidence phishing by anti-spam policies, regardless of the quarantine policy’s release setting. Where a release permission would otherwise apply in these cases, users can request release instead; check the actual assigned policy and administrator approval process.

The administrator checks the reason for message detection, the applied policy, and the automatic action status, and decides who will approve the release. Messages sent to the Junk folder, quarantined messages, and messages rejected by the server have different follow-up actions, so read them along with message trace results.

If legitimate mail is blocked

Do not turn off phishing protection for the entire organization just because there is a delivery issue with legitimate mail. Check the status using message trace, and investigate the quarantine reason, sender authentication results, and the actual applied policy. If it is a false positive, narrow down and modify the affected sender and policy conditions, and verify that the intended legitimate mail can arrive without creating a broad bypass for harmful messages. Conversely, if phishing reaches the inbox, review the allow lists, priority settings, and domain authentication settings.

Do not allow an entire domain merely because the sender asks. Verify the real sending source and the results of Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting and Conformance (DMARC). Adding an address to a mailbox’s Safe Senders list does not bypass malware or high-confidence phishing detection; an address-book contact is a separate concept. For false positives that require submission or an allow entry, use the official submission method supported for that detection type and record the target, expiration and justification.

After changing a policy, retest the same legitimate sending route and check for protection gaps affecting other recipients. Keep a record of the policy, recipients and exclusions so you can restore only the problematic changes to their previous values. Assign an owner to review or remove temporary allow entries before expiration. Do not consider an issue resolved merely because one email arrived after protection was weakened.