ARC explained: why email still fails after a forward

You configured SPF, DKIM, and DMARC correctly. Your domain passes every check. Then a user forwards one of your emails, or it lands on a mailing list, and DMARC fails at the final recipient. The message was never tampered with. The authentication broke anyway.

Why authenticated email still fails after a forward

SPF (RFC 7208) verifies the server that connects to deliver a message, not the message itself. An intermediary that forwards your email becomes the new sending server. The envelope MAIL FROM now points at the forwarder's domain instead of yours, so SPF re-evaluates against a domain your DNS record never authorized. SPF fails, even though the original message was legitimate.

DKIM (RFC 6376) usually survives a simple forward, since it signs the message body and headers rather than the connection. But mailing lists routinely rewrite the subject line, add a footer, or alter headers to comply with list conventions. Any of those changes invalidates the DKIM signature, because the signed hash no longer matches the modified content.

Either failure mode produces the same downstream effect: DMARC (RFC 7489) requires SPF or DKIM to pass and align with the visible From domain. One broken link is enough to fail DMARC, and a strict p=reject policy then blocks a message that was authentic when it left your servers.

What ARC defines

RFC 8617 defines the Authenticated Received Chain (ARC). Each intermediary that touches a message, a mailing list, a forwarding rule, an internal relay, records what SPF, DKIM, and DMARC looked like when that intermediary received the message, then signs that record before passing the message along.

The final recipient can look at this chain and see the authentication results from every hop, including the original sender. A mailbox provider can then decide to trust an ARC chain even when its own SPF or DKIM check on the final hop fails, because it can see the message was authenticated correctly earlier in its journey.

How ARC works

Every intermediary that participates in ARC repeats the same sequence on each hop:

1. It evaluates SPF, DKIM, and DMARC on the message as it received it, exactly as any receiving server would.
2. It seals the incoming ARC set (if one already exists) together with its own authentication results into a new ARC set.
3. It increments the instance number, i=, by one. The first intermediary to touch the message starts at i=1.
4. It attaches the new ARC headers and forwards the message, whether or not it also modifies the subject, body, or other headers.

The chain grows by one instance per hop. A message that passes through a mailing list and then a corporate relay before reaching the final mailbox carries two ARC sets, i=1 and i=2.

ARC header anatomy

Each hop adds three headers, always in this order:

• ARC-Authentication-Results: mirrors that hop's own Authentication-Results header: the SPF, DKIM, and DMARC verdicts as seen at this point in the chain.
• ARC-Message-Signature: a DKIM-style signature over the message as it looked at this hop, using the same a=, d=, s=, h=, bh=, b= fields as a regular DKIM-Signature.
• ARC-Seal: seals the entire ARC set for this instance. Carries i= (instance number), cv= (chain validation status: none, pass, or fail), and b= (the seal's own signature).

The final recipient reads the cv= field first. The first hop carries cv=none, since it has no prior chain to validate. cv=pass means this hop verified every ARC set that came before it. cv=fail means something in the chain doesn't check out, and a receiving server then has no reason to trust the rest of it.

ARC in practice

A message sent to a mailing list, then forwarded to its final recipient, picks up two ARC sets.

Hop 1, the mailing list server, receives the original message and evaluates it directly from the sender's domain:

ARC-Authentication-Results: i=1; mx.list.example;
  spf=pass smtp.mailfrom=acme.com;
  dkim=pass header.d=acme.com header.s=selector1;
  dmarc=pass header.from=acme.com
ARC-Message-Signature: i=1; a=rsa-sha256; d=list.example; s=arc;
  h=from:to:subject:date:message-id; bh=2jUS...; b=k3nP...
ARC-Seal: i=1; a=rsa-sha256; d=list.example; s=arc;
  cv=none; b=q9Lm...

The list server then rewrites the subject line to add a [list-name] prefix, breaking the original DKIM signature, and forwards the message.

Hop 2, the final MTA, receives that rewritten message. Its own SPF check fails, since the connecting server is now the mailing list, not acme.com. Its own DKIM check also fails, since the subject changed. But it validates the existing i=1 ARC set from hop 1, confirms it, and adds its own:

ARC-Authentication-Results: i=2; mx.recipient.com;
  spf=fail smtp.mailfrom=list.example;
  dkim=fail header.d=acme.com header.s=selector1 (body hash mismatch);
  dmarc=fail
ARC-Message-Signature: i=2; a=rsa-sha256; d=recipient.com; s=arc;
  h=from:to:subject:date:message-id; bh=8fQw...; b=r7Vt...
ARC-Seal: i=2; a=rsa-sha256; d=recipient.com; s=arc;
  cv=pass; b=n4Xz...

cv=pass on the i=2 seal tells the receiving mailbox provider that the chain checks out end to end, including the i=1 results showing the original message passed SPF, DKIM, and DMARC before the list ever touched it. The provider can use that to deliver the message normally, despite the final-hop SPF and DKIM failures.

What ARC doesn't do

A receiving mailbox provider decides whether to trust an ARC chain and how much weight to give it against a p=reject DMARC policy. ARC doesn't override that policy or force delivery on its own; it only gives the provider more information to decide with.

Not every mailbox provider evaluates ARC. If the receiving side doesn't check the chain, the ARC headers are inert, and a message with broken SPF or DKIM at the final hop is judged on those results alone.

Check it yourself

Open the raw headers of a message you received after it passed through a forwarder or a mailing list. In Gmail, open the message and select "Show original" from the menu.

Look for ARC-Seal headers with the highest i= value. A cv=pass on that seal means the receiving side validated the entire chain and trusted the earlier authentication results. cv=fail or a missing ARC set means either the chain broke somewhere, or the receiving mail server doesn't support ARC at all.

Where ARC fits

ARC builds on SPF, DKIM, and DMARC. If those three terms are new, read the DKIM, SPF, and DMARC guide first: ARC only makes sense once you understand what breaks and why. For the wider set of email standards ARC sits inside, see the full email RFC standards guide.

ARC covers the authentication layer of a forwarded message. It says nothing about whether the connection carrying that message was encrypted in transit. That's a separate problem with its own set of standards: MTA-STS, TLS-RPT, and DANE, covered in the SMTP transport security guide.

Each ARC seal is added hop by hop, as the message relays from one server to the next over SMTP. SMTP itself is the transport layer ARC's chain of custody rides on.

FAQ

Does ARC replace SPF, DKIM, or DMARC?

No. ARC doesn't replace them, it preserves their result across intermediaries so a later hop's own SPF or DKIM failure doesn't discard the fact that the original message was authenticated.

Does every mailbox provider check ARC?

No. If the receiving side doesn't evaluate ARC, the headers are inert and the message is judged on the final hop's own SPF, DKIM, and DMARC results alone.

Can I add ARC to my own outbound email?

No. ARC is added by intermediaries, mailing lists, forwarders, relays, that handle a message after it leaves the original sender. It isn't something the original sender configures.

What does cv=fail mean?

The chain of ARC seals doesn't validate: something in an earlier hop's signature doesn't check out, so the receiving side has no reason to trust the rest of the chain.

RFC reference

RFCs covered: RFC 8617. Superseded / updated by: None.