ARC Email Authentication: Why Forwarded Mail Fails DMARC

Introduction

You moved your domain's DMARC policy to `p=reject` after weeks of clean reports. Then a customer writes in: the mail you send to their team address now bounces, while mail to their personal address is fine. Their team address is a mailing list that adds a footer and resends to every member. Your message left your servers signed and aligned, and arrived at the members' mailboxes failing both SPF and DKIM.

ARC email authentication is the standard written for exactly this. ARC, the Authenticated Received Chain defined in RFC 8617, lets every server that forwards a message record the SPF, DKIM and DMARC results it saw, sign the message as it stood, and seal that record. The final receiver can then see that your message passed before the list changed it. ARC is evidence, not an override: each receiver decides whether to trust the server that sealed it.

Why Forwarding Breaks SPF, DKIM And DMARC

Each check fails for its own reason when a message is forwarded, which is the gap ARC email authentication was designed to close:

• SPF checks the IP address that connected against the SPF record of the envelope sender's domain. A forwarder connects from its own IP, which your SPF record does not list. If the forwarder rewrites the envelope sender to its own domain, which Google's forwarding guidance recommends, SPF can pass, but for the forwarder's domain, not yours.
• DKIM survives forwarding untouched, because the signature travels with the message. It breaks when the content changes. Google lists the usual culprits: a modified subject, changed MIME boundaries, and software that rewrites or re-encodes the body. A list footer or a [team] subject tag is enough.
• DMARC needs SPF or DKIM to pass for a domain aligned with the From address. With SPF passing only for the forwarder and DKIM broken, nothing aligned passes, so DMARC fails and a p=reject policy asks the receiver to refuse the message.

None of this means anything was forged. The message is genuine; it just no longer carries proof of that. RFC 7960 catalogues these indirect mail flows and the ways they collide with DMARC.

What ARC Adds: The Three ARC Headers

A server that supports ARC email authentication adds one numbered set of three header fields each time it handles the message. The number is the instance tag i=, and it runs from 1 to 50.

The cv= tag is the one people misread. On set 1 it must be none, because there was no chain before the first forwarder. On every later set it must be pass. Here is the ARC part of a message from sender.example, forwarded through a list at lists.relay.example and delivered to a Gmail mailbox. Signatures are shortened:

ARC-Seal: i=2; a=rsa-sha256; cv=pass; d=google.com; s=arc-20240605; b=AAAA
ARC-Message-Signature: i=2; a=rsa-sha256; d=google.com; s=arc-20240605; h=from:subject:date; b=CCCC
Authentication-Results: mx.google.com;
       dkim=fail (body hash did not verify) [email protected];
       arc=pass (i=1 spf=pass spfdomain=lists.relay.example dkim=pass dkdomain=sender.example dmarc=pass fromdomain=sender.example);
       spf=softfail [email protected];
       dmarc=fail (p=REJECT sp=REJECT dis=NONE) header.from=sender.example
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=lists.relay.example; s=arc1; b=DDDD
ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.relay.example; s=arc1; h=from:subject; b=FFFF
ARC-Authentication-Results: i=1; mx.lists.relay.example; spf=pass smtp.mailfrom=sender.example;
       dkim=pass header.d=sender.example; dmarc=pass header.from=sender.example

How To Read ARC Headers In A Real Message

1. Find your own provider's Authentication-Results line, the one carrying its name, and read the arc= result. Here it is arc=pass, next to dkim=fail and dmarc=fail.
2. Find the ARC set with the highest i=. Its d= is the last server that sealed the chain, and its cv= is that server's verdict. Here Google's own set 2 says cv=pass.
3. Read ARC-Authentication-Results: i=1. That is what the first forwarder saw before it changed anything: SPF, DKIM and DMARC all passing for sender.example.
4. Compare the two. Passing at i=1 and failing at delivery means the message was changed in transit, and the d= of set 1 tells you which forwarder to talk to.

That last comparison is the diagnosis the bounce message never gives you. In the example, the list at lists.relay.example received a message that passed everything and then broke the body hash, almost certainly by adding its footer.

What ARC Pass And ARC Fail Mean

Section 5.2 of RFC 8617 gives the validator's steps. The chain fails if there are more than 50 sets, if the newest seal already says cv=fail, if any set is missing one of its three fields, if the numbers have a gap or repeat, if a cv= value is wrong for its position, or if the newest message signature or any seal does not verify. Otherwise it passes. The RFC is blunt about failure: a message with a failed chain must be treated the same as a message with no chain at all.

An ARC pass is narrower than it sounds. It proves that each sealer really added its set and that nothing was changed after the last seal. It does not prove the results inside the sets are true; that depends on whether you trust the servers that wrote them.

Does ARC Fix DMARC Failures?

Sometimes. ARC email authentication only helps at the receiver's discretion. RFC 8617 says a DMARC processor may, by local policy, accept a message that fails DMARC because a trusted chain shows it passed earlier. It is permission, not a rule, and the RFC itself is published as Experimental.

Microsoft 365 is the clearest public example of how this works in practice. An admin lists trusted ARC sealers, the d= domains from the ARC-Seal lines of the services they use, and Microsoft then uses those sealers' original results. Microsoft's documentation shows arc=pass with oda=1 when the sealer is trusted, and compauth=pass reason=130 when ARC overrode a DMARC failure. It also notes that ARC only overrides DMARC: spam filtering still applies.

What To Do When Forwarded Mail Fails DMARC

As the sender, you control one thing that helps more than ARC email authentication ever can: DKIM aligned with your From domain. SPF never survives a forward from a new IP, but DKIM does unless the content changes, and a forwarder that only re-sends the message keeps your DMARC pass. Sign with your own domain in d=, use c=relaxed/relaxed so small whitespace changes do not break the signature, and confirm now and then that the signature still passes at the far end.

For mailing lists and gateways you do not run, ask the operator whether they add ARC seals. If they do, a Microsoft 365 recipient's admin can add their sealing domain as trusted. If the list modifies messages and does not seal, the list itself has to change: some lists rewrite the From address to their own domain for exactly this reason, one of the mitigations RFC 7960 discusses. Moving your policy back from p=reject is the last resort, not the first.

ARC Email Authentication Questions

Is ARC The Same As DKIM?

No, though it reuses DKIM's signing method and its DNS key format. DKIM is added once by the author's domain and proves the message is unchanged. ARC is added by each forwarder, records the authentication results that forwarder saw, and lets a later receiver see those results even after the message was changed.

Do I Need To Set Up ARC For My Domain?

Not as a sender. ARC email authentication needs no record from you. ARC is added by servers that forward mail, and they sign with keys published under their own domain. What you control is a DKIM signature aligned with your From domain, which is what an ARC set needs to record as passing in the first place.

Why Does The First ARC-Seal Say None?

Because there is no earlier chain to judge. RFC 8617 requires cv=none on the set with i=1 and cv=pass on every set after it. A first set with pass, or a later set with none, makes the whole chain fail. So cv=none on set 1 is correct, not a warning.

Can Spammers Fake ARC Headers?

Anyone can add ARC headers, signed with keys for their own domain, and the chain can still pass. That is why receivers decide whom to trust: a valid seal from an unknown domain proves only that the domain added it. A seal that does not verify fails the chain, and a failed chain counts the same as no chain.

How Eklow Handles This

Reading ARC email authentication results by hand means matching instance numbers across six or more header lines. The free email header analyzer does that matching. It shows the receiving server's own results first, and lists any Authentication-Results added earlier separately, marked as not verified by the receiver.

Below that, every ARC set is listed with its sealing domain, its cv= value and the results it recorded, and set 1 is labelled as what the first forwarding server saw. The chain's structure is checked against RFC 8617: three fields per set, numbers in sequence, and cv= values valid for their position. The page says plainly that this is a structure check. To verify the signatures themselves, tick Verify DKIM and ARC signatures and paste the whole message; the seals are then checked against the keys published now.

Inside Eklow, the part you control is taken care of before a campaign sends. A sending domain only verifies once its SPF and DMARC records resolve and every DKIM record Eklow lists for it is published, and a mailbox whose domain is not verified is never used to send. Verified domains are re-checked every six hours, and a domain whose records stop resolving is flagged and you are notified. The domain verification guide walks through the records, and SPF, DKIM and DMARC explained for founders covers why aligned DKIM matters before you get to ARC.