ARC Email Authentication: Fix DMARC on Forwarded Mail

ARC (Authenticated Received Chain) solves a specific but critical deliverability problem: emails that are legitimately forwarded — through mailing lists, vacation autoresponders, or email security gateways — often fail DMARC when they arrive at the final recipient. The original SPF check fails because the forwarding server is not in the sender's SPF record, and DKIM can break if the forwarder modifies the message body. ARC preserves the original authentication results at each hop, allowing the final receiving server to evaluate the entire chain of trust rather than just the last hop.

What ARC Solves — The Forwarding Problem

Without ARC, a legitimate forwarded email often arrives at the final destination with a DMARC fail. Consider the path: sender → mailing list → subscriber. The mailing list rewrites the Return-Path (breaking SPF alignment), and may modify the subject or add a footer (breaking DKIM). When the subscriber's Gmail receives the message, it checks DMARC and sees: SPF fails (the list server IP is not in the original sender's SPF), DKIM fails (body was modified). The message may be rejected or filtered to spam despite being completely legitimate.

ARC adds a set of headers at each intermediary hop that preserve the authentication results seen at that point. The final receiver can evaluate the ARC chain: did the original message pass authentication? Did a trusted intermediate server vouch for it? If yes, the receiver may apply a more lenient policy even though the current DMARC check fails.

ARC Headers — What Each One Does

ARC adds three headers at each forwarding hop, all indexed with an instance number (i=1, i=2, etc.). The instance number increments at each hop, allowing receivers to reconstruct the full chain.

# First hop — added by the mailing list server:
ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@originalcompany.com header.s=selector1;
       spf=pass (original sender's SPF);
       dmarc=pass (p=REJECT) header.from=originalcompany.com
       # This records the auth results at the FIRST hop (before forwarding)

ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
       d=listserver.com; s=arckey2025;
       # The mailing list's DKIM-like signature over the message at hop 1

ARC-Seal: i=1; a=rsa-sha256; cv=none; d=listserver.com; s=arckey2025;
       # cv=none at first hop (no prior chain to verify)
       # Seals the ARC-Authentication-Results and ARC-Message-Signature headers

# Second hop — added when the subscriber's server receives it:
ARC-Authentication-Results: i=2; mx.google.com;
       dkim=fail (body modified by mailing list);
       spf=fail (mailing list IP not in originalcompany.com SPF);
       dmarc=fail (p=REJECT);
       # Records the CURRENT auth results (which fail due to forwarding)

ARC-Message-Signature: i=2; a=rsa-sha256; ...
ARC-Seal: i=2; a=rsa-sha256; cv=pass;
       # cv=pass = the i=1 ARC chain verified successfully
       # Gmail can now see: original auth passed, chain is intact

ARC for Email Operators — Do You Need to Implement It?

Whether you need to implement ARC depends on your role in the email chain. There are three distinct scenarios:

You are the original sender: You do not implement ARC yourself. ARC is added by intermediaries. Your job is to have correct SPF, DKIM, and DMARC — these are what gets preserved in the ARC chain.

You operate an email intermediary (mailing list, security gateway, forwarding service): You should implement ARC sealing. Your server adds ARC headers when forwarding messages, preserving the original authentication results for the final receiver. OpenARC, rspamd, and recent versions of Postfix (with milter support) can add ARC headers.

You are a receiver: You should evaluate ARC chains when a message fails DMARC. Gmail, Microsoft, and Yahoo all evaluate ARC chains. If you operate your own MX (for corporate mail), configure your mail server to check ARC before applying DMARC policy.

ARC Implementation with OpenARC + Postfix

# Install OpenARC:
# Debian/Ubuntu: apt install openarc
# RHEL/CentOS: yum install openarc

# /etc/openarc.conf
Syslog          yes
LogWhy          yes
Canonicalization relaxed/relaxed
Domain          yourforwarder.com
Selector        arckey2025
KeyFile         /etc/openarc/keys/arckey2025.private
SignatureAlgorithm rsa-sha256
Mode            sv    # s = seal, v = verify
Socket          local:/run/openarc/openarc.sock
# AuthservID should match your server's MX hostname
AuthservID      mail.yourforwarder.com

# /etc/postfix/main.cf — connect OpenARC milter:
milter_protocol = 6
milter_default_action = accept
# Add OpenARC alongside any existing milters (OpenDKIM etc.)
smtpd_milters = local:/run/opendkim/opendkim.sock, local:/run/openarc/openarc.sock
non_smtpd_milters = $smtpd_milters

# Generate ARC signing key:
# openssl genrsa -out /etc/openarc/keys/arckey2025.private 2048
# openssl rsa -in /etc/openarc/keys/arckey2025.private -pubout
# Add public key to DNS:
# arckey2025._domainkey.yourforwarder.com IN TXT "v=DKIM1; k=rsa; p=[pubkey]"