Read composite authentication as a Microsoft result
Microsoft's compauth field is not another spelling of DMARC. It is a composite assessment using authentication and other message signals, and its interpretation belongs to Microsoft's documented processing. A message can therefore contain different-looking DMARC and composite results without the header being inherently contradictory. The correct task is to read each field, its identity context and the associated reason code before deciding what the result establishes.
This article uses Microsoft primary documentation retained on 8 November 2026. The anti-spam header page identifies a 27 July 2026 update. No original message or tenant trace was supplied, and the example below is explicitly fictional rather than a redacted header. The catalogue requires a real original-message example before operational conclusions can be released.
Keep the identities visible
Microsoft defines header.from as the visible From domain, smtp.mailfrom as the envelope MAIL FROM domain, and header.d as the DKIM signing domain when present. These fields can differ. Preserve their relationship when reading results: an SPF pass for one domain does not automatically establish alignment with the visible sender, and a DKIM pass must be associated with the signature and domain it describes. Microsoft authentication header fields
DMARC's protocol decision concerns alignment with the visible From domain under its rules. Microsoft composite authentication uses that From domain as a basis while combining SPF, DKIM, DMARC and other information. Do not replace the separate DMARC result with compauth in a compliance statement or a DNS troubleshooting conclusion. They answer related but nonidentical questions. RFC 9989 Microsoft composite fields
Interpret the result and reason together
Microsoft documents compauth values pass, fail, softpass and none, with a three-digit reason. Keep the full pair. A reason code is not an SMTP reply code, even when its digits resemble another diagnostic. Do not decode reason=130 using a generic SMTP table or infer a tenant-wide condition from one message's value. Use the current Microsoft table for the observed context. Microsoft composite authentication
The header reference describes reason 000 as explicit authentication failure with a DMARC failure and quarantine or reject policy, while 001 concerns implicit authentication failure in the documented weak or absent-policy circumstances. It describes 109 as a case where no DMARC record exists but the message would otherwise pass. These are scoped vendor definitions, not instructions to manufacture a header or proof that such a message was observed here. Microsoft reason codes
Understand bestguesspass without claiming a published policy
Microsoft's dmarc=bestguesspass label means that no DMARC TXT record exists but the message would pass if the domain had one. It must not be reported as proof that the domain published a valid DMARC policy or that the actual standard DMARC evaluation returned pass. Preserve the vendor label verbatim and explain its limited meaning. Microsoft DMARC field values
A sender reviewing such a result should still verify the actual public policy and intended authentication configuration. Do not assume that composite success removes the need for explicit domain policy or guarantees other receivers will make the same assessment. A receiver-specific heuristic or inference is not a portable replacement for the domain's published controls.
ARC and implicit signals do not rewrite the underlying facts
Microsoft documents reason 130 as a trusted ARC sealer's result overriding a DMARC failure. That can explain a composite outcome in a forwarded or mediated path, but it does not mean the underlying DMARC failure should be erased from the evidence record. Keep the original result, ARC context, reason and final handling distinguishable. Do not claim that any arbitrary ARC header is sufficient; the documented case concerns a trusted sealer. Microsoft reason 130
Similarly, Microsoft describes other implicit signals and notes that a composite failure does not directly result in blocking. The overall assessment can allow a message despite that failure, while other protection technologies can identify risk in authenticated mail. Consequently, compauth=pass is not a guarantee of inbox placement or content safety, and compauth=fail is not by itself proof of rejection. Microsoft handling explanation
Establish the header trust boundary
Obtain an authorized original message from the relevant receiver and identify which trusted system produced the results. RFC 8601 explains why Authentication-Results assertions need a trust boundary. Multiple headers can appear along a message path, and an untrusted sender can insert text that looks authoritative. Do not select whichever occurrence best matches the desired conclusion without tracing provenance. RFC 8601
Keep an untouched original for internal verification and a separate redacted explanatory copy. Changing addresses or signed content can prevent independent cryptographic revalidation, so label the copy accordingly. An annotation can preserve identity relationships for discussion, but it is not a newly verifiable original message. If the recipient needs stronger evidence, use an approved secure transfer process rather than silently widening disclosure.
Original composite-result worksheet
The following proposed worksheet makes field interpretation reproducible. It is not populated with a real message and should not be treated as a completed authentication analysis.
- Evidence origin: received-message reference, receiver, timestamp and trusted verifier.
- Visible identity: header.from and its relationship to the business sender.
- SPF: exact result, smtp.mailfrom and observed source context.
- DKIM: result for each relevant signature and corresponding header.d.
- DMARC: exact vendor field value and separately verified policy context.
- Composite: compauth value, three-digit reason and cited Microsoft definition.
- Mediation: forwarding, trusted ARC or other route evidence actually available.
- Outcome: observed handling, unsupported conclusions and next evidence needed.
Do not combine results from different messages to create a synthetic all-pass record. A successful direct-delivery sample and a forwarded failure sample can reveal a route difference, but each needs its own identity and timestamp. Preserve unknowns when a field or original message is unavailable.
Fictional example: inferred success is mistaken for policy deployment
Fictional Seabright Desk sees a hypothetical report containing dmarc=bestguesspass and compauth=pass reason=109. The proposed review explains that the documented meaning does not establish a published DMARC record. The mail owner would still inspect the actual policy and confirm the intended deployment rather than mark the domain complete from the composite result alone.
No Seabright Desk header, DNS answer or tenant result exists in this work. The values are used only to illustrate Microsoft's documented interpretation, not as fabricated verification evidence. A real analysis requires the original message and trusted source context.
The catalogue requires current Microsoft field definitions and a redacted original-message example. The definitions are source-grounded, but the original-message evidence is absent. Original evidence, human SME, source applicability, production routes, visual accessibility and owner release remain open. This draft is an interpretation guide, not a verified tenant assessment.