ARC: preserving authentication results across relays

ARC (Authenticated Received Chain) addresses a specific problem: a legitimate message passing through an intermediary (mailing list, mailbox forwarding, security gateway) often loses its authentication. SPF breaks because the relay's IP address is not authorised by the originating domain; DKIM breaks if the relay rewrites the subject or appends a footer. ARC lets every relay vouch for the results it observed before modifying the message, so that the final recipient can take them into account. ARC is described in RFC 8617, published with experimental status.

How the chain works#

Every participating relay adds a set of three headers, numbered with an increasing i= instance:

• ARC-Authentication-Results: (AAR): a copy of the SPF, DKIM and DMARC results as the relay saw them on receipt;
• ARC-Message-Signature: (AMS): a DKIM-style signature over the message as the relay re-emits it, after its modifications;
• ARC-Seal: (AS): a signature covering all previous ARC headers plus the current instance's AAR and AMS, with a cv= (chain validation) tag set to none for the first link, pass if the received chain was valid, fail otherwise.

The final recipient validates the chain end to end: every seal must verify and every cv= must be consistent. If the chain is intact, it can read in the first AAR that the message passed DMARC before the mailing list touched it. Nothing forces it to act on that: ARC provides signed information, and it is the provider's local policy, based on how much it trusts the sealing domain, that decides whether to override a DMARC failure.

The DNS record#

ARC defines no record of its own. Seals and signatures are verified with a key published exactly like a DKIM key, under _domainkey:

arc2026._domainkey.relay.example.net.  IN TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...IDAQAB"

The d= domain of the ARC headers is the relay's, not the original sender's. Here is what one link looks like inside a message:

ARC-Seal: i=1; a=rsa-sha256; t=1759276800; cv=none; d=relay.example.net; s=arc2026; b=...
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=relay.example.net; s=arc2026; h=from:to:subject:date:message-id; bh=...; b=...
ARC-Authentication-Results: i=1; relay.example.net; spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com

Who should deploy ARC#

ARC concerns systems that receive and then re-emit messages: mailing list servers, anti-spam or archiving gateways in front of a mail system, address forwarding services, mailbox providers forwarding to other domains. A domain that sends directly to its recipients has nothing to do: SPF, DKIM and DMARC are enough.

For a relay, deployment comes down to:

1. Publish a key under _domainkey for the relay's domain, separate from the DKIM key used for its own outbound mail.
2. On receipt, evaluate SPF, DKIM and DMARC and record the results in an Authentication-Results: header under the relay's identifier.
3. Before re-emitting, validate the existing ARC chain, then add the next instance (AAR, AMS, AS) with the appropriate cv=.
4. Never seal a message whose incoming chain is invalid with cv=pass.

Most current list managers and gateways support ARC; it is then a matter of enabling it and publishing the key.

For recipients#

A provider verifying ARC has to decide which sealing domains deserve trust. A valid chain signed by an unknown domain means nothing: an attacker can perfectly well forge an AAR claiming that DMARC passed. ARC's value therefore rests entirely on the relay's reputation and on trust lists maintained by each provider. Large mailbox providers use it to let known mailing lists through despite a p=reject policy on the author's domain.

Common mistakes#

• Expecting ARC to fix a misconfigured DMARC: ARC only concerns messages modified by an intermediary, not unaligned direct streams.
• Sealing with the production DKIM key: it works, but mixes two purposes and complicates rotation.
• Omitting the AAR or recording incomplete results in it: the chain is valid but useless.
• Reusing an i= or skipping a number: the chain is invalid.
• Modifying the message after computing the AMS, for instance by adding a footer at queue exit.
• Sealing cv=pass without validating the incoming chain.

What SenderRadar shows#

For a domain that operates relays, SenderRadar flags published key selectors used for ARC sealing when they can be identified, and sets the domain's DMARC configuration against the streams likely to pass through intermediaries. SenderRadar relies on its own analysis base to present these elements without presuming how much trust any given provider places in the relay.

References#

• RFC 8617 – The Authenticated Received Chain (ARC) Protocol
• RFC 8601 – Message Header Field for Indicating Message Authentication Status
• RFC 6376 – DKIM