An email can pass authentication before a mailing list changes it. The next receiver needs evidence of that earlier result to distinguish legitimate processing from impersonation.
Why can legitimate forwarding break authentication?
Forwarding can change the sending server or signed content that authentication checks depend on.
SPF checks whether a server is authorized for the envelope sender domain used for delivery-failure notices. A forwarder can connect from an unauthorized IP.
DKIM validates a signature associated with a signing domain. The signature can survive a plain forward. A mailing list that changes a signed Subject or body can invalidate it.
DMARC requires a passing SPF or DKIM domain to match the visible From domain. That match is called alignment. If neither method supplies an aligned pass, DMARC fails even when the message is legitimate.
What does ARC add to the message?
Each participating handler adds three headers, together called an ARC set.
| Header | Evidence it supplies |
|---|---|
ARC-Authentication-Results | The authentication results observed before the handler's changes |
ARC-Message-Signature | A signature over the message as the handler sends it onward |
ARC-Seal | A signature protecting the ARC set and the earlier chain |
The instance number i= orders the sets. The first handler uses i=1. The next uses i=2, making their order explicit.
The seal's cv= value records chain validation. The value none marks the first set. The value pass records successful validation of an existing chain. The value fail records failed validation.
RFC 8617 describes how receivers verify the chain's integrity. Verification does not establish that every handler's reported assessment is trustworthy.
Does a valid chain guarantee delivery?
A valid ARC chain does not guarantee delivery. It supplies evidence for the receiver's own handling decision.
The receiver decides whether it trusts the handlers that supplied the evidence. An unknown handler does not become trustworthy merely by producing a valid signature.
The ARC specification is Experimental, meaning it documents a protocol for evaluation rather than an Internet Standards Track specification. Its delivery decision remains receiver-controlled.
Who needs to implement ARC?
Forwarders and mailing lists use ARC to preserve authentication evidence for downstream receivers.
| Your role | Relevant task |
|---|---|
| Original sender | Authenticate your mail with an aligned domain |
| Forwarder or mailing list | Evaluate the incoming chain and add an ARC set when processing the message |
| Receiver | Validate available chains and decide which handlers to trust |
Yahoo's sender guidance asks forwarders to implement ARC. Doing so can help recipients evaluate legitimate mail affected by forwarding. Receivers still decide whether to accept it.
If your direct mail fails DMARC, fix its authentication or alignment. Adding an ARC seal does not repair the original domain mismatch.
What can an original sender do about forwarded mail?
An original sender can provide aligned DKIM that survives forwarding when the signed content remains intact.
Sign the headers that need protection. Avoid a body-length limit that leaves appended content unsigned. DKIM signing explains those choices.
If a later handler edits signed content, preserving evidence of the earlier result requires that handler's participation. ARC gives it a way to record that evidence. The receiver still decides how much weight to give it.
In short
Forwarding and editing can affect authentication.
A changed sending server can break SPF. Changing signed content can break DKIM.
Each participating handler adds an ARC set.
The three headers record authentication results, sign the outgoing message and seal the chain.
A valid chain does not guarantee delivery.
Receivers decide whether to trust the intermediaries and how to use their evidence.
Originators and intermediaries have different tasks.
Original senders authenticate their mail. Intermediaries can preserve evidence of results observed before their changes.