How to Find and Interpret Outlook's SCL Score (Cold Email Header Walkthrough)

Why SCL Beats Every "Spam Score" Tool

Third-party spam checkers simulate a generic filter and hand you a guess. SCL is not a simulation, it's the number Microsoft's production filtering stack stamped on the exact message you sent, through your exact infrastructure, to a real tenant. When Outlook placement is your problem (the classic Gmail-inbox-Outlook-junk split), this header is the ground truth every fix should be judged against: change one thing, resend, read the new SCL.

Getting the Headers

• •Have a Microsoft seed mailbox. An Outlook.com address works; a Microsoft 365 mailbox on a real tenant is better, it's what your B2B prospects actually use.
• •Send a real test from your actual sending inbox through your actual sequencer, a hand-sent test from the web UI doesn't exercise the same path.
• •Outlook web: open the message (junk folder included) → ⋯ menu → View → View message source. Desktop: File → Properties → Internet headers.
• •Paste the whole thing into our Header Analyzer for the authentication half (SPF/DKIM/DMARC verdicts, alignment, hops), then read the Forefront line yourself for the Microsoft-specific half below.

Decoding X-Forefront-Antispam-Report

X-Forefront-Antispam-Report: CIP:209.85.220.41;CTRY:US;LANG:en;
 SCL:6;SRV:;IPV:NLI;SFV:SPM;PTR:mail-sor-f41.google.com;
 CAT:SPM;SFTY:;BCL:4;

• •SCL:6, filtered as spam → Junk folder. The headline verdict.
• •SFV:SPM / CAT:SPM, why-codes: SPM = content filter marked it spam. Other values you'll meet: SFV:BLK (recipient blocked this sender), SFV:SKS (marked before content filtering, often a transport rule or reputation call), CAT:BULK (bulk classification), CAT:PHSH (phishing, a five-alarm fire for a cold emailer).
• •BCL:4, the source is developing a bulk footprint. SCL tells you about this email; BCL tells you about your infrastructure's complaint history. High BCL doesn't fix with copy edits, it fixes with volume discipline and suppression hygiene.
• •CIP / PTR, the connecting IP and its reverse DNS. PTR:...google.com on mail landing in a Microsoft tenant is the unmatched-route tell: Google infrastructure knocking on Microsoft's door.
• •IPV:NLI, the IP wasn't found on Microsoft's reputation lists (neutral, normal for shared Google/Microsoft sending IPs).

Reading Microsoft's Authentication-Results Beside It

Same message source, one header up: Microsoft's own Authentication-Results. Gmail passing your SPF/DKIM/DMARC is irrelevant here, Microsoft evaluates independently and is stricter about alignment. The high-value combination to check: auth all passing + SCL 5-6 means your identity is proven and the content/behavior layer is the problem (tracking pixels, links, formatting, route mismatch, the fixes in the Outlook guide). Auth failing here while "passing" elsewhere means fix alignment first, usually custom DKIM or the SPF include set, staged to enforcement per the DMARC plan.

Tenant Overrides: Why Results Vary Between Companies

SCL thresholds and actions are tenant-configurable, admins reroute SCL 5 to quarantine, whitelist senders (that's the SCL:-1 you'll occasionally see), or bolt Mimecast/Proofpoint in front so mail is pre-filtered before Forefront ever scores it. So treat any single tenant's SCL as one data point, test against 2-3 different Microsoft mailboxes when it matters, and identify gateway-protected recipients up front with the ESP Segmenter, those domains play by their gateway's rules, not Forefront's.