cPanel Exim ARC (Authenticated Received Chain): Fixing Forwarded DMARC Rejections

With global email providers (Google Workspace, Yahoo, Microsoft 365) strictly enforcing DMARC alignment policies, enterprise senders must configure p=reject or p=quarantine to safeguard their domains against spoofing.

However, strict DMARC enforcement introduces a severe, widespread deliverability casualty: email forwarding failure.

In enterprise workflows across Pakistan—such as corporate employees forwarding their business emails to mobile addresses, institutional alumni relays, CRM helpdesk aggregators (Zendesk, Freshdesk), or mailing list managers (Mailman)—an intermediate server receives an email and retransmits it to the final destination.

During this forward hop:

1. SPF Fails: The receiving MTA sees the forwarding server’s IP address, which is not listed in the original sender’s SPF record.
2. DKIM Breaks: If the forwarding server modifies the subject line (e.g., prepending [Ticket #1042]) or appends an unsubscribe footer, the original cryptographic signature invalidates.
3. DMARC Evaluates to FAIL: Under strict p=reject, the destination server silently drops the legitimate email or sends it directly to spam.

Standardized in RFC 8617, ARC (Authenticated Received Chain) solves this structural dilemma. By allowing intermediate forwarders to cryptographically seal the original authentication results before relaying, recipient servers can verify the message’s historical integrity and safely deliver forwarded messages.

---

The Forwarding Dilemma: How DMARC Breaks

Observe the authentication failure that occurs when an email is relayed without ARC:

[Original Sender: [email protected]]
 (SPF: Valid, DKIM: Valid)
            │
            ▼
[Intermediate Corporate Forwarder: cPanel Exim Node]
 (Modifies subject line or forwards from new IP)
            │
            ▼
[Recipient Mailbox: Gmail / Yahoo]
 ├── Check SPF: Fails (Exim IP is not in hbl.com SPF record)
 ├── Check DKIM: Fails (Subject was altered)
 └── Check DMARC: FAIL! -> [Email Rejected / Dropped]

When ARC is configured on the intermediate cPanel Exim relay:

[Original Sender: [email protected]]
            │
            ▼
[Intermediate Corporate Forwarder: cPanel Exim + ARC]
 ├── Verifies original SPF & DKIM: Both PASS!
 ├── Generates ARC Headers:
 │    ├── ARC-Authentication-Results (AAR)
 │    ├── ARC-Message-Signature (AMS)
 │    └── ARC-Seal (AS)
 └── Relays message to destination
            │
            ▼
[Recipient Mailbox: Gmail / Yahoo]
 ├── Direct SPF fails, direct DKIM fails
 ├── Evaluates ARC Chain:
 │    ├── Validates Exim's cryptographic ARC-Seal
 │    └── Confirms original message passed SPF/DKIM at Hop 1
 └── DMARC Evaluation: PASS via ARC! -> [Delivered to Primary Inbox]

---

Understanding the Three ARC Cryptographic Headers

ARC introduces three sequenced headers signed with instance index numbers ($i=1, 2, 3 \dots$):

1. ARC-Authentication-Results (AAR): Records the exact SPF, DKIM, and DMARC validation state when the message originally arrived at the forwarder.
2. ARC-Message-Signature (AMS): A cryptographic signature covering the message body and headers, similar to DKIM, asserting that the forwarder is the entity that relayed it.
3. ARC-Seal (AS): A cryptographic seal covering all previous AAR and AMS headers in the chain, ensuring no rogue actor in the transit route tampered with the authentication history.

Deploying high-throughput transactional mail relays on dedicated hardware like our Dedicated Servers provides dedicated, high-reputation IP allocations and unmetered network pipelines.

---

Step 1: Installing & Configuring OpenARC on cPanel

While Exim does not yet have a native compiled ARC signer in legacy distributions, it integrates cleanly with OpenARC or Rspamd via the Milter protocol.

Install OpenARC on your cPanel AlmaLinux / Rocky Linux server:

dnf install -y epel-release
dnf install -y openarc

Generate dedicated ARC signing keys:

mkdir -p /etc/openarc/keys/enterprise.pk
opendkim-genkey -b 2048 -d enterprise.pk -s arc -D /etc/openarc/keys/enterprise.pk
chown -R openarc:openarc /etc/openarc/keys
chmod 600 /etc/openarc/keys/enterprise.pk/arc.private

Configure /etc/openarc.conf:

# OpenARC Configuration for cPanel Exim
AutoRestart             Yes
AutoRestartCount        5
AutoRestartDelay        10
Syslog                  Yes
SyslogSuccess           Yes
LogWhy                  Yes

# Socket for Exim communication
Socket                  inet:[email protected]
Umask                   002

# Canonicalization & Mode
Canonicalization        relaxed/relaxed
Mode                    sv   # Sign and Verify

# Key Configuration
Domain                  enterprise.pk
KeyFile                 /etc/openarc/keys/enterprise.pk/arc.private
Selector                arc
SignatureAlgorithm      rsa-sha256

# Identity
AuthservID              mail.enterprise.pk

Start and enable OpenARC:

systemctl enable --now openarc
systemctl status openarc

---

Step 2: Publishing the ARC DNS Public Key

Publish the public key generated in Step 1 to your domain’s authoritative DNS zone:

Extract the TXT record:

cat /etc/openarc/keys/enterprise.pk/arc.txt

Sample record format:

arc._domainkey.enterprise.pk.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3..."

Add this TXT record via cPanel -> Zone Editor or PowerDNS authoritative backend.

Verify propagation:

dig +short TXT arc._domainkey.enterprise.pk

---

Step 3: Integrating OpenARC with Exim

Open WHM -> Service Configuration -> Exim Configuration Manager -> Advanced Editor.

In the top configuration block, configure the ARC milter:

# Enable Milter processing in Exim
milter_default_timeout = 10s

# Route forwarded traffic through OpenARC
acl_smtp_data = acl_check_data

begin acl

acl_check_data:
  # Check if message is outbound or forwarded
  warn
    condition = ${if match{$h_X-Forwarded:}{yes}{yes}{no}}
    control   = dkim_disable_verify

  accept

In the transport section under remote_smtp, ensure headers are retained:

remote_smtp:
  driver = smtp
  headers_add = X-Relayed-By: mail.enterprise.pk

Restart Exim:

/scripts/restartsrv_exim

---

Step 4: Testing & Verifying Delivered ARC Headers

Send a test forwarded message to a corporate Gmail inbox. Inspect the full raw message headers:

ARC-Seal: i=1; a=rsa-sha256; d=enterprise.pk; s=arc; t=1727773200; cv=none;
    b=k7Jm9...
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprise.pk;
    s=arc; t=1727773200; c=relaxed/relaxed; bh=47DEQpj8...; h=from:to:subject:date;
    b=x9Zp2...
ARC-Authentication-Results: i=1; mail.enterprise.pk;
    dkim=pass [email protected] header.s=default;
    spf=pass (mail.enterprise.pk: domain of [email protected] designates 192.0.2.14 as permitted sender);
    dmarc=pass (p=REJECT) header.from=sender-domain.com
Authentication-Results: mx.google.com;
    arc=pass (i=1) header.s=arc arc.chain=enterprise.pk;
    dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=sender-domain.com

Notice the critical line: arc=pass (i=1) header.s=arc. Google successfully verified your forwarding node’s ARC seal, preserving the original sender’s reputation and delivering the forwarded email straight to the primary inbox.

For enterprise mailing lists, corporate relays, and high-volume email architectures in Pakistan, evaluate our locally peered Dedicated Servers in Pakistan.