Microsoft Filtering Internals (EOP / Defender for Office 365)

When your mail to a business that uses Microsoft 365 lands in Junk or quarantine, the message headers tell you why. Below is how Exchange Online Protection (EOP) filters inbound mail for business tenants, and how a sender or consultant reads its verdict.

This is a different system from the filtering of consumer Outlook.com mailboxes (descended from SmartScreen, and visible in SNDS), which Microsoft Sender Requirements covers. The two systems share reputation inputs, though, and B2B senders depend on EOP verdicts.

To diagnose a message, get a copy of it as delivered (or as junked or quarantined) from a Microsoft 365 recipient, and extract the full headers. Read three headers in order: Authentication-Results (did authentication pass?), X-Forefront-Antispam-Report (what was the verdict, and why?) and X-Microsoft-Antispam (BCL). Microsoft's own parser is the Message Header Analyzer at https://mha.azurewebsites.net/.

How the layers stack

1. Connection filtering at the edge of the service, based on IP address. Most spam is caught here. The inputs are Microsoft's blocked senders list (see Microsoft Escalation Channels), the tenant's IP Allow and Block lists, and IP reputation. Entries in a tenant's IP block list drop mail at the edge.
2. Anti-spam policies (content filtering) classify each message as bulk, spam, high confidence spam, phishing, or high confidence phishing, and stamp SCL and BCL values. There are three tiers of policy: the default policy, custom policies created by administrators, and the Standard and Strict preset security policies. The presets have progressively more aggressive defaults, and for the recipients they include, preset settings override custom policy settings.
3. Anti-phishing, spoof intelligence and composite authentication: Microsoft's implicit authentication layer (compauth), which judges the From domain even when no DMARC record exists.
4. Add-ons in Defender for Office 365 (MDO): impersonation protection (for users, for domains, and through mailbox intelligence), Safe Links and Safe Attachments. They exist only in tenants with MDO licenses, and they produce the CAT values marked as MDO only below.

Policy changes take up to 1 hour to apply. When several detections fire, the policies apply in order of precedence and the verdict with the highest priority wins.

X-Forefront-Antispam-Report header

The header is a list of field:value pairs separated by semicolons, for example ...CTRY:;LANG:hr;SCL:1;SRV:;IPV:NLI;SFV:NSPM;PTR:;SFTY:;.... Fields that Microsoft does not document are internal diagnostics. The documented fields are:

CAT (category) values

SFV (spam filtering verdict) values

How a consultant reads these: SKA, SFE and SKN mean the recipient side has allowlisted you. That is fragile, because placement depends on an override, not on reputation. SKB and BLK mean the recipient side has blocked you explicitly. No amount of reputation work on the sender side fixes that; the recipient organization must remove the entry.

SCL: Spam Confidence Level

The SCL is stamped as an X-header on every inbound message. Filtering never stamps the values 2, 3 or 4. SCL 7 is typically set not by spam filtering itself, but by analyst grading, DMARC failures or mail flow rules.

BCL: Bulk Complaint Level

The BCL is stamped in the X-Microsoft-Antispam header (for example, X-Microsoft-Antispam: BCL:5;). Microsoft assigns it, based on complaint behavior, to mail from recognized bulk senders ("gray mail"), whether the sources are internal to Microsoft or external. This is the header that matters most to ESPs, because it is in effect Microsoft's published complaint reputation score for each sender.

Thresholds and actions (a message is treated as Bulk when its BCL meets or exceeds the threshold):

What this means for a sender: mail at BCL ≤ 3 reaches the Inbox everywhere. BCL 4 is sent to Junk by tenants with the Strict preset (the recommended minimum for opting in to the Promotions folder feature is 5). BCL 5–6 is sent to Junk or quarantined by tenants using preset policies. BCL ≥ 7 is sent to Junk by default in every tenant. Recipient administrators can tune the threshold, and can see the bulk volume of each sender in the "bulk senders insight" in the Defender portal.

Promotions folder (preview, 2026): tenants can choose to deliver bulk mail that is below the BCL threshold (even bulk mail at BCL 0) to a Promotions folder instead of the Inbox. They do this with a mail flow rule that stamps X-MS-Exchange-Organization-BulkStamping: 1, plus the "Bulk moves enabled" setting in the anti-spam policy. Microsoft 365 learns from users moving messages into and out of the folder. Mail still reaches the Inbox if the sender is on the user's Safe Senders list. For senders, this means that even bulk mail with no complaints may stop landing in Microsoft 365 Inboxes because of how it is classified, much as Gmail's tabs work.

Authentication-Results and composite authentication

Microsoft stamps the standard spf=, dkim= and dmarc= results (see Authentication-Results Header), plus fields specific to Microsoft:

• The dmarc= values include the nonstandard bestguesspass: no DMARC record exists, but the message would have passed if one did.
• action= on DMARC: oreject (rejected under the policy); pct.quarantine or pct.reject (failed DMARC but was delivered, because pct < 100 randomly exempted it); permerror; temperror.
• compauth is composite authentication: Microsoft's combined verdict from SPF, DKIM, DMARC and signals in the message, evaluated against the From (5322.From) domain. A compauth=fail result does not guarantee the message goes to Junk if the other signals are clean.
• reason is a three-digit code that explains the compauth result:

Reason 001 is the code ESP consultants see most often. It means the sender had no authentication, or weak authentication, and Microsoft sent the message to Junk on suspicion from implicit authentication. The fix is aligned SPF and DKIM, plus a DMARC record. This is the same remediation as for the Outlook.com May 2025 mandate.

Tenant Allow/Block List (TABL): what recipient tenants control

The TABL is a list of overrides for each tenant, at https://security.microsoft.com/tenantAllowBlockList. It applies during mail flow and at the time of a click. The types of entry are: domains and email addresses (matched on the From (5322.From) address, not on MAIL FROM), spoofed senders, URLs, files, IP addresses and Teams domains. Block entries take precedence over allow entries. Entries take effect within ~5 minutes.

What a block does:

Expiry of block entries: for domains and addresses, files and URLs, entries expire after 30 days by default (this can be set to 90 days or to never). Entries for spoofed senders, IP addresses and Teams never expire.

How allow entries work, and why "just get them to allowlist us" has limits:

• Administrators cannot directly create allow entries for verdicts of malware or high confidence phishing. For those, the message, URL or file must be submitted to Microsoft through the Submissions page (https://security.microsoft.com/reportsubmission) and confirmed clean; only then can an allow entry be created. Messages identified as malware or high confidence phishing are always filtered, whatever the allow entries say.
• Direct allow entries for domains and addresses, and for URLs, can override only these verdicts: bulk, spam, high confidence spam, and phishing that is not high confidence.
• Allow entries for domains and addresses, files and URLs are kept for 45 days after the filtering system last judges the entity clean, and are then removed automatically (or an administrator sets them to expire ≤30 days after creation). Allow entries for spoofed senders never expire. Microsoft may automatically remove allow entries it considers unnecessary, and sends an alert when it does.
• An allowed sender still goes through the rest of the stack. The message must also pass authentication, URL and file checks, because an allow entry skips only the filters tied to the allowed entity.
• URL allows created through a submission automatically cover variations and sub-paths of the reported URL.

What this means for a sender: if your mail is judged high confidence phishing at a customer's tenant, the recipient's administrator cannot simply allowlist you. The usual causes are a URL or domain blocked in their TABL, or detection of spoofing or impersonation. The path goes through a submission to Microsoft by the administrator. Ask the recipient's administrator to submit the message as a false positive; Microsoft's review may create the allow entry.

FAQ material relevant to external senders

Microsoft's anti-spam FAQ documents these causes when legitimate mail is sent to Junk at Microsoft 365, and their fixes:

Microsoft's own list of outbound best practices for reaching Microsoft 365:

• The sending domain resolves in DNS. (With no A or MX record, mail is routed through Microsoft's high-risk pool, whatever its content.)
• The source IP address has a PTR record.
• HELO or EHLO and MAIL FROM are consistent and based on a domain, and HELO matches the PTR record.
• SPF is correct.
• Mail is DKIM-signed with relaxed canonicalization, because strict header canonicalization can break when mail passes through the service.
• WHOIS records are accurate.
• Bounces use the format of RFC 3464.
• Addresses that return an NDR as nonexistent are removed.
• SNDS is monitored.

Outbound throttling inside the service matters when a compromised customer sends through Microsoft. A user who sends >50% spam within a time window is blocked from sending, and outbound spam is routed through the high-risk delivery pool (separate IP addresses) to protect the normal pool.

Related articles

• Microsoft Sender Requirements, on consumer Outlook.com policies, error codes and the 2025 authentication mandate
• Microsoft Escalation Channels
• Microsoft SNDS & JMRP
• Authentication-Results Header, the RFC 8601 baseline that Microsoft extends