If you troubleshoot mail into Microsoft 365 long enough, you eventually hit a header that makes the normal SPF, DKIM, and DMARC story feel incomplete:
Authentication-Results: ... compauth=pass reason=130Or this one:
Authentication-Results: ... dmarc=fail action=none header.from=example.com; compauth=pass reason=109Or the opposite:
Authentication-Results: ... spf=pass; dkim=pass; compauth=fail reason=001That is the point where many admins realize Microsoft is evaluating more than the three familiar acronyms alone.
In Microsoft 365, compauth means composite authentication. Microsoft combines regular authentication results with other signals to decide whether the message looks legitimate, spoofed, or trustworthy enough to treat gently. Microsoft Learn explicitly says this evaluation can include SPF, DKIM, DMARC, sender reputation, sender history, recipient history, behavioral analysis, and other advanced techniques.
So if a message verdict feels odd, compauth is often the missing layer.
compauth is Microsoft's combined authentication verdict for inbound mail. The reason= value explains why Microsoft 365 marked the message as pass, softpass, fail, or none.
The practical meaning is this:
compauth=pass does not always mean DMARC passedcompauth=fail does not always mean the message will be blockedIf you only read spf=, dkim=, and dmarc=, you can miss the real explanation for Microsoft's final handling.
Microsoft documents the current reason code table in its Anti-spam message headers, Email authentication, and SecOps guide for email authentication pages.
compauth is really doingDMARC is standards-based and relatively strict: either aligned SPF or aligned DKIM passes, or DMARC fails.
Microsoft's compauth layer is different. It tries to answer a more operational question:
given the full context of this message, should Microsoft treat the sender identity as trustworthy, suspicious, or inconclusive?
That is why messages can land in combinations that surprise people:
compauth passes because ARC from a trusted sealer preserved trustworthy original authenticationcompauth passes because the message still aligns well enough with SPF or DKIM for Microsoft to accept it implicitlyFrom: identityIf this sounds close to the broader point in Why DMARC passes at one provider and fails at another, that is because it is. Microsoft is one of the clearest examples of a receiver applying a local trust model on top of the standards.
compauth result familiesMicrosoft stamps one of four top-level values:
compauth=passMicrosoft decided the message authenticated strongly enough overall.
This can happen because:
compauth=softpassMicrosoft saw some legitimacy signals, but not enough for a full confident pass.
This usually appears with the 2xx reason family and often points to weaker implicit trust, such as PTR-domain relationships rather than strong explicit standards-based alignment.
compauth=failMicrosoft concluded the sender identity was not trustworthy enough.
That might be because:
Important detail: Microsoft says a compauth failure does not automatically mean the message is blocked. Other filtering layers still matter.
compauth=noneComposite authentication was not checked or was bypassed.
This usually appears in the 3xx, 4xx, or some 9xx situations, where another routing or policy condition made normal composite evaluation irrelevant.
Microsoft publishes many codes, but a smaller subset explains most real troubleshooting cases.
reason=000This is the straightforward hard-fail case.
Microsoft says 000 means the message failed explicit authentication and received a DMARC fail where the policy action is p=quarantine or p=reject.
Operationally, read this as:
If you see 000, start with ordinary DMARC troubleshooting: compare header.from, smtp.mailfrom, and header.d, then fix alignment. If you want a refresher, DMARC troubleshooting with real headers and Return-Path vs From cover that workflow.
reason=001This is one of the most useful and misunderstood codes.
Microsoft says 001 means the message failed implicit authentication because the sending domain had no published authentication records, or only weak policy such as SPF ~all, SPF ?all, or DMARC p=none.
This matters because it explains a common admin reaction:
“But SPF passed” or “DKIM passed”
That can still coexist with compauth=fail reason=001 if the pass does not actually support the visible From: identity strongly enough, or if the overall sender posture remains too weak for Microsoft to trust.
In other words, 001 often means the standards did not fail in the simplest binary sense, but the sender still did not look convincingly authenticated.
Typical causes:
p=noneFrom:From:reason=010Microsoft documents 010 as a DMARC-fail situation with p=reject or p=quarantine where the sending domain is one of your organization's accepted domains.
This is the self-spoofing or intra-org spoofing case.
When you see 010, do not treat it like an ordinary third-party deliverability issue. Treat it as one of these instead:
reason=109This is the code that often makes people say “wait, DMARC passed even though there is no DMARC record?”
Strictly speaking, Microsoft says 109 means the sender's domain has no DMARC record, but the message would pass anyway.
You will often see this with dmarc=bestguesspass rather than an actual policy-backed DMARC pass.
The right interpretation is:
If you own the domain, fix it by publishing a real DMARC record. DMARC policy modes explained is a good companion if the sticking point is rollout policy.
reason=111 and reason=112These two are easy to overread.
Microsoft says:
111: despite a DMARC temp/permanent error, SPF or DKIM aligns with the From: domain112: a DNS timeout prevented the DMARC record from being retrievedThese codes tell you the message outcome may reflect DNS retrieval trouble, not a clean sender-side authentication design.
If 111 appears repeatedly, verify the DNS health and syntax of the sender's DMARC record anyway. If 112 appears repeatedly for the same domains, suspect lookup instability, timeouts, or infrastructure in front of Microsoft that complicates retrieval.
reason=115Microsoft says 115 means the message was sent from a Microsoft 365 organization where the From: domain is configured as an accepted domain.
This tends to show up in Microsoft-native flows where Microsoft has a strong platform-level basis to trust the sender identity.
It is less about “what exact public DMARC evidence convinced the receiver?” and more about “Microsoft knows this domain belongs to a tenant sending through expected Microsoft 365 paths.”
reason=130This is the famous ARC override case.
Microsoft says 130 means the ARC result from a trusted ARC sealer overrode the DMARC failure.
This is the code to look for when:
If you are dealing with secure email gateways, list expanders, or forwarding services, 130 often tells the whole story. Microsoft documents this behavior in Configure trusted ARC sealers.
For broader background, see What is ARC and how does it work? and Trusted ARC sealers at mailbox providers.
reason=501 and reason=502These are special-case NDR or bounce scenarios.
Microsoft says:
501: DMARC was not enforced because the message is a valid NDR and sender-recipient contact is previously established502: DMARC was not enforced because the message is a valid NDR for mail sent from this organizationIf you are looking at DSNs, bounces, or null return-path traffic, these codes matter a lot. Regular DMARC expectations do not map cleanly onto that traffic class. That is exactly why DMARC for NDRs, DSNs, and auto-replies exists.
reason=601Microsoft says 601 means the sending domain is an accepted domain in your organization, again pointing to self-to-self or intra-org spoofing.
Think of 601 as another “this is your own domain problem, not an outside sender problem” flag.
reason=701 to 704These are easy to miss, but they explain a lot of “why did Microsoft still let this through?” incidents.
Microsoft says these codes mean DMARC was not enforced because the recipient organization has a history of receiving legitimate messages from the sending infrastructure.
This is one of the clearest examples of Microsoft applying local trust on top of standards. The message might not satisfy the kind of strict textbook expectation an admin has in mind, but Microsoft has enough historical confidence in the infrastructure to avoid treating it as straightforward spoofing.
That is useful to know diagnostically, but it should not be read as permission to leave the sender misconfigured. Receiver trust history is not portable across providers.
reason=905Microsoft says 905 means DMARC was not enforced because of complex routing, for example when internet mail passes through on-premises Exchange or a non-Microsoft service before reaching Microsoft 365.
This is a big one for hybrid and gateway-heavy environments.
If you see 905, ask these questions immediately:
When admins say “the sender is fine but Microsoft is doing something weird,” 905 often turns out to mean your routing topology is part of the authentication result.
compauth without fooling yourselfThe safest reading order is:
header.from= first because Microsoft says compauth uses the visible From: domain as its basisspf=, smtp.mailfrom=, dkim=, and header.d=dmarc= and the DMARC action=compauth= and reason= as Microsoft's final interpretation layerThat order matters because compauth is not a replacement for the underlying evidence. It is Microsoft's summary of how that evidence should be interpreted in context.
dmarc=fail but compauth=pass reason=130Interpretation: forwarding or message modification likely broke normal authentication, and ARC from a trusted sealer preserved enough trust to rescue the message.
dmarc=bestguesspass and compauth=pass reason=109Interpretation: the sender has no DMARC record, but SPF or DKIM behavior still gives Microsoft enough confidence to treat the message as implicitly acceptable.
Fix: publish real DMARC anyway.
spf=pass, dkim=pass, but compauth=fail reason=001Interpretation: do not celebrate the raw passes too early. Check whether the authenticated domains actually support the visible From: identity. This is often an alignment or spoofing-context problem, not a missing-check problem.
compauth=none reason=905Interpretation: complex routing or a non-standard path made Microsoft's normal composite-auth logic less applicable. Investigate the recipient-side mail path, not just the sender's DNS.
compauth=fail reason=010 or 601Interpretation: Microsoft thinks this is spoofing involving one of your own accepted domains. Look inward first.
compauth does not tell you by itselfcompauth is useful, but it is not magic.
It does not, by itself, tell you:
So always pair compauth with the rest of the header and the surrounding mail flow.
When a Microsoft 365 result feels contradictory, use this order:
From: domain you are actually trying to authenticatecompauth and reasonThat order prevents a lot of wasted time.
Microsoft 365 compauth reason codes exist because real inbound mail is messier than a pure SPF/DKIM/DMARC checklist.
If you remember only one thing, make it this: compauth is Microsoft's explanation of how it interpreted the message identity after looking beyond the bare standards results.
That means:
000 and 001 usually explain why Microsoft was not persuaded109 explains why a sender with no DMARC record still got some trust130 explains why ARC changed the story501 and 502 explain why NDR traffic is special701 to 704 explain why prior good history can matter905 explains why complex routing can change the evaluation entirelyOnce you start reading those codes as context clues rather than mysterious verdicts, Microsoft header analysis gets much easier.