ARC (Authenticated Received Chain, RFC 8617) lets your gateway seal each message with a cryptographic record of the authentication results it observed (SPF, DKIM, DMARC). When the message is later forwarded — and SPF or DKIM inevitably break — the next hops can still trust your gateway's original verdict by validating the ARC chain.
¶ The problem ARC solves
When a message goes through a forwarder (mailing list, alias, relay, migration gateway), the forwarding hop changes the sending IP and often rewrites parts of the message:
- SPF fails at the destination because the forwarder's IP is not in the author domain's SPF record.
- DKIM often fails because mailing lists modify the subject or the body.
- As a result, DMARC fails and legitimate forwarded mail gets quarantined or rejected.
ARC preserves the authentication verdict computed before forwarding, in a tamper-evident chain that each hop extends.
¶ Advantages
- Forwarded mail survives DMARC: receivers that evaluate ARC (Gmail, Microsoft 365...) can accept mail whose SPF/DKIM broke in transit but whose ARC chain proves it authenticated correctly upstream.
- Chain validation: Artica Milter validates any existing ARC chain (
cv=pass/cv=fail/cv=none) before adding its own seal, so a forged chain cannot be laundered through your gateway. - Same key infrastructure as DKIM: ARC reuses the
/etc/dkimPKs/<domain>/<selector>.pemlayout — no separate key tooling. - Fail-open by design: if a key cannot be loaded or sealing fails, the message is delivered unsealed and the error is logged. ARC never blocks your mail flow.
¶ Use cases
- Your gateway relays or forwards mail to Microsoft 365 / Google Workspace mailboxes and you want your authentication results honored downstream.
- You operate mailing lists or redistribution aliases that rewrite messages.
- Multi-hop routing between sites or between an on-premises gateway and a cloud filter, where the last hop must still be able to apply DMARC sensibly.
¶ Create the ARC rule
Open MTA Mail system » Access Control Lists, click New Rule and select ARC:
¶ Configure the sealing options
The ARC rule uses the same options form as DKIM — domain, selector and canonicalization:
| Option | Meaning |
|---|---|
| Domain | The sealing domain (the d= tag of the ARC headers). Sealing applies to messages whose author domain matches. |
| Selector | The DNS selector publishing the public key at <selector>._domainkey.<domain>. |
| Canonicalization | Normalization applied before signing; keep relaxed/relaxed. |
Apply the settings: the key pair is generated automatically if missing, and the DNS TXT record to publish is displayed — exactly like DKIM.
¶ What the seal looks like
For each sealed message, Artica Milter adds the three ARC headers with the next instance number (i=N+1):
- ARC-Authentication-Results (AAR) — a snapshot of the SPF / DKIM / DMARC results your gateway observed.
- ARC-Message-Signature (AMS) — a DKIM-like signature of the message at sealing time.
- ARC-Seal (AS) — a signature over the whole chain, carrying the chain validation verdict (
cv=).
¶ Good to know
- You can run DKIM signing and ARC sealing together: sign with the DKIM rule, seal with the ARC rule — a common setup for outbound gateways.
- Messages with no prior authentication to report still get sealed (e.g. pure outbound submission), so downstream hops always find a chain.
- Verify a seal externally with any RFC 8617 validator, or by sending a message to a Gmail mailbox and inspecting Show original.