Before You Replace Microsoft Defender for Office 365: Check These Settings First

Microsoft Defender for Office 365 is not necessarily the strongest email security product in every category. Different platforms have different strengths, particularly around behavioral analysis, business email compromise and investigation workflows.

However, I would be careful about judging Defender based on its default configuration.

I regularly see organizations license Defender, enable a few policies during deployment and then leave the environment largely untouched. Safe Links may still be assigned only to a pilot group. Safe Attachments may still be running in Monitor mode. Anti-phishing protection may be using the default sensitivity. Old allow entries may be bypassing filtering entirely.

Before concluding that Defender is not effective enough, I would first make sure you are evaluating it as Microsoft intends it to be configured.

Start with Standard and Strict preset policies

The default threat policies are not Microsoft's strongest recommended settings.

Microsoft provides Standard and Strict preset security policies. Standard is designed as a baseline for most users, while Strict applies more aggressive filtering for higher-risk accounts.

A practical configuration is:

• Standard protection for most mailboxes
• Strict protection for executives, finance, payroll and administrators
• Custom policies only where there is a clear technical requirement

One detail that causes confusion is that Standard and Strict policies do not protect anyone until recipients are assigned to them.

After enabling them, use Microsoft's Configuration Analyzer to compare your tenant with Microsoft's recommended Standard and Strict configurations.

This quickly shows whether your anti-phishing, anti-spam, Safe Links and Safe Attachments settings are weaker than Microsoft's current recommendations.

Confirm which policy actually applies

Defender policies follow a precedence order.

Strict preset policies normally take priority over Standard policies. Standard policies take priority over custom policies, which in turn take priority over the built-in or default policies.

This means a custom policy can be configured correctly but still have no effect because another policy has already matched the recipient.

It is worth reviewing how Microsoft combines threat policies before making changes.

Whenever a setting appears not to work, first confirm:

• Which policy is applied
• Which users are included
• Whether exclusions exist
• Whether a higher-priority policy is taking precedence

Policy scope problems are extremely common and can make the product look less effective than it really is.

Strengthen impersonation protection

Anti-phishing protection is one of the most important areas to review.

Microsoft's default anti-phishing policy is less aggressive than its Standard and Strict recommendations. Microsoft documents these differences in its recommended email security settings.

I would explicitly protect internal users who are likely to be impersonated, including:

• Senior management
• Finance
• Accounts payable
• Payroll
• Procurement
• Privileged administrators

The most valuable target is not always the person with the highest job title. Someone who can change bank details or approve an invoice can be more useful to an attacker than a senior executive.

Defender can also protect important external identities and domains. This is useful for suppliers, accountants, banks, legal advisers and other organizations your users communicate with regularly.

These settings are managed through anti-phishing policies.

Enable mailbox-intelligence impersonation protection

Mailbox intelligence uses communication history to understand who users normally exchange email with.

This helps Defender identify unusual sender relationships, display-name spoofing and impersonation attempts involving real contacts.

There are two related settings:

• Enable mailbox intelligence
• Enable intelligence for impersonation protection

The first allows Defender to build the communication model. The second allows the policy to take action when mailbox intelligence detects impersonation.

It is possible to have mailbox intelligence enabled without applying meaningful enforcement to its detections.

Microsoft's Standard and Strict policies enable stronger mailbox-intelligence-based protection than the default policy. I would verify both the detection setting and the action applied when impersonation is found.

I would also enable safety tips for similar users, similar domains and unusual characters. These warnings are useful when a message looks suspicious but does not meet the threshold for immediate blocking.

Tune bulk email carefully

Microsoft assigns bulk email a Bulk Complaint Level, or BCL, between 1 and 9.

The default threshold is relatively permissive. Microsoft's Standard and Strict configurations use lower thresholds:

• Default: 7
• Standard: 6
• Strict: 5

Lower values are more aggressive.

A threshold of 4 may be appropriate in some environments, but it is more aggressive than Microsoft's Strict baseline. I would not deploy it across an entire tenant without reviewing the effect first.

Microsoft provides more detail in its anti-spam policy documentation.

The objective is not to quarantine as much email as possible. An overly aggressive bulk threshold can create so much noise that administrators stop treating quarantine decisions seriously.

Review spoof intelligence and allow entries

Spoof intelligence and the Tenant Allow/Block List should be reviewed regularly.

I would look for:

• Spoofed senders currently allowed
• Old temporary exceptions
• Allow entries for former suppliers
• Broad domain allowances
• IP addresses bypassing filtering
• Mail-flow rules that set the spam-confidence level to -1

Microsoft warns against broad allowed-domain entries because they can allow messages that would otherwise be filtered.

Use the Tenant Allow/Block List and spoof intelligence rather than creating permanent blanket exceptions.

Every allow entry should have a technical reason, an owner and a review date.

Do not block all onmicrosoft.com domains without evidence

Malicious Microsoft 365 tenants frequently use onmicrosoft.com domains for spam and phishing.

That does not automatically mean the entire namespace should be blocked.

Legitimate Microsoft 365 tenants may still send from these domains during migrations, application deployments, testing or incomplete custom-domain configuration.

A safer approach is to review message-trace data, identify the abusive tenant domains and block confirmed malicious senders or domains individually.

A broader rule should only be considered after measuring how much legitimate traffic would be affected.

It is also important to use the correct control. Connection filtering is primarily IP-based, while sender-domain blocks generally belong in anti-spam policies, mail-flow rules or the Tenant Allow/Block List.

Verify Safe Links coverage

Safe Links should be checked for effective coverage, not merely for the existence of a policy.

Verify that:

• Email protection is enabled
• Time-of-click scanning is active
• The intended users are included
• Office application protection is enabled where required
• Exclusions are narrow and documented
• The expected policy is actually applied

A user can be protected when clicking a link in Outlook but not receive the same protection when opening a link from Word or another supported Microsoft 365 application.

Microsoft explains the available controls in its Safe Links documentation.

Verify Safe Attachments coverage

Safe Attachments has similar deployment risks.

I have seen environments where the policy was still scoped to a pilot group or left in Monitor mode long after deployment.

Check that:

• All intended users are included
• The production action is not Monitor
• Dynamic Delivery is configured where appropriate
• Scanning failures are handled safely
• Important recipients are not excluded
• SharePoint, OneDrive and Teams protection is enabled where required

The available actions and workloads are described in Microsoft's Safe Attachments documentation.

Fix SPF, DKIM and DMARC

Defender configuration cannot compensate for weak email authentication.

SPF should include every legitimate sending platform and exclude services that are no longer used. Common senders include Microsoft 365, marketing systems, ticketing platforms, HR tools, invoicing applications and website services.

Microsoft provides detailed guidance for configuring SPF.

DKIM should be enabled for every custom domain and every legitimate sending platform that supports it. Do not assume that enabling DKIM in Exchange Online also covers third-party marketing or transactional systems.

Microsoft documents the required DNS and selector configuration in its DKIM guide.

DMARC then ties SPF and DKIM to the visible From domain.

A normal DMARC rollout starts with reporting, identifies legitimate senders, fixes alignment problems and gradually moves toward quarantine or reject.

A permanent p=none policy provides monitoring, but it does not request enforcement.

Microsoft's DMARC configuration guidance explains how to introduce enforcement gradually.

DMARC will not stop every phishing attack. It does not prevent lookalike domains, compromised supplier accounts or attacker-controlled domains with valid authentication. It does, however, significantly reduce direct spoofing of your own domains when properly enforced.

Configure transport security separately

MTA-STS and TLS-RPT protect SMTP transport rather than message content.

MTA-STS allows your domain to require encrypted delivery and validate the expected receiving infrastructure. TLS-RPT provides reporting about delivery and encryption failures.

Microsoft explains inbound and outbound behavior in its MTA-STS guidance and SMTP DANE and TLS reporting documentation.

These controls do not detect phishing, but they help protect email transport from downgrade and interception risks.

Use post-delivery protection

Initial delivery is only one stage of email security.

Microsoft's Zero-hour Auto Purge can take action after a message has already reached a mailbox.

This matters when:

• A URL becomes malicious later
• A file receives an updated verdict
• Microsoft identifies a wider campaign
• New threat intelligence changes the message classification

Defender for Office 365 Plan 2 also provides investigation, hunting and automated remediation capabilities.

Organizations paying for Plan 2 should use these capabilities rather than treating the product only as a mail gateway. Microsoft's Defender for Office 365 overview explains the main differences between Plan 1 and Plan 2.

Final recommendation

Before replacing Microsoft Defender for Office 365, confirm that you are testing a properly configured environment.

Enable Standard and Strict preset policies. Check policy precedence. Strengthen impersonation protection. Review mailbox intelligence, bulk thresholds, spoof decisions and allow entries. Confirm Safe Links and Safe Attachments coverage. Fix SPF, DKIM and DMARC, and make sure post-delivery protection is being used.

Then measure what still gets through.

You may find that Defender is sufficient. You may find that it is capable but requires more administration than expected. You may also find that it still leaves important technical gaps in your environment.

The important part is to make that decision using a properly configured tenant and measurable results rather than judging the product by its default settings.