ARC Authentication: What the Chain Proves and Who Actually Needs It

ARC Authentication: What the Chain Proves and Who Actually Needs It

ARC, short for Authenticated Received Chain, is a protocol that preserves the results of SPF and DKIM checks across intermediaries that would otherwise invalidate them. Each intermediary records the authentication results it saw when the message arrived, signs that record, and passes it along, so the final receiver can inspect what happened earlier in the delivery path instead of judging only the message in the state it finally arrived.

The problem ARC exists to solve

Email authentication was designed for a direct path. A sending server connects to a receiving server and the receiver checks two things.

SPF authorises a sending IP address for a domain. The receiver looks up the domain's published record and asks whether the IP that just connected is on the authorised list. DKIM works differently: the sender signs selected headers and the message body with a private key, publishes the public key in DNS, and the receiver recomputes the hash and verifies the signature. DMARC then requires that at least one of those passes AND that the passing identifier aligns with the domain in the visible From address, and it tells the receiver what to do when neither does.

Now put an intermediary in the middle.

A mailing list receives your message, appends a footer, tags the subject line, and re-sends it to hundreds of members from the list operator's own infrastructure. Both checks break at once. SPF fails, because the IP now connecting to the final destination belongs to the list, not to you, and your record never authorised it. DKIM fails, because the body hash was computed over a body that no longer exists once a footer was appended and the subject was rewritten. DMARC then finds nothing passing and aligned, and if your policy asks receivers to reject, the receiver rejects a message you legitimately sent to a subscriber who legitimately asked for it.

Plain forwarding produces a softer version of the same failure. A forwarder that relays the message untouched breaks SPF and usually leaves DKIM intact, so DMARC can still pass on the DKIM side. A forwarder that modifies anything at all, including some virus scanners and gateways that rewrite links, breaks both.

1. Step 1Original send

   Your server sends the message. SPF authorises your IP and your DKIM signature covers the headers and the body as sent.

2. Step 2Intermediary receives

   A list or forwarder receives the message and performs its own SPF, DKIM and DMARC checks. At this moment everything passes.

3. Step 3Intermediary modifies and relays

   A footer is appended, the subject is tagged, or the message is simply re-sent from the intermediary's own infrastructure.

4. Step 4Final receiver checks

   SPF now names the intermediary's IP and the DKIM body hash no longer matches. DMARC finds nothing passing and aligned.

5. Step 5The chain is read

   With ARC, the receiver can also read what the intermediary recorded before it made any changes, and decide whether to accept that record.

The three header fields

RFC 8617 defines three header fields, added as a set by each participating intermediary and numbered so their order can be verified.

ARC-Authentication-Results carries the snapshot. It records the authentication verdicts the intermediary observed at the moment the message arrived at it: whether SPF passed, whether DKIM validated, what DMARC concluded. This is the substance of the claim, and everything else in the set exists to make the claim checkable.

ARC-Message-Signature signs the message as the intermediary handled it. It is shaped like a DKIM signature, covering headers and body, and it lets a later receiver verify that the message it holds corresponds to what the intermediary signed rather than to something altered afterwards.

ARC-Seal signs the chain itself. It covers the ARC header sets already present, including earlier ones, which means a party further along cannot quietly delete, reorder or rewrite an inconvenient entry without the seal failing. Without it a chain would be a list of unprotected assertions; with it the chain has integrity as a chain.

Each set also carries a chain validation status, recorded by the intermediary that added it, stating whether the chain it received was intact when it arrived. A chain that has been broken somewhere upstream stays marked as broken from that point onward, and a broken chain cannot be repaired by a later party adding a valid set of its own. That is deliberate. A repairable chain would be a chain any party could launder, and the whole value of the structure is that a receiver at the end can tell an unbroken record from a patched one.

ARC-Authentication-ResultsThe claim

• Records the SPF, DKIM and DMARC verdicts the intermediary observed
• Written at the moment the message arrived, before any modification
• This is the evidence a later receiver actually wants
• Meaningless on its own without something binding it to the message

ARC-Message-SignatureBinding the claim to the message

• A DKIM-style signature over headers and body
• Ties the recorded verdicts to the message the intermediary handled
• Lets a receiver detect changes made after the intermediary relayed it
• Signed with the intermediary's own key, published in its own DNS

ARC-SealProtecting the chain

• Signs the ARC header sets already present, including earlier ones
• Prevents silent deletion, reordering or rewriting of entries
• Makes the chain verifiable as a sequential record
• Instance numbering keeps the order unambiguous

Where it breaks: a chain is not a passport

ARC does not make a message trusted. This is the single most common misreading and it is worth stating flatly.

What ARC provides is visibility. A receiver holding a verified chain knows what an intermediary claims to have seen, and knows the claim has not been tampered with in transit. It still has to decide whether to believe the intermediary, and it makes that decision on the intermediary's own reputation, exactly as it would decide anything else about a party sending it mail.

The consequences follow directly. A chain sealed by a large, well-known mailing list operator with an established record is worth something, because the receiver has a basis for extending trust. A chain from a forwarder the receiver has never encountered buys nothing at all: a perfectly valid cryptographic seal from an unknown party is an unverifiable assertion with a signature on it. A chain from a party with a poor reputation can be worse than no chain, since it identifies the message with that party. There is no mechanism in the protocol that converts a sealed claim into an authentication pass, and receivers are under no obligation to act on a chain at all. Support is a receiver-side policy decision, so implementing ARC says nothing about whether any particular receiver honoured it.

It is also worth being precise about what "supports ARC" means when a mailbox provider says it. Validating a chain and acting on a chain are separate steps. A receiver can verify every seal, confirm the chain is intact, read the recorded verdicts, and still decline to override a DMARC failure, because the decision to override rests on its assessment of the sealing party rather than on the cryptography. From the outside, a provider that validates but rarely overrides and a provider that ignores ARC entirely are hard to tell apart, and neither publishes the rule. Any claim that adding ARC to a path will fix delivery through that path is a claim nobody outside the receiver is in a position to make.

Where it breaks, practically: this is a protocol for intermediaries

Here is the part that matters most to anyone running cold outbound, and it is the reason most people arrive at this page by mistake.

ARC is implemented by intermediaries. A direct sender has essentially nothing to implement. If your messages travel from your sending infrastructure to the recipient's mail server without passing through a mailing list, a forwarding service or a relay that modifies them, there is no chain to seal and no set of headers for you to add. ARC is not a record you publish in DNS. It is not a setting in your sending platform. It is not a step in a deliverability checklist. It is code that runs inside systems that receive mail and re-send it onward, and unless you operate one of those, it is not your problem.

An enormous number of senders read about ARC while chasing a deliverability issue, conclude that here is something else they have failed to configure, and spend a day on it. The day is wasted. The authentication that a direct sender genuinely owns is SPF, DKIM and DMARC, and if messages are failing authentication on a direct path, the cause is in one of those three.

Does ARC concern you?

• ✓Yes: You operate a mailing list that receives mail and re-sends it to subscribers
• ✓Yes: You run a forwarding service, a security gateway or a relay that modifies messages in transit
• ✓Yes: You are a mailbox provider deciding what to do with mail arriving from intermediaries
• ~Depends: Some of your recipients auto-forward their mail elsewhere and you are reading unfamiliar sources in your DMARC reports
• ✕No: You send cold outbound directly from your own domains to recipients' mail servers
• ✕No: Your authentication is failing and you are looking for the missing piece

Those three items marked as yours to fix instead lead somewhere specific. The SPF, DKIM and DMARC setup for cold email covers the records a direct sender actually publishes. When authentication is failing and it is not obvious why, the six causes of DMARC failure in order of likelihood works through them in the order that finds most problems fastest. And choosing what your own policy instructs receivers to do is a real decision with real trade-offs, laid out in quarantine versus reject while sending cold email.

The one way ARC reaches a cold sender

There is a genuine connection, and it runs in the opposite direction from the one people expect.

Your recipients forward their own mail. A role address relays to somebody's personal mailbox. A company routes everything through a security gateway before it reaches the mailbox provider. A person who changed jobs has their old address forwarding onward. None of this is visible to you, none of it is under your control, and all of it produces exactly the indirect path described at the top of this page.

The place it surfaces is your DMARC reporting. Aggregate reports name the sources that sent mail claiming to be your domain, along with their authentication results, and forwarding paths appear there as sources you do not recognise failing SPF. The correct response is usually to recognise the pattern rather than to act on it, since a forwarder breaking SPF on your legitimate mail is the protocol working as designed. Misreading the same rows as evidence of spoofing has sent plenty of teams chasing an attacker who does not exist. Getting DMARC aggregate reports and understanding what they cannot tell you covers how to read that distinction.

Volume discipline sits behind all of this, and it is worth stating in its own terms. We send one message per campaign, written on one premise and sent once, and a later approach to the same person is a separate campaign with its own premise. Fewer deliveries into the same mailbox means fewer opportunities for an intermediary you cannot see to mangle a message you cannot inspect, and it keeps the load your domain places on any receiving provider proportionate to what you are actually asking of it.

If the authentication layer is not where you want your attention, our pay-per-qualified-meeting outbound puts the infrastructure on our side of the line and leaves you the meetings.

Verified as of August 2026. Verify current terms with the vendor before relying on them.