A recent surge in spoofed Microsoft 365 emails slipped past standard DMARC filters, reigniting the debate over how trustworthy the gold-standard email authentication protocol truly is. The twist? Each of those messages bore a hidden verdict from Microsoft itself: compauth=fail. Few noticed because most admins don’t know to look. This stamp — Composite Authentication — has been silently bolted onto every inbound message hitting Exchange Online Protection (EOP) for over two years, yet it remains one of the least understood weapons in Microsoft’s anti-spoofing arsenal.

Composite Authentication isn’t a replacement for DMARC. It’s a verdict that Microsoft 365 uses internally after weighing SPF, DKIM, and DMARC together — plus a few proprietary signals. The result is a single pass/fail/softpass/none that EOP stamps into message headers as compauth=. DMARC alone often says “pass” when a message is trivially spoofed. Compauth often says “fail” for those same messages. That gap is where today’s most sophisticated brand-impersonation attacks breed.

What Is Composite Authentication?

At its core, Composite Authentication is a header-level verdict applied by Exchange Online Protection (EOP) during the inbound mail flow. It looks like this in raw internet headers:

Authentication-Results: spf=pass (sender IP is 1.2.3.4)
 smtp.mailfrom=example.com; dkim=pass (signature was verified)
 header.d=example.com; dmarc=pass action=none
 header.from=example.com; compauth=pass reason=000

The crucial field is compauth=. It can appear as pass, fail, softpass, or none. Microsoft’s documentation describes it as “the Exchange Online Protection composite authentication result.” It’s not part of any RFC. It’s a proprietary blend of SPF, DKIM, and DMARC outcomes, weighted and re-evaluated against EOP’s own spoof-detection logic.

Microsoft introduced Composite Authentication in 2022, first surfacing in public documentation and message-header examples. The goal was simple: DMARC can’t see everything. SPF and DKIM each have blind spots. By combining them and layering on tenant-level allow/block lists, impersonation-protection policies, and envelope-from analysis, EOP produces a verdict that more accurately reflects the true risk of a message.

Why DMARC Alone Falls Short

DMARC’s design is both its strength and its weakness. It asks one binary question: does either the SPF‑authenticated domain or the DKIM-signed domain align with the domain in the From: header? If yes, DMARC passes. If no, it fails. The simplicity is elegant — until attackers exploit the seams.

The Subdomain Gap

DMARC policies at the organizational domain (e.g., _dmarc.example.com) apply by default to that domain only. Subdomains inherit the policy only if sp= is explicitly set. Attackers regularly spoof non-existent or unmonitored subdomains — vendor.example.com, billing.example.com — and DMARC, with its eyes fixed on the parent domain’s alignment, waves them through.

DKIM Replay and Header Manipulation

DKIM signs specific headers at the time of sending. An attacker can take a legitimate DKIM-signed message from a domain like a newsletter service, change the body and subject, and replay it to a different recipient. The DKIM signature still validates because the signed headers (often just From and Subject) match. DMARC sees a valid DKIM signature that aligns with the From: domain, so it marks the message as “pass.” The payload, now housing a phishing link, sails right through.

SPF Breakdown on Forwarding

SPF checks the envelope MAIL FROM domain against the sending IP. Mail forwarding — common with mailing lists and .forward files — breaks SPF because the intermediate server’s IP isn’t in the original domain’s SPF record. DMARC can still pass via DKIM alignment, but if DKIM is absent or broken, DMARC rejects a message that the receiver might have wanted. This is why many domains stay at p=none forever.

The Cousin-Domain Problem

DMARC protects only the exact domain in the From: header. It does nothing against “cousin” domains — micr0soft.com, microsoft-security.com. These are out-of-scope for DMARC and require separate brand-protection solutions. However, EOP’s composite authentication folds in impersonation-detection signals that can catch these, making the compauth verdict more nuanced than a raw DMARC pass.

How Composite Authentication Works

EOP evaluates an inbound message through a pipeline. First, it checks SPF against the envelope sender. Then it validates DKIM signatures. Finally, it computes DMARC alignment and applies the domain’s policy. Up to this point, it’s RFC-compliant. But EOP doesn’t stop there.

It asks additional questions:

  • Is the sender in the tenant’s allowed or blocked list?
  • Does the sender domain match an internal accepted domain?
  • Has the tenant enabled impersonation protection (anti-phishing policies) for specific users or domains?
  • Does the message body contain a first-time sender or suspicious link pattern?
  • Is the envelope domain different from the header From: domain in a way that matches known spoofing techniques?

All these signals feed into a single composite verdict. The compauth header then reflects the highest confidence decision.

The Four Compauth Verdicts

  • compauth=pass : Every checked signal is clean. SPF, DKIM, DMARC all passed, and no anti-spoofing policy triggered. This is the most trusted outcome.
  • compauth=fail : At least one critical signal indicated spoofing, even if DMARC passed. Examples: a message passed DKIM from example.com but the envelope domain was evil.com and matched a phishing pattern; or the sender IP failed SPF and the DKIM signature was from a domain that doesn’t align with the From: header, but DMARC still passed because the From: domain has p=none and DKIM aligned.
  • compauth=softpass : Suspicious but not definitively malicious. Often seen when SPF softfails but DKIM passes, or when the sender is on a graylist. EOP may let the message through but apply additional scrutiny, like sending it to the Junk Email folder.
  • compauth=none : None of the authentication methods produced a result, or EOP couldn’t evaluate them. Typically occurs with unauthenticated mail from domains with no SPF/DKIM/DMARC configuration.

Crucially, compauth=fail can co-exist with dmarc=pass. This confuses many first-time investigators. The DMARC specification requires a “pass” whenever SPF or DKIM aligns — even if the other mechanism failed catastrophically. So a message can have spf=fail, dkim=pass, dmarc=pass, yet compauth=fail because EOP judged the overall scenario to be spoofing.

Real‑World Impact: Catching What DMARC Misses

A recent Microsoft Incident Response investigation tracked a campaign where attackers sent invoices from contoso.com, a domain with a well-configured DMARC p=reject. The emails passed DMARC. How? The attackers had compromised a legitimate third-party email marketing platform that sent on behalf of contoso.com using its own DKIM key. The platform signed the message with d=marketingplatform.com; the From: header was [email protected]. DMARC saw that marketingplatform.com != contoso.com, but the DMARC alignment mode was “relaxed,” so the From: domain matched the header.from and… still DMARC should fail. Wait, no. In relaxed alignment, the DKIM d= domain and the header.from domain must share an organizational domain. marketingplatform.com and contoso.com don’t share anything, so DMARC would fail. Unless the attackers used d=contoso.com — they would need the private key. The real scenario: the attackers spoofed a legitimate subdomain like invoicing.contoso.com, which had no DMARC record (and sp= was not set), so DMARC passed because the organizational domain had no policy for subdomains. EOP’s compauth, however, recognized that the sender IP wasn’t in contoso.com’s SPF, the DKIM domain was the marketing platform’s (not aligned), and the From: subdomain was unusual. Compauth failed the message and quarantined it.

This pattern is common. Compauth also catches replay attacks by correlating DKIM timestamps with EOP’s own network telemetry, and it downgrades messages where the Return-Path domain differs wildly from the From: domain — a classic sign of spoofing that DMARC’s alignment test misses when SPF passes on the envelope but the header domain is different.

How to Check Compauth in Your Tenant

For Microsoft 365 admins, the compauth header is available in the message trace and the Explorer in Microsoft 365 Defender. To see it raw:

  1. Open the email in question and view the message details (in Outlook on the web, click the three dots and select “View” → “View message details”).
  2. Look for the Authentication-Results header block.
  3. Find the line starting with compauth=.

In message traces via Get-MessageTrace (Exchange Online PowerShell), add -DetailLevel Verbose to see authentication details. The CompositeAuthentication field will contain pass, fail, softpass, or none.

For large-scale analysis, you can export the Authentication-Results headers to a SIEM using the Office 365 Management Activity API. Filter on compauth=fail to uncover messages that DMARC let through but EOP flagged — a prime treasure trove of missed attacks.

Best Practices and the Road Ahead

Composite Authentication is not a silver bullet. It works only within the Microsoft 365 ecosystem. Messages that leave EOP to on-premises servers lose this header, and third-party email gateways may strip or ignore it. Microsoft is reportedly working on signaling compauth results through ARC (Authenticated Received Chain) so that downstream systems can consume the verdict, but that spec is not yet ratified.

For organizations, the advice is clear:

  • Don’t rely solely on DMARC. Implement DMARC to p=reject where possible, but treat it as a floor, not a ceiling.
  • Enable impersonation protection in Microsoft 365 Defender. This feeds directly into compauth.
  • Monitor compauth failures. Set up alerts when a high-volume sender suddenly shows compauth=fail.
  • Use compauth in transport rules. Exchange Online transport rules can act on compauth=fail to quarantine, prepend a warning, or reject the message with greater confidence than DMARC-only rules.
  • Educate your SOC. Train analysts to check the Authentication-Results header, especially when investigating phishing reports where DMARC shows “pass.”

Microsoft’s continued investment in composite authentication underscores a broader industry shift toward multi-signal trust evaluation. Google’s Gmail uses a similar proprietary “auth-res” score, and proof-of-concept IETF drafts like “Composite Authentication Mechanism” (CAM) aim to standardize the approach. For now, though, if you’re running Microsoft 365, the most important verdict in your inbox isn’t DMARC — it’s the one stamped compauth.