How do I interpret SCL scores in Microsoft headers?
Published 22 May 2025
Updated 20 Jun 2026
12 min read
Summarize with
Updated on 25 Jun 2026: We updated this guide with tenant-specific SCL troubleshooting and clearer header clues for Microsoft 365 investigations.
An SCL score in Microsoft headers is Microsoft 365's spam confidence result. The direct read is simple: -1 means spam filtering was bypassed, 0 and 1 mean not spam, 5 and 6 mean spam, and 7 to 9 mean high confidence spam. Microsoft's Microsoft SCL table also states that spam filtering does not stamp 2, 3, or 4. If those appear, check for a mail flow rule, gateway rewrite, older Exchange stamp, or another policy path. Normal spam filtering also does not usually stamp 7; DMARC failure handling and mail flow rules can set it, and analyst review can too.
Do not treat SCL as a full root cause. It is the verdict marker. To understand why Microsoft placed the message in Inbox, Junk, or quarantine, read it beside SFV, CAT, BCL, PCL, X-MS-Exchange-Organization-SCL, X-CustomSpam when present, authentication results, and mailbox delivery headers. Microsoft's Microsoft header guide is the reference for current cloud header names.
Read the score first
Start by mapping the value before chasing every header field. A higher SCL means Microsoft judged the message more likely to be spam. The score does not tell you which exact model, rule, reputation input, or mailbox setting made the decision, but it tells you which class of action to expect.
SCL score bands
How to read Microsoft SCL values before checking policy context.
Bypassed filtering
-1
Delivered because spam filtering was skipped by allow logic, a safe sender, or a rule.
Not spam
0-1
Microsoft spam filtering determined that the message was not spam.
Unexpected values
2-4
Current spam filtering does not stamp these values, so check rules or older paths.
Spam
5-6
Default anti-spam, new anti-spam, and Standard preset policies usually deliver to Junk; Strict can quarantine.
High confidence spam
7-9
Default and new anti-spam policies usually deliver to Junk; Standard and Strict preset policies can quarantine.
- Policy precedence matters: Strict preset, Standard preset, custom anti-spam, and default anti-spam policies can handle the same score differently.
- If a transport rule set the SCL, the number is not a pure spam-filtering verdict.
- Mailbox safe sender, blocked sender, quarantine release, and tenant policy can change placement after classification.
- An SCL of 2 is not worse than 1 in current cloud spam filtering, because it is not a normal stamped value.
- An SCL of 7 should be checked for DMARC failure handling and mail flow rules before assuming ordinary spam filtering created it. Analyst grading can also set this value.
|
|
|
|---|---|---|
-1 | Bypassed | Inbox |
0-1 | Not spam | Inbox |
2-4 | Not normal | Investigate |
5-6 | Spam | Junk or quarantine |
7-9 | High confidence spam | Junk or quarantine |
Compact SCL interpretation table
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, and CAT:SPM. Some messages also show X-MS-Exchange-Organization-SCL, which records the final SCL value stamped on the message. If values differ, use SFV, X-CustomSpam, and message trace clues to find whether a rule, allow list, or filter changed the result.
For final placement, also check X-Microsoft-Antispam-Mailbox-Delivery when it is present. dest:I points to Inbox delivery and dest:J points to Junk Email at mailbox delivery time. That confirms where Microsoft put the message, but it does not identify every reason behind the SCL.
Example Microsoft header extract
X-Forefront-Antispam-Report: CIP:203.0.113.9; CTRY:US; SCL:5; SRV:; IPV:NLI; SFV:SPM; CAT:SPM; PTR:mail.example.com; X-MS-Exchange-Organization-SCL: 5 X-Microsoft-Antispam: BCL:0; PCL:2; 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, SCL:5 is the first answer: Microsoft marked the message as spam. X-MS-Exchange-Organization-SCL: 5 confirms the final stamp matches the Forefront report. SFV:SPM backs that up. CAT:SPM says the applied category was spam. dest:J and RF:JunkEmail confirm final Junk placement. The authentication results passed, so the next question is reputation, content, bulk treatment, recipient policy, or another Microsoft signal.
Microsoft Defender portal message details showing SCL 5, spam verdict, and SPF, DKIM, DMARC results.
Use nearby Microsoft stamps
The fastest way to misread SCL is to stop at the number. Read the small set of nearby stamps that explain the delivery path. Some stamps are public enough to use confidently. Others are internal Microsoft diagnostics, and those carry weaker evidence unless Microsoft documents them.
|
|
|
|---|---|---|
SCL | Spam score | Spam class |
SFV | Verdict | Filtered, skipped, or spam |
CAT | Category | Spam, bulk, phish, spoof |
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, impersonation, or first contact clues |
X-CustomSpam | ASF | Advanced Spam Filter trigger |
PCL | Phishing | Older phish stamp |
DMARC | Auth | Domain trust input |
compauth | Composite auth | Microsoft authentication result |
dest, OFR, RF | Mailbox result | Inbox, Junk, and outcome clues |
Header fields to read beside SCL
SCL
SCL is the spam confidence level. It is the main number for spam classification in Microsoft headers.
- Values 0-1 mean not spam.
- Values 5-6 usually explain Junk placement.
- Values 7-9 mean high confidence spam.
- Value -1 means filtering was skipped.
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 can raise SCL
BCL is bulk complaint level, and Microsoft uses it for bulk email, also called gray mail. Microsoft documents BCL:4 through BCL:7 as mixed complaint bulk. When Microsoft identifies a message as bulk and the tenant policy treats bulk as spam, the result can be SCL:6. If BCL:6 or SRV:BULK appears, start with sending IP reputation, sender domain history, list source, unsubscribe clarity, complaint trend, and recent volume changes.
Trace who set the SCL
When a message looks inconsistent, use SFV as the primary source clue, then confirm it with IPV, X-CustomSpam, Authentication-Results, and message trace. The goal is to separate normal spam filtering from SCL overrides, because the fix is different.
|
|
|
|---|---|---|
SFV:SPM + CAT:SPM or HSPM | Spam filtering | Check reputation, content, URLs, and X-CustomSpam |
SFV:SKN or SFV:SKS | Mail flow rule | Inspect transport rules that 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 |
IPV:CAL with SCL:-1 | IP Allow List | Review connection filtering and scope |
compauth=fail reason=000 with CAT:SPOOF | DMARC or spoof handling | Fix SPF or DKIM and DMARC for the visible From domain before editing content |
Common SCL 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 SFV shows spam filtering and authentication passes, test content, sending IP, sender domain, BCL, and recipient segment separately.
When scores differ by tenant
The same message can receive different SCL values in two Microsoft 365 tenants, including tenants still called O365 or Office 365 by their users. SCL is calculated in the receiving tenant context, so anti-spam policies, anti-phishing settings, safe sender entries, blocked sender entries, user complaint history, mail flow rules, gateways, connectors, and forwarding can change the final score 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 SCL, SFV, CAT, BCL, PCL, CIP, Authentication-Results, Received hops, and mailbox-delivery fields for both copies. If only one tenant shows the high score, the recipient admin should review Defender policy, user submissions, allow or block entries, mail flow rules, and quarantine settings. If several tenants show the same high score, treat it as a sender reputation, content, bulk, or authentication issue.
Troubleshoot what set the score
Once the SCL value is clear, the next job is to identify the path that created it. Move through the headers in a fixed order so classification, policy action, and final 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 SCL and SFV to confirm whether spam filtering marked the message as nonspam, spam, skipped, or blocked.
- Check X-Microsoft-Antispam-Mailbox-Delivery for dest:I or dest:J so final folder placement is separated from spam classification.
- Read CAT and SRV for spam, bulk, spoof, impersonation, malware, or phishing categories.
- Look for X-CustomSpam when SFV:SPM and a high SCL appear, 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.
- Send a clean test message through the same system and inspect the result with an email tester.
- 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 opens the report when the test is ready.
?/43tests passed
Preparing test address...
A test send is useful because one old header can send you chasing the wrong problem. If the fresh test has SCL:1 and passes authentication, the old complaint was likely recipient-specific, policy-specific, or content-specific. If the fresh test has SCL:5 or higher, the sending path needs real work.
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.
What authentication can and cannot explain
A message can pass authentication and still get a high SCL. That surprises people because authentication feels binary. Microsoft uses SPF or DKIM with DMARC as trust inputs, but SCL also reflects content, URLs, sending patterns, recipient feedback, tenant policy, and reputation. Passing authentication removes one major reason for suspicion. It does not force Inbox delivery.
Authentication is necessary, not enough
If authentication fails, fix it before debating SCL. If authentication passes and SCL is still high, 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 means explicit DMARC failure handling is part of the problem, so content edits will not fix the first failure.
This is where Suped's product fits the workflow. Suped connects DMARC monitoring, hosted SPF, hosted DMARC, DKIM checks, blocklist monitoring, and real-time alerts in one place. The practical value is that authentication failures become specific fix steps instead of raw XML reports and scattered headers.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
When Microsoft shows 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. Microsoft does not publish every factor behind the SCL value, so the practical goal is to remove every visible defect and retest.
Common interpretations
The same SCL number can mean different operational work depending on the neighboring stamps. These are the patterns that matter most when reading Microsoft headers.
Low SCL, bad placement
- The likely cause is mailbox rules, blocked sender, focused inbox behavior, or tenant policy.
- The header clue is SCL at 0-1, while dest:J or another delivery header shows Junk or special handling.
- Check recipient-level settings before changing sender infrastructure.
- Changing DNS will not fix a mailbox rule or user block.
High SCL, auth passes
- The likely cause is reputation, content, URLs, bulk signals, or complaints.
- The header clue is DMARC passing while SCL is 5-9.
- Retest with plain content and a stable sending source.
- Allowlisting can hide the symptom while reputation keeps deteriorating.
If the issue involves bulk classification, compare the SCL with BCL and the tenant bulk threshold. BCL is the bulk complaint level, and BCL:6 usually means sender reputation needs attention before copy edits. When SRV:BULK appears, check sending IP reputation, sender domain history, list freshness, complaint rates, and recent volume shifts. The SCL and BCL ratings breakdown is useful when SRV:BULK or a high BCL appears.
If the header has many Microsoft-specific fields and the SCL is only part of the story, the Microsoft header signals guide helps connect SCL with category, safety, authentication, and delivery stamps.
If authentication is correct but Outlook still places the message in Junk, use the Outlook junk placement checklist before making broad DNS changes.
Views from the trenches
Best practices
Read SCL with SFV and CAT before changing DNS or rewriting message content too soon.
Use original raw headers, because forwarded samples can hide the real delivery path.
Treat PCL as separate from SCL, especially when older Exchange stamps appear in logs.
Common pitfalls
Assuming SCL 2 is worse than SCL 1 leads teams to chase the wrong signal in triage.
Reading one high SCL sample without a fresh test can misdiagnose the sender path.
Using allow rules too early hides reputation, content, or bulk classification issues.
Expert tips
Compare a clean plain-text test with the original campaign to isolate content risk.
Check whether bulk policy created SCL 6 before treating the message as spam only.
Keep DMARC reports separate from SCL headers, then compare them during triage work.
Marketer from Email Geeks says Microsoft header parsing is easier when SCL, SFV, CAT, BCL, and authentication results are read together instead of one field at a time.
2024-02-12 - Email Geeks
Marketer from Email Geeks says PCL should not be confused with SCL, because low PCL values are neutral while SCL controls spam classification.
2024-02-13 - Email Geeks
Practical readout
The clean answer is this: read SCL as Microsoft's spam confidence class, then prove the cause with nearby headers. -1 means bypassed. 0 and 1 mean not spam. 5 and 6 mean spam. 7 to 9 mean high confidence spam. Values 2-4 need context because current spam filtering does not stamp them.
For actual remediation, work in this order: confirm the raw header, map the SCL, read SFV and CAT, check for override clues, verify authentication, check mailbox-delivery and reputation signals, compare affected and clean tenants when scores conflict, then retest. Suped helps with the parts a sender can control: DMARC visibility, SPF cleanup, DKIM diagnostics, hosted records, real-time alerts, and practical fix steps across domains.
