Forwarding authentication forensics

ARC & Forwarding Analyzer

Reconstruct ARC sets, instance continuity and preserved authentication evidence after forwarding or mailing-list transformations.

arc header analyzerauthenticated received chain checkeremail forwarding dmarc arcarc seal analyzer
Reconstruct ARC evidence across forwarding boundariesStructural ARC analysis is separated from receiver-stamped cryptographic validation.

What this analysis does

Paste headers containing ARC-Seal, ARC-Message-Signature and ARC-Authentication-Results. Mailybox groups each ARC instance, checks whether the structural sets are complete and contiguous, surfaces chain-validation declarations and separates structural evidence from a trusted receiver’s cryptographic ARC result.

Forwarding breaks the authentication a receiver would otherwise verify. ARC exists to carry the earlier result across that boundary, so a final receiver can see what an intermediary observed before the message was modified. Reading an ARC chain is how a DMARC failure on legitimate forwarded mail is explained.

Reviewed against RFC 8617 on 29 August 2026

Why forwarding breaks authentication

A forwarding system replaces the envelope sender with its own address, which breaks SPF alignment for the original domain. Mailing lists go further by modifying the subject or appending a footer, which invalidates the DKIM signature covering that content. After both, no aligned path remains and DMARC fails on entirely legitimate mail.

ARC addresses this by having each participating intermediary record the authentication state it observed and seal that record cryptographically. A final receiver that trusts the intermediary can then consider the earlier result instead of only the broken current one.

  • Forwarding replaces the envelope sender, breaking SPF alignment.
  • Content modification invalidates the DKIM signature over that content.
  • ARC preserves the earlier result across the boundary.

Instance numbering must be continuous

Each ARC set carries an instance number, and the sets must form an unbroken sequence starting at one. A gap means a system in the path either did not implement ARC or removed a set, and the chain cannot be validated as complete.

A chain that has already failed validation stays failed. Once an intermediary records a failure, subsequent participants preserve that state rather than repairing it, so a chain marked fail at instance two remains fail regardless of what follows.

Trust is a receiver decision, not a protocol guarantee

A valid ARC chain does not compel any receiver to accept a message. It supplies evidence that a receiver may use if it trusts the sealing intermediary, and that trust relationship is entirely local policy. Major providers maintain their own view of which forwarders are credible.

For a domain moving to DMARC enforcement, this means forwarded mail cannot be assumed safe simply because ARC is present. The reliable protection remains an aligned DKIM signature that survives forwarding, with ARC as a supplementary signal rather than a substitute.

Example: a mailing list that broke the signature

Evidence supplied
A message forwarded through a list that appended a footer, carrying two ARC sets.

How to read the result
The analysis reports the current DKIM signature as invalid because the body changed, identifies the list as the modifying intermediary, and shows that the first ARC set recorded a passing authentication state before the modification occurred.

Known limits

  • ARC is only present when intermediaries in the path implement it.
  • A valid chain is evidence, not an instruction; receivers decide whether to act on it.
  • A chain that failed at an earlier hop cannot be repaired by later participants.

Common questions

Does ARC fix DMARC failures from forwarding?

Not on its own. It preserves evidence that a receiver may choose to use. An aligned DKIM signature that survives forwarding remains the durable protection.

Why is the chain incomplete?

An intermediary in the path did not implement ARC or removed a set. Instance numbers must form an unbroken sequence from one.

Should my domain implement ARC?

Only if you forward mail on behalf of others. Ordinary sending domains consume ARC evidence rather than producing it.

Primary references