How do I interpret SCL scores in Microsoft headers?
Published 22 May 2025
Updated 24 Oct 2026
14 min read
Summarize with
Updated on 24 Oct 2026: We clarified SCL rule values, Outlook header steps, and the limits of bypass and delivery stamps.
SCL stands for spam confidence level. Microsoft stamps an SCL value of -1 or 0 to 9 in email headers, but its meaning depends on the receiving environment. In Microsoft 365 cloud organizations, SCL no longer determines whether a message receives a Spam or High confidence spam verdict, and it does not determine the action. Microsoft's current Microsoft SCL guidance says categorization and other signals make those decisions. An SCL of 5 or higher generally indicates a negative assessment, 0 or 1 usually appears on mail evaluated as not spam, and -1 is used to request a bypass. Even a successful bypass request can leave a final stamp of 0 or 1.
Treat SCL as context, then read CAT for the category that filtered the message, DIR for directionality, SFV for filter or override clues, and mailbox-delivery headers for destination clues. Also check BCL, X-CustomSpam, authentication results, and policy context. Microsoft's Microsoft header guide is the reference for current cloud header names.
What SCL scores mean in Microsoft 365
Start by recording the SCL, but do not map the number directly to a cloud delivery action. Higher values still provide useful context and an SCL of 5 or higher generally indicates a message Microsoft considered bad. The same value can now appear with different cloud verdicts, so CAT and the applied policy must confirm what happened.
SCL score context
How to use Microsoft SCL values without treating them as cloud verdicts.
Bypass request
-1
A rule or allow path requested a spam-filtering bypass, although the final stamp can still be 0 or 1.
Usually not spam
0-1
The message was commonly evaluated as not spam, but CAT, policy, and delivery evidence still need checking.
Check the source
2-4
Valid rule values that have no fixed cloud verdict. Check mail flow rules and any on-premises or hybrid path.
Spam treatment request
5-6
Mail flow rules use 5 or 6 to request spam treatment. CAT and policy establish the actual cloud result.
Check the source
7-8
Valid rule values that do not establish a cloud verdict or guarantee rejection. Inspect the receiving environment.
High confidence spam request
9
Mail flow rules use 9 to request high confidence spam treatment. It does not automatically mean rejection.
- In cloud mailboxes, CAT identifies the filtering category and carries more diagnostic weight than the SCL number.
- Policy precedence matters because the first matching anti-spam policy applies to the recipient.
- A transport rule that sets SCL makes the number an input or override request, not a pure filter verdict.
- An SCL bypass request does not bypass malware scanning. High confidence phishing protection normally remains active, with a routing exception described below.
- Values 2-4 and 7-8 are valid mail flow rule choices, but they do not define standalone cloud verdicts.
Microsoft's SCL rule guidance documents an exception: if the recipient domain's MX record points to an upstream service or device instead of Microsoft 365, an SCL -1 bypass rule can allow high confidence phishing into the Inbox. Review the routing and rule scope before assuming the bypass preserves that protection.
Separate cloud and on-premises meaning
The largest interpretation mistake is applying on-premises Exchange thresholds to Microsoft 365 cloud filtering. SCL still has direct operational meaning for the Content Filter agent, organization Junk Email thresholds, and mailbox thresholds in on-premises Exchange. It also supports hybrid delivery when cloud-filtered mail reaches on-premises mailboxes. In Microsoft 365 cloud organizations, categorization and policy action have replaced SCL as the primary explanation of handling.
|
|
|
|---|---|---|
Microsoft 365 cloud | Supporting stamp and rule input | CAT, DIR, SFV, policy, and delivery evidence |
On-premises Exchange | Threshold input for Junk, reject, quarantine, or delete handling | Content Filter and organization or mailbox thresholds |
Hybrid delivery | Cloud stamp can affect the on-premises mailbox path | Both cloud categories and on-premises thresholds |
SCL meaning by Microsoft environment
Thresholds still matter on-premises
On-premises Exchange uses configurable SCL thresholds. For example, the default organization Junk Email threshold is 4, so a message above that threshold moves to Junk when the mailbox junk rule is enabled. Do not use that threshold as a universal explanation for Exchange Online or Microsoft 365 cloud handling.
Open the message headers in Outlook
Open the affected message in the receiving mailbox and copy its full internet message headers. A screenshot of the sender address or a forwarded message does not preserve the same diagnostic evidence.
- In new Outlook, Outlook on the web, or Outlook.com, open the message and select More actions (...) > View > View message details.
- In classic Outlook for Windows, double-click the message to open it in its own window, then select File > Properties and copy the Internet headers box.
Paste the complete headers into a text editor and search for SCL: and X-MS-Exchange-Organization-SCL. Keep Received and Authentication-Results alongside the anti-spam headers so the receiving path stays available for comparison.
Find SCL in the right header
For Microsoft 365 mail, first look for X-Forefront-Antispam-Report. It usually contains semicolon-separated stamps such as SCL:5, SFV:SPM, CAT:SPM, and DIR:INB. Some messages also show X-MS-Exchange-Organization-SCL, which records an SCL stamped on the message. If values or outcomes look inconsistent, use CAT, SFV, X-CustomSpam, and message trace evidence to identify the filtering component or override.
For placement clues, also check X-Microsoft-Antispam-Mailbox-Delivery when it is present. dest:I commonly indicates Inbox delivery and dest:J indicates Junk Email at mailbox delivery time. Microsoft does not document these fields in its public cloud header reference. Confirm placement with the receiving mailbox and message trace, especially if a mailbox rule, Outlook, or later remediation moved the message.
Outlook.com and Hotmail consumer mailboxes can expose fewer diagnostic fields than Microsoft 365 organizational mailboxes. If X-Forefront-Antispam-Report is absent and only X-MS-Exchange-Organization-SCL remains, the exact filtering component generally cannot be identified from the consumer header alone.
Do not read diagnostic pairs as SCL
A value such as SpamDiagnosticOutput: 1:5 is not an SCL of 1 out of 5. Microsoft's public header reference does not define SpamDiagnosticOutput or SpamDiagnosticMetadata. Read the explicitly named SCL header instead of assigning meanings to either number.
Example Microsoft header extract
X-Forefront-Antispam-Report: CIP:203.0.113.9; CTRY:US; SCL:5; SRV:; IPV:NLI; SFV:SPM; CAT:SPM; DIR:INB; PTR:mail.example.com; X-MS-Exchange-Organization-SCL: 5 X-MS-Exchange-Organization-PCL: 2 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Mailbox-Delivery: dest:J; RF:JunkEmail; Authentication-Results: spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com; compauth=pass reason=100
In that example, CAT:SPM and SFV:SPM show that spam filtering categorized the message as Spam. DIR:INB confirms inbound direction. SCL:5 is consistent supporting context, but it is not the field that establishes the cloud verdict. dest:J and RF:JunkEmail are consistent with Junk delivery, which should be verified in the mailbox. Authentication passed, so examine reputation, content, bulk treatment, recipient policy, and other Microsoft signals.
Microsoft Defender portal message details showing SCL 5, spam verdict, and SPF, DKIM, DMARC results.
Decode the other Microsoft header fields
The fastest way to misread SCL is to stop at the number. Read the nearby stamps that explain category, direction, filter path, and destination. Microsoft documents some fields for external use. Undocumented fields are internal diagnostics and should not carry the same evidentiary weight.
|
|
|
|---|---|---|
CAT | Category | What filtered the cloud message |
DIR | Direction | Inbound, outbound, or internal |
SFV | Filter clue | Filtered, skipped, allowed, or blocked path |
SCL | Supporting stamp | General spam context, not the cloud action |
BCL | Bulk | Bulk complaint risk |
CIP | Connection IP | Which source IP Microsoft evaluated |
IPV | Connection | IP allow result or list status |
SFTY | Safety signal | Phishing or impersonation clue |
X-CustomSpam | ASF | Advanced Spam Filter trigger |
PCL | Phishing | Older phish stamp |
DMARC | Authentication | Visible From domain result |
compauth | Composite auth | Microsoft authentication result |
dest, OFR, RF | Internal mailbox diagnostics | Undocumented delivery clues; verify against the mailbox and trace |
Header fields to read beside SCL
For common category values, CAT:SPM means Spam, CAT:HSPM means High confidence spam, CAT:PHSH means Phishing, and CAT:HPHSH or CAT:HPHISH means High confidence phishing. These categories explain the filtering result more precisely than SCL alone.
SCL
SCL is a supporting spam confidence stamp in Microsoft 365 cloud headers. It remains a direct threshold input in on-premises Exchange.
- Values 0-1 usually appear on mail evaluated as not spam.
- A value of 5 or higher generally supplies negative context.
- Value -1 requests a filtering bypass.
- Use CAT and policy evidence for the cloud verdict and action.
PCL
PCL is phishing confidence level. It appears in older Exchange-style anti-spam stamps and some Microsoft header paths.
- Values 1-3 mean phishing is unlikely.
- Values 4-8 mean phishing is likely.
- PCL is not the same score as SCL.
- Also read CAT and SFTY for phishing or impersonation categories.
Bulk classification uses BCL
BCL is bulk complaint level, and Microsoft uses it for bulk email, also called gray mail. When bulk-as-spam handling is enabled and the BCL meets the applied anti-spam policy's bulk threshold, SRV:BULK and CAT:BULK provide stronger evidence than trying to infer bulk treatment from SCL alone. Start with sending IP reputation, sender domain history, list source, unsubscribe clarity, complaint trend, and recent volume changes.
Trace what filtered the message
When a message looks inconsistent, use CAT and SFV as the main filtering clues, then confirm them with DIR, IPV, X-CustomSpam, Authentication-Results, and message trace. The goal is to separate normal filtering, categorization, and override requests because each needs a different fix.
|
|
|
|---|---|---|
SFV:SPM + CAT:SPM or HSPM | Spam filtering | Check reputation, content, URLs, and X-CustomSpam |
SFV:NSPM | Spam filtering found the message nonspam | Check CAT and delivery evidence if the message still appears in Junk |
SFV:SKN or SFV:SKS | Mail flow rule or hybrid input | Inspect rules that bypass or set SCL before filtering |
SFV:SFE, SFV:SKA, SFV:SKB, or SFV:BLK | Allow or block setting | Check safe sender, blocked sender, and anti-spam policy entries |
SFV:SKI + IPV:CAL | IP Allow List | Review connection filtering and scope |
SFV:SKQ | Quarantine release | Review the original verdict and release history rather than treating this as a fresh clean result |
compauth=fail reason=000 + CAT:SPOOF | DMARC or spoof handling | Check SPF or DKIM domain matching for the visible From domain; inspect forwarding and ARC when relevant |
Common filtering source clues
One high number is not enough
Do not rebuild the sending program from one SCL value. If SFV shows an override, fix that override. If CAT shows Spam or Bulk and authentication passes, test content, sending IP, sender domain, BCL, and recipient segment separately.
When results differ by tenant
The same message can show different SCL stamps or different handling in two Microsoft 365 tenants. Anti-spam policy scope, safe sender entries, blocked sender entries, user complaint history, mail flow rules, gateways, connectors, and forwarding can change the result without any change to SPF, DKIM, or DMARC.
When one tenant shows SCL:1 and another shows SCL:5 or SCL:9 for the same email, compare the raw headers before changing DNS. Record CAT, DIR, SFV, SCL, BCL, CIP, authentication results, Received hops, and mailbox-delivery fields for both copies. If only one tenant shows the negative category or destination, the recipient admin should review policy scope, user submissions, allow or block entries, mail flow rules, and quarantine settings. If several unrelated tenants show the same negative category, investigate sender reputation, content, bulk treatment, and authentication.
Check preset policy scope before editing a custom policy: Strict and Standard preset security policies take precedence over custom anti-spam policies. Among custom policies, priority 0 is highest, and only the first matching anti-spam policy applies to the recipient.
Troubleshoot high SCL and Junk placement
Once the SCL value is recorded, identify the path that created the filtering result. Move through the headers in a fixed order so category, override evidence, policy action, and mailbox placement stay separate.
Flowchart for troubleshooting Microsoft SCL scores with raw headers, verdicts, authentication, and retesting.
- Capture the original raw headers, not a forwarded copy, because forwarding can alter the chain.
- When comparing tenants, keep the content, sender address, envelope sender, outbound IP, and send time as close as possible.
- Locate CAT, DIR, SFV, and SCL to identify the category, direction, filter clue, and supporting score.
- Use X-Microsoft-Antispam-Mailbox-Delivery values such as dest:I or dest:J as delivery clues, then confirm the observed folder and message trace events.
- Read CAT for the threat category and SRV:BULK for bulk treatment, rather than inferring either from SCL.
- Look for X-CustomSpam when SFV:SPM appears, because Advanced Spam Filter settings can add their own header after mail flow rules.
- Check SPF or DKIM pass results, then confirm DMARC passed for the visible From domain. A passing check for an unrelated domain does not satisfy DMARC.
- Send a clean test message through the same system and inspect the result with Suped's email tester. For Microsoft-specific SCL and CAT evidence, also send to the affected Microsoft mailbox and inspect that received copy.
- Review complaint patterns, recent volume changes, sending IP history, sender domain history, and blocklist (blacklist) status.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
A test send is useful because one old header can send you chasing the wrong problem. A fresh test to an unrelated mailbox does not establish what happened to the affected recipient. Repeat the test through the same sending system to the affected Microsoft tenant, compare CAT and SFV, and verify delivery there. Change one variable at a time when testing content or sending infrastructure.
For a broader health check, pair this with a domain health checker to catch DNS, authentication, and policy gaps that are easy to miss when reading one message header.
For a confirmed false positive from Microsoft's filtering, ask the recipient admin to submit the original message through Submissions in the Microsoft Defender portal. If X-CustomSpam identifies an ASF setting, review that tenant setting instead; Microsoft does not accept false-positive submissions for ASF detections.
What authentication can and cannot explain
A message can pass authentication and still receive a negative category or a high SCL. SPF, DKIM, and DMARC report authentication results, while Microsoft also evaluates content, URLs, sending patterns, recipient feedback, tenant policy, and reputation. Passing authentication removes one major reason for suspicion. It does not force Inbox delivery.
Check authentication before reputation
If a legitimate source fails DMARC, check its SPF or DKIM configuration and domain matching before debating SCL. DMARC needs a passing SPF or DKIM result for a domain that matches the visible From domain under the domain's DMARC matching mode. If DMARC passes and the message still receives a negative category, move to reputation, bulk signals, message content, URLs, sending cadence, and Microsoft-specific policy.
Pay special attention to Microsoft composite authentication. A compauth=fail reason=000 result with CAT:SPOOF indicates explicit authentication failure: DMARC failed with a published p=quarantine or p=reject policy. Check the sending source and any forwarding or ARC path before assuming that content edits or a DNS change will fix it.
Suped's DMARC monitoring helps identify which sending sources fail authentication and provides fix steps for those sources. Use it to investigate authentication failures found in Microsoft headers, then send a fresh message to confirm the receiving result.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
When Microsoft shows a negative category or high SCL, separate what Suped can verify from what Microsoft keeps internal. Suped can show whether the domain is sending authenticated mail, whether a source is unauthorized, whether SPF is near lookup limits, whether DKIM is missing, and whether reputation problems are visible through blocklist monitoring. DMARC aggregate reports do not contain SCL or mailbox folder placement, so keep the original received headers for those checks. Microsoft does not publish every factor behind its filtering results, so remove every visible defect and retest.
Resolve common SCL interpretation problems
The same SCL number can require different operational work depending on CAT, SFV, the applied policy, and mailbox delivery. These patterns cover common Microsoft header investigations.
Low SCL, bad placement
- Check CAT and mailbox-delivery fields before assuming the low SCL guarantees Inbox placement.
- A dest:J stamp suggests Junk delivery even when SCL is 0-1; confirm the actual folder and delivery events.
- Review recipient rules, blocked sender settings, and tenant policy before changing sender infrastructure.
- Changing DNS will not fix a mailbox rule or user block.
High SCL, auth passes
- Use CAT to distinguish spam, bulk, spoofing, phishing, or another category.
- Passing DMARC does not cancel reputation, content, URL, bulk, or complaint signals.
- Retest with plain content and a stable sending source, then compare the category and destination.
- Allowlisting can hide the symptom while reputation keeps deteriorating.
If the issue involves bulk classification, compare CAT:BULK or SRV:BULK with BCL and the applied anti-spam policy's bulk threshold. A high BCL is a reason to review bulk sender complaint risk, not a direct measurement of this message's complaint rate. Check sending IP reputation, sender domain history, list freshness, complaint rates, and recent volume shifts. The SCL and BCL ratings breakdown is useful when bulk fields appear.
If authentication is correct but Outlook still places the message in Junk, use the Outlook junk placement checklist before making broad DNS changes.
