ARC Email Authentication Is Not Yours to Publish

There is no ARC record to add to your DNS. ARC is applied by the servers that handle your message after it leaves you, so a sender whose forwarded mail keeps failing DMARC cannot fix it by adopting ARC. The repair available to you sits in DKIM, and confusing the two sends a deliverability project after a control it does not own.

What the Standard Actually Describes

RFC 8617 opens with a definition worth reading closely: "The Authenticated Received Chain (ARC) protocol provides an authenticated 'chain of custody' for a message, allowing each entity that handles the message to see what entities handled it before and what the message's authentication assessment was at each step in the handling."

Every actor in that sentence is downstream of the original sender. The entities handling the message are mailing lists, forwarding services, scanning gateways and multi-tier mail systems. The chain records their assessments for the benefit of whoever receives the message last.

The standard defines three headers, and each does a separate job. ARC-Authentication-Results captures the authentication assessment at the moment that intermediary received the message. ARC-Message-Signature records which intermediary took responsibility and exposes later changes to the content. ARC-Seal signs the set so a receiver can confirm the earlier two were not altered.

The problem being solved is described in the introduction: intermediaries modify content or reroute messages, and legitimate mail then fails authentication checks it would have passed on a direct path. The chain gives the final receiver a second question to ask, which is whether the message was authentic when it entered the forwarding path, in place of a single pass or fail at the door.

Why the Sender Has No Move Here

Two things break on a forwarding hop, and only one of them is yours.

SPF checks the sending server against the domain in the envelope sender. A forwarding server is not on your SPF list and was never meant to be, so SPF fails at the second hop as a matter of design. You cannot authorise every server that might ever forward your mail, and attempting it by widening the record hits the ten-lookup ceiling and weakens the record for its actual purpose.

DKIM behaves differently. The signature travels with the message and validates against your published key regardless of which server relays it, as long as the signed content survives the trip. A forwarder that passes the message through unmodified leaves a valid DKIM signature, DKIM alignment carries DMARC on its own, and the message passes.

A cold outbound programme whose messages fail DMARC after a prospect forwards them internally has two candidate causes, and both live in DKIM: a signature covering content that the forwarding hop rewrites, or no DKIM alignment at all, with SPF quietly carrying DMARC until the first forward removed it. Our walkthrough of how to fix email authentication failing covers isolating which of the two signatures broke on a specific message.

Our view: a deliverability audit that recommends your sending domain adopt ARC has drifted onto a control you do not own. Send it back and ask for the DKIM alignment result on the same messages, which is the finding that would have produced an actionable repair.

The Limits Google States Plainly

Google's own documentation on ARC describes what the standard delivers: "ARC helps prevent authentication failure by: Saving previous authentication results for forwarded messages, Verifying forwarding servers, Adding headers to messages to indicate message authentication status."

The same page is direct about what it withholds. "ARC does not: Evaluate or provide information about sender and forwarder reputation. Prevent forwarding servers from adding harmful content to messages. Prevent forwarding servers from removing ARC headers from messages."

A chain that any participant can delete is evidence a receiver may find, never a guarantee it will. A forwarding service that strips the headers, deliberately or through an older configuration, leaves the receiver with the same bare failure it would have seen without ARC.

It also explains why receivers treat a chain as input to a decision instead of an override. The headers say a previous hop judged the message as authenticated; they do not say that hop was trustworthy. Reputation stays with the receiver, which is where Google's second sentence puts it.

Where ARC Becomes Your Problem

The answer flips if your company operates a hop, and the ways to become one are ordinary: a security gateway that scans inbound mail before releasing it, a catch-all address that redirects to a shared inbox, a distribution alias that fans a message out to a team, or a legacy domain whose mail is redirected to a current one after an acquisition.

Each of those makes you an intermediary for somebody else's mail. If your hop does not seal what it received, the mail you pass on fails DMARC at the far end for reasons that originate with you, and the sender has no visibility into why.

Ask each platform that touches inbound mail on the way through whether it seals messages with ARC, and ask separately whether it preserves a chain that arrives already sealed. The second question is the one vendors answer less readily, and Google's own list is why it matters: nothing stops a hop from removing the headers it was handed. A gateway that neither adds nor preserves is the quiet cause of complaints from partners whose mail keeps failing after it reaches you.

What To Do With This

1. Stop looking for an ARC record to publish and confirm DKIM signs and aligns on every sending domain you use.
2. Pull headers from a real forwarded copy of one of your messages and read whether the DKIM body hash survived the hop.
3. List every system in your company that receives mail and passes it onward, including aliases and redirected legacy domains.
4. Ask each of those vendors two questions: do you seal with ARC, and do you preserve a chain that arrives with the message.
5. Leave your SPF record narrow. Widening it to cover forwarders trades a real control for a failure it cannot prevent anyway.

Step two settles most arguments. A surviving DKIM signature on the forwarded copy means your authentication is sound and the failure belongs to the forwarding path, while a body hash mismatch means the forwarder rewrote your message and no amount of DNS work on your side will change the outcome.

If you want your DKIM setup, sending domains and outbound sequences reviewed together before the next campaign, book a free ICP and campaign-fit discovery call →.