Microsoft 365 Exchange Online Protection (EOP) and Microsoft Defender for Office 365 (MDO) rely on well-established email authentication mechanisms such as SPF, DKIM, DMARC, and ARC to evaluate incoming messages. These technologies enable the platform to assess sender legitimacy at an early stage and, in some cases, block messages before performing any deeper content analysis. This approach reflects a standard and widely adopted security model.
However, when we examine DMARC results more closely, we notice an interesting behavior: some messages that return a DMARC FAIL result still reach a Microsoft 365 tenant. In many cases, these messages originate from legitimate sources and do not represent malicious activity. This observation raises an important question: how does Microsoft handle DMARC failures, and why does the platform allow certain messages with a DMARC FAIL status to pass through?
This article explores that question by presenting several real-world examples and explaining the underlying decision process. In particular, we highlight the role of Composite Authentication (COMPAUTH), a mechanism that evaluates multiple authentication signals together. COMPAUTH enables Microsoft 365 to make more nuanced trust decisions and helps administrators avoid adding complex or environment-specific exceptions within EOP anti-spam policies.
Case of an out-of-office (OOF) and automatic reply emails
An out-of-office (OOF) or automatic reply email uses an empty envelope sender (MAIL FROM). This behavior follows standard email protocol requirements for automatic responses and prevents mail loops.
As a result, the message presents a mismatch between the envelope sender and the header sender (From address). This difference breaks domain alignment requirements defined by DMARC. Consequently, DMARC alignment fails by design for this type of message.
Case of application emails with envelope from and mime from different or mail with send on behalf
Some SaaS applications send emails on behalf of their customers or use a specific sender address, such as an address associated with an incident or ticket number. In these scenarios, the application sets the envelope sender (MAIL FROM) independently from the header sender (From address). As a result, the envelope sender and the MIME From address often belong to different domains.
This configuration breaks DMARC alignment requirements and leads to a DMARC FAIL result. In this context, COMPAUTH plays a key role by evaluating multiple authentication signals together. It allows Microsoft 365 to recognize legitimate messages even when strict DMARC evaluation would reject them.
Here are some samples or emaila with SOB, DMARC FAIL or BESTGUESSPASS and COMPAUTH PASS.
Composite Authentication values and raison codes
As a consequence, when you analyze an incoming email in Microsoft 365, you need to review the Composite Authentication (COMPAUTH) result carefully.
COMPAUTH provides several possible values, and for each value, a reason code explains the logic behind the evaluation. These reason codes help you understand why the platform assigns a given trust level to a message.
COMPAUTH can also return a value of NONE. In this situation, it does not influence the acceptance or rejection of the message, and the platform relies on other signals instead.
The two sections below list the possible COMPAUTH values and the associated reason codes. They come directly from Microsoft documentation (see the following link: https://learn.microsoft.com/en-us/defender-office-365/email-authentication-about). They help you understand why Microsoft 365 can accept some messages that show a DMARC FAIL result.
COMPAUTH Values
| COMPAUTH Value | Description | Microsoft 365 Interpretation | Recommended Action |
|---|---|---|---|
| PASS | The message successfully passed Composite Authentication. | Microsoft 365 determined that the message is trustworthy based on authentication results (SPF, DKIM, DMARC) and additional reputation and anti-spoofing signals. | No action required. Continue monitoring authentication compliance. |
| SOFTPASS | The message received a partial trust verdict. | Some authentication signals may be missing or weak, but Microsoft still considers the message acceptable based on reputation or other implicit trust indicators. | Review SPF, DKIM, and DMARC configuration to strengthen email authentication and improve deliverability. |
| FAIL | The message failed Composite Authentication. | Microsoft 365 considers the message potentially spoofed, fraudulent, or high-risk. The message may be delivered to Junk Email, quarantined, or subjected to additional filtering. | Investigate SPF, DKIM, DMARC alignment, sender reputation, forwarding scenarios, and ARC configuration. |
| NONE | No Composite Authentication evaluation was performed. | Microsoft 365 did not generate a COMPAUTH verdict for the message. Delivery decisions rely on other security mechanisms such as SPF, DKIM, DMARC, anti-spam, anti-phishing, and reputation checks. |
COMPAUTH Raison Codes
| Reason code | Compauth Result | Description |
|---|---|---|
| 000 | FAIL | The message failed explicit authentication (compauth=fail). The message received a DMARC fail and the DMARC policy action is p=quarantine or p=reject. |
| 001 | FAIL | The message failed implicit authentication (compauth=fail). The sending domain didn’t have email authentication records published, or if they did, they had a weaker failure policy (SPF ~all or ?all, or a DMARC policy of p=none). |
| 002 | FAIL | The organization has a policy for the sender/domain pair that’s explicitly prohibited from sending spoofed email. An admin manually configures this setting. |
| 010 | FAIL | The message failed DMARC, the DMARC policy action is p=reject or p=quarantine, and the sending domain is one of your organization’s accepted domains (self-to-self or intra-org spoofing). |
| 1xx | PASS | The message passed explicit or implicit authentication (compauth=pass). |
| 100 | PASS | SPF passed or DKIM passed and the domains in the MAIL FROM and From addresses are aligned. |
| 101 | PASS | The message was DKIM signed by the domain used in the From address. |
| 102 | PASS | The MAIL FROM and From address domains were aligned, and SPF passed. |
| 103 | PASS | The From address domain aligns with the DNS PTR record (reverse lookup) associated with the source IP address |
| 104 | PASS | The DNS PTR record (reverse lookup) associated with the source IP address aligns with the From address domain. |
| 108 | PASS | DKIM failed due to a message body modification attributed to previous legitimate hops. For example, the message body was modified in the organization’s on-premises email environment. |
| 109 | PASS | Although the sender’s domain has no DMARC record, the message would pass, anyway. |
| 111 | PASS | Despite a DMARC temporary error or permanent error, the SPF or DKIM domain aligns with the From address domain. |
| 112 | PASS | A DNS timeout prevented the DMARC record from being retrieved. |
| 115 | PASS | The message was sent from a Microsoft 365 organization where the From address domain is configured as an accepted domain. |
| 116 | PASS | The MX record for the From address domain aligns with the PTR record (reverse lookup) of the connecting IP address. |
| 130 | PASS | The ARC result from a trusted ARC sealer overrode the DMARC failure. |
| 2xx | SOFTPASS | The message soft-passed implicit authentication (compauth=softpass). |
| 201 | SOFTPASS | The PTR record for the From address domain aligns with the subnet of the PTR record for the connecting IP address. |
| 202 | SOFTPASS | The From address domain aligns with the domain of the PTR record for the connecting IP address. |
| 3xx | NONE | The message wasn’t checked for composite authentication (compauth=none). |
| 4xx | NONE | The message bypassed composite authentication (compauth=none). |
| 501 | NONE (*) | DMARC wasn’t enforced. The message is a valid non-delivery report (also known as an NDR or bounce message), and contact between the sender and recipient is previously established. |
| 502 | NONE (*) | DMARC wasn’t enforced. The message is a valid NDR for a message sent from this organization. |
| 6xx | FAIL | The message failed implicit email authentication (compauth=fail). |
| 601 | FAIL | The sending domain is an accepted domain in your organization (self-to-self or intra-org spoofing). |
| 7xx | PASS | The message passed implicit authentication (compauth=pass). |
| 701-704 | PASS | DMARC wasn’t enforced because this organization has a history of receiving legitimate messages from the sending infrastructure. |
| 9xx | PASS | The message bypassed composite authentication (compauth=none). |
| 905 | PASS | DMARC wasn’t enforced due to complex routing. For example, internet messages are routed through an on-premises Exchange environment or a non-Microsoft service before reaching Microsoft 365. |
By Lionel TRAVERSE
Microsoft 365 Certified / MVP Microsoft 365 & Graph