Written by Venkat Nookala · Last updated 2026-09-19
Quick answer: Authentication proves who sent the message. It does not decide the folder. Outlook stamps its own spam-filtering fields into the delivered message, next to the authentication results, and you can read both from your own copy.
SPF, DKIM and DMARC answer one question: is this message really from the domain it claims? They are inputs a receiving system checks. For mail that passes all three, none of the standards asks a receiver to file the message anywhere in particular. A DMARC policy of quarantine or reject does ask for an action, but only on mail that fails DMARC, which is not the case here.
Outlook runs its own spam filtering alongside that check and stamps its fields into the delivered message. Both sets of values travel in the headers of the copy that arrived. What that lets you read is whether authentication was the problem. It does not tell you why the folder was chosen.
On 19 September 2026 we sent two report emails from the same sender, on the same template, to the same Outlook.com mailbox we own. Our own delivery log records them at 20:14:45 and 20:49:26 IST, 34 minutes and 41 seconds apart.
| Message | Authentication | compauth | SCL | Landed in |
|---|---|---|---|---|
| 20:14:45 IST | spf=pass dkim=pass dmarc=pass | pass, reason 100 | 1 | Inbox |
| 20:49:26 IST | spf=pass dkim=pass dmarc=pass | pass, reason 100 | 5 | Junk |
Two things did differ between the two sends, and both are ours. First, the name our server announced when it connected to Microsoft changed: the first external Received line reads from e2e-99-124 on the 20:14 message and from mail.humerly.com on the 20:49 one, from the same IP address both times. We changed that setting between the two sends. Second, the report audited a different domain each time, so the subject line and the score inside the message differ. The template is the same; the data in it is not.
Every authentication value is identical across the two. The folder is not. We do not know why they differ, and Microsoft does not say. That is the honest end of what two messages can tell you, and it is the reason this page exists: if you are looking at an authenticated message in Junk and assuming your SPF or DKIM is broken, these two messages are a counterexample from a mailbox we control.
Two observations are not a rule. This is one pair of messages in one mailbox on one evening. It shows that two messages with identical authentication results can end up in different folders. It does not establish a rate, a cause, or anything about what happens to your mail.
It is tempting to read the table above as "SCL 5 sent it to Junk". Both messages carry the value in one header, X-MS-Exchange-Organization-SCL, and that is the only SCL-bearing header either of them has. Of that header our analyzer says: it carries an Exchange spam confidence level (SCL) stamp. Microsoft documents this header on its Exchange Server antispam-stamps page; its cloud page separately documents the SCL value as not determining the spam verdict or the action taken. Of the numbers themselves it says only this: Microsoft documents 0 as an extremely low probability that the message is spam and 9 as an extremely high probability.
We do not claim to know what an SCL of 5 means for a consumer Outlook.com mailbox. The table shows two values next to two folders, from two messages. That is not causation.
X-Microsoft-Antispam-Mailbox-Delivery is present on both of our messages. Our analyzer shows it exactly as received. None of the five Microsoft documentation pages we read mentions it, so we give it no meaning and decode none of its fields.
In Outlook on the web: open the message, click the three dots, then View, then View message source. Four headers are worth reading.
| Header | What it records |
|---|---|
Authentication-Results | The SPF, DKIM and DMARC results, plus compauth and its reason code. |
X-MS-Exchange-Organization-SCL | The Exchange spam confidence level stamp. |
X-Microsoft-Antispam | The bulk complaint level (BCL) and related markers. |
X-Microsoft-Antispam-Mailbox-Delivery | Shown exactly as received. Not described on the Microsoft pages we read. |
You can read those by eye, or paste the whole source into our header analyzer, which decodes the documented fields into sentences and shows the undocumented ones raw.
compauth is a composite authentication result that Microsoft derives from SPF, DKIM, DMARC and other parts of the message, using the From: domain. Reason 100 means SPF or DKIM passed and the MAIL FROM and From domains are aligned. Both of our messages recorded compauth=pass reason=100, and they still landed in different folders.
It does not tell you why Outlook chose the folder, and it does not predict where your next message will land. A passing authentication result does not determine that.
What this page does tell you is whether authentication was the problem. In our two messages it was not.
In our one pair, the message carrying SCL 5 was in Junk and the message carrying SCL 1 was in the Inbox. The value sits in X-MS-Exchange-Organization-SCL. Microsoft documents that header on its Exchange Server antispam-stamps page, with 0 as an extremely low probability that the message is spam and 9 as an extremely high probability, and its cloud page separately documents the SCL value as not determining the spam verdict or the action taken. Two messages cannot tell you more than that, and we do not claim a rule.
No. compauth is an authentication result, not a placement decision. Both of our messages recorded compauth=pass with reason 100 and they went to different folders.
No. DNS carries your SPF, DKIM and DMARC records, which are inputs a receiver checks. Outlook stamps its own spam-filtering fields into the delivered message, so you need the copy that arrived. A DNS audit tells you whether your records are correct; it cannot tell you what any receiver did with a particular message.