SPF, DKIM and DMARC work well when a message goes directly from the sender's servers to the recipient's. They struggle when someone in the middle handles it. A forwarding rule sends your mail on to another address. A mailing list adds a footer and a prefix to the subject. A security gateway rewrites links or adds a disclaimer. In each case the message arrives at its final destination from a server that is not in the sender's SPF record, possibly with a changed body that no longer matches the original DKIM signature, and a strict DMARC policy tells the receiver to treat it as a forgery. The intermediary did nothing wrong, and the original authentication was valid, but nothing in the message proves it any more. ARC, the Authenticated Received Chain, was created to fix this: it lets each intermediary record what it saw when the message arrived, and sign that record, so that the final receiver can see the history. This guide explains how ARC works, what the headers contain, how receivers use them, what ARC cannot do and how to approach it as a sender or an administrator.
Why forwarded mail fails
Take a message from [email protected] to [email protected], which Alex has set to forward to a webmail account. The first receiver checks SPF and DKIM: both pass. It then forwards the message. The second receiver sees a connection from the university server, not from the example.com servers, so SPF for example.com fails. DKIM may still pass if the message was not changed. If the forwarder added a footer, DKIM fails too. With both failing, DMARC fails, and if example.com publishes p=reject, the second receiver may reject a message that Alex wanted. The sender cannot prevent this by changing their record, and the forwarder cannot re-sign the message as example.com. The details of why SPF breaks and how aligned DKIM helps are in email forwarding explained.
What ARC adds
ARC (RFC 8617) lets an intermediary that handles a message add a set of three headers that together record the authentication results it observed on arrival, and bind them to the message as it stood when the intermediary passed it on. Later receivers can read the chain and see that, at the first hop, SPF and DKIM passed. They can then decide to treat the message as legitimate despite the DMARC failure at the last hop. ARC does not change the DMARC result. It gives the receiver more information with which to override it.
The three headers
| Header | Role | Key contents |
|---|---|---|
ARC-Authentication-Results (AAR) | Records what the intermediary saw on arrival | The authentication results (SPF, DKIM, DMARC) for the message as received, with an instance number i= |
ARC-Message-Signature (AMS) | A signature over the message at this hop | Like a DKIM signature of the message headers and body as the intermediary received it, with d= and s= for the sealing domain and selector |
ARC-Seal (AS) | A signature over the ARC headers themselves | Contains the chain validation result cv= (none, pass or fail), the instance number and a signature that protects earlier ARC sets from tampering |
Each intermediary adds one set with the next instance number: the first adds i=1, the next i=2, and so on. The first one records cv=none, because there was no earlier chain. Each later one records whether the chain it received validated, cv=pass or cv=fail. A shortened example shows the shape:
ARC-Seal: i=1; a=rsa-sha256; t=1750000000; cv=none; d=forwarder.example; s=arc1; b=...
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=forwarder.example; s=arc1;
h=from:to:subject:date; bh=...; b=...
ARC-Authentication-Results: i=1; mx.forwarder.example;
spf=pass smtp.mailfrom=example.com;
dkim=pass header.d=example.com;
dmarc=pass header.from=example.comWhen the message reaches the final receiver, the receiver validates the chain: it checks each seal and message signature from the latest instance to the first, confirms that the chain is unbroken and reads the recorded results. If the chain is valid and the receiver trusts the sealer, it may accept a message that would otherwise fail DMARC. If any part fails, the chain is marked cv=fail and it is ignored.
ARC depends on trust
A valid ARC chain proves only that a particular domain signed particular results. It does not prove that the results are true. A spammer can set up a server, seal a message that claims all checks passed and sign it with their own ARC key, and the signature will be valid. For that reason, a receiver does not trust every sealer. It keeps its own list of sealers whose behaviour it knows, typically well-run forwarders, mailing-list software and large providers, and gives weight to ARC only from those. The design is intentional: ARC is a mechanism for passing information, and the receiver's decision about whom to trust is local. The consequence for a small forwarder is that adding ARC does not guarantee acceptance. It helps once receivers come to know and trust your sealing domain, which depends on your reputation.
Who uses ARC
ARC was designed with large mailbox providers, mailing-list software and gateways in mind, and several of the biggest receivers evaluate ARC results when deciding how to treat forwarded mail. Many mailing-list managers and gateway products can add ARC seals. Support among receivers is partial and their rules are not published in full, so do not treat it as a guarantee. The standard is published as an experimental RFC, which reflects its role as a mechanism still being refined. If you operate a forwarding service or list, adding ARC is good practice. If you are a sender, you do not add ARC to your own mail; you rely on strong DKIM and DMARC and let intermediaries handle the rest.
What ARC does not fix
- It does not make a bad message good. ARC records results; it does not override a receiver's spam filtering or reputation checks.
- It does not replace aligned DKIM. A message with an aligned DKIM signature that survives forwarding passes DMARC directly. ARC is a backup for cases where that is not possible.
- It does not help if the first hop failed. If the original message did not authenticate when the first intermediary received it, the chain records a failure.
- It does not guarantee that receivers trust you. A new sealing domain has no reputation.
- It does not remove the need for sender-side hygiene. Senders should still align SPF and DKIM and use a DMARC policy that they can manage.
What senders should do
Since you cannot control intermediaries, make your mail resilient. Sign with DKIM using your own domain so that the signature aligns; this is the single most useful step, because a signature that stays intact lets DMARC pass without ARC. Sign the headers that matter and use relaxed canonicalisation, which tolerates harmless whitespace changes. Avoid features that make signatures fragile, such as signing a very long list of headers that intermediaries commonly change. Keep an eye on your DMARC aggregate reports for forwarders that fail: see DMARC aggregate reports. If you use p=reject and discover that legitimate forwarded mail is rejected, consider the trade-off with your policy, and read the DMARC pct tag for gradual rollout. Our overview of the records is in email authentication explained.
What administrators of forwarders and lists should do
- Check whether your software supports ARC sealing, and enable it for mail you forward or relay.
- Create a dedicated DKIM-style key pair for ARC, publish the public key in DNS under a selector for your sealing domain, and rotate it as you would a DKIM key (see DKIM key rotation).
- Validate the incoming chain and authentication results before sealing, and record them accurately. A forwarder that seals false results damages its own reputation.
- Seal only what you have verified. Do not seal mail that you know failed authentication and was not otherwise vetted.
- Where you modify messages, such as list footers, keep the changes minimal and consistent so that the sealed AMS matches what you send.
- Monitor how receivers treat your forwarded mail, using test messages and the headers they return. See how to read email headers.
Reading ARC in headers
If you receive a forwarded message, open the full headers and search for ARC-. You will see one set per intermediary, numbered from i=1. Look at the AAR lines to see what each hop recorded, at the cv= value in each seal and at the final Authentication-Results added by your own mail system, which often includes an arc=pass or arc=fail result. If your message passed in a mailbox that uses ARC and failed in one that does not, the difference is likely ARC support. A message with several ARC sets and cv=pass throughout is the sign that the chain is intact.
Authenticate for the real world Sign every message with aligned DKIM so it survives forwarding, and see how receivers judge your mail.
References and further reading
Frequently asked questions
What is ARC in email?
The Authenticated Received Chain lets intermediaries such as forwarders and mailing lists sign the authentication results they saw, so the final receiver can see that the message was authentic when it arrived.
Does ARC make forwarded mail pass DMARC?
Not by itself. DMARC still evaluates the final hop. ARC gives the receiver evidence it can use to accept a message that would otherwise fail, if it trusts the sealer.
What are the three ARC headers?
ARC-Authentication-Results records the results seen, ARC-Message-Signature signs the message at that hop and ARC-Seal signs the ARC headers and carries the chain validation result.
Do I need to add ARC as a sender?
No. ARC is added by intermediaries. As a sender, sign with aligned DKIM so your messages pass DMARC even when forwarded.
Do all receivers trust ARC?
No. Receivers evaluate ARC from sealers they trust, and support and policy vary. ARC is an aid, not a guarantee.