ARC (Authenticated Received Chain), standardised in RFC 8617 in 2019, exists to solve a problem that predates DMARC but was made much more visible by DMARC enforcement: legitimate email forwarded from one mailbox to another fails authentication at the final destination because the forwarding server modified the email in ways that break DKIM signatures. If you have ever wondered why email forwarded through a corporate email redirect or an email alias lands in spam at the destination even though it was properly authenticated at the source, ARC is the answer — or at least, the mechanism that is supposed to be the answer.
ARC does not have high visibility in most deliverability discussions because its impact is most noticeable in specific forwarding scenarios that do not affect all senders. But for certain use cases — corporate email aliases that forward to personal accounts, university alumni email addresses that forward to personal Gmail, mailing list servers — ARC determines whether forwarded legitimate email reaches the inbox or lands in spam. Understanding it is part of a complete authentication picture.
The Forwarding Problem That ARC Solves
DKIM signing works by cryptographically signing specific email headers and the email body at the time of sending. The signature is verified by the receiving server by re-computing the same hash from the same headers and body and comparing against the signature. If anything in the signed content changes during transit, the hash no longer matches and DKIM fails.
Email forwarding usually changes something in the signed content. The most common changes that break DKIM during forwarding:
Mailing list modification: Mailing list servers add text to the subject line ("[List Name] original subject"), append footer text to the message body, or add list-specific headers. Any of these changes invalidates the original sender's DKIM signature because the body or headers have been modified from the state they were in when signed. The list server is not itself responsible for the authentication failure — it is a legitimate intermediary — but the consequence is that DKIM fails at the final recipient's mailbox provider, and if DMARC is at p=reject, the email may be rejected or quarantined despite being legitimate.
Simple forwarding with header modification: Some forwarding setups add a "Forwarded by" header or modify the Received chain in ways that affect DKIM-signed headers. Even a forwarding server that does not intentionally modify the email body can break DKIM if the server re-encodes the email body (changing whitespace or line endings) during the forward.
The business consequence: a company with DMARC at p=reject whose customer emails support@company.com (which is actually a forwarding alias to a personal Gmail inbox) will see those customer emails fail DMARC at Gmail and be quarantined or rejected — even though the customer is a legitimate sender. From the customer's perspective, they emailed the company and got silence. From the company's perspective, customer emails are going to spam without any indication of what happened. ARC provides the mechanism to preserve the authentication history through the forwarding hop, allowing Gmail to recognise that the email was properly authenticated before the forward.
How ARC Works: Seals, Signatures, and the Trust Chain
When an email passes through an ARC-capable intermediary server (a forwarding relay, a mailing list server), the intermediary adds three headers to the email:
ARC-Authentication-Results (AAR): Records the authentication results (SPF, DKIM, DMARC) as the intermediary observed them. This preserves the record of what authentication state the email had when it arrived at the intermediary — before any modifications the intermediary might make. Instance number 1 is added by the first intermediary, instance 2 by the second, and so on.
ARC-Message-Signature (AMS): A new DKIM-like signature of the entire message as it exists at the intermediary, including the newly added AAR header. This signature is computed by the intermediary using its own DKIM key. Even if the original sender's DKIM signature has been invalidated by body modifications, the AMS records what the email looked like at the intermediary step.
ARC-Seal (AS): A signature over all the ARC headers from all previous instances plus the current AAR. The AS creates a cryptographically linked chain — each seal covers the previous seals — that makes it impossible to modify the ARC chain without breaking the signature.
# Example: email forwarded once through an ARC-capable relay
# After forwarding, the email headers contain:
ARC-Authentication-Results: i=1; mx.google.com;
dkim=fail header.i=@sender.com header.s=mail2026;
spf=pass smtp.mailfrom=sender.com;
dmarc=fail action=none header.from=sender.com
# ^ Gmail records what authentication looked like AFTER forwarding
# DKIM failed because the forwarding server modified the body
# This AAR is signed into the ARC chain
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=forwarder.example.com; s=arc2026; t=1713744000;
h=arc-authentication-results:from:to:subject:date;
bh=BASE64_BODY_HASH;
b=BASE64_SIGNATURE
# ^ Forwarder's signature of the message at forwarding time
ARC-Seal: i=1; a=rsa-sha256; cv=none;
d=forwarder.example.com; s=arc2026; t=1713744000;
b=BASE64_SEAL_SIGNATURE
# ^ Seal over the ARC headers — cv=none means first hop (no prior ARC chain)
# If this were the second hop: cv=pass (prior ARC chain was valid)
# The receiving server (Gmail) evaluates ARC:
# 1. Verify ARC-Seal chain integrity
# 2. If the chain is valid and cv=pass from a trusted ARC sealer:
# Gmail may use the ARC-Authentication-Results from the first hop
# to determine the email's original authentication state
# 3. If the original authentication passed (ARC-Authentication-Results
# from hop 1 shows DKIM=pass), Gmail may override the current DKIM fail
# and treat the email as authenticated
Where ARC Actually Appears in Practice
Gmail and Microsoft 365 both implement ARC evaluation as of 2026 — they will use ARC headers when making delivery decisions for forwarded email. The scenarios where ARC has practical impact:
Corporate email aliases forwarded to personal Gmail: Many professionals have company email aliases that forward to their personal Gmail. When senders email the company alias, the corporate email server forwards to Gmail. If the forwarding server modifies the email, DKIM fails at Gmail. If the corporate server has ARC signing, Gmail receives the ARC chain showing the email was DKIM-verified before forwarding. Gmail, recognising the corporate server as a trusted ARC sealer, may override the DKIM failure and deliver the email to the inbox rather than spam.
University and alumni email forwarding: Universities commonly provide alumni email addresses (name@alumni.university.edu) that forward to the alumnus's personal email account. These forwarding setups break authentication for every email the alumnus receives. ARC on the university's forwarding infrastructure would preserve authentication for the alumni forwarding chain.
Mailing list servers: Mailman, Majordomo, and other mailing list servers are significant ARC use cases. List servers modify email bodies (adding footers), modify subjects (adding list prefixes), and send from the list address rather than the original sender. Modern Mailman versions (Mailman 3.x) include ARC signing support. Google Groups has implemented ARC sealing for its list operations.
Email security gateways that scan and reroute: Some enterprise email security gateways add headers, modify content for safe-link rewriting, or reroute email through a different SMTP path. These modifications break original DKIM signatures. ARC on the gateway provides the relay signature that allows the receiving server to understand the authentication state before the gateway modifications.
ARC and DKIM: What Happens When DKIM Breaks in Transit
The ARC and DKIM relationship is the core of what ARC does. Without ARC: email arrives at destination with broken DKIM, DMARC evaluates against broken DKIM and SPF alignment, if DMARC fails the email is quarantined or rejected per the sender's DMARC policy. With ARC: email arrives at destination with broken DKIM but a valid ARC chain showing DKIM was passing before the forwarding hop. Gmail and Microsoft 365 may use the ARC evidence to determine that the email was legitimately authenticated before forwarding and treat it as authenticated despite the current DKIM failure.
The trust question: Gmail and Microsoft 365 do not trust ARC chains from any source — they evaluate whether the ARC sealer (the server that added the ARC headers) is a known, trusted participant. A random server adding ARC headers claiming "DKIM was passing before I forwarded this" would be indistinguishable from a forged chain. The major email providers maintain lists of trusted ARC sealers — servers known to implement ARC correctly and honestly — and only apply ARC override logic for chains from trusted sealers.
This means adding ARC signing to your forwarding infrastructure is a prerequisite but not a sufficient condition for ARC to resolve authentication problems — the receiving server must also consider your forwarding server a trusted ARC participant. Gmail's trusted ARC list includes Google's own infrastructure, major mail hosts, and over time has expanded to include well-established corporate and institutional forwarding servers. New entrants to the ARC ecosystem are not immediately trusted — trust is established over time through consistent, correct ARC behaviour.
Mailing Lists, Newsletters, and ARC
If you operate a mailing list that receives email from subscribers and redistributes it to the full list (as distinct from newsletters that originate content), ARC signing on the list server protects the authentication chain for every redistributed email. Mailman 3.x supports ARC; upgrading to Mailman 3.x from Mailman 2.x is the most significant mailing list ARC improvement available for operators of classic mailing list infrastructure.
For newsletters that originate content (the sender drafts the email, the newsletter platform sends it to subscribers), ARC is less relevant — the newsletter platform signs the email with DKIM under the sending domain, and the email is not forwarded through additional hops that would break DKIM. ARC becomes relevant for newsletters only if the subscriber's mailbox applies a forwarding rule to the newsletter — which is outside the newsletter operator's control.
The mailing list operator's deliverability decision tree: (1) Is the list redistributing content from member submissions? ARC signing on the list server is highly valuable. (2) Is the list a newsletter with original content? ARC is less relevant; focus on DKIM signing and domain reputation instead. (3) Is the list operating a discussion forum where members reply to the list and the list redistributes to all? ARC is most critical here — every reply's authentication is broken by the redistribution, and ARC is the mechanism to preserve it.
Adding ARC Signing to Postfix with OpenARC
# OpenARC is the reference implementation for ARC signing # Install on Ubuntu/Debian: apt-get install openarc # Install on AlmaLinux/RHEL: yum install openarc # Generate ARC signing key (same as DKIM key generation): mkdir -p /etc/openarc/keys opendkim-genkey -t -s arc2026 -d forwarder.example.com -D /etc/openarc/keys/ # Generates arc2026.private and arc2026.txt # Publish the public key in DNS: # arc2026._domainkey.forwarder.example.com IN TXT "v=DKIM1; k=rsa; p=..." # Note: ARC uses the same key infrastructure as DKIM # /etc/openarc/openarc.conf configuration: Mode as # 'a' = authentication, 's' = sealing; both = 'as' Domain forwarder.example.com Selector arc2026 KeyFile /etc/openarc/keys/arc2026.private AuthservID forwarder.example.com TrustedAuthservIDs forwarder.example.com google.com microsoft.com Socket inet:8891@localhost # Postfix integration (milter interface): # /etc/postfix/main.cf — add OpenARC as a milter: smtpd_milters = inet:localhost:8891, inet:localhost:8890 # (8890 is OpenDKIM; 8891 is OpenARC) non_smtpd_milters = inet:localhost:8891, inet:localhost:8890 milter_default_action = accept # Restart services: systemctl restart openarc systemctl restart postfix # Verify ARC sealing is working: # Send a test email through the forwarding server and check headers: # Should see ARC-Authentication-Results, ARC-Message-Signature, ARC-Seal grep -i "ARC-" /path/to/test-email-headers.txt
ARC in PowerMTA
PowerMTA supports ARC sealing as of version 5.x. The configuration is similar to DKIM signing configuration:
# PowerMTA /etc/pmta/config — ARC sealing configuration: <arc-sealing> domain forwarder.example.com selector arc2026 private-key /etc/pmta/arc/forwarder.example.com.key # ARC sealing applies when PowerMTA is acting as an intermediary # i.e., when forwarding or relaying email from other sources # Trusted authserv-ids: identify which ARC sealers to trust # when building the chain trusted-authserv-id google.com trusted-authserv-id microsoft.com trusted-authserv-id forwarder.example.com </arc-sealing>
When ARC Actually Matters for Your Programme
ARC is not a configuration that most email senders need to implement themselves. The relevant actors in the ARC ecosystem are intermediaries — forwarding relays, mailing list servers, email security gateways — rather than original senders or final recipients. If your programme is a typical commercial email sender (newsletter, SaaS transactional email, marketing campaigns) that sends email directly to recipients without forwarding intermediaries in the delivery chain, ARC signing on your sending infrastructure is not necessary for your deliverability.
The situations where ARC matters to you as a sender: (1) You operate a forwarding relay or email alias service. Add ARC signing to that infrastructure. (2) You operate a mailing list server (Mailman, Sympa, etc.) that redistributes member submissions. Upgrade to Mailman 3.x or add OpenARC. (3) Your organisation's inbound email routes through a security gateway (Proofpoint, Mimecast) before delivery to internal mailboxes. Verify that the gateway adds ARC headers — most modern enterprise gateways do. (4) You receive email destined for forwarding aliases (e.g., support@yourdomain.com forwarded to a personal Gmail) and users are reporting forwarded legitimate email landing in spam. ARC on the forwarding infrastructure is the solution.
Understanding ARC is part of a complete authentication picture. Implementing it is relevant only where you operate forwarding infrastructure. For the majority of commercial email senders, the authentication stack to focus on is DMARC enforcement, DKIM key health, SPF record accuracy, and Ed25519 dual signing — ARC is the mechanism that protects email in the forwarding scenarios those practices cannot address, and it operates in the background of Gmail and Microsoft 365 without requiring action from the original sender.