Authenticated Received Chain (ARC): Forwarding and Mailing Lists

Anil Jalela · Published Feb 12, 2026 · 14 min read

Forwarders and mailing lists can legitimately change a message after its first authentication checks. They may alter the body, rewrite the subject or replace the envelope sender. Those changes can break DKIM or SPF alignment by the time the message reaches its final destination. Authenticated Received Chain, or ARC, carries signed evidence of what an intermediary observed before and after handling the message.

How ARC preserves authentication evidence

ARC is defined by RFC 8617 as an ordered chain of authentication assessments. Each participating intermediary adds an ARC set with the same instance number across three fields: ARC-Authentication-Results, ARC-Message-Signature and ARC-Seal. The authentication-results field records the intermediary’s assessment, the message signature covers message content, and the seal binds the new set to the chain that came before it.

A final receiver validates chain structure and signatures, evaluates the identity and reputation of ARC sealers, and applies local policy. A valid chain proves that the signed assertions have not been altered since sealing; it does not prove that every assertion is honest. ARC therefore supplies evidence. It does not turn a DMARC failure into an automatic pass and it does not replace SPF, DKIM or DMARC at the originating domain.

What a valid ARC chain does and does not prove

The common operational mistake is to treat cv=pass as a delivery instruction. Chain validation only describes the chain. A receiver still decides whether it trusts the intermediaries and whether the message is safe. Conversely, rejecting every forwarded DMARC failure without considering trusted ARC evidence can penalize normal forwarding paths.

ARC also has strict construction rules. Instance numbers must be contiguous, a set must be complete, and an intermediary must assess the incoming chain before extending it. Header reordering, duplicate sets, signing the wrong content or using an unavailable selector will make downstream validation fail. Logging only “ARC failed” hides the exact instance and field that operators need.

ARC processing sequence for intermediaries and receivers

1. Authenticate on receipt. Evaluate SPF, DKIM and DMARC before local modifications. Preserve the actual results and relevant identifiers rather than reconstructing them later.
2. Validate any incoming ARC chain. Check set completeness, contiguous instance numbers, signatures, seals and the prior chain-validation state. Record why validation passed or failed.
3. Perform authorized message handling. Apply mailing-list or forwarding changes. Minimize unnecessary body and signed-header modification because preservation still helps non-ARC receivers.
4. Create ARC-Authentication-Results. Record the authentication assessment made by this administrative domain, using the new ARC instance and an authserv-id controlled by the handler.
5. Create ARC-Message-Signature. Sign the handled message with a protected private key and a published selector. Choose covered headers deliberately and operate key rotation like DKIM.
6. Seal the chain. Generate ARC-Seal over the current set and prior seals, with the correct chain-validation value. Do not extend a malformed chain as though it passed.
7. Validate at the final receiver. Verify cryptography and structure, identify each sealer, compare ARC evidence with current authentication results and use a documented local policy.
8. Retain trace evidence. Log message identifiers, instance count, selectors, sealers, validation results and disposition without retaining more message content than operations require.

Interpret ARC validation evidence correctly

Worked forwarding and mailing-list scenario

A subscriber forwards corporate mail through a forwarding service. SPF no longer aligns because the forwarder’s IP sends the message, and a footer addition breaks the original DKIM body hash. Before modifying the message, the forwarder saw aligned DKIM pass and DMARC pass. It validates the incoming ARC chain, adds a complete ARC set and signs it.

The destination verifies the chain and recognizes the forwarder as a trusted handler. It may use the sealed earlier result as one signal while still applying anti-abuse, content and account policy. If the same message arrives with a valid chain from an unknown low-reputation sealer, the destination can decline to rely on it. Cryptographic validity and operational trust are separate decisions.

ARC evidence to log and retain

• Chain structure: highest instance, missing or duplicate instances, set completeness and the cv value at each hop.
• Cryptography: sealer domain, selector, algorithm, key retrieval result, signature result and failure reason.
• Authentication context: SPF identity, DKIM signing domain, DMARC alignment and result observed at the sealing hop.
• Handling path: message ID, queue ID, receiving host, sealer sequence and timestamps correlated with Received fields.
• Outcome: whether ARC evidence influenced disposition, which trust rule applied and whether the message passed current authentication independently.

ARC implementation and trust mistakes

• Treating ARC as an allowlist: attackers can create valid ARC chains too; receiver trust and abuse controls remain necessary.
• Sealing reconstructed results: authentication must be assessed at receipt, before changes remove the evidence being described.
• Removing selectors too quickly: downstream receivers may validate delayed mail after a rotation, so old public keys need an overlap period.
• Logging only pass or fail: without instance, sealer and signature details, a chain failure is difficult to repair.
• Modifying more than necessary: ARC helps forwarding, but preserving original DKIM validity where possible remains valuable.

ARC deployment checklist

• Implement ARC from a maintained library or MTA feature and follow RFC 8617 field construction.
• Assess SPF, DKIM and DMARC immediately when the message enters the administrative domain.
• Validate the incoming chain before adding a new instance.
• Protect ARC private keys and publish selectors with a safe rotation overlap.
• Keep instances contiguous and add all three fields in each ARC set.
• Define which sealers the receiving policy trusts and why.
• Never describe ARC as overriding DMARC or guaranteeing inbox placement.
• Capture structured diagnostics and test real mailing-list and forwarding paths.

Read one complete ARC set in a message header

An ARC instance is complete only when the same instance number appears in all three ARC fields. The following shortened header illustrates the relationship; production signatures are much longer.

ARC-Authentication-Results: i=1; forwarder.example;
  spf=pass smtp.mailfrom=sender.example;
  dkim=pass header.d=sender.example;
  dmarc=pass header.from=sender.example
ARC-Message-Signature: i=1; a=rsa-sha256;
  d=forwarder.example; s=arc-2026; c=relaxed/relaxed;
  h=from:to:subject:date:message-id; bh=...; b=...
ARC-Seal: i=1; a=rsa-sha256; d=forwarder.example;
  s=arc-2026; cv=none; b=...

For the first ARC set, cv=none is expected because there is no earlier ARC chain to validate. Later sealers record whether the chain they received validated. The final receiver performs its own validation rather than trusting the text of cv.

Follow ARC instances across multiple handlers

When another participating intermediary handles the message, it adds instance 2 rather than replacing instance 1. A later mailing-list gateway may add instance 3. All instance numbers must be present and ordered, and each instance must contain AAR, AMS and AS.

A missing instance, repeated instance, incomplete set or invalid earlier seal makes the chain unusable as a clean sequence. Do not delete the broken chain and create a new instance that makes the history appear intact.

Separate ARC cryptography from sealer trust

ARC validation has two layers. Cryptographic and structural validation determines whether the chain is intact. Local policy determines whether assertions from a particular sealer deserve weight. A malicious operator can sign a perfectly valid chain containing a misleading assessment.

Trust rules should be explicit, reviewed and narrow. Record the sealer domain, path, observed behavior, abuse history and reason for relying on it. ARC is one input to disposition, not a sender certification program.

Diagnose a broken ARC chain from the failing instance

Start with the raw message received by the final system. Preserve header order and folding. Count every AAR, AMS and AS field, group them by i=, and find the earliest instance that is incomplete or fails verification. Later failures may be consequences of that first defect.

# Inspect ARC and authentication fields without changing the message
grep -iE "^(ARC-|Authentication-Results:|Received:|DKIM-Signature:)" message.eml

# Query the public key used by an ARC signer
dig +short TXT arc-2026._domainkey.forwarder.example

• Body-hash mismatch: compare the message after the sealing hop with later footer, disclaimer, encoding or line-ending changes.
• Signature mismatch: inspect covered header fields, duplicated headers, canonicalization and modification after sealing.
• Key lookup failure: verify selector spelling, DNS response, TXT syntax, DNSSEC state where relevant and key-rotation overlap.
• Invalid chain structure: locate missing, duplicated or incomplete instances and identify the handler that constructed them.
• Valid chain ignored: examine receiver trust policy; cryptographic pass does not require the receiver to rely on that sealer.

Test ARC with messages that reproduce real forwarding changes

A useful test suite includes an unmodified forward, a changed envelope sender, a subject rewrite, a footer addition, a message with an existing valid ARC chain, and deliberately malformed instances. Verify both the intermediary output and the final receiver decision.

Retain the original message, handled message, keys or selector versions, validator output and final Authentication-Results. Repeat tests during key rotation and MTA upgrades. If the implementation is provided by an MTA or filtering product, document the exact feature version and configuration owner instead of attempting to construct ARC signatures in ad hoc scripts.

Use ARC beside DMARC rather than rewriting DMARC results

At the final hop, evaluate the message as received. SPF may pass for the intermediary but fail alignment with the visible From domain. An original DKIM signature may survive, or a list modification may break its body hash. The current DMARC result reflects those current aligned identities.

ARC can preserve evidence that an earlier trusted handler observed aligned authentication before legitimate modification. Receiver policy may use that evidence when deciding disposition, but logs should keep the current DMARC result, ARC validation result and ARC-based policy decision as separate fields. This separation prevents a downstream dashboard from claiming ordinary DMARC pass when the receiver actually relied on a trusted intermediary.

Read one complete ARC set before judging the chain

ARC-Authentication-Results: i=2; mx.forwarder.example;
  spf=pass smtp.mailfrom=sender.example;
  dkim=pass header.d=sender.example;
  dmarc=pass header.from=sender.example
ARC-Message-Signature: i=2; a=rsa-sha256;
  d=forwarder.example; s=arc2026; c=relaxed/relaxed;
  h=from:to:subject:date:message-id; bh=...; b=...
ARC-Seal: i=2; a=rsa-sha256; d=forwarder.example;
  s=arc2026; cv=pass; b=...

The three fields for an instance share the same i= value. ARC-Authentication-Results records what the handler assessed. ARC-Message-Signature protects the handled message. ARC-Seal binds the current set to the preceding chain. A parser should retain field order, raw values and canonicalized verification result rather than flattening everything into one pass flag.

ARC headers are prepended. Instance numbers must form a contiguous sequence, and each valid set contains exactly one AAR, AMS and AS for the instance and signing algorithm. Duplicate, missing or out-of-order fields are structural evidence, not a reason to guess the intended chain.

Interpret ARC-Seal chain validation states correctly

A downstream validator computes its own chain result. It does not trust the text merely because a sealer wrote cv=pass. Likewise, ARC chain validation is separate from DMARC evaluation and final spam or abuse policy.

Build a sealer trust model outside cryptographic validation

ARC proves integrity and signer identity for verifiable sets. It does not prove that the signer performed correct authentication, protected its service from abuse or described modifications honestly. Receiver policy therefore needs reputation and accountability for the sealing administrative domain.

Never create a global rule that “ARC pass overrides DMARC.” Use ARC as one input when the forwarding path and sealer are accountable.

Test the forwarding mutations ARC is meant to explain

Run these only in a controlled lab. Preserve the original, post-handler and final received EML files plus ARC verifier output. The goal is to learn which mutation breaks which signature, not to weaken DKIM signing.

Operate ARC keys, logging and failure tests like production identity

arc_event(
  message_id, received_at, handler_domain,
  instance_count, computed_chain_result,
  failing_instance, failing_field, selector,
  key_lookup_result, original_dmarc_result,
  final_dmarc_result, local_disposition,
  verifier_version
)

Protect private keys, publish selectors before use, rotate without breaking messages in transit, and monitor DNS lookup failures. Log computed results and failure location, not only the header’s claimed cv. Limit content retention and use message hashes or governed samples where possible.

Failure tests should cover missing set members, duplicate instances, unavailable selector, expired or revoked operational key, altered body, invalid seal, chain length at implementation limits and an untrusted but cryptographically valid sealer. Verify that local policy degrades safely rather than accepting or rejecting every forwarded message.

Combine ARC with current authentication and abuse evidence

A local receiver should document which sealers can influence disposition, the minimum observation history, abuse exceptions and review schedule. The policy must remain resilient when ARC is absent because many valid paths do not seal.

Diagnose a chain that breaks only through one mailing list

A domain’s DKIM passes at direct recipients but fails after a list adds a subject tag and footer. The list adds ARC set 1 with cv=none after evaluating the original message. A downstream security gateway then modifies the body but creates an incomplete set 2 without ARC-Message-Signature. Final receivers report chain failure.

Preserve the original submission, list output, gateway output and final message. Verify DKIM and ARC independently at every boundary. The corrective action is not to remove DMARC or trust all ARC. Fix the gateway set construction, minimize unnecessary mutation, rotate/publish its selector correctly, and test downstream validators. During recovery, receiver policy can use the known list’s earlier evidence only under its existing trust model and other abuse controls.

Primary references

• RFC 8617: The Authenticated Received Chain Protocol
• RFC 8601: Message Header Field for Indicating Message Authentication Status
• RFC 9989: Domain-based Message Authentication, Reporting and Conformance

Continue learning

• Fix SPF, DKIM and DMARC
• Email Security and Privacy
• Email Format and Structure
• Email Standards RFC Reference