How to fix compauth failure in email headers due to domain alignment issues?
Published 22 Jun 2025
Updated 19 Aug 2026
13 min read
Summarize with
Updated on 19 Aug 2026: We clarified Microsoft's compauth reason codes, added connector-aware diagnostics, and covered cases where standard authentication passes but composite authentication still fails.
To fix a domain-alignment problem reported with compauth=fail reason=001, make sure at least one domain that authenticated the message has DMARC alignment with the visible From domain. In practice, that means enabling branded DKIM for the sender's domain, using a custom bounce or MAIL FROM domain under the same organizational domain, and publishing a DMARC record for the visible From domain. Reason 001 identifies an implicit authentication failure, so also check for missing authentication records, SPF ending in ~all or ?all, and DMARC at p=none.
The key point is that SPF passing is not enough when it passes for the wrong domain. DMARC passes when SPF or DKIM passes and that authenticated domain matches the visible From domain under the domain matching mode in use. For transactional mail, branded DKIM is usually the first fix because a DKIM signature survives forwarding better than SPF and is easier to keep stable across sending infrastructure.
A published DKIM DNS key does not prove the message was signed. The message header must include a DKIM-Signature header with a d= value that has DMARC alignment with the visible sender domain. An exact domain match is required only when adkim=s is in use. If Microsoft reports dkim=none, the sender did not sign that specific message.
What compauth failure means
Microsoft 365 writes compauth into the Authentication-Results header after it combines SPF, DKIM, DMARC, spoof intelligence, and other Microsoft 365 signals. Microsoft defines reason 001 as an implicit authentication failure. It commonly appears when the sending domain has no authentication records or uses a weak failure policy such as SPF ~all or ?all, or DMARC p=none. The Microsoft 365 guide explains how Microsoft evaluates sender identity.
A compauth failure is not the same as an automatic block. It is a receiver-side signal. Microsoft can still deliver the email if the message has low risk in other filters, and Microsoft can still quarantine mail that passes one authentication check if the sender looks suspicious. Treat compauth=fail as a header diagnosis, not as the full delivery verdict.
Microsoft's Microsoft troubleshooting page separates SPF, DKIM, DMARC, and composite authentication failures. That distinction matters because a message can fail compauth after a domain mismatch, missing DKIM, an enforced DMARC policy, a spoof intelligence decision, or a gateway path that changed the message after signing.
|
|
|
|---|---|---|
compauth | Microsoft composite result | Find the failed identity proof |
reason 001 | Implicit auth failure | Publish stronger aligned auth |
reason 000 | Explicit DMARC enforcement failure | Fix aligned SPF or DKIM |
reason 002 | Sender pair explicitly blocked | Review tenant spoof settings |
reason 010 | Accepted-domain DMARC failure | Check self-to-self spoofing |
spf pass | MAIL FROM passed | Check its domain against From |
dkim none | No message signature | Turn on branded DKIM |
dmarc bestguesspass | No record, but message would pass | Publish a DMARC record |
dmarc none | No policy found | Publish a DMARC TXT record |
Compact reading of the relevant header fields.
Why SPF passed but compauth failed
The common confusing case looks like this: SPF passes for the envelope sender domain, but that domain belongs to the hosting provider or email vendor. The user sees a different visible From address. DKIM is absent or signed with the vendor's domain. DMARC has no matching SPF or DKIM result to use, so Microsoft treats the sender identity as weak.
Header pattern that triggers the issuetext
Authentication-Results: spf=pass smtp.mailfrom=mail01.vendor.example; dkim=none header.d=none; dmarc=none action=none header.from=example.com; compauth=fail reason=001 From: Example App <receipts@example.com> Return-Path: <bounces@mail01.vendor.example>
In that header, SPF tells Microsoft that the vendor infrastructure is allowed to send for the vendor bounce domain. It does not prove that example.com authorized the visible From address. If the message also has dkim=none, there is no DKIM fallback for DMARC to use.
Broken pattern
- SPF passes for a vendor-controlled MAIL FROM domain.
- DKIM is missing, unsigned, or signed with a vendor domain only.
- DMARC has no authenticated domain that matches the visible From domain.
- Microsoft can record compauth failure even though SPF says pass.
Fixed pattern
- SPF passes for a branded MAIL FROM domain you control.
- DKIM signs with the visible sender's domain or an eligible subdomain.
- DMARC finds SPF or DKIM evidence tied to the From domain.
- Microsoft has a stronger sender identity signal.
Compauth failure diagnosis flow for From, SPF, DKIM, DMARC, and Microsoft header results.
The exact fix
Fix the domain mismatch at the identity that users actually see: the visible From address. Do not start by adding records to the vendor's infrastructure domain unless the vendor also uses that domain in the visible From address. For a normal transactional sender, the fix is a short sequence.
- Confirm the visible From domain, the Return-Path domain, and the DKIM d= domain in the same delivered message.
- Enable branded DKIM so every message signs with the visible From domain or an eligible subdomain.
- Delegate DKIM with CNAME records when the provider rotates keys or manages hosted signing.
- Set a custom MAIL FROM or return-path domain such as bounce.example.com rather than a vendor domain.
- Publish a DMARC record to the visible From domain, starting at p=none while you verify sources.
- Check whether strict SPF or DKIM matching is enabled before using subdomains for mail streams.
- Retest by sending a new message to a Microsoft mailbox and inspecting the fresh delivered header.
Minimum DNS records to request or publishdns
selector1._domainkey.example.com. 3600 IN CNAME selector1.vendor.net. bounce.example.com. 3600 IN CNAME bounce.vendor.net. _dmarc.example.com. 3600 IN TXT ( "v=DMARC1; p=none; " "rua=mailto:dmarc@example.com; pct=100" )
DMARC uses relaxed alignment by default. With relaxed SPF matching, bounce.example.com can match example.com because they share the same organizational domain. Strict mode with aspf=s or adkim=s requires an exact domain match, so it breaks more third-party sender setups unless every stream uses the same domain.
Those records are examples. Your provider should give you the real DKIM selector, destination host, and return-path target. If you do not control DNS for the visible From domain, you cannot fully fix this for that From domain. The practical choices are to get DNS access, use a subdomain whose DNS you control, or change the visible From address to a domain you can authenticate.
Healthier header pattern after the fixtext
Authentication-Results: spf=pass smtp.mailfrom=bounce.example.com; dkim=pass header.d=example.com; dmarc=pass action=none header.from=example.com; compauth=pass reason=100 From: Example App <receipts@example.com> Return-Path: <bounces@bounce.example.com>
What to ask your provider
When a provider sends transactional mail for multiple customer domains, ask for customer-specific authentication. A provider-side DKIM key on its own domain does not fix your visible From domain. The provider needs to sign on behalf of your domain and support a branded bounce domain.
A clear provider request is: "Please enable branded DKIM for example.com, provide the DKIM CNAME or TXT record, configure a custom MAIL FROM or return-path domain under example.com, and confirm that new messages include a DKIM signature with a d= domain that has DMARC alignment with example.com."
If the provider says the domain already has a DKIM key, ask for a fresh delivered header. A DNS record can exist while the message is still unsigned. That is why the header is the source of truth. DNS tells you what can work. The delivered header tells you what actually happened.
Microsoft Defender message details with SPF, DKIM, DMARC, compauth fail, and reason 001 results.
When forwarding or gateways are involved
If the same sender passes authentication at one receiver but fails compauth in Microsoft 365, inspect the path between the internet and the Microsoft mailbox. Forwarding, relays, and gateways can change which IP Microsoft sees, which MAIL FROM domain SPF evaluates, and whether the original DKIM body hash still verifies.
A typical gateway failure has SPF pass for the gateway domain, DKIM fail after body or header modification, and DMARC fail because neither authenticated domain matches the visible From domain. In that case, adding another SPF include to the From domain does not fix the message path by itself.
- Use ARC when a trusted forwarding or gateway path needs to preserve original authentication results.
- Configure the gateway to avoid changing signed headers or message bodies after DKIM signing.
- Re-sign with branded DKIM after any required modification, so Microsoft sees a valid final signature.
- Use Enhanced Filtering for Connectors when inbound internet mail reaches Microsoft 365 through a non-Microsoft filter, appliance, or supported linear hybrid route.
- Compare the header at initial receipt with the header delivered to Microsoft before changing policy.
Enhanced Filtering for Connectors, also called skip listing, lets Microsoft recover the original source IP and sender information instead of evaluating only the last gateway hop. After enabling it on the correct inbound connector, look for X-MS-Exchange-ExternalOriginalInternetSender and X-MS-Exchange-SkipListedInternetSender in newly delivered messages. Do not use it to compensate for a routing path that sends mail through Microsoft 365, out to a non-Microsoft system, and back again.
A gateway issue does not remove the sender's responsibility to authenticate the visible From domain. It changes where to fix the break: at the intermediary, at the post-processing DKIM signer, or in the Microsoft 365 connector configuration.
When DMARC passes but compauth still fails
If the final Microsoft-stamped Authentication-Results header shows an aligned SPF or DKIM pass and dmarc=pass but compauth still fails, the remaining work is usually on the recipient side. Do not change working DNS records just to chase the composite result. First confirm that the pass values appear in the last Microsoft result, not only in an earlier header copied by a forwarder.
- Check the exact compauth reason code and the final Microsoft anti-spam headers.
- Review spoof intelligence for the precise visible sender and sending infrastructure pair.
- Inspect anti-phishing policy, accepted-domain handling, inbound connectors, and message trace for a tenant decision.
- Confirm a gateway did not stamp or copy an earlier pass that Microsoft later reevaluated.
- Use a narrowly scoped tenant override only after the sender and infrastructure are verified.
Do not allow an entire domain or gateway IP range as the first fix. A broad allow entry can hide real spoofing. Scope any exception to the verified sender and sending infrastructure pair, then retest a new message.
Verify before changing policy
After DNS changes, verify two different things. First, check DNS so you know the DMARC, SPF, and DKIM records are present and syntactically valid. Second, send a real message through the same application path that produced the failure. A web app, billing system, and password reset flow can use different senders even when they share the same brand.
For DNS validation, a DMARC checker confirms the published policy and reporting addresses. A broader domain health checker helps catch related SPF and DKIM issues before you retest in Microsoft 365. If you need to create the TXT record, use a DMARC record generator and start with reporting enabled.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
When the new message arrives, inspect the fresh header. You want at least one DMARC-valid path: SPF pass with a branded MAIL FROM domain, or DKIM pass with a signing domain tied to the visible From domain. DKIM is the stronger operational target for most apps because it is not tied to the connecting IP address.
Also check the failure type, not only the pass or fail word. spf=permerror points at an SPF syntax, duplicate-record, or lookup-limit problem. spf=temperror points at a temporary DNS lookup problem. dkim=fail with a body hash note usually means the message changed after signing.
Policy rollout stages
Move policy only after the authenticated sources are visible in reports.
Discovery
p=none
Collect reports and identify legitimate senders.
Partial enforcement
p=quarantine
Quarantine a controlled share after fixes land.
Full enforcement
p=reject
Reject unauthenticated mail after monitoring is clean.
How Suped fits into the workflow
Suped's product helps with this workflow by connecting raw DMARC data to the exact operational question: which source is sending, which domain it uses, and what needs to change. Suped's DMARC monitoring shows authentication health, source breakdowns, and issue details without forcing teams to read XML reports by hand.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
This matters for compauth failures because the visible header is only one sample. DMARC reports show patterns across receivers and sending sources. Suped's product can flag unverified sources, DKIM gaps, SPF lookup problems, and policy gaps before you move to enforcement.
- Automated issue detection turns failures into concrete steps to fix.
- Real-time alerts surface sudden authentication drops after vendor or DNS changes.
- Hosted DMARC, hosted SPF, SPF flattening, and hosted MTA-STS reduce DNS maintenance.
- Blocklist (blacklist) monitoring adds reputation context when delivery still suffers.
- MSP and multi-tenant views make multi-domain sender cleanup manageable.
Check path-specific sender failures
If this issue appears only for one vendor, one subdomain, or one mailbox provider, look for a path-specific sender configuration. Marketing mail and transactional mail often leave through different accounts. A single domain can have correct DNS while one application still sends unsigned mail.
For a broader failure tree, use DMARC failure troubleshooting. If the header has a DKIM signature but the d= domain is wrong, check the DKIM domain mismatch case before changing policy.
Do not raise DMARC straight to p=reject while compauth failures are still unexplained. First confirm every legitimate source has branded DKIM or branded SPF domain matching. Then increase policy in stages.
Views from the trenches
Best practices
Use branded DKIM for every visible From domain before moving DMARC past p=none.
Set a custom MAIL FROM domain under the same organizational domain as the From address.
Check the final Microsoft header after gateways or forwarding have finished processing.
Common pitfalls
Publishing a DKIM key does nothing if the sending system does not sign with it.
Letting a vendor use its own bounce domain makes SPF pass without helping DMARC.
Assuming SPF pass is enough when MAIL FROM does not match the visible From domain.
Expert tips
Ask the provider for branded DKIM and a custom return-path setup in writing.
Use a subdomain you control when the root domain DNS process is slow or restricted.
Use ARC or post-processing DKIM when gateways modify mail after the first signature.
Marketer from Email Geeks says compauth=fail reason=001 points to Microsoft composite authentication, so the full header matters more than one result token.
2020-03-06 - Email Geeks
Marketer from Email Geeks says a message can have SPF pass for a vendor domain while the visible From domain gets no DMARC benefit.
2020-03-06 - Email Geeks
Prevent repeat compauth failures
The durable fix for compauth failure from domain matching issues is to fix the sender identity. Sign the message with branded DKIM, use a branded MAIL FROM domain when possible, publish DMARC on the visible From domain, and retest with a newly delivered Microsoft header.
If you send for many customer domains and lack DNS access, make domain ownership part of the onboarding process. Without a DKIM delegation, a custom return-path, or a DMARC record on the visible From domain, Microsoft has limited evidence that the message is legitimate.
