Exchange Online anti-spam and anti-phishing

Exchange Online Protection (EOP) provides the baseline anti-spam, anti-malware, and anti-phishing defence for every Microsoft 365 mailbox. Defender for Office 365, on higher tiers, adds advanced detections. Together they're a layered filter that catches the vast majority of unwanted mail before users see it.

What EOP does (included with every tenant)

• Anti-spam policies — bulk and spam confidence scoring (SCL/BCL), with actions: quarantine, move to junk, redirect.
• Anti-malware policies — file-type blocking and signature scanning on attachments.
• Anti-phishing baseline — spoof intelligence, mailbox intelligence, and impersonation protection of internal senders.
• Connection filtering — IP allow/block lists.
• Outbound spam filtering — limits on outbound rate and content, so compromised users can't blast spam from your domain.

What Defender for Office 365 adds

• Safe Links — URLs in emails are rewritten and detonated at click time, so even links that go bad post-delivery are caught.
• Safe Attachments — unknown attachments are detonated in a sandbox before delivery (or Dynamic Delivery sends a preview while the scan completes).
• Advanced anti-phishing — impersonation protection of users and domains, mailbox-intelligence-based phish detection.
• Attack Simulation Training — controlled phishing simulations and embedded training.
• Automated Investigation and Response (AIR) — automated playbooks for confirmed phishing incidents.
• Threat Explorer — investigation surface for analysts.

Plan 1 covers protection; Plan 2 adds AIR, attack simulation, and Threat Explorer.

Quarantine

Both EOP and Defender route detections to quarantine. End users see a daily digest and can self-release low-risk messages; admins see the full quarantine in the Defender portal. Permissions for self-release vary by detection type — high-confidence phish stays admin-only.

Tuning

A few high-leverage tuning steps:

• Configure anti-phishing policies with the right list of protected users (executives, finance).
• Add trusted ARC senders for partners that legitimately re-route mail through gateways.
• Use Tenant Allow/Block Lists rather than transport rules for ad-hoc blocks — they're easier to audit.
• Turn on DKIM signing for every accepted domain.
• Publish a strict DMARC policy (p=reject or quarantine) once you've verified legitimate sources.

Resist the gateway temptation

A traditional pattern is to keep a third-party email security gateway in front of Microsoft 365. Many organisations have moved away from this — Defender for Office 365 catches as much or more, and integrates directly with Defender XDR. If you've got a third-party gateway, evaluate whether it's still earning its place.

The cost of running two filters at once

A tenant that keeps a legacy third-party gateway in addition to Defender for Office 365, rather than choosing one, doesn't get double protection for free — it gets a genuinely harder-to-diagnose mail flow, because a message that's blocked or modified upstream by the gateway never reaches EOP's own filters in a state those filters were designed to evaluate, and Safe Links/Safe Attachments rewriting can interact awkwardly with a gateway that also rewrites URLs or strips attachments. If a third-party gateway stays in place for a genuine reason (a compliance requirement tied specifically to that vendor, say), it's worth explicitly documenting which product is authoritative for which detection category, rather than assuming both are quietly reinforcing each other with no downside.

Frequently asked questions

Why did a message pass anti-phishing checks but still turn out to be a scam? Anti-phishing policies catch known patterns — spoofed domains, impersonated display names, malicious links and attachments detonated at click or delivery time — but a sufficiently well-crafted business email compromise message sent from a genuinely compromised but legitimate external mailbox, with no malicious link or attachment at all, can pass every automated check because there's no technical signal to catch; user training and out-of-band verification for payment or credential requests remain necessary alongside the technical stack, not instead of it.

Should every user be added to the "priority accounts" / protected users list in anti-phishing policies? No — that list is meant to concentrate extra scrutiny (mailbox intelligence, impersonation protection) on the specific individuals most valuable to impersonate, typically executives and finance approvers; adding the entire user base defeats the purpose of prioritisation and can dilute the signal the feature is built to sharpen.

Do the Standard and Strict preset security policies ever conflict with a custom policy? Preset policies take precedence over custom policies for any user or group assigned to both, by design — Microsoft's stated intent is that presets should represent an unambiguous best-practice floor, so a tenant that wants a specific exception for a specific mailbox needs to exclude that mailbox from the preset's scope rather than expecting a weaker custom policy to quietly override it.