Microsoft 365 compauth=fail: What the Reason Codes Mean and How to Fix Them

Quick answer

compauth is Microsoft 365's composite authentication verdict. It is stamped in the Authentication-Results header of inbound mail and combines SPF, DKIM and DMARC with other signals to decide whether the domain in the visible From: address is authenticated. compauth=fail means Microsoft 365 couldn't confirm that domain; the three-digit reason= code says why.

A compauth failure on its own doesn't block a message. Microsoft 365 weighs it with the rest of the message, and spoof intelligence and the anti-phishing policy decide what happens. To make it go away for a legitimate sender:

1. Give every service that sends as the From domain an aligned SPF or DKIM pass: DKIM signing with that domain, or a MAIL FROM (return-path) under it.
2. Publish SPF, DKIM and DMARC for the domain, so it is checked explicitly instead of by inference.
3. If your MX points to another filter or to on-premises servers first, turn on Enhanced Filtering for Connectors. For forwarders and services that modify mail, add them as trusted ARC sealers.
4. Use a spoofed-sender allow entry in the Tenant Allow/Block List only as a last resort, for a sender you can't get fixed.

What composite authentication is

Many sending domains on the internet still don't publish strong SPF, DKIM and DMARC records, so Microsoft 365 uses implicit email authentication for inbound mail. It extends the regular (explicit) SPF, DKIM and DMARC checks with signals such as sender reputation, sender history, recipient history and behavioral analysis. The combined result is the compauth value, and it uses the From domain as the basis of evaluation.

Microsoft describes three layers:

1. Composite authentication passes: the message is delivered normally.
2. Spoof intelligence looks at mail-flow patterns and the history of the sending infrastructure. If it identifies the sender as legitimate, the message is delivered.
3. If spoof intelligence flags the sender as suspicious, the anti-phishing policy action applies (move to the Junk Email folder or quarantine).

Explicit DMARC failures from domains with p=quarantine or p=reject are handled by the anti-phishing policy setting Honor DMARC record policy when the message is detected as spoof. Turning spoof intelligence off disables only the implicit protection from composite authentication.

Read the Authentication-Results header

Open the message source (in Outlook: File > Properties, or View message source in Outlook on the web) and paste the headers into the Email Header Analyzer. Microsoft 365 writes a line like this one, adapted from Microsoft's own example:

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

In the example, SPF and DKIM both passed, but for the vendor's domains, not example.com. DMARC failed for lack of alignment, the sender's policy is reject, and compauth failed with reason 000.

The X-Forefront-Antispam-Report header adds context: CAT:SPOOF marks a spoofing verdict, SFTY:9.11 intra-org spoofing and SFTY:9.22 cross-domain spoofing. The DIR field shows INB, OUT or INT for inbound, outbound or internal.

compauth result values

Microsoft also documents 501 and 502 (DMARC not enforced for valid bounce messages) without tying them to one of these results.

compauth reason codes

These are the codes Microsoft documents in its anti-spam message headers reference. For a code that isn't listed, the range row (1xx, 2xx, 3xx, 4xx, 6xx, 7xx, 9xx) is the only documented meaning.

Fix reason 000: the sender's SPF and DKIM aren't aligned

Reason 000 is an explicit failure: the From domain publishes an enforcing DMARC policy and the message didn't pass it. The usual cause is a service sending as the domain with its own identities. Microsoft's example is a partner whose marketing platform sends From: sender@fabrikam.com with MAIL FROM bounces@adatum.com and a DKIM signature for adatum.com. SPF and DKIM both pass for adatum.com, DMARC fails because neither aligns with fabrikam.com, and compauth fails. Email marketing platforms, cloud email gateways and relay or shared hosting services are the common sources.

The fix belongs to the owner of the From domain (you, or the partner):

• Turn on DKIM signing with the From domain at the service (custom DKIM or domain authentication). One aligned DKIM pass is enough.
• Or set a custom MAIL FROM (return-path) under the From domain and authorize the service in that domain's SPF record.
• Or move the service to its own subdomain, such as marketing.example.com, with its own SPF and DKIM.

The DMARC fail with SPF pass guide walks through alignment in detail. If dkim=fail (body hash did not verify) appears, something changed the message after signing; see how to fix DKIM body hash did not verify.

Fix reason 001: implicit failure (no records or weak policy)

Reason 001 shows up when the From domain has no SPF, DKIM or DMARC, or only ~all, ?all or p=none, and Microsoft's implicit signals didn't vouch for the sender. Microsoft's examples show both sides: a domain with no records fails with 001, while the same domain with an SPF pass for the From domain, or an aligned DKIM signature, can pass as dmarc=bestguesspass with compauth=pass reason=109.

1. Check the domain with the SPF Record Checker, DKIM Checker and DMARC Record Checker.
2. Publish SPF listing every known source. Microsoft suggests starting with ~all while you find the rest, then moving to -all.
3. Set up DKIM signing, then DMARC with reporting so you can see every source.

If it is someone else's domain, ask them to do this. As the recipient you can only work around it, with spoof intelligence or an allow entry (see the last resort below).

Fix 6xx, 601 and 010: intra-org spoofing

These codes mean the From domain is one of your accepted domains, but the message came in from outside without authenticating as you: 601 (and the 6xx range) for an implicit failure, 010 when your own DMARC policy is quarantine or reject. Microsoft counts mail between your accepted domains, and between subdomains of the same domain, as intra-org too. The X-Forefront-Antispam-Report header shows SFTY:9.11.

Legitimate causes are usually an app, scanner, website form or SaaS tool sending as your domain straight to your MX. Find the source IP in the route of the Email Header Analyzer, then either authorize it in your SPF record or have it DKIM-sign with your domain. Mail sent from a Microsoft 365 organization where the From domain is an accepted domain is listed as a pass (reason 115), so sending through your tenant instead of straight to your MX is one way to avoid it, if the device supports that. If the source is unknown, treat it as a real spoofing attempt.

Fix reason 002: an admin block

Reason 002 isn't an authentication problem: someone in your organization blocked that sender/domain pair from spoofing. Check the block entries on the Spoofed senders tab of the Tenant Allow/Block Lists page in the Microsoft Defender portal, and remove the entry if it was a mistake.

Fix gateways, on-premises routing and forwarders

When your MX points to a non-Microsoft filter, a filtering appliance or on-premises Exchange, Microsoft 365 sees the IP of the last hop in front of it, not the real sender. SPF is checked against the gateway's IP address, so it fails for most senders, and a gateway that rewrites links or adds banners breaks DKIM. Reason 905 (DMARC not enforced because of complex routing) is a sign of this.

• Enhanced Filtering for Connectors (also called skip listing) on the inbound connector preserves the original source IP and sender information, recovers from DKIM failures, and switches domain authentication from implicit to explicit SPF, DKIM and DMARC. Find it in the Defender portal under Email & Collaboration > Policies & Rules > Threat policies > Enhanced filtering. Choose Automatically detect and skip the last IP address, or list the gateway's public IP addresses. Microsoft 365 IP addresses, loopback and RFC 1918 private ranges aren't supported. After you enable it, disable mail flow rules that set SCL -1 for that connector. Headers then carry X-MS-Exchange-ExternalOriginalInternetSender.
• With the MX pointed elsewhere, the Honor DMARC record policy setting applies only when Enhanced Filtering is on for the inbound connector, and Microsoft 365 doesn't send DMARC aggregate reports.
• Trusted ARC sealers help when a legitimate service modifies mail before it reaches Microsoft 365 (forwarders, mailing lists, gateways that support ARC). Add the sealer's domain, the d= value from the ARC-Seal header, in the Defender portal or with Set-ArcConfig -Identity Default -ArcTrustedSealers. That parameter replaces the whole list, so include the existing sealers too. A pass through a trusted sealer shows as reason 130.

Last resort: allow the spoofed sender

For a legitimate sender you can't get fixed, create an allow entry on the Spoofed senders tab of the Tenant Allow/Block List (or override the verdict in the spoof intelligence insight). An entry is a domain pair:

• Spoofed user: the From address or domain, or *.
• Sending infrastructure: the domain in the source IP's PTR record, the source IP as /24 if it has no PTR record, a verified DKIM domain, or *.

New-TenantAllowBlockListSpoofItems -Identity Default -Action Allow -SpoofedUser bob@contoso.com -SendingInfrastructure contoso.com -SpoofType External

Only that exact pair is allowed to spoof, the limit is 1,024 spoofed-sender entries (allow and block combined), and the entries never expire, so review them. Microsoft calls this the short-term resolution; the long-term one is fixing the sender's SPF and DKIM. Avoid allowed sender and allowed domain lists in anti-spam policies: those senders bypass most of the filtering stack.

Verify the fix

1. Send a new message through the same path and paste its headers into the Email Header Analyzer. Look for compauth=pass with a 1xx reason, ideally 100, 101 or 102, and dmarc=pass.
2. Confirm the From domain's records with the DMARC Record Checker, the DKIM Checker and the SPF Record Checker.
3. Still dmarc=fail with spf=pass or dkim=pass? It's alignment: follow how to fix DMARC fail with SPF pass.
4. For your own domain, watch a week of aggregate reports in the DMARC Report Analyzer to catch every source still failing.

Audit hundreds of domains at once

Need SPF, DMARC and MX checks across a whole client list? Run the Bulk SPF / DMARC / MX Auditor on Apify ($2 per 1,000 domains).

Related tools and guides

Decode Authentication-Results, compauth and the spam headers with the Email Header Analyzer, check the sender with the SPF Record Checker, DKIM Checker and DMARC Record Checker, audit a domain in one pass with the Email Deliverability Checker, and see every source in the DMARC Report Analyzer. Related guides: DMARC fail with SPF pass (alignment), DKIM body hash did not verify, DMARC for Microsoft 365 and SPF for Microsoft 365.

FAQ

What does compauth=fail mean in Microsoft 365?

Composite authentication (compauth) is the verdict Microsoft 365 stamps in the Authentication-Results header after combining SPF, DKIM, DMARC and its own implicit signals for the From domain. compauth=fail means it could not confirm the From domain, and the reason code says why: 000 is an explicit DMARC failure, 001 an implicit failure, 6xx intra-org spoofing.

Does compauth=fail mean the message was blocked?

No. Microsoft says a composite authentication failure does not directly block a message. Spoof intelligence and the anti-phishing policy decide: the message may be delivered, moved to Junk Email or quarantined. Failures for p=reject domains can be rejected when the Honor DMARC record policy setting is on.

Why does compauth fail with reason 001 when the sender has no DMARC record?

Reason 001 is an implicit failure: the sending domain has no SPF, DKIM or DMARC records, or only weak ones such as ~all, ?all or p=none, and Microsoft could not otherwise vouch for it. An SPF or DKIM pass for the From domain itself can turn this into dmarc=bestguesspass with compauth=pass reason=109.

What does compauth reason 601 mean?

Reason 601 (part of the 6xx range) means intra-org or self-to-self spoofing: the From domain is one of your accepted domains, but the message arrived from outside without authenticating as you. Authorize the real source in SPF or have it DKIM-sign with your domain, or treat it as an attack if the source is unknown.

Should I add a Tenant Allow/Block List entry for a spoofed sender?

Only as a last resort. An allow entry lets one spoofed user and sending infrastructure pair through, and spoofed-sender entries never expire. Fix SPF and DKIM at the source first, use Enhanced Filtering for Connectors for your own gateways, and trusted ARC sealers for services that modify mail.

Want the full kit?

Runbooks, checklists and helpdesk templates: IT Admin Packs on Gumroad.