1. The Indirect Mail Crisis: Why Intermediaries Break DMARC

Under DMARC (RFC 7489), an email is considered legitimate only if either SPF or DKIM passes in direct domain alignment with the RFC 5322 From: header. This security model functions seamlessly for direct point-to-point mail delivery.

However, when a message traverses an indirect email intermediary:

• SPF Alignment Breaks: The intermediate server connects to the final recipient from its own IP address, which is not authorized in the original sender’s SPF record.
• DKIM Alignment Breaks: If the intermediary modifies the message—such as appending an unsubscribe link, reformatting MIME parts, or altering subject lines—the cryptographic body hash (bh=) or header signature (b=) fails validation.

When both SPF and DKIM fail, a sender with p=reject will have their email dropped by Gmail, Yahoo, and Outlook. ARC solves this by allowing each intermediate hop to record the authentication status it observed upon receipt and sign that assessment with its own cryptographic key before forwarding.

2. Anatomy of the Three ARC Headers: AAR, AMS, and AS

ARC introduces a sequence of three ordered, indexed headers (where i=1 represents the first intermediary, i=2 the second, and so on):

# 1. ARC-Authentication-Results (AAR)
# Records the authentication validation results observed when the intermediary received the email
ARC-Authentication-Results: i=1; mx.intermediary.com;
    dkim=pass header.i=@sender.com header.s=s2026 header.b=Ab12Cd34;
    spf=pass (mx.intermediary.com: domain of alice@sender.com designates 192.0.2.1 as permitted sender) smtp.mailfrom=alice@sender.com;
    dmarc=pass (p=reject sp=reject dis=none) header.from=sender.com

# 2. ARC-Message-Signature (AMS)
# A DKIM-style signature over the message headers and body as modified by the intermediary
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=intermediary.com;
    s=arc2026; t=1761148800;
    h=to:subject:message-id:date:from:mime-version:arc-authentication-results;
    bh=wX892jklSD8923KLJsd923kjsd8=;
    b=KLJds923...[base64 signature]...

# 3. ARC-Seal (AS)
# Seals the entire preceding ARC chain, validating that intermediate headers were not tampered with
ARC-Seal: i=1; a=rsa-sha256; d=intermediary.com; s=arc2026; t=1761148800; cv=none;
    b=Xyz8923...[base64 seal]...

The cv= (Chain Validation) tag indicates the integrity of previous ARC seals: cv=none for the first intermediary, and cv=pass for subsequent intermediaries that verified previous hops.

3. Generating 2048-Bit ARC Keys & DNS Selector Records

ARC signing requires an RSA private key on your PowerMTA server and a corresponding public key published in DNS:

# 1. Generate 2048-bit RSA Private Key for ARC
openssl genrsa -out /etc/pmta/arc2026.key 2048

# 2. Extract Public Key
openssl rsa -in /etc/pmta/arc2026.key -pubout -out /etc/pmta/arc2026.pub

# 3. Set Secure File Permissions
chown pmta:pmta /etc/pmta/arc2026.key /etc/pmta/arc2026.pub
chmod 0600 /etc/pmta/arc2026.key

Publish the public key in your authoritative DNS zone using the _domainkey namespace:

arc2026._domainkey.intermediary.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

4. PowerMTA ARC Directives: Inbound Verification & Outbound Signing

Incorporate the following directives into your PowerMTA configuration to handle both inbound chain verification and outbound ARC signing:

# ==============================================================================
# RFC 8617 AUTHENTICATED RECEIVED CHAIN (ARC) CONFIGURATION
# ==============================================================================

# 1. Inbound ARC Verification
# Evaluates incoming ARC chains from upstream senders on all MX listeners
arc-verify yes

# 2. Outbound ARC Signing Pool
<virtual-mta vmta-arc-forwarder>
    smtp-source-ip 198.51.100.55
    host-name mail.intermediary.com
    
    # Enable ARC signing on forwarded messages
    arc-sign yes
    
    # Path to cryptographic private key
    arc-key /etc/pmta/arc2026.key
    
    # DNS selector and signing domain
    arc-selector arc2026
    arc-domain intermediary.com
    
    # Canonicalization algorithms (relaxed headers / relaxed body)
    arc-canonicalization relaxed/relaxed
</virtual-mta>

5. The 2026/2027 IETF Landscape: ARC Limitations & DMARCbis

While ARC successfully enables major mailbox providers (Gmail, Microsoft, Fastmail) to accept forwarded mail that would otherwise fail DMARC, operators must understand its evolving governance in 2026/2027:

• Reputation Dependency: ARC does not automatically force a mailbox provider to trust an intermediate forwarder. Recipient servers maintain local reputation scores for ARC sealers. If an intermediate forwarder seals spam or phishing traffic, its ARC signatures are ignored.
• DMARCbis (RFC 7489bis): The IETF DMARC working group has actively drafted updates addressing indirect mail flows, clarifying how receivers should interpret ARC chains alongside Sender Rewriting Scheme (SRS).
• Best Practice Recommendation: For bulletproof inbox placement across both consumer and enterprise destinations, deploy ARC signing alongside SRS. SRS guarantees that SPF passes on the forwarder’s return-path, while ARC guarantees that the original DKIM/DMARC pass is cryptographically asserted for receivers that evaluate ARC.

6. Email Authentication Preservation Matrix