reason=130: A trusted ARC sealer overrode the DMARC failure
compauth reason=130 means an ARC chain from a sealer you explicitly trusted overrode a DMARC failure. Why only configured sealers count, and what ARC going Historic changes.
Published · Last verified · Maintained by TamingDNS
Pass
compauth=pass reason=130
1xx
Microsoft 365 only
📖 What Microsoft Says
The ARC result from a trusted ARC sealer overrode the DMARC failure.
Verbatim from Anti-spam message headers in Microsoft 365, "Composite authentication Reason codes". Everything below is our reading of it.
💬 What It Actually Means
DMARC failed, and an Authenticated Received Chain vouched for what the message looked like before an intermediary handled it. Microsoft accepted that testimony and passed the message. The usual cause is a mailing list or a forwarder that modified the message in transit and sealed a record of what it saw first.
What happens to the message
The message passes on the strength of an intermediary's word. Trusted is literal here: Microsoft only honours a chain from a sealer you have explicitly configured as trusted. An unconfigured sealer's chain does not produce this code, however valid the chain is.
What to do
Nothing on the message. On the configuration: know which sealers you have trusted, because each one is an entity whose claims about authentication you have agreed to accept. Review the list the way you would review any allow-list. A chain tells you what an intermediary says it saw. Weigh who sealed it, not the fact that a seal validated.
⚠️ Easily confused with
An absent chain does not mean no forwarding happened. Plenty of forwarders do not seal at all, so no ARC headers means nobody recorded the forward.
ARC is on its way out. The IETF's DMARC working group has adopted a draft, Reclassifying ARC as Historic, telling implementers not to rely on it going forward. Historic status switches nothing off: RFC 8617 stands, deployed code keeps running, and Microsoft's header documentation still described reason=130 at its August 2026 revision. The successor work is DKIM2, still at draft stage. You will keep meeting this code for years.
📋 What It Looks Like in a Header
Paste your own headers into the email header analyser to see this line decoded against the rest of the message.
Authentication-Results: spf=fail (sender IP is 198.51.100.60)
smtp.mailfrom=lists.listserver.example; dkim=fail (body hash did not verify)
header.d=contoso.com;
dmarc=fail action=none header.from=contoso.com;
compauth=pass reason=130
A mailing list appended a footer, which broke DKIM, and relayed from its own IPs, which broke SPF. The chain it sealed is what rescued the message.
🔗 Related Reason Codes
🔧 Check It Yourself
A reason code is one line of one header. These read the rest of the picture: what the domain publishes, and whether the message that carried this code holds up.