1. Strict preset
Highest anti-spam precedence for included recipients. Its protection settings are Microsoft-managed and cannot be edited. Use it for higher-risk cohorts when the stricter business impact is understood.
EOP policy precedence, verdicts, quarantine, exceptions, and outbound response
Exchange Online Anti-Spam Policy Tuning Guide
Reduce unwanted and malicious email without hiding legitimate business messages. Determine the policy that actually applies, map every verdict to an action and quarantine permission, tune bulk and advanced spam controls from evidence, replace broad bypasses with narrow expiring remediation, and treat outbound spam as a potential account or application compromise.
Strict, Standard, custom, and default policy precedenceSpam, bulk, ASF, spoof, allow/block, and quarantine decisionsSubmissions, message evidence, outbound alerts, change, and rollback
Operating objective
Tune the effective protection path—not the policy an administrator happens to open
Exchange Online Protection evaluates inbound anti-spam policies by precedence. For a recipient, Strict preset protection applies before Standard preset protection; matching custom anti-spam policies follow in priority order; the default policy covers everyone not matched earlier. Processing stops after the first applicable anti-spam policy. A custom change therefore has no effect when the recipient is already covered by Strict or Standard.
Policy tuning must start with recipient coverage and effective settings, then correlate verdict, action, quarantine policy, message headers, Explorer or reports where licensed, message trace, user/admin submission, release outcome, sender authentication, and business context. Complaint volume alone is not enough: the same symptom can be caused by BCL, ASF, spoof intelligence, a Tenant Allow/Block List entry, an Outlook safe list, a transport rule, connector filtering, or another protection layer.
Keep this guide distinct from daily quarantine processing and Microsoft submissions. Tuning owns policy design, controlled thresholds, scoped assignments, exceptions, outcome measurement, and rollback. Quarantine operations own review/release permissions and evidence; submissions own false-positive/false-negative feedback and Microsoft reclassification.
Control statement: Before changing an action, threshold, allow/block entry, ASF setting, quarantine policy, or outbound limit, record the effective recipient policy, triggering verdict, sample evidence, expected improvement, business-risk boundary, test cohort, rollback trigger, and expiration/review date.
Effective-policy precedence
Prove which layer protects each recipient cohort
2. Standard preset
Applies after Strict and before custom/default policy. If a recipient is covered, custom anti-spam settings are ignored for that recipient. Keep scope unambiguous.
3. Custom policies
Apply in priority order, where priority 0 is highest. Only the first matching custom policy wins. Use named cohorts, deliberate exclusions, small policy count, and an owner.
4. Default policy
Always present at lowest priority and applies to unmatched recipients. It cannot be deleted or renamed. Treat it as a governed baseline, not an invisible fallback.
Troubleshooting rule: When a setting “does not work,” first resolve recipient coverage and precedence. Then inspect SCL/BCL, protection headers, policy/rule hits, bypasses and quarantine policy before changing another control.
Verdict-to-action design
Map each detection to business impact, release authority, and evidence
| Verdict or condition | Tuning question | Preferred evidence | Controlled response | Validation |
|---|---|---|---|---|
| Spam | Is ordinary spam reaching Inbox or is legitimate low-risk mail going to Junk/quarantine? | SCL, headers, effective policy, message trace, samples, user reports, release/submission history. | Adjust action only for a measured cohort; avoid global exceptions for isolated sender hygiene problems. | Seeded tests, sample monitoring and false-positive trend after change. |
| High-confidence spam | Are clear spam patterns handled safely without user self-release risk? | SCL 9 context, quarantine reason, sender/authentication pattern, campaign samples and TABL state. | Use an appropriate quarantine policy and admin workflow; remediate legitimate senders through authentication and submissions. | Confirm containment, notifications/permissions, trace and release behavior. |
| Phishing / high-confidence phishing | Is the complaint actually anti-spam, anti-phishing, impersonation, Safe Links or Safe Attachments? | Threat classification, headers, URL/file verdicts, impersonation/spoof signals, policy lineage and investigation. | Do not weaken high-confidence phishing protection to fix a sender problem. Submit, authenticate, and use the correct policy family. | Re-test with safe samples and confirm no bypass of malware or high-confidence phishing. |
| Bulk mail (BCL) | Which newsletters, vendors and graymail are wanted, and by which users? | BCL, sender/domain, unsubscribe quality, complaint history, cohort preference and business owner. | Tune threshold or action by cohort; separate sanctioned marketing platforms from person-to-person mail. | Track wanted bulk delivery, user complaints, Junk/quarantine volume and unsubscribe outcomes. |
| ASF detection | Which specific Advanced Spam Filter condition fired and is the aggressive behavior acceptable? | X-CustomSpam header, quarantine reason, message structure, effective policy and repeat samples. | Test a single ASF change in a pilot. Microsoft notes ASF-filtered messages cannot be reported as false positives to Microsoft. | Verify the targeted X-header/detection and business impact; roll back if collateral rises. |
| Spoof / authentication failure | Is the sender legitimate, misconfigured, forwarded, or malicious? | SPF, DKIM, DMARC, composite authentication, ARC/forwarding path, spoof intelligence and headers. | Fix sender alignment or connector filtering; use narrowly governed spoof/TABL decisions rather than domain-wide bypasses. | Confirm authenticated production samples and removal/expiration of the temporary exception. |
| Outbound suspicious sending | Is the user/app compromised, misconfigured or performing an unsupported bulk-mail function? | Alerts, message trace, sign-ins, mailbox rules, app/OAuth activity, recipient counts, complaints and endpoint evidence. | Contain account/app, investigate, remediate and unblock only after evidence. Route legitimate bulk mail through an appropriate service. | Confirm sending pattern normalizes, forwarding state is correct and alerts/restrictions work. |
Twelve-step tuning runbook
Baseline, pilot, measure, and preserve a reversible decision
Define the symptom and outcome
Separate missed spam, unwanted bulk, false positive, unsafe release, spoofing, bypass, outbound compromise, or forwarding request. Name the business owner, affected cohort, urgency and acceptable tradeoff.
Export every policy layer
Capture Strict/Standard scopes, custom policy/rule priority and assignments, default inbound/outbound policies, quarantine policies, TABL, connection filtering, transport rules and relevant connector settings.
Calculate effective coverage
Test representative users from executives, finance, frontline, shared mailboxes, service accounts and general population. Resolve overlapping groups, exclusions and first-match precedence.
Collect representative evidence
Use multiple message IDs and headers, traces, SCL/BCL, quarantine reasons, user/admin submissions, reports, sender authentication and release history. Remove message-body PII from working evidence where possible.
Find the actual control
Determine whether the result came from inbound anti-spam, preset protection, ASF, TABL, Outlook safe/block lists, spoof intelligence, anti-phishing, transport, connector, malware, Safe Links or Safe Attachments.
Remove unsafe bypasses first
Inventory allow senders/domains, SCL -1 rules, safe lists, IP allows and advanced-delivery entries. Replace broad/permanent bypass with sender remediation or a narrow, owned, expiring exception.
Design the smallest change
Choose one policy, cohort and control: BCL threshold, verdict action, quarantine policy, international/ASF option, assignment or targeted block. Define expected metrics and prohibited side effects.
Prepare quarantine and support
Verify notification cadence, release/request-release permissions, high-risk verdict restrictions, reviewer role, escalation and help-desk message. A tuning change is incomplete if users cannot safely recover legitimate mail.
Pilot with real cohorts
Use a bounded group that represents actual senders and user behavior. Preserve a control cohort when practical. Do not use production phishing, broad bypasses or simultaneous unrelated policy changes.
Validate inbound and outbound
Test legitimate external mail, bulk, known spam test patterns, spoof/authentication cases, quarantine permissions, submissions, alerts, restricted-user operations and automatic-forwarding behavior.
Measure and decide
Compare detection, quarantine, release, false-positive, complaint, submission and support-ticket rates with the baseline. Expand, revise or roll back based on the declared acceptance criteria.
Close with evidence and review
Attach before/after exports, tests, metrics, exceptions and screenshots; record final scope and owner; set exception expiration and policy review; update quarantine/submission/outbound incident runbooks.
Safe exception hierarchy
Fix the sender or classification before weakening a tenant
| Option | Use when | Risk boundary | Required controls | Exit evidence |
|---|---|---|---|---|
| Sender authentication/remediation | A legitimate sender fails SPF, DKIM, DMARC, reputation or message-quality expectations. | Best long-term option; may require vendor or DNS coordination. | Owner, headers, alignment tests, production sample and target date. | Passing authenticated samples and stable classification. |
| Microsoft admin submission | A false positive or false negative needs Microsoft analysis and temporary allow handling. | Submission is evidence, not permanent trust. | Correct category, original message, business impact, tracking and follow-up. | Classification result and removal/expiry of temporary entry. |
| Tenant Allow/Block List | A specific sender/domain/spoof, URL or file needs controlled allow or block treatment. | Block entries override allow entries; allows should be narrow and temporary. | Scope, reason, owner, expiration, sample and monitoring. | Entry removed/expired after root cause closes. |
| Anti-spam allowed/blocked sender or domain | Multiple users need a targeted sender/domain decision and better options do not fit. | Allowed domains can be spoofed and bypass spam filtering; they do not bypass malware/high-confidence phishing. | Documented exception, narrow scope, periodic export and expiry process. | Replacement by authentication or TABL workflow where appropriate. |
| Outlook safe/block list | An individual user preference is appropriate. | User safe senders can set SCL -1 and create targeted spoofing risk. | User education, audit visibility, no security-critical domain-wide dependence. | Safe-list cleanup and verified sender behavior. |
| Transport rule or IP allow | A precisely defined mail-flow architecture requires it and no safer native control applies. | Highest bypass and blast-radius risk; broad IP/domain patterns age badly. | Security review, exact conditions, owner, expiry, logging, negative tests and emergency rollback. | Removal after connector/authentication or application design is corrected. |
Top anti-spam tuning risks and misconfigurations
Changes that hide threats, quarantine business mail, or create unpredictable outcomes
Custom policy never applies
Strict or Standard preset protection already covers the recipient, or a higher-priority custom policy wins first.
Domain-wide allow
A spoofable sender domain bypasses spam filtering for a broad population with no expiration or root-cause correction.
ASF enabled without pilot
Aggressive structural detections generate high-confidence spam and cannot be submitted to Microsoft as false positives.
BCL tuned from one complaint
A tenant-wide threshold change solves a local newsletter preference while harming wanted bulk mail elsewhere.
Quarantine permission mismatch
The action changes, but the mapped quarantine policy allows unsafe self-release or blocks necessary recovery.
Transport bypass masks classification
SCL -1 or broad connector/IP rules prevent useful filtering and make headers/reports misleading.
False positive is not submitted
Teams permanently allow a sender instead of correcting authentication and feeding evidence back to Microsoft.
Outbound alert is treated as nuisance
A restricted user or unusual sending pattern is unblocked without investigating identity, rules, apps and endpoints.
Automatic forwarding left ambiguous
System-controlled is assumed to allow forwarding even though Microsoft documents that it now behaves as Off.
No before/after measurement
The organization cannot prove whether spam fell, false positives rose, or the expected policy actually applied.
Evidence and cadence
Operate email filtering as a measurable security service
Configuration evidence
- Preset, custom and default scopes/priority
- Inbound/outbound settings and rules
- Verdict actions and quarantine mappings
- BCL, ASF, TABL, safe-list and bypass inventory
- Authentication, connector and forwarding context
Outcome evidence
- Messages by verdict, SCL/BCL and action
- Quarantine/release/request-release trends
- User/admin submissions and Microsoft results
- False-positive, missed-spam and support cases
- Outbound alerts, restricted users and incident closure
Useful metrics
- Effective-policy coverage by cohort
- Broad/permanent allows and overdue exceptions
- False-positive and release-confirmation rates
- Wanted-bulk complaints by cohort
- Time to contain and remediate outbound events
Daily
Review high-impact detections, restricted senders, release escalations, false positives and active campaigns.
Weekly
Analyze submissions, repeated senders, bulk patterns, bypass requests, support cases and exception expiry.
Monthly
Reconcile effective coverage, policy priority, actions, quarantine mappings, TABL, safe lists and outbound alerts.
Quarterly/event-driven
Review policy architecture, preset adoption, ASF/BCL strategy, senders, forwarding and incident lessons.
Authoritative resources and related guidance
Connect tuning to quarantine, submissions, authentication, and incident response
Microsoft implementation sources
Frequently asked questions
Exchange Online anti-spam policy tuning FAQ
Why is a custom anti-spam policy not applying?
Check precedence and recipient scope first. Strict preset protection applies before Standard, then custom policies in priority order, then default. Only the first matching anti-spam policy applies to the recipient.
Should a legitimate sender be added to an allowed domain list?
Usually not as the first response. Validate classification and SPF/DKIM/DMARC, submit the message, correct the sender, and prefer a narrow expiring control. Allowed domains can be spoofed and bypass spam filtering for the covered population.
How should BCL be tuned?
Use message BCL values, wanted/unwanted bulk patterns, complaints, cohort preferences, unsubscribe quality and business ownership. Pilot a cohort-specific threshold/action before any broad change.
What is the risk of Advanced Spam Filter settings?
ASF is aggressive; some detections increase spam score and others mark messages high-confidence spam. Microsoft states messages filtered by ASF cannot be reported as false positives, so pilot individual settings and retain X-CustomSpam evidence.
Does changing the spam action also change who can release a message?
No. Quarantine permissions and notifications come from the mapped quarantine policy. Validate the verdict action and quarantine policy together, especially for high-risk detections.
What should happen when a user is restricted for outbound spam?
Treat it as a possible identity, mailbox-rule, OAuth application, endpoint or bulk-sending incident. Contain and investigate, remediate the cause, validate alerts/forwarding, and unblock only with evidence.
Tune from evidence, not guesswork
Reduce unwanted mail while preserving legitimate business communication
IT Perfection helps Orange County and Southern California organizations map effective Exchange Online policy coverage, tune EOP and Defender anti-spam outcomes, clean risky bypasses, align quarantine and submissions, strengthen sender authentication, improve outbound-spam response, and preserve repeatable evidence for Microsoft 365 operations and security.
Created by Ali Hassani, CISO — 25+ years of IT, cybersecurity, compliance, and infrastructure experience. This guide is for initial guidance only and does not replace a professional cybersecurity audit, compliance assessment, penetration test, legal/compliance review, incident investigation, licensing review, or tested mail-flow recovery plan.
