Apply the Strict preset security policy (or its custom equivalent), enable Zero-hour Auto Purge, and set outbound sending limits before you do anything else. These three moves close the gaps that the default configuration deliberately leaves open. Everything else in this guide, from PowerShell scripting to quarantine tuning, builds on that baseline through the Microsoft Defender portal or Exchange Online PowerShell.

TL;DR:

• Applying the Strict preset to high-risk users is essential, and a phased rollout helps balance increased spam filtering with false positive risks.
• Microsoft advises enforcing SPF, DKIM, and DMARC for all domains and enabling impersonation protection to improve overall email security.
• Outbound spam detection relies on alert thresholds and limits, with ZAP and quarantine working together to catch threats after initial delivery.
• Troubleshooting false positives requires examining message headers and detection tech, then submitting false positives to Microsoft or adding scoped allowlist entries.
• Maintaining in-house controls depends on resource availability for ongoing monitoring, with managed support suitable for organizations lacking dedicated security personnel.

Table of Contents

• What is exchange online spam filtering and how does the pipeline work?
• Which preset security policy should you apply first?
• How do you configure anti-spam policies in the Defender portal?
• What PowerShell commands manage anti-spam policies?
• When should you use mail flow rules instead of anti-spam policy changes?
• How do quarantine and Zero-hour Auto Purge protect mailboxes after delivery?
• What should you monitor to catch spam problems early?
• What is the priority order for hardening Exchange Online spam protection?
• How do you troubleshoot false positives without weakening security?
• When does in-house configuration reach its limit?
• Get help configuring Exchange Online spam protection properly
• Sources
• FAQ

What is exchange online spam filtering and how does the pipeline work?

Exchange Online spam filtering is the layered checking process every inbound and outbound message passes through before it reaches, or leaves, a mailbox. It isn’t a single filter but a pipeline, and understanding the order of operations matters because each stage can override or defer to the next.

Mail arrives at connection filtering first. This checks the sending IP against Microsoft’s reputation lists and any custom IP allow or block entries you’ve configured. A message that fails here gets rejected outright, before Exchange Online spends any compute cycles on content analysis.

Messages that pass connection filtering move into anti-spam processing, where the Advanced Spam Filter (ASF) settings and the wider content filtering engine assign a Spam Confidence Level (SCL) and a Bulk Complaint Level (BCL). Anti-phishing and anti-spoofing checks run in parallel, evaluating DMARC, DKIM, and SPF alignment along with impersonation signals for protected senders and domains.

The system then assigns one of several verdicts: Bulk, Spam, High confidence spam, Phishing, or High confidence phishing. Each verdict maps to a default action. Bulk mail typically lands in the Junk Email folder; Spam and High confidence spam are usually quarantined; Phishing and High confidence phishing are quarantined by default and, critically, cannot be redirected to the inbox no matter how the SCL is manipulated downstream. Malware scanning sits outside this negotiation entirely: a message confirmed as carrying malware is blocked regardless of any allow rule an admin has written.

This is the detail administrators most often miss when troubleshooting: a transport rule that sets a lower SCL can influence borderline Spam or Bulk classifications, but it has no effect on a High confidence phishing verdict. Exchange Online mailboxes ship with anti-spam, anti-malware, and anti-phishing built in, and those core protections are not something a custom rule can quietly switch off.

Feedback loops keep the models current. When users click “Report Phishing” or an admin submits a false positive through the portal, that signal feeds back into Microsoft’s global threat intelligence, which is the same intelligence that drives Zero-hour Auto Purge re-evaluations later in the message lifecycle.

Which preset security policy should you apply first?

Start with Strict for any mailbox handling finance, HR, or executive communication, and use Standard as the tenant-wide floor for everyone else. Default is not a policy you should be actively choosing in 2026. It exists mainly as a legacy baseline for tenants that haven’t yet reviewed their configuration.

The three presets differ in one number that matters more than any other setting: the Bulk Complaint Level threshold used to mark a message as spam.

Strict uses a lower BCL threshold compared to Standard and Default presets, and it defaults to quarantining spam outright rather than routing it to the Junk Email folder. A lower BCL threshold means the filter treats a wider range of bulk-mail complaint signals as spam, which catches more marketing-adjacent junk but also raises the odds of catching a legitimate newsletter your finance team actually reads.

That trade-off is exactly why a phased rollout beats a tenant-wide flip. Apply Strict to a pilot group first, ideally the users most targeted by phishing (finance, payroll, anyone with wire-transfer authority), and monitor quarantine volume for two to three weeks before expanding it further.

A few settings are worth checking individually rather than trusting the preset label alone:

• MarkAsSpamBulkMail: confirm this is enabled so bulk-mail scoring actually feeds the BCL calculation.
• High confidence spam and phishing actions: verify these are set to quarantine, not “add X-header” or “no action”, which some legacy custom policies still carry over.
• Quarantine policy assignment: Strict’s default quarantine policies restrict end-user release permissions more tightly than Standard’s, which matters for how much autonomy you want to hand ordinary users.
• Notification settings: decide whether quarantined-message digests go out daily or on a different cadence, since Strict will generate more of them.

One interaction catches administrators out regularly: preset policies and custom anti-phishing policies aren’t mutually exclusive, but they are prioritised. If you’ve built a custom anti-phishing policy for a VIP group, check its priority number against the preset’s priority. Presets typically sit at a low priority number by design so custom policies can override them for specific users, but a misordered priority means your custom protections silently never fire, and the preset’s more permissive defaults apply instead.

Microsoft’s own recommendation treats presets as a maintained baseline that updates automatically as threat patterns shift, which is genuinely useful for tenants without a dedicated email security function. You get Microsoft’s tuning without having to track every ASF setting change yourself. The trade-off is control: if your organisation has specific exceptions to make, layer custom policies on top rather than editing the preset directly, since presets can’t be modified in place.

How do you configure anti-spam policies in the Defender portal?

Navigate to Microsoft 365 Defender portal > Email & collaboration > Policies & rules > Threat policies > Anti-spam to see both inbound and outbound policy lists side by side. This is where most day-to-day tuning happens, and it’s worth knowing the exact click path because Microsoft has moved these settings between menus more than once over the past few years.

1. Review existing policies first. Before creating anything new, check whether a preset (Standard or Strict) is already assigned to the users you care about. Duplicating coverage creates priority conflicts that are painful to untangle later.
2. Create a custom anti-spam inbound policy if you need settings a preset doesn’t offer, such as a specific ASF setting tuned for your mail patterns. Give it a clear, dated name; six months from now you want to know why it exists without opening it.
3. Set the policy priority. Lower numbers process first. A custom policy meant to override a preset for a specific group needs a lower priority number than that preset, or it will never take effect.
4. Choose actions per verdict. For each of Bulk, Spam, High confidence spam, and Phishing, decide between moving to Junk, quarantining, or (rarely appropriate) taking no action. Match these to how much unsupervised email flow your organisation can tolerate.
5. Assign a quarantine policy. This governs what end users can see and do with their own quarantined mail: whether they can release messages themselves, request release from an admin, or only view and delete.
6. Configure the outbound anti-spam policy separately. This is where recipient rate limits live, and it’s the policy most often left on default settings because admins focus entirely on inbound protection.
7. Test before wide deployment. Apply new or modified policies to a small pilot group first and watch the quarantine list for a week. A policy that’s too aggressive shows up quickly as user complaints about missing newsletters or vendor invoices.

A recurring portal pitfall: administrators create a new custom policy, assign it, and then wonder why nothing changed. Nine times out of ten, an existing preset still holds a lower priority number and continues to win. The portal shows policy priority in a simple ordered list on the Anti-spam overview page, and it’s the first thing to check whenever a change doesn’t seem to apply.

What PowerShell commands manage anti-spam policies?

PowerShell becomes essential once you’re managing anti-spam settings across dozens of policies or want to script consistent configuration across tenants. You’ll need the Exchange Online PowerShell module connected with an account holding Security Administrator or Exchange Administrator role permissions; lower-privilege accounts can view most settings but can’t modify them.

To see what’s currently configured, start with:

Get-HostedContentFilterPolicy | Format-Table Name, SpamAction, HighConfidenceSpamAction, BulkThreshold

This lists every content filter policy on the tenant along with the action taken for each verdict and the current bulk complaint threshold. Pair it with:

Get-HostedContentFilterRule | Format-Table Name, HostedContentFilterPolicy, Priority, State

to see which rule applies which policy, in what priority order, and whether the rule is enabled. This second command is where you catch the priority conflicts described above.

Creating or modifying a policy follows a predictable pattern. A new custom policy might look like this:

New-HostedContentFilterPolicy -Name "Finance-Strict-Spam" `
  -BulkSpamAction Quarantine `
  -HighConfidenceSpamAction Quarantine `
  -PhishSpamAction Quarantine `
  -BulkThreshold 5 `
  -MarkAsSpamBulkMail On

Then bind it to a rule targeting the right recipients:

New-HostedContentFilterRule -Name "Finance-Strict-Rule" `
  -HostedContentFilterPolicy "Finance-Strict-Spam" `
  -SentTo "finance@yourdomain.com" `
  -Priority 0

To adjust an existing policy rather than create a new one, Set-HostedContentFilterPolicy takes the same parameters:

Set-HostedContentFilterPolicy -Identity "Finance-Strict-Spam" -BulkThreshold 5 -MarkAsSpamBulkMail On

A few points worth keeping in mind:

• Cmdlet names have shifted slightly across Exchange Online PowerShell module versions; if a command isn’t recognised, confirm you’re on the current module version before assuming a typo.
• Changes made through PowerShell and changes made through the Defender portal write to the same underlying policy objects, so you can mix both interfaces without conflict.
• Always verify a change took effect with a Get- command immediately after running a Set- or New- command. Policy changes can take a short time to propagate across the service.
• Some newer features, particularly around impersonation protection and preset policy details, are tenant-feature-gated and may not appear identically across every Microsoft 365 licence tier.

Pro Tip: Export your current policy configuration with Get-HostedContentFilterPolicy | Export-Csv before making bulk changes. It takes thirty seconds and gives you an exact rollback reference if a scripted change behaves unexpectedly.

When should you use mail flow rules instead of anti-spam policy changes?

Reach for a mail flow rule (transport rule) when you need a narrow, well-documented exception, not when you want to broadly weaken spam filtering. The two mechanisms solve different problems, and conflating them is where most tenant misconfigurations start.

Anti-spam policies determine how a message is scored and classified in the first place. Mail flow rules act afterwards, on messages that match specific conditions, and can adjust the Spam Confidence Level a message carries, add headers, or reroute delivery. The critical limit here, and it surprises a lot of administrators, is that SCL adjustments made through transport rules cannot override a High confidence phishing verdict or bypass malware scanning. You genuinely cannot switch off Exchange Online’s spam filtering by writing a permissive enough rule. That’s a deliberate design decision, not a gap.

Where mail flow rules earn their keep:

• Setting a specific SCL for mail from a known, trusted third-party system (a scanning appliance, a legacy CRM) that consistently trips borderline spam scoring.
• Adding a warning header or banner to mail from external domains, independent of spam scoring.
• Routing mail matching specific header patterns to a dedicated mailbox for review, useful for security teams triaging suspicious patterns at scale.

Where a mail flow rule is the wrong tool:

• “Always allow this sender” rules written to fix a one-off false positive. This is exactly what the Tenant Allow/Block List (TABL) is for, and it’s the mechanism Microsoft recommends for persistent false positives, because entries there are visible, auditable, and time-bound rather than buried in a transport rule nobody remembers writing.
• Domain-wide bypass rules created under time pressure during an incident and never revisited. These accumulate into the single biggest hidden risk in most tenants that have run Exchange Online for several years.

The recommended workflow for a genuine persistent false positive is straightforward: add the specific sender or domain to the Tenant Allow/Block List as an allow entry, set an expiration date rather than leaving it permanent, and document why the entry exists. Review TABL entries quarterly. An allow entry from three years ago for a vendor you no longer use is a standing hole in your filtering that nobody is actively watching. If you’re troubleshooting deliverability issues from the sending side rather than the receiving side, this analysis of deliverability signals and spam-folder placement is a useful companion read on what actually trips filters upstream.

How do quarantine and Zero-hour Auto Purge protect mailboxes after delivery?

Quarantine and ZAP together cover the gap between “the filter made a decision” and “that decision turns out to be wrong hours later.” They’re two different mechanisms solving related problems, and mixing them up leads to confused incident response.

Quarantine holds messages that triggered a Spam, High confidence spam, or Phishing verdict before they reach the inbox at all. Admin quarantine gives full visibility and control: release, delete, or block sender, applied to any message regardless of verdict. End-user quarantine access is deliberately more restricted, and this is by design rather than an oversight. A message flagged as High confidence phishing typically cannot be self-released by the end user under any standard quarantine policy; it requires an admin review, because the cost of a user accidentally releasing a credential-harvesting email into their own inbox is high enough that Microsoft doesn’t leave that door open by default.

Zero-hour Auto Purge works on a different timeline entirely. ZAP doesn’t evaluate a message before delivery; it re-evaluates messages that have already been delivered, as Microsoft’s threat intelligence updates in near real time, and retroactively removes anything later confirmed as malicious. This matters because a genuinely new phishing campaign can slip past initial scanning in its first few minutes of circulation, before enough recipient and reporting signal exists to flag it. ZAP is the mechanism that reaches back into inboxes and pulls that message out once the classification catches up. Leaving ZAP enabled is one of the clearer “just do this” recommendations in the entire Exchange Online security stack; there’s no credible operational reason to disable it.

Choosing a quarantine policy comes down to how much autonomy you’re comfortable handing users. A tighter policy (closer to Strict’s defaults) limits self-release to low-confidence spam only and routes everything else to admin review. A looser policy lets users manage more of their own quarantine, which reduces admin overhead but raises the risk of a user releasing something they shouldn’t.

The practical workflow for admins reviewing quarantine: check the quarantine dashboard in the Defender portal on a set schedule, review anything flagged as Phishing or High confidence phishing first, and use the “submit to Microsoft for review” option on anything you’re not confident about rather than guessing. That submission feeds directly back into the same threat intelligence that powers ZAP for every other tenant.

What should you monitor to catch spam problems early?

Three reports do most of the work: the anti-spam and mail flow dashboard, Threat Explorer, and message trace. Each answers a different question, and knowing which one to open first saves real time during an incident.

• Anti-spam reports (in Defender > Reports > Email & collaboration) give you the aggregate trend view: volume of spam, bulk, and phishing detections over time, broken down by policy. This is where you spot a sudden spike before individual users start complaining.
• Threat Explorer lets you search and pivot across delivered, quarantined, and blocked mail by sender, recipient, subject, or detection technology. It’s the tool for investigating a specific incident: “who else received this exact message” is a Threat Explorer question, not a message trace question.
• Message trace answers the narrower “what happened to this one message” question. Pull up the trace, check the detail view, and look specifically at the SCL, BCL, and the detection technology that fired. That detail view tells you whether a message was blocked at connection filtering, scored as spam, or flagged for phishing, which is exactly the information you need before deciding whether a false positive is a policy problem or a sender authentication problem.

Set alert policies on outbound spam thresholds specifically. A sudden jump in outbound mail volume from one account, or a spike in external recipient counts, is one of the most reliable early signals of a compromised account sending spam through your own tenant. Configure the alert to notify your security team immediately, not on a digest.

A weekly review of the anti-spam dashboard is a reasonable baseline cadence for most SMEs; move to daily during any active threat campaign or after onboarding a Strict policy rollout, when you want to catch tuning problems fast.

What is the priority order for hardening Exchange Online spam protection?

Work through these in order. Each step assumes the previous ones are already in place, and the sequence reflects impact, not alphabetical convenience.

1. Apply Strict preset (or an equivalent custom policy) to high-risk users, and Standard tenant-wide as the floor. This single change closes more gaps than anything else on this list.
2. Enforce SPF, DKIM, and DMARC for every domain you send from. Filtering can only trust authentication signals that exist; an unenforced DMARC record gives spoofers an open lane regardless of how strict your spam policy is.
3. Enable impersonation protection for your executive team and finance staff specifically. This is a manual configuration step even under Strict, and it’s the control most directly aimed at business email compromise rather than generic spam.
4. Confirm Zero-hour Auto Purge is enabled for spam, phishing, and malware. Check this explicitly rather than assuming it’s on; some legacy tenant configurations have it disabled for specific mailboxes.
5. Set outbound sending limits. A commonly recommended external-recipient threshold is set at a moderate level under Strict-aligned configurations, with the account automatically restricted once the threshold is crossed. Tune the exact number to your organisation’s legitimate mail patterns, but have a limit.
6. Turn on Safe Attachments and Safe Links where your licence includes Microsoft Defender for Office 365 Plan 1 or 2. These sit alongside spam filtering rather than replacing it, catching malicious payloads and links that a spam score alone wouldn’t flag.
7. Add an external sender warning banner. A simple visual cue on external mail meaningfully reduces successful impersonation attempts, and it costs nothing to configure.
8. Enable alerting on outbound spam thresholds and unusual sending patterns, tied to a team that actually monitors the alert queue.
9. Document every policy and TABL exception with a reason and, where possible, an expiry date. A security policy template gives you a starting structure for change records if you don’t already have one.
10. Audit configuration quarterly, specifically hunting for broad bypass rules or stale allow entries nobody remembers creating.

Pro Tip: Default EOP settings are tuned to minimise false positives for business continuity, not to stop targeted attacks. That’s a deliberate Microsoft trade-off, and it’s exactly why steps 2 and 3 above, authentication enforcement and impersonation protection, need manual admin attention rather than trusting the defaults to cover them.

How do you troubleshoot false positives without weakening security?

Start with the message header and message trace detail, not with a broad allow rule. Pull the specific message in Threat Explorer or message trace, check the SCL and BCL values it received, and identify which detection technology fired: authentication failure, bulk-mail scoring, or a specific ASF setting.

Common root causes worth checking first: SPF or DKIM misalignment on the sending domain (frequently the culprit when a legitimate vendor suddenly starts landing in quarantine), a sender that recently moved to a new bulk-mail platform and triggered bulk-complaint scoring, or a genuine change in sending pattern that looks like account compromise from the outside.

For a confirmed one-off false positive, submit it to Microsoft through admin submission so the classification improves for everyone. For a persistent, recurring false positive from a known sender, add a scoped Tenant Allow/Block List entry with an expiry date rather than a permanent transport rule bypass. Test any policy change on a pilot group first; a fix that clears one false positive can just as easily open a new gap if applied tenant-wide without verification.

When does in-house configuration reach its limit?

Everything covered here is achievable by a competent in-house administrator with time to dedicate to it. That’s the honest caveat: the constraint for most SMEs isn’t technical complexity, it’s whether anyone has the hours to monitor quarantine trends weekly, review TABL entries quarterly, and respond to an outbound-spam alert at 2am on a Sunday.

That’s the practical dividing line for deciding between in-house management and managed support: does your organisation have someone watching the alert queue outside business hours, and does anyone own the quarterly audit of stale bypass rules? If the answer is no on either count, that’s a resourcing gap, not a knowledge gap.

Some managed IT providers work with SMEs on ongoing Microsoft 365 configuration and monitoring, often using a similar checklist as a baseline to implement and keep current as threats and tenant features shift.

— Will

Get help configuring Exchange Online spam protection properly

Getting the Strict preset rolled out correctly, ZAP verified as active, outbound limits tuned to your actual mail patterns, and quarterly TABL audits actually happening takes ongoing attention, not a one-off setup session. CTA Systems provides Microsoft 365 configuration and management as part of its wider managed IT support, covering exactly this kind of email security hardening alongside broader cybersecurity monitoring for SMEs that would rather have a team watching the alert queue than checking it themselves once a month.

The value isn’t a one-off configuration change: it’s someone reviewing the quarantine dashboard, checking policy priority hasn’t drifted, and catching a compromised-account outbound spike before it becomes a blocklisted domain. That’s the gap between “we set this up once” and “someone is actually watching it,” and it’s a gap often addressed by managed IT security services for organisations that lack a dedicated security administrator. If that sounds like your situation, get in touch through Ctasystems to talk through your current setup and where the gaps are.

FAQ

Does Office 365 have spam filtering?

Yes. Every Exchange Online mailbox includes built-in anti-spam, anti-malware, and anti-phishing protection as a standard part of Exchange Online Protection, with no separate licence required for the baseline features. Preset policies (Default, Standard, Strict) let admins choose how aggressively that filtering behaves.

Why is Outlook’s spam filter so bad?

It usually isn’t the filter itself but the configuration: many tenants still run on the Default preset, which uses a higher BCL threshold (7, against Strict’s 5) and misses more borderline bulk mail and phishing. Enabling Strict or a tuned custom policy, plus enforcing DMARC and impersonation protection, closes most of the gap users complain about.

How can I bypass spam filtering in Office 365?

You can’t fully bypass it. High confidence phishing verdicts and malware scanning remain enforced regardless of any transport rule or SCL adjustment. For a legitimate persistent false positive, add a scoped entry to the Tenant Allow/Block List with an expiry date rather than writing a broad bypass rule.

Why is my email getting blocked by spam filters?

The most common causes are SPF or DKIM misalignment on your sending domain, a recent change in sending pattern that resembles compromised-account behaviour, or bulk-mail scoring triggered by a new mailing platform. Check the message trace detail for the SCL, BCL, and detection technology that fired to identify the exact cause.

What’s the difference between quarantine and Zero-hour Auto Purge?

Quarantine holds a message before delivery based on its initial verdict, while ZAP re-evaluates messages already delivered and retroactively removes anything later confirmed malicious as threat intelligence updates. Both should stay enabled; they cover different points in the message lifecycle.