What Is Outlook SCL Score?

What Outlook SCL score means

A message can pass SPF, DKIM, and DMARC and still land in Outlook Junk. That feels wrong when you first see it. It is also normal.

SCL means spam confidence level. Microsoft 365 stamps this value on inbound mail after filtering or after another mail flow feature sets it. A higher SCL means Microsoft judged the message to be more likely spam. In cloud organizations, SCL -1 means spam filtering was skipped, often because of an allow rule or other override. SCL 0 or 1 means the message was not marked as spam. SCL 5 or 6 means spam. SCL 7, 8, or 9 means high confidence spam. Microsoft says spam filtering does not stamp SCL 2, 3, or 4.

The score helps you narrow the problem. If a test message has SCL 5 or higher, a missing DNS record may be only one part of the issue. Outlook saw enough risk to route or quarantine the message. That risk can come from failed authentication, weak alignment, sender history, complaints, content, links, bulk patterns, tenant rules, or blocklists.

For the official table, see Microsoft Learn on spam confidence level.

Why authenticated mail still goes to Junk

SPF, DKIM, and DMARC are entry checks. Outlook still grades the message and the sender.

SPF checks whether the sending server is allowed to send for the envelope domain. DKIM checks a cryptographic signature from the signing domain. DMARC checks whether SPF or DKIM passes and aligns with the visible From domain, then applies the domain owner's policy. Microsoft also uses composite authentication, which can include sender reputation, sender history, recipient history, behavior, and other signals. Gmail works from the same broad idea: authentication matters, then reputation, complaints, engagement, volume, and policy affect where mail lands. For details, compare Google email sender guidelines and Microsoft email authentication guidance.

That means a signed message can still look risky. Common causes are a new sending domain with little history, a shared IP with poor behavior, a sudden volume jump, links to a low-trust domain, repeated sends to stale contacts, or content that looks like bulk mail. Outlook can also use bulk complaint signals for gray mail. A newsletter that people ignore can be treated very differently from a receipt that people open and reply to.

If you are testing one domain, start with the live records. InboxRadar can check SPF, DKIM, DMARC, and MX free and show the first fix. Use the result as a map, then test a fresh message to an Outlook.com or Microsoft 365 mailbox and inspect the headers.

Checks worth making first

Do the boring checks before rewriting the email. They catch many SCL problems and give Microsoft cleaner signals on the next send.

• SPF: publish one SPF TXT record for the domain that sends mail. Include every real sender. Avoid duplicate SPF records. Stay under the SPF 10 DNS lookup limit from RFC 7208, because too many lookups can cause permerror. Use ~all while you are still finding senders, then move to -all only when every source is listed.
• DKIM: make sure each sending platform signs mail with its own selector and that the selector DNS record exists. DKIM from the visible From domain, or a domain aligned with it, can satisfy DMARC.
• DMARC: publish a record at _dmarc.yourdomain. Start with p=none and a rua address so you can see who sends as you. Move to p=quarantine or p=reject after real senders are aligned. If RUA XML reports are hard to read, use the free DMARC report reader.
• Alignment: check the Header From domain, SPF Mail From domain, and DKIM signing domain. SPF or DKIM can pass but DMARC can fail if the domains do not align.
• MX and replies: use a From and reply domain that can receive mail. If the domain receives mail, keep its MX records correct. A reply path that breaks can hurt normal customer workflows.
• Blocklists and reputation: check whether the sending IP or domain is listed. Then look at list quality, complaint rates, bounces, and sudden volume changes. Fix the cause before asking for delisting.
• Message and link trust: use a stable From name, a real reply address, clear unsubscribe for bulk mail, and links that match your brand domain. Avoid URL shorteners in business mail.

How to read the headers

Outlook message headers tell you what Microsoft decided. They are noisy, but a few fields matter.

Look for X-Forefront-Antispam-Report, X-MS-Exchange-Organization-SCL, or similar Microsoft headers. The SCL value may appear as SCL:5 or another number. Also check Authentication-Results for SPF, DKIM, DMARC, and compauth. If DMARC failed, fix alignment before blaming content. If authentication passed but SCL is still high, look at reputation, link domains, volume, recipient engagement, and tenant policies.

For Microsoft 365 admins, message trace and quarantine details can show whether a rule, policy, DMARC failure, or high-confidence spam verdict affected delivery. Be careful with allowlists. They can hide a problem in your own tenant while the same message still goes to Junk for everyone else.

AI search visibility is a different crawlability check

Email deliverability and AI search visibility both depend on machine access. The rules are different, so keep the checks separate.

For AI answers, the crawlers that decide whether a site can be found and read are OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google AI Overviews, and Applebot for Apple Intelligence. Google AI Overviews use the normal Google Search index. There is no separate Google AI Overview crawler to block.

If you disallow those live search crawlers in robots.txt, you remove the site from that engine's live answer path. For Google, AI features use normal Search controls: a page must be indexed and eligible for a snippet. By contrast, GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls. Blocking those does not remove a site from live AI search visibility. Google-Extended and Applebot-Extended are robots.txt control tokens, not separate crawl user agents.

Robots.txt is a stated site policy. It is not proof of what any bot actually did. Perplexity-User and Bytespider have been reported to ignore robots.txt, so logs and server controls matter when you need evidence. Google publishes detailed JavaScript rendering guidance for Googlebot. Other AI-search crawlers either do not document the same rendering pipeline or document it less fully, so client-side-only content remains a risk. Server-render the main text when you need AI systems to read it. You can test the basics with the free AI visibility checker. For bot names and controls, use the vendor docs from OpenAI, Anthropic, Perplexity, Google, Apple, and Common Crawl.

What to fix when SCL is high

Work from proof to judgment calls. A clean message with bad authentication still looks bad. A fully aligned domain with poor behavior can still be junked.

• Send a new test message to Outlook and save the full headers.
• Find the SCL value and the authentication results.
• Fix any SPF, DKIM, DMARC, or alignment failure first.
• Check that every platform sending as the domain is known and signed.
• Review Microsoft 365 transport rules, tenant allow or block lists, and anti-spam policies if you control the receiving tenant.
• Lower volume if you recently ramped up. Send to engaged recipients first.
• Remove stale or scraped contacts. High bounces and low engagement teach filters fast.
• Check link domains, redirect chains, attachments, and URL shorteners.
• Watch DMARC aggregate reports for unknown senders and forwarders.
• Retest after DNS changes have propagated and after several normal sends.

If you want the standards behind the checks, read RFC 7208 for SPF, RFC 6376 for DKIM, and RFC 7489 for DMARC. For Microsoft-specific behavior, use Microsoft sender and Defender for Office 365 guidance as the source of truth.