Enforce DMARC and, sooner or later, someone reports that legitimate mail sent through a mailing list, a corporate forwarder, or a “forward to my Gmail” rule is landing in spam or being rejected outright. It isn’t spoofed — it’s collateral damage. Mailing lists and forwarders modify messages in ways that break the very checks DMARC relies on, and Authenticated Received Chain (ARC) exists specifically to fix it.

Why Forwarding Breaks DMARC

What the intermediary does	What breaks
Mailing list adds a footer or changes the subject line	DKIM signature no longer validates — the body changed
Forwarder resends using its own envelope sender	SPF fails — the sending IP doesn’t match the original domain’s SPF record
List software rewrites the From header	DKIM may still pass, but alignment with the visible sender breaks

Any one of these is enough for a receiving server to see a DMARC failure on a message that was, at the point of origin, perfectly legitimate.

What ARC Adds

ARC lets each intermediary in the delivery chain cryptographically vouch for what it received and validate before forwarding it. Three headers get added at every hop:

Header	Purpose
ARC-Authentication-Results	Records what SPF/DKIM/DMARC results this hop actually observed
ARC-Message-Signature	A DKIM-style signature over the message as this hop saw it
ARC-Seal	Signs the entire chain so far, including previous ARC headers, and increments an instance number i=

Example ARC Header Set

ARC-Seal: i=1; a=rsa-sha256; d=example.com; s=arc; t=1758000000;
  cv=none; b=...
ARC-Message-Signature: i=1; a=rsa-sha256; d=example.com; s=arc;
  h=from:to:subject:date; bh=...; b=...
ARC-Authentication-Results: i=1; mx.example.com;
  spf=pass smtp.mailfrom=sender.com;
  dkim=pass header.d=sender.com;
  dmarc=pass header.from=sender.com

A receiving server that supports ARC can look back through this chain and see: “the message failed DMARC as I received it, but the last trusted intermediary confirmed it originally passed” — and use that as a signal to still deliver it instead of rejecting it outright.

Who Needs to Implement This

As a hosting customer, you’re on both sides at different times. Major mailbox providers (Gmail, Microsoft, Yahoo) already validate ARC on inbound mail, so you don’t need to do anything to benefit as a recipient. But if you run a mailing list, a forwarding service, or any relay that resends mail on behalf of other domains, your own mail server needs to be the one adding ARC headers — otherwise messages you forward have no chain of trust to check.

Adding OpenARC to Exim or Postfix

OpenARC is the common open-source ARC implementation, installed as a milter alongside your existing OpenDKIM setup:

# Generate an ARC signing key (same process as DKIM)
openssl genrsa -out /etc/openarc/arc.private 2048
openssl rsa -in /etc/openarc/arc.private -pubout -out /etc/openarc/arc.public

# openarc.conf
Mode                    sv
Domain                  example.com
Selector                arc
KeyFile                 /etc/openarc/arc.private
Socket                  inet:8894@localhost

Point your MTA’s milter configuration at that socket the same way you already point it at OpenDKIM, and publish the ARC public key in DNS at arc._domainkey.example.com — identical format to a DKIM record.

Limitations of ARC

ARC is advisory, not authoritative. It gives a receiving server extra evidence to consider, but the receiver decides how much to trust it, and not every mailbox provider participates. It also doesn’t fix SPF or DKIM — it wraps around their failure and provides context, which is why it’s a mitigation for forwarding, not a replacement for authentication.

Conclusion

If your DMARC enforcement is breaking mail sent through lists or forwarders you don’t control, there’s nothing to fix on the sending side — the fix belongs to whoever operates that relay, and it’s ARC. If you operate a relay yourself, add OpenARC now, before enforcement elsewhere turns a display quirk into rejected mail.