A customer who runs an industry mailing list contacted us in October about deliverability problems. Their subscribers were complaining that messages from the list were landing in spam folders, particularly for subscribers on Gmail. The mailing list software had been working for years; nothing on their side had changed. The cause was DMARC enforcement at major receivers combined with the structural issues mailing lists introduce.

The fix was implementing ARC (Authenticated Received Chain). The implementation took about three weeks of work spread across DNS configuration, OpenARC installation, testing, and gradual deployment. The deliverability returned to acceptable levels by mid-November.

ARC is one of those email infrastructure mechanisms that sits below operational awareness for most senders but matters enormously for specific scenarios. Mailing lists, corporate forwarders, university .forward files, mail filters that modify content all benefit from ARC. The implementation is bounded but not trivial.

This post is what ARC actually does, how to implement it correctly for mailing list operations, and what we have learned from production deployments.

The problem ARC solves

The fundamental issue: forwarding scenarios break DMARC alignment.

The original mail leaves the sender’s domain authenticated with SPF (passing) and DKIM (signed by the sender’s domain). The DMARC alignment is correct because the From header matches the authenticated domain.

The mailing list software receives the mail, processes it (adds list-specific headers, possibly modifies the subject line with a [List-Name] prefix, possibly adds footer text), and forwards to subscribers.

The forwarded mail at the recipient looks different from the original:

SPF: the connecting IP is now the mailing list’s, not the original sender’s. SPF check fails for the sender’s domain.
DKIM: the modifications (subject line, footer) have invalidated the original DKIM signature. The body hash no longer matches.
DMARC: with both SPF and DKIM failing alignment, DMARC fails.

The receiver enforcing DMARC (at p=quarantine or p=reject) sees the failed authentication and treats the mail as suspicious. The list message lands in spam folder or is rejected outright.

This is the structural problem ARC was designed to solve.

How ARC works

ARC creates a chain of authentication results that survives the modifications introduced by intermediate mail servers.

The mechanism:

The intermediate server (the mailing list software, in our case) receives the original mail.
The server records the authentication results of the original mail (SPF pass, DKIM pass, DMARC pass) in special ARC headers.
The server signs the ARC headers with its own DKIM-like signature.
The modified mail is forwarded with the ARC headers preserved.
The receiving server validates the ARC chain. If the chain shows the original mail passed authentication at the intermediate server, the receiver gives the message credit for the original authentication even though current SPF/DKIM fail.

The ARC headers added to the message:

ARC-Authentication-Results: documents the authentication results the intermediate server observed
ARC-Message-Signature: signs the original message content (similar to DKIM signature)
ARC-Seal: signs the ARC headers themselves

Each “hop” through an intermediate mail server adds another set of ARC headers with incrementing sequence numbers (i=1, i=2, i=3, etc.). The chain can be inspected to see the full authentication history.

What makes ARC effective

Several specific properties make ARC actually work in production.

Sealed at intermediate

The intermediate server seals the ARC chain with its own signature. This signature is verifiable independent of the original sender’s authentication. The receiver verifies the seal to confirm the intermediate server actually saw the original authentication.

Trust-based override

The receiver decides whether to trust a particular ARC sealer. Trusted intermediaries (typically major mailing list providers, established forwarding services) get their ARC chains accepted. Untrusted intermediaries do not.

Backward compatible

Mail with ARC headers still works at receivers that do not check ARC. The headers are ignored without causing problems. Mail without ARC headers still works at receivers that do check ARC. The receivers use SPF/DKIM/DMARC as before.

Trace preserving

The ARC chain documents the full forwarding history. Each intermediate server adds its records. The receiver can see the complete path the mail took.

When ARC actually helps

ARC is operationally valuable in specific scenarios:

Traditional mailing lists

Mailman, Sympa, Listserv, Google Groups, and similar mailing list software produces the exact scenario ARC was designed for. Mail comes in, gets modified, gets forwarded. ARC preserves authentication credit through the modification.

Corporate forwarding

Corporate mail servers that forward employee mail to personal addresses (or vice versa) often introduce modifications that break authentication. ARC preserves the original authentication credit.

University .forward files

Academic email infrastructure often allows users to forward mail via personal .forward files. The forwarding produces authentication issues at the eventual recipient. ARC can address this.

Mail filters that modify content

Some mail filters (anti-spam, content scanners) modify mail in ways that invalidate DKIM. ARC allows the filter to seal its own authentication results, preserving the chain.

Email service providers handling deflection

ESPs that need to handle bounce-back and complaint scenarios sometimes need to relay mail in ways that break alignment. ARC can help in these scenarios.

When ARC does not help

ARC has specific limitations.

Bad actors at intermediate

If the intermediate server itself is compromised or malicious, the ARC seal does not protect against tampered content. The receiver trusts the intermediate’s claim about what they observed. A malicious intermediate can falsely claim authentication passed.

Untrusted intermediaries

The receiver chooses which intermediaries to trust. Small or unknown mailing list operators may not be trusted by major receivers. The ARC chain is added but ignored.

Chains too long

Multiple hops through different intermediaries (with potentially different sealers) can produce long chains. Receivers may not validate beyond certain chain lengths.

Modifications too extensive

Even ARC has limits on what modifications can be preserved. Significant content changes may invalidate the seals even when the chain is otherwise valid.

Setup mistakes

Incorrectly configured ARC (wrong key, wrong domain, broken signatures) produces ARC chains that do not validate. The validation failure may produce worse outcomes than no ARC at all.

Implementation: the architecture

For a mailing list deployment of ARC, the architecture has specific components.

Mail server with ARC capability

The mail server processing the list needs ARC support. Several options:

OpenARC: open-source ARC milter for Postfix and Sendmail. Works alongside OpenDKIM (which most setups already have). Standard for self-hosted mail servers.

Rspamd: includes ARC support as a built-in feature. Works with various mail server configurations.

Postfix-policyd or custom milters: ARC implementations exist for these setups.

For mailing list software, the ARC processing happens at the mail server level, not in the mailing list software itself. The mailing list software hands mail to the local mail server, the mail server processes ARC headers and sends out.

DNS records for ARC signing

ARC signing requires DNS records similar to DKIM but separate.

The DKIM record exists at a selector (e.g., mail._domainkey.example.com). The ARC record exists at a similar location (e.g., arc._domainkey.example.com) with the ARC public key.

The record format is similar to DKIM:

arc._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIBIj..."

The same DNS infrastructure that handles DKIM handles ARC records.

ARC sealer identification

The ARC seal includes the sealer domain. Major receivers maintain lists of trusted ARC sealer domains. To get credit for ARC sealing, the sealer needs to be on the receiver’s trusted list.

For small mailing list operators, getting on the trusted list may not happen automatically. Building reputation as an ARC sealer takes time. The benefit grows over time as the sealer accumulates trust.

Validation infrastructure

The receiving side validates ARC chains. Most major receivers (Gmail, Microsoft, Yahoo) implement ARC validation. Smaller receivers may not.

For a mailing list operator, the validation side is the receivers’ responsibility. The operator’s job is correct ARC sealing on the outbound side.

Implementation: the specific steps

For our customer’s mailing list, the implementation involved several specific steps.

Step 1: OpenARC installation

OpenARC was installed on the mail server alongside the existing OpenDKIM. Both ran as milters processing outbound mail.

# Install OpenARC
apt install opendkim-tools openarc

# Configure OpenARC to sign outbound mail
# /etc/opendkim/openarc.conf
Domain example.com
Selector arc
KeyFile /etc/opendkim/keys/example.com/arc.private
Mode sv
Socket inet:8893@localhost

The configuration mirrors OpenDKIM’s pattern but with ARC-specific options. The Mode sv indicates the milter handles both signing (s) outbound and validation (v) inbound.

Step 2: Key generation

ARC keys are generated similarly to DKIM keys:

opendkim-genkey -d example.com -s arc -b 2048

The output is the private key (kept secret on the server) and a DNS record value for the public key.

Step 3: DNS publication

The public key is published in DNS:

arc._domainkey.example.com IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

DNS propagation takes a few hours. Verification with dig confirms the record resolves correctly.

Step 4: Mail server integration

Postfix configuration adds OpenARC as a milter:

# /etc/postfix/main.cf
smtpd_milters = inet:localhost:8891,inet:localhost:8893
non_smtpd_milters = inet:localhost:8891,inet:localhost:8893

The first milter is OpenDKIM (port 8891), the second is OpenARC (port 8893). Both process every message.

After configuration, Postfix is reloaded:

systemctl reload postfix

Step 5: Testing

Test sends through the mailing list verify ARC headers are added correctly:

ARC-Seal: i=1; a=rsa-sha256; cv=none; d=example.com; s=arc; t=1639...
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=arc; t=1639...
ARC-Authentication-Results: i=1; example.com; spf=pass smtp.mailfrom=sender@original.com; dkim=pass header.d=original.com

The headers appear in the test message. The values are checked for correctness.

Step 6: Validation testing

Send test messages through the mailing list to recipients at major receivers (Gmail, Microsoft, Yahoo). Check the message headers at the recipient side. Verify the receivers process the ARC chain correctly.

The verification confirms ARC is operating end-to-end, not just on the sending side.

Step 7: Production rollout

After validation, enable ARC on all production mail through the list. Monitor for any regressions in deliverability or unexpected behavior.

The rollout for our customer was gradual: 10% of list traffic first, then 50%, then 100% over the course of a week. The gradual rollout caught issues at small scale before they affected the full list.

What we learned during implementation

The implementation produced several insights worth documenting.

Key length matters

We initially used 1024-bit keys (matching the customer’s existing DKIM key length). The ARC validation at some receivers was rejecting 1024-bit signatures. We regenerated with 2048-bit keys and validation worked correctly.

The recommendation: always use 2048-bit keys for new ARC implementations. The 1024-bit key compatibility issues are not worth saving the bytes.

Mailing list software interactions

Different mailing list software produces different modification patterns. Mailman 3 has built-in ARC support that integrates with OpenARC. Older Mailman 2 implementations may not work as smoothly with ARC.

For our customer’s Sympa-based list, the integration required some additional configuration to ensure Sympa was not modifying mail in ways that broke ARC sealing.

Trust building

The initial ARC implementation produced improved deliverability but not immediately dramatic improvement. Receivers needed to accumulate trust in our customer’s ARC sealing over time.

Within 2-4 weeks, the deliverability improvement was substantial. Within 8-12 weeks, the deliverability had returned to or exceeded pre-DMARC-enforcement levels.

Header preservation

Some intermediate mail systems (anti-spam filters, mail transfer agents) strip headers they do not recognize. The ARC headers are a relatively new addition; older systems may strip them.

The mitigation: ensure all intermediate systems in the customer’s mail path preserve ARC headers. This required some configuration changes on the customer’s anti-spam filter.

Signature on body modifications

ARC seals the body content. If different subscribers receive different content (personalization, list-specific customization), each variation needs its own ARC seal. This is operationally manageable but adds complexity.

Multiple sealer scenarios

For mail that passes through multiple intermediates, each adds its own ARC seal. The chain grows. Each receiver decides which sealers to trust. The first trusted sealer in the chain (from the receiver’s perspective) provides the authentication credit.

For our customer’s deployment, the mailing list is typically the first and only intermediate. The chain is short. The trust evaluation is straightforward.

The operational impact

After full ARC deployment for our customer:

Deliverability to Gmail improved from 67% inbox placement to 89% inbox placement.

Deliverability to Microsoft improved from 71% to 86%.

Deliverability to Yahoo improved from 64% to 84%.

Deliverability to corporate mail servers improved more variably, depending on the specific receiver’s ARC support.

The customer’s subscriber complaints about spam folder placement decreased significantly. The list operation became sustainable for the long term.

What does not improve with ARC

Some scenarios are not addressed by ARC.

Receivers without ARC support

Receivers that do not check ARC chains see the same DMARC failures as before. ARC adoption is widespread among major receivers but not universal. Mail to receivers without ARC support continues to face DMARC alignment issues.

Content that does not pass receiver-side filtering

ARC addresses the authentication issue. It does not address content quality issues. Mail that is rejected for content reasons (spam patterns, suspicious links, etc.) continues to be rejected even with proper ARC.

Mailing lists with bad practices

ARC does not fix list quality issues, complaint rate problems, or content relevance issues. Lists with structural problems continue to have problems regardless of ARC implementation.

Forwarding to invalid recipients

ARC does not address the issue of mail forwarded to recipients who do not exist or have suspended accounts. Those failures continue to occur.

ARC vs alternative approaches

Several alternative approaches address the mailing list problem.

DMARC mailing list mode

Some mailing list software can be configured to rewrite the From header to be the list address, with the original sender in a different header. This makes DMARC alignment work because the From header is the list’s domain.

The trade-off: the recipient sees the list as the From sender, not the original author. The semantic of the From header changes. Some users find this confusing.

List-friendly DMARC policy

Senders posting to lists can publish DMARC policy with aspf=r adkim=r (relaxed alignment) which is more forgiving. The mail may still fail alignment but the failure is less severe.

The trade-off: relaxed alignment provides weaker protection against spoofing. The trade-off may be acceptable for some senders.

Avoiding mailing lists

Some organizations migrate away from mailing lists to other communication patterns (forums, Slack/Discord channels, web-based community platforms). The shift avoids the email forwarding issues entirely.

The trade-off: different communication patterns serve different needs. Mailing lists remain valuable for specific use cases.

Sender-side DKIM with multiple selectors

Senders with sophisticated infrastructure can use multiple DKIM keys with different scope. The list-relevant keys may have different alignment requirements than the main domain keys.

The trade-off: complexity. The operational discipline to maintain multiple key scenarios is real.

Best practices for ARC implementation

Based on our customer experience and broader observation:

Use 2048-bit keys

Smaller keys produce validation issues at some receivers. 2048-bit is the current standard. The bytes saved by smaller keys are not worth the compatibility issues.

Test before production

Test ARC implementation against major receivers before production rollout. Verify the chains validate correctly. Catch issues at small scale.

Monitor after implementation

Continued monitoring is important. ARC chain handling can be affected by infrastructure changes, key rotations, configuration updates. Periodic verification catches drift.

Use established sealer identities

Receivers trust established sealer identities. Brand new sealing domains have no reputation. Where possible, sealing from established domains improves outcomes.

Document the implementation

ARC implementation involves multiple components: DNS records, key files, milter configuration, mail server configuration. Documentation of the full setup matters for ongoing maintenance.

Plan for key rotation

ARC keys, like DKIM keys, should rotate periodically. Plan rotation procedures. Test the rotation process before relying on it under pressure.

Coordinate with mailing list software

The mailing list software needs to coordinate with the mail server’s ARC handling. Some software has built-in awareness; some needs configuration. The coordination produces operational reliability.

What we offer for ARC implementation

For customers running mailing lists or other forwarding scenarios, we offer:

ARC capability on managed infrastructure

For customers on our managed PowerMTA or Postal infrastructure, ARC capability is available as a feature. The customer requests ARC support, we configure the infrastructure, the customer maintains the operational practice.

Implementation consultation

For customers running their own mail servers, we provide consultation on ARC implementation. Architecture decisions, configuration patterns, testing procedures.

Monitoring and verification

We help customers set up ARC monitoring to catch issues before they affect operations. The monitoring includes chain validation testing and receiver-side outcome tracking.

Operational continuity

ARC implementation is not a one-time event. Ongoing operations (key rotations, infrastructure updates, mailing list software updates) all require ARC awareness. We help customers maintain ARC operational continuity over time.

The bigger pattern

ARC implementation reflects a broader pattern in email infrastructure.

Authentication continues maturing

The basic authentication mechanisms (SPF, DKIM, DMARC) work for simple cases. Complex cases (forwarding, modification, mailing lists) need additional mechanisms. ARC fills one gap.

Receiver-side adoption matters

The benefits of new authentication mechanisms depend on receiver-side adoption. ARC is widely adopted at major receivers, which makes implementation worthwhile. Mechanisms with narrow receiver adoption produce limited benefit.

Operational discipline accumulates

Each new authentication mechanism requires operational work. The cumulative discipline of properly authenticated mail infrastructure is significant but bounded. Operators investing in the discipline see compounding benefits.

Edge cases drive specifications

Authentication specifications often emerge in response to specific edge cases. The mailing list forwarding problem drove ARC. Other edge cases drive other specifications. The pattern continues as email infrastructure encounters new scenarios.

What we expect for ARC

Looking forward:

Adoption will continue spreading. More receivers implement ARC validation. More intermediates implement ARC sealing. The mechanism’s effectiveness grows with adoption.

Tooling will improve. Current implementation requires technical configuration. Better tooling (especially for non-mail-server-running organizations) will lower the implementation barrier.

The specification may evolve. RFC 8617 defines the current ARC specification. Refinements based on production experience may produce updated specifications over time.

Adjacent mechanisms may emerge. ARC addresses one specific scenario. Other forwarding scenarios may produce additional authentication mechanisms.

The honest summary

ARC is operationally valuable for specific scenarios. Mailing list operators, corporate forwarders, mail filter operators all benefit from ARC implementation.

The implementation is bounded but not trivial. Several weeks of work is typical for proper deployment. The result is sustainable improvement in forwarded mail delivery.

The benefit grows over time as receiver trust accumulates. The initial improvement is meaningful; the long-term improvement is substantial.

The work is technical but documented. The OpenARC software, the DNS configurations, the testing procedures are all available. The operational discipline to deploy correctly is bounded.

For operators running mailing lists or similar scenarios facing DMARC-related deliverability issues: ARC is the operational answer. The implementation is worth the work. The result is sustained mailing list deliverability that the operation can rely on.

The customer who started this post is operating their list successfully. The implementation work paid off in customer satisfaction (subscribers reaching their mail) and operational sustainability (the list infrastructure can continue operating without periodic deliverability crises).

For other operators in similar situations: the work is achievable. The documentation exists. The benefit is real. The investment in ARC capability is justified by the operational improvement it enables for the specific scenarios it addresses.