Why Emails Land in Outlook's Junk Folder, and How to Find Out

Outlook sends your email to Junk when Microsoft's filter decides it's spam, phishing or bulk mail that people complain about. You can usually tell which from the message headers. Check the CAT and SFV values in X-Forefront-Antispam-Report, then BCL in X-Microsoft-Antispam. The compauth result in Authentication-Results tells you whether authentication was the cause.

Most guides on this tell you to look at the SCL number. That advice is out of date. Microsoft's own documentation, updated in August 2026, says the SCL "no longer holds the same meaning in cloud organizations". It "doesn't determine whether spam filtering identifies a message as Spam or High confidence spam, and it doesn't determine the action taken on the message." Below is how to read what actually decided it, and what to do about each cause.

First, get a junked message and its headers

To diagnose a junked email, you need a copy that actually landed in Junk, plus its full headers. A message in your own Sent folder won't do: the verdict is only stamped on the recipient's copy.

The quickest way is a test mailbox: a free Outlook.com account, or a Microsoft 365 mailbox you or a colleague control. Send your real campaign or sequence email to it, from the same sending tool and on the same route. If it lands in Junk, open it and view the source:

• Outlook on the web: open the message, select the three dots, then View and View message source.
• Classic Outlook for Windows: File, then Properties, then Internet headers.

If you'd rather not read raw headers, paste them into Microsoft's own Message Header Analyzer. Our walkthrough of how to read email headers covers the Received chain in more depth. This post sticks to the Microsoft-specific fields.

One caveat: Microsoft documents these headers for Microsoft 365 (business) mailboxes. Outlook.com consumer mailboxes are a separate service with their own postmaster site. The authentication fields read the same way in both, but treat the Microsoft 365 field definitions below as the documented reference.

The four header values that tell you why

Four values tell you why the message was junked. CAT gives the category of verdict, SFV says whether filtering ran or was skipped, BCL scores bulk mail on complaints, and compauth gives the authentication verdict. You'll find them in three headers.

Here is a real-format example of the first header, taken from Microsoft's documentation:

X-Forefront-Antispam-Report: ...CTRY:;LANG:hr;SCL:1;SRV:;IPV:NLI;SFV:NSPM;PTR:;SFTY:;...

And the values that matter, from Microsoft's anti-spam header reference:

Header	Value	What Microsoft says it means
X-Forefront-Antispam-Report	SFV:SPM	Marked as spam by spam filtering
	SFV:NSPM	Marked as non-spam and delivered
	SFV:BLK	Sender is on the user's Blocked Senders list
	SFV:SKS	Marked as spam before filtering, by a mail flow rule
	CAT:SPM / CAT:HSPM	Spam / high confidence spam
	CAT:BULK	Bulk
	CAT:SPOOF / CAT:PHSH	Spoofing / phishing
	SRV:BULK	Identified as bulk using the BCL threshold
	IPV:NLI	Your IP was not found on any IP reputation list
	PTR:	The reverse DNS of the connecting IP (blank means none)
X-Microsoft-Antispam	BCL:0 to BCL:9	Bulk complaint level, higher means more complained about
Authentication-Results	compauth=fail reason=000	Failed DMARC, and your policy is quarantine or reject
	compauth=fail reason=001	Failed implicit authentication: no records, or weak ones (~all, p=none)
	compauth=pass reason=1xx	Passed authentication

The SCL is still in the header, but in a cloud mailbox you can mostly ignore it. Microsoft says its main remaining use is on-premises and hybrid Exchange, plus mail flow rules.

Reading the verdict: a decision table

Each combination points to a different cause, so fix the one the headers name, not the one you assumed. This table maps what you see to what it means and the fix.

What the headers show	Likely cause	What to do
compauth=fail, spf=fail or dkim=none	Authentication	Fix SPF, DKIM and DMARC alignment first. Nothing else matters until this passes
CAT:BULK, SRV:BULK, BCL:7 or higher	Complaints about you as a bulk sender	Cut unengaged recipients, make unsubscribing easy, slow down
CAT:SPM, auth passes, BCL:0	Content or IP/domain reputation	Check reputation (SNDS if you own the IP), simplify the message, look at links
CAT:SPOOF	From domain doesn't authenticate as the sender	Align the From domain with your DKIM signing domain
SFV:BLK	This user blocked you	Nothing to fix at your end, apart from not mailing them
CAT:BULK but BCL below 7	Bulk, but under the default threshold	Look at the recipient's policy: Strict uses 5, Standard uses 6

The bulk row catches out a lot of legitimate senders. According to Microsoft's bulk detection page, the default anti-spam policy junks bulk mail at BCL 7 or above. The Standard preset uses 6, and the Strict preset uses 5 and quarantines rather than junking. So the same newsletter can reach the inbox in one company and Junk in the next, because their admins chose different presets.

There's a newer wrinkle too. Microsoft's documentation says that as of July 2026, all mail identified as bulk receives a Promotions tag. Where an admin has turned on "Bulk moves enabled", bulk mail below the threshold goes to a Promotions folder instead of the inbox. If recipients say they "never got" your email but it isn't in Junk, look there.

Authentication: the May 2025 rules

If the headers show an authentication failure, start here. Microsoft now enforces this for high-volume senders.

Microsoft's Outlook.com policies page says that from 5 May 2025, domains sending more than 5,000 emails per day to Outlook.com addresses must pass SPF, DKIM and DMARC. DMARC needs at least p=none and must align with SPF or DKIM, preferably both. Non-compliant mail goes to Junk first, and may then be rejected with:

550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.

We cover the full requirements in Microsoft Outlook's bulk sender requirements. Below 5,000 a day the rule doesn't formally apply, but compauth=fail reason=001 will still count against you. You can check all three records for your domain in one pass with the deliverability audit.

SNDS and JMRP: useful only if you own the IP

SNDS (Smart Network Data Services) and JMRP (the Junk Mail Reporting Program) are Microsoft's free sender tools. They only work for IP addresses you can prove are yours. Most small senders don't have any.

To get access, you prove control of an IP range. The SNDS FAQ describes three routes: an authorisation email to postmaster@ or abuse@ at the domain in the IPs' reverse DNS, an address from the RDAP allocation record, or the ASN record. If you send cold email through Google Workspace, or newsletters through Mailchimp or a similar platform on shared IPs, you can't pass that check, and the data belongs to your provider. These tools are for people running their own mail servers, or on dedicated IPs.

If you do qualify, SNDS gives you the most direct view of Outlook.com's opinion available anywhere. According to the FAQ:

SNDS colour	Share of messages given a spam verdict
Green	Under 10%
Yellow	10% to 90%
Red	Over 90%

The FAQ adds a reading tip: if your other IPs are green, a yellow one is probably near the 10% end. It counts one message to ten recipients as ten verdicts. And it notes the colour "doesn't directly represent deliveries to users' inboxes or Junk e-mail folders", because users' own settings can move mail either way.

The other numbers worth watching, all from the same FAQ:

• Complaint rate is complaints divided by message recipients. Microsoft says "more than 30% of the IPs sending mail to Outlook.com keep their complaint rate at less than 0.3%", and calls that "a good bar to shoot for". Complaints are counted on the day they're reported, so a single day can show over 100%.
• RCPT commands against message recipients. Microsoft says more than a third of IPs keep the share of RCPT commands that don't become actual recipients under 10%, and that a large gap "can indicate problems with the sender, such as out of date recipient lists or namespace mining".
• IP status shows whether an IP is Blocked, Bot or Junked. It reflects only the last 24 hours, with no history.

Data is aggregated daily, around midnight Pacific time, and kept for 90 days. IPs that sent fewer than 100 messages on a given day may show no data at all. Access also expires: the new portal says network access lapses 10 months after approval, so you have to re-attest ownership.

JMRP is the feedback loop. Microsoft's services page says it returns "the full message with headers of any email marked as junk or phishing", and that you typically start receiving feedback "within as little as 72 hours" of enrolling. Every address that comes back through JMRP should be suppressed at once.

The rejections that tell you more than Junk does

When Outlook.com rejects a message outright rather than junking it, the bounce carries a code that names the reason. These come from Microsoft's troubleshooting page:

Code	Microsoft's stated reason
421 RP-001 / RP-002 / RP-003	Rate or connection limit exceeded, "related to IP/domain reputation"
550 SC-001	Content with spam-like characteristics, or IP/domain reputation
550 SC-002	The connecting IP "has exhibited namespace mining behavior"
550 SC-004	Block placed because of complaints. Microsoft recommends enrolling in JMRP
550 DY-001	Mail from a dynamic IP
550 OU-001	Points you to Spamhaus for removal
550 5.7.515	Authentication requirements not met

If you see OU-001, you're on a third-party list. Our guide to getting off an email blacklist covers that.

SC-002 deserves a plain explanation, because it involves our own category of product. Microsoft's policy says senders "must not use namespace mining techniques", which it defines as "verifying email addresses without sending (or attempting to send) emails to those addresses", and it takes action against IPs that do so. In practice, that means two things. Never run address checks from the same IP your real mail leaves from. And keep the share of invalid recipients low, because SNDS reads a big gap between RCPT commands and delivered recipients as a warning sign. Verify lists away from your sending infrastructure, and verify before the send, not by sending.

What Microsoft says matters most

Microsoft singles out the junk complaint rate as one of the principal factors. Its troubleshooting page lists the inputs to its SmartScreen filter: "sending IP, domain, authentication, list accuracy, complaint rates, content and more". It then adds: "Of these, one of the principal factors in driving down a sender's reputation and deliverability is their junk email complaint rate."

A few other points from the same pages are worth knowing:

• There is no allow list. Microsoft says plainly that Outlook.com doesn't operate one. The nearest thing it names is Validity's Sender Certification, a paid third-party programme.
• New IPs start with no reputation. Microsoft says a new IP "can expect to be fully ramped within a couple of weeks or sooner", depending on volume, list accuracy and complaint rates. A new IP added to a domain with a good SPF-authenticated record can inherit some of that domain's reputation.
• Valid reverse DNS is required, and connections from dynamic IP space may not be accepted.
• Don't retry after a 5xx. The policy says that after a permanent error you must not retransmit to that recipient, and after repeated failures you must stop sending to them altogether.

A practical order of work

Work through it in this order, and stop when the headers come back clean:

1. Get one junked copy and read compauth, CAT, SFV and BCL. Don't guess the cause.
2. Fix authentication if compauth failed. Check your DMARC record aligns with your DKIM signing domain.
3. If it's CAT:BULK with a high BCL, cut the list, not the copy. Drop people who haven't engaged, honour unsubscribes at once, and remove every invalid address before the next send.
4. If you own your sending IPs, enrol in SNDS and JMRP today. Suppress every JMRP complaint.
5. If you're on shared infrastructure, ask your provider what SNDS shows for the IPs your mail uses.
6. Re-test with a fresh message after each change, not after all of them, so you know which one worked.

If reputation is already damaged rather than borderline, a single fix won't be enough. See our 30-day reputation recovery plan for the slower, staged version.