ARC verification belongs after SPF, DKIM and DMARC
Message forwarding can break authentication results. A mailing list changes the envelope sender, and SPF no longer aligns. A forwarder may also modify the message body, which invalidates DKIM. The Authenticated Received Chain (ARC) gives intermediaries a way to record their authentication view and lets a later receiver inspect how the message traveled.
ARC does not turn an untrusted message into an authenticated message from the original domain. It preserves a chain of custody, including ARC-Authentication-Results, ARC-Message-Signature and ARC-Seal fields. The receiving domain still decides how much trust to place in the chain.
Verify the chain in order
The ARC-Seal records the chain state and the cv or chain-validation value. ARC-Message-Signature covers selected message headers and body content. ARC-Authentication-Results records the authentication assessment at that hop.
Start by identifying the ARC sets in the message and validating them as a chain rather than as unrelated signatures. Check the message signature for each set, ensure the seals cover the expected sequence and reject a chain with missing, duplicated or reordered elements. Only a chain whose validation result is cv=pass should influence policy.
The receiving domain should know which intermediaries it trusts to seal ARC. A valid chain from an arbitrary host is still a claim by that host. Restrict trusted sealers to configured infrastructure, review their outbound behavior and remove stale forwarders.
Apply local policy
Run SPF, DKIM and DMARC evaluation on the message as received. Use the ARC result only for the decision it can support, such as recognizing that authentication failed after a known forwarding step. ARC does not remove the need to check the author domain's DMARC policy, the message content or the recipient's own block list.
Keep the raw authentication result, the ARC chain result and the final disposition in logs. That separation makes it possible to explain why a forwarded mailing-list message was accepted and why a direct message with a forged chain was rejected.
Test with a normal SPF failure after forwarding, a broken DKIM signature caused by body modification, a reordered ARC set and a valid chain from an unapproved sealer. Each case should produce a distinct policy outcome.
ARC is useful when its trust model is narrow. It becomes dangerous when a receiver treats every valid chain as proof that the original sender was legitimate.
Top comments (0)