Decoding Microsoft 365's Authentication-Results Header: A Guide for Analysts

That BEC attempt that landed in a VIP's inbox? The one with no payload, just a simple, urgent request? Your filters missed it, but the clues to its illegitimacy were hiding in plain sight. They were embedded in a single, dense email header: `Authentication-Results`.

For analysts working in a Microsoft 365 environment, this header is ground zero. It’s far more than a simple log of SPF and DKIM checks. It’s a narrative of Microsoft’s internal decision-making process, packed with proprietary tags, scores, and reason codes. Understanding this dialect is the difference between a quick, confident triage and hours spent chasing false signals. EOP and Defender for Office 365 tell you their final verdict, but this header tells you *why* they reached it.

Compauth: The Linchpin of Microsoft's Judgment

The first and most important tag you'll see is `compauth`. This isn't an internet standard; it's Microsoft's own Composite Authentication verdict. Think of it as the final grade after weighting the results of multiple, sometimes conflicting, authentication checks. An email can fail SPF but still pass `compauth`. It can have a misaligned DKIM signature and still pass `compauth`. This is the system's attempt to make a judgment call, not just read a meter.

The Underlying Signals: SPF, DKIM, and DMARC

Before you can appreciate `compauth`, you need a firm grip on the three standard pillars it's built on. SPF (Sender Policy Framework, RFC 7208) checks if the sending IP is authorized in the domain's DNS records. DKIM (DomainKeys Identified Mail, RFC 6376) provides a cryptographic signature that verifies the message body and certain headers haven't been tampered with. DMARC (Domain-based Message Authentication, Reporting, and Conformance, RFC 7489) ties them together, requiring one of them to pass *and* align with the `From:` header domain, while also providing policy (p=quarantine, p=reject) for failures.

In the `Authentication-Results` header, you'll see these broken out. A typical result might show `spf=pass`, `dkim=pass`, and `dmarc=pass`. But the real world is messy. A sales rep sending an email from a third-party marketing platform will almost certainly fail SPF, because the platform's IP isn't in their corporate SPF record. But if the platform correctly signs it with a DKIM signature for the sending domain, DMARC can still pass. Microsoft's `compauth` is designed to weigh these scenarios.

Why `compauth=pass` Is Not a Free Pass

The most crucial part of the `compauth` result is the `reason` code. A `compauth=pass` with `reason=100` means it passed because DMARC passed. Great. But a `compauth=pass` with `reason=102` means it passed because of a manually configured sender allow list. That's a huge difference. The former is an organic pass based on public standards; the latter is a 'get out of jail free' card from an administrator. If that email is malicious, your investigation just shifted from analyzing the sender's infrastructure to auditing your own transport rules.

Authentication-Results: ... compauth=pass reason=130 — Header Snippet

Seeing a `reason=130` indicates the message was judged to be from an intra-organizational sender, exempting it from the harshest scrutiny. A threat actor who has compromised an internal account will sail past external checks, and this reason code is the evidence. You're no longer hunting a phish; you're hunting a compromised account.

Scoring The Gray: SCL and BCL Explained

Authentication tells you if the sender is who they claim to be. It doesn't tell you if the content is wanted. Legitimate senders can be annoying, and that's where Microsoft's scoring comes in. The `X-MS-Exchange-Organization-SCL` and `X-MS-Exchange-Organization-BCL` headers are where a lot of the magic happens, and their effects are reflected in the final action taken.

SCL: Spam Confidence Level

The Spam Confidence Level (SCL) is a rating from -1 to 9. An SCL of -1 means the message came from an internal sender or was allowed by a transport rule and bypassed all spam filtering. An SCL of 0 or 1 means filtering occurred, and the message was deemed not spam. Scores of 5 or 6 indicate spam, and a 9 flags high-confidence spam. The action taken (deliver to Inbox, Junk, or Quarantine) is directly tied to this score and your organization's configured thresholds.

When a user reports a 'missed phish', the SCL is the first place I look after `compauth`. If `compauth=pass` but the `SCL=5`, EOP likely did its job and put it in the Junk folder. The user going into their Junk, clicking the link, and then reporting it is a training issue, not a filtering failure. That context is operationally critical.

BCL: Bulk Complaint Level

The Bulk Complaint Level (BCL) is different. It measures how likely a message from a legitimate, authenticated sender is to generate complaints. Think newsletters, marketing blasts, and social media notifications. A sender might have perfect DMARC alignment, but if enough users mark their mail as spam, their BCL will rise. The scale is 0-9. A message from a brand-new sender starts at 0. As they send mail and get feedback, the score adjusts. A BCL of 4, 5, 6, or 7 is considered progressively worse, and your organization's bulk threshold determines if mail with a BCL of, say, 7 or higher is automatically sent to Junk. A high BCL on an otherwise pristine email is a strong indicator of graymail.

The Forwarding Problem and ARC's Chain of Custody

The moment an email gets forwarded, all bets are off. Classic email forwarding, mailing lists, and even some security services that process mail before delivery will break authentication. The forwarder's IP address won't be in the original sender's SPF record, causing an SPF fail. If the forwarding service adds a footer like 'Scanned for viruses by ServiceX', it modifies the message body, breaking the DKIM signature's body hash.

This is a nightmare for DMARC, which often sees both checks fail for perfectly legitimate mail. Imagine a calendar invite from a vendor that gets auto-forwarded from your old email address. It arrives broken. To solve this, the industry created the Authenticated Received Chain (ARC), specified in RFC 8617.

Reading the ARC-Seal

ARC creates a chain of trust. Each intermediary that forwards the message assesses the initial authentication results, then cryptographically signs those results along with the new message headers. When the email arrives at its final destination, the receiver can validate this chain of signatures. In Microsoft 365, you'll see three key headers: `ARC-Seal`, `ARC-Message-Signature`, and `ARC-Authentication-Results`.

The `ARC-Seal` contains the validation result for the chain. Look for `cv=none` (no previous ARC hops) or `cv=pass` (the chain is intact and valid). A `cv=fail` means the chain was tampered with and cannot be trusted. The `ARC-Authentication-Results` header will contain the original `dmarc=pass` from the first hop. Microsoft can see this, trust the ARC chain (`cv=pass`), and choose to honor the original `dmarc=pass` result, even if its own SPF and DKIM checks are now failing. This allows legitimate forwarded mail to be delivered correctly.

If you see a `compauth=fail` on what looks like a forwarded email, check for ARC headers. Their absence or a `cv=fail` status tells you the forwarding path was insecure or broken, and Microsoft was right to be suspicious.

A Practical Triage Workflow

When a suspicious email lands on your desk, resist the urge to jump straight to the sender's IP reputation or the URL payload. The headers tell the story of its delivery. Here's a decision process.

First, find the primary `Authentication-Results` header from `*.protection.outlook.com`. Read the `compauth` verdict and `reason` code. If `compauth=fail`, the game is afoot. The reason code tells you why. A `reason=2xx` or `4xx` often points to DMARC failures, misaligned DKIM, or other explicit authentication failures. Now you can dig into the `spf`, `dkim`, and `dmarc` results to see if it's a misconfiguration or a spoof.

If `compauth=pass`, but the email is clearly malicious, the `reason` code is your primary lead. Did it pass because of a transport rule (`reason=102`)? An IP allow list (`reason=109`)? Or because the sender is considered a trusted organizational contact (`reason=130`)? This directs your investigation internally.

Next, inspect the forensics headers. Look at `X-MS-Exchange-Organization-SCL` and `BCL`. If the SCL is 5 or higher, the message was likely delivered to Junk. Confirm this with the user. If the SCL is low but the BCL is high, it was probably an unwanted but technically legitimate bulk email. The `CAT` (Category) value in the `X-MS-Exchange-Organization-AuthAs` header confirms this: `SPM` for spam, `BLK` for bulk, `PHS` for phish.

Finally, if a legitimate message failed authentication, look for an ARC chain. Are there `ARC-Seal` headers? Does the final one show `cv=pass`? If so, Microsoft may have used this to override the local SPF/DKIM failures. If not, you've found a likely cause for a false positive delivery failure, usually involving a non-compliant forwarding service.

The takeaway

The `Authentication-Results` header is not a simple pass/fail stamped on an envelope. It’s the detailed inspector's report, complete with footnotes and dissenting opinions. It gives you Microsoft's final judgment (`compauth`), the evidence it used (SPF/DKIM/DMARC), the context it considered (ARC), and the factors that overrode its own logic (reason codes, transport rules).

Learning to read this header is a non-negotiable skill for anyone defending a Microsoft-centric organization. It's the fastest path to understanding not just what happened, but precisely why it happened. For particularly complex or obfuscated cases, automated tools like MailSleuth.AI can parse these intricate header blocks into a clear, actionable timeline, but the foundational knowledge of what these tags mean is indispensable.