How do I interpret SCL scores in Microsoft headers?
Matthew Whittaker
Co-founder & CTO, Suped
Published 22 May 2025
Updated 22 May 2026
7 min read
Summarize with
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, I look for a mail flow rule, gateway rewrite, older Exchange stamp, or another policy path.
I 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, authentication results, and mailbox delivery headers. Microsoft's Microsoft header guide is the reference I use for the 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 I 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
The message was marked as spam and is usually delivered to Junk by default policy.
High confidence spam
7-9
The message was marked as high confidence spam and can be junked or quarantined.
- Policy context: Default anti-spam policy, custom policy, Standard preset security, and Strict preset security can handle the same score differently.
- Score source: If a transport rule set the SCL, the number is not a pure spam-filtering verdict.
- Recipient effects: Mailbox safe sender, blocked sender, quarantine release, and tenant policy can change placement after classification.
- Value 2: An SCL of 2 is not worse than 1 in current cloud spam filtering, because it is not a normal stamped value.
|
|
|
|---|---|---|
-1 | Bypassed | Inbox |
0-1 | Not spam | Inbox |
2-4 | Not normal | Investigate |
5-6 | Spam | Junk |
7-9 | High spam | Junk/quarantine |
Compact SCL interpretation table
Find SCL in the right header
For Microsoft 365 mail, I 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, especially in Exchange paths. I still treat the Forefront anti-spam report as the main place to read the cloud verdict.
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-Microsoft-Antispam: BCL:0; PCL:2; Authentication-Results: spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com
In that example, SCL:5 is the first answer: Microsoft marked the message as spam. SFV:SPM backs that up. CAT:SPM says the applied category was spam. 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 and authentication results.
Use nearby Microsoft stamps
The fastest way to misread SCL is to stop at the number. I 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 I treat those as weak evidence unless Microsoft documents them.
|
|
|
|---|---|---|
SCL | Spam score | Spam class |
SFV | Verdict | Filtered, skipped, or spam |
CAT | Category | Spam, bulk, phish, spoof |
BCL | Bulk | Complaint risk |
PCL | Phishing | Older phish stamp |
DMARC | Auth | Domain trust input |
Header fields to read beside SCL
SCL
SCL is the spam confidence level. It is the main number for spam classification in Microsoft headers.
- Low: Values 0-1 mean not spam.
- Spam: Values 5-6 usually explain Junk placement.
- High: Values 7-9 mean high confidence spam.
- Bypass: 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.
- Neutral: Values 1-3 mean phishing is unlikely.
- Suspicious: Values 4-8 mean phishing is likely.
- Different use: PCL is not the same score as SCL.
- Modern clue: Also read CAT and SFTY for phishing or impersonation categories.
Bulk can raise SCL
When Microsoft identifies a message as bulk and the tenant policy treats bulk as spam, the result can be SCL:6. That is why BCL matters. If SRV:BULK appears, I treat the issue as bulk complaint risk and sender reputation first, not only message content.
Troubleshoot what set the score
Once the SCL value is clear, the next job is to identify the path that created it. I move through the headers in a fixed order so I do not confuse classification, policy action, and final placement.
Flowchart for reading raw headers, SCL, verdict, category, authentication, and a fresh test.
- Capture raw headers: Use the original message headers, not a forwarded copy, because forwarding can alter the chain.
- Locate SCL and SFV: Confirm whether spam filtering marked the message as nonspam, spam, skipped, or blocked.
- Read CAT and SRV: Look for spam, bulk, spoof, impersonation, malware, or phishing categories.
- Compare authentication: Check SPF or DKIM pass results, then confirm DMARC passed for the visible From domain.
- Run a fresh test: Send a clean test message through the same system and inspect the result with an email tester.
- Check reputation: Review complaint patterns, recent volume changes, sending IP 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, I 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 does use 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.
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. For most teams, Suped is the stronger practical choice for DMARC because the platform turns authentication failures into specific fix steps instead of leaving people to interpret 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, I still 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 I use
The same SCL number can mean different operational work depending on the neighboring stamps. These are the patterns I use most often when I read Microsoft headers.
Low SCL, bad placement
- Likely cause: Mailbox rules, blocked sender, focused inbox behavior, or tenant policy.
- Header clue: SCL is 0-1, but delivery headers show Junk or special handling.
- Next step: Check recipient-level settings before changing sender infrastructure.
- Risk: Changing DNS will not fix a mailbox rule or user block.
High SCL, auth passes
- Likely cause: Reputation, content, URLs, bulk signals, or complaints.
- Header clue: DMARC passes, but SCL is 5-9.
- Next step: Retest with plain content and a stable sending source.
- Risk: 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. 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
My 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, I work in this order: confirm the raw header, map the SCL, read SFV and CAT, verify authentication, check bulk and reputation signals, 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.
