ARC
TXT (DKIM-style key record) recordRFC 8617Authenticated Received Chain
ARC (Authenticated Received Chain, RFC 8617) preserves email authentication results through forwarding and mailing list hops. When a message is forwarded, the forwarder adds three ARC headers: ARC-Authentication-Results (the original auth results), ARC-Message-Signature (a DKIM-like signature over all ARC headers), and ARC-Seal (a chain seal). The final receiver can verify the ARC chain even if SPF and DKIM now fail due to forwarding.
How it works
An ARC-participating intermediary evaluates authentication results for the message it received, records them in ARC-Authentication-Results (i=N), signs the message state with ARC-Message-Signature (i=N), and seals all ARC headers with ARC-Seal (i=N). The final receiver retrieves the public keys from DNS (same format as DKIM selectors), verifies each ARC-Seal and ARC-Message-Signature in the chain, and checks that the oldest link (i=1) shows the original message passed authentication. If the chain is valid and the original authentication passed, the receiver can deliver the message.
Details
ARC solves the forwarding problem that breaks SPF and DKIM.
The forwarding problem: 1. Alice sends email from [email protected] to [email protected]. 2. Bob's address forwards to his personal [email protected]. 3. When Gmail receives the message, the sending IP is corp.com's server. 4. corp.com's IP is not in example.com's SPF record → SPF fails. 5. If corp.com modified the message (added a footer) → DKIM body hash fails. 6. DMARC fails. Gmail may reject the message even though it was legitimate.
ARC adds a chain of trust: Each hop (forwarder, mailing list) that participates in ARC records what it saw: - ARC-Authentication-Results (i=N): SPF/DKIM/DMARC results at this hop - ARC-Message-Signature (i=N): DKIM-like signature over the message at this hop - ARC-Seal (i=N): seals the ARC-Authentication-Results and ARC-Message-Signature headers
i= is the chain instance number (1 for first hop, 2 for second, etc.).
Final receiver evaluation: The receiver verifies the ARC chain from the oldest (i=1) to the newest. If all ARC-Seals are valid and the i=1 authentication results showed the original message passed, the receiver can choose to trust the ARC chain and deliver the message despite failing SPF/DKIM.
ARC adoption: Google and Microsoft validate ARC. Most mailing list software (Mailman 3, Google Groups) now adds ARC headers. ARC does not override DMARC p=reject outright -- it is a signal the receiver may use to apply a more lenient policy.
ARC is not a replacement for SPF/DKIM/DMARC. It is a complementary mechanism specifically for intermediaries.
DNS record example
; ARC headers added by a forwarder (example.com → forwarder → gmail.com): ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.d=example.com; spf=pass smtp.mailfrom=example.com; dmarc=pass action=none header.from=example.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=forwarder.com; s=arc; h=to:from:subject:date:dkim-signature:mime-version; bh=47DEQpj8HBSa...; b=IzxEcSj6KrRgkD... ARC-Seal: i=1; a=rsa-sha256; t=1721908800; cv=none; # cv=none (first hop), cv=pass (subsequent hops) d=forwarder.com; s=arc; b=Ww0V1bRjS... ; Forwarder publishes public key for ARC verification: arc._domainkey.forwarder.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0..."
On failure
ARC failure means one of the ARC-Seal or ARC-Message-Signature headers failed verification, indicating the chain was tampered with. This is treated as a signal that the forwarding chain cannot be trusted. The final DMARC policy still applies. ARC is advisory -- it helps receivers make a trust decision but does not override a strict p=reject DMARC policy automatically.
Limitations
- !Not universally adopted by all forwarders and mailing lists
- !Does not override p=reject DMARC policies -- merely an advisory signal
- !Requires forwarders to maintain DKIM-like key infrastructure
- !Chain verification complexity increases with each additional hop