Why cold emails land in Outlook junk when SPF, DKIM and DMARC all pass

On 31 August 2026 we sent one message from a freshly provisioned domain to three receivers. Same message, same mailbox, same minute. It landed in three different places, and the one that matters most to anyone emailing businesses on Microsoft was the worst of the three.

The instinct on seeing that is to check SPF, DKIM and DMARC again. We did, from Outlook’s own headers on the junked copy, and they were all fine. This post is about why that is possible, how to read what Outlook actually decided, and what changes it.

Why does Outlook junk email that passes authentication?

Because authentication answers whether the mail is really from your domain, and the junk decision answers whether Outlook wants it. Passing SPF, DKIM and DMARC removes a reason to junk a message. It does not supply a reason to trust it. For a domain Outlook has never seen, that trust comes from history the domain does not have yet.

Here is the authentication result Outlook.com recorded on the message it put in Junk:

spf=pass (sender IP 40.93.194.141)
dkim=pass (signature was verified)
dmarc=pass action=none
compauth=pass reason=100

compauth is Microsoft’s composite authentication verdict, and pass with reason 100 is the strongest result it issues. There is nothing left to fix in the records. The same headers then show why it was junked anyway:

X-MS-Exchange-Organization-SCL: 5
RF:JunkEmail   ENG:SpamFilterAuthJ

How do you read SCL in Outlook headers?

SCL is the spam confidence level Microsoft’s filter assigns to each message, and it decides the folder. Find X-MS-Exchange-Organization-SCL in the message headers. A value of 0 or 1 goes to the inbox. A value of 5 or 6 means the filter judged it spam and it goes to Junk. Authentication results sit in a separate header and feed into that score.

One detail in our headers is worth knowing about, because it explains a lot of confused troubleshooting. The stamp from our own sending tenant said SCL:1, not spam. Outlook.com then scored the same message SCL:5 on arrival. Those are two different filters: Microsoft 365 checking what it sends, and Outlook.com’s consumer filter judging what it receives. A clean outbound score tells you nothing about the inbound one.

What pushed our message into Junk

Nothing in the headers names a single cause, so this is our reading of the contributing factors, most important first.

1. The domain was days old and had sent about 6 messages in its life. Outlook.com had no history to judge it by, and it defaults to caution for unknown senders
2. No engagement. Nobody at Outlook.com had ever opened, replied to or rescued mail from this domain
3. The sending IP was a shared Microsoft outbound address. Its reputation is pooled across many tenants and is not something any of them controls
4. The message itself was junk-shaped: no signature, no unsubscribe line, a machine subject with a timestamp in it, almost no content, to a stranger

The last one is the easiest to overlook, because it is a test message and test messages feel exempt. They are not. A filter scoring an unknown sender has little to go on except the content, and a contentless message with a timestamp in the subject looks exactly like what it was: automated mail nobody asked for.

What not to change

• Do not touch SPF, DKIM or DMARC. If compauth says pass, the records are doing their job, and editing them only risks breaking them
• Do not retire the domain. A domain that has never warmed up has not failed; it has not started
• Do not file a delisting request with Microsoft. Their delist portal is for IP addresses you own that are blocked from sending into Microsoft, and on shared Exchange Online outbound you own none
• Do not sign up for SNDS or JMRP expecting to see your sending. Both report on IP addresses you control, which on Microsoft 365 you do not

If you want to rule out configuration in a minute and then stop thinking about it, run the domain through the DNS records checker. If it comes back clean and the headers say compauth=pass, the problem is reputation and the rest of this post applies.

What actually moves Outlook from Junk to inbox

Time and engagement. Outlook builds trust in a sender from how its mail is treated: opened, replied to, moved out of Junk, not reported. A warm-up pool does exactly that at low volume for two weeks before any cold mail goes out, which is why warming up the domain is the fix rather than anything in DNS.

• Warm up for at least 14 days before the first campaign, at 1 a day rising to 5, and keep warm-up running afterwards
• Keep volume low when cold sending starts. On Microsoft we size inboxes at 3 a day
• Send real messages: a signature, a plain subject a person would write, enough content to say something, a way to opt out
• Retest with a real message after warm-up, not with a contentless one, and judge placement only once the domain has history

Our own test is the illustration. The message that went to Junk at Outlook.com on day one was sent before any warm-up. That is the expected result, not a finding about the infrastructure, and it is why we judge acceptance rather than placement on the test sends we run before handing a domain over.

Outlook.com is not the same as a business on Microsoft 365

Our measurement was Outlook.com, the consumer service, and it is the harshest consumer filter we test against. A company whose mail runs on Microsoft 365 is filtered by Exchange Online Protection under that company’s own policies, which can be stricter or more relaxed, and can include gateways in front of Microsoft entirely.

So test against what your list is made of. If you email businesses, a seed address on a business Microsoft 365 tenant tells you more than an Outlook.com account does. If your list is mostly Gmail, the provider comparison is worth reading, with the caveat that we have not measured a placement difference between the two and do not claim one.