ARC fail (arc=fail): what the Authenticated Received Chain means

What it means

ARC (Authenticated Received Chain, RFC 8617) helps emails survive forwarding. When a forwarder or mailing list changes a message, SPF and DKIM often break. ARC lets each intermediate server record what the authentication results were when it received the message, and sign that record. The final receiver can then decide to trust those earlier results.

Each server that adds ARC writes three headers with an instance number i=1, i=2...:

• ARC-Authentication-Results: SPF, DKIM and DMARC results as that server saw them.
• ARC-Message-Signature: a DKIM-like signature of the message.
• ARC-Seal: a signature over the ARC headers, with cv= (chain validation) set to none (first hop), pass or fail.

A result like this means the chain could not be validated:

Authentication-Results: mx.example.com; arc=fail (signature failed)
ARC-Seal: i=2; a=rsa-sha256; cv=fail; d=lists.example.org; s=arc; ...

Once one seal says cv=fail, the chain is broken for good: later servers cannot repair it.

Why it happens

• A server changed the message after sealing it: a footer, a subject tag, a security gateway rewriting links, or an antivirus adding a banner after ARC was added.
• A bad or missing ARC key: the selector in ARC-Seal (s=) has no public key in DNS at selector._domainkey.domain, or the key does not match.
• Broken order or missing headers: a hop removed or reordered ARC headers, or an instance number is missing.
• Too many hops: the standard allows at most 50 instances.
• Buggy implementations in a gateway or mailing list software.

Important: arc=fail does not mean your domain is broken. If you sent the email directly and SPF, DKIM and DMARC pass, ARC only matters for forwarded mail. Also, arc=none just means nobody added ARC, which is normal for direct mail.

How to check

1. Test your own sending first. Send an email to the unique address on the Delivmail home page (/) directly from your tool. If SPF, DKIM and DMARC pass, the problem is in the forwarding path, not your setup.
2. Read the received message headers at the final mailbox (Gmail "Show original", Outlook "View message source"). Find each ARC-Seal and note i=, cv=, d= and s=. The first seal with cv=fail, or the hop right before it, is where it broke. See how to read email headers.
3. Check the ARC key of the sealer:

   dig TXT arc._domainkey.lists.example.org +short

How to fix it

If you run the forwarder, list or gateway

• Add ARC after every change to the message. Footer and banner insertion must happen before sealing.
• Publish the ARC public key and check the selector. Many servers can do ARC: for example Rspamd has an ARC module, and Mailman 3 supports ARC signing.
• Prefer forwarding without modifying the body, and use SRS for SPF on forwarded mail.

If you are the original sender

• Make sure DKIM passes and is aligned with your From domain. DKIM survives simple forwarding much better than SPF.
• For mailing lists, read mailing lists and Google Groups break DMARC.

If you are the final receiver (Microsoft 365)

If a trusted service (a security gateway, a list) breaks DMARC but seals correctly with ARC, Microsoft 365 lets you list it as a trusted ARC sealer, in the Defender portal or with PowerShell. The parameter replaces the whole list, so include existing values:

Set-ArcConfig -Identity Default -ArcTrustedSealers "lists.example.org"

Only trust sealers you really know: a trusted sealer can make failing mail look legitimate.

Check that it is fixed

Send a new message through the same path and read the headers at the destination: the last ARC-Seal should show cv=pass and Authentication-Results should show arc=pass. Send a Delivmail test as well to confirm your own SPF, DKIM and DMARC still pass. Receivers decide themselves whether to use ARC, so a valid chain helps but does not guarantee delivery.