ARC & DKIM2Authenticated Received Chain & DKIM version 2
ARC and DKIM2 solve two different long-standing weaknesses in email authentication — one already standardized and stable, one still being written.
ARC fixes a problem every mailing list and forwarding service causes: SPF and DKIM tend to break the moment a message passes through an intermediary, because the intermediary resends it from a different server or edits the subject line. ARC preserves what the authentication looked like at each hop, so the final receiver can still tell the message was legitimate at its source. DKIM2 is a newer, still-in-progress rework of DKIM itself, aimed at closing a specific attack DKIM was never designed to stop: replaying a validly-signed message to a different, unintended recipient.
How ARC works
ARC (RFC 8617) adds three headers — ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal — that each intermediary in a message's path stamps on. Every "ARC sealer" records the authentication results it observed and its own contribution, cryptographically signed, building a verifiable chain of custody. ARC doesn't authenticate a message on its own; it preserves evidence of earlier authentication so a final receiver can make an informed decision even after SPF or DKIM alignment broke somewhere upstream.
The problem DKIM2 addresses: signature replay
A DKIM signature authenticates the message body and headers, but not who it was actually sent to. That means an attacker who intercepts one legitimately-signed email can resend it, unmodified, to different recipients — the signature still validates, because DKIM never bound it to a specific delivery. DKIM2's draft specification (an active IETF DKIM working group effort as of mid-2026) closes this by binding each signature to the SMTP envelope's MAIL FROM and RCPT TO values, so a signature captured from one delivery fails verification when replayed against a different recipient.
Where DKIM2 stands today
DKIM2 is a draft, not a ratified standard — the core specification (draft-ietf-dkim-dkim2-spec) and its DNS record format are still moving through the IETF DKIM working group, with early interoperability testing between individual vendors underway but no broad mailbox-provider deployment yet. Treat it as a direction to watch, not something to configure today.
How Trustliant handles this
Neither ARC nor DKIM2 is part of Trustliant's engine today — ARC because it addresses forwarding-path authentication that DMARC/SPF/DKIM alignment checking doesn't currently need to parse for a domain's own posture scan, and DKIM2 because it's still a pre-standard draft with no meaningful production deployment to detect. Both are on our radar as candidates for the roadmap as ARC parsing becomes useful for specific client scenarios (heavy mailing-list or forwarding usage) and as DKIM2 moves toward ratification and real adoption.
Questions we get about ARC & DKIM2
- Should I set up ARC or DKIM2 for my domain right now?
- ARC is typically configured by mailing list software, forwarding services, and security gateways — not something a domain owner publishes directly the way DMARC or SPF is. DKIM2 isn't ready for production configuration at all yet; there's no stable specification or receiver support to target.
- Does ARC replace DMARC, SPF, or DKIM?
- No. ARC is a supplement that helps DMARC/SPF/DKIM survive being relayed through intermediaries — it doesn't replace any of them, and a domain with no DMARC record gets no benefit from ARC alone.