ARC

Forwarding breaks the usual authentication of a message. When a mailing list or a forwarding service passes a message on, it often modifies it, for example by adding a footer, and that change breaks the original DKIM signatures. It also sends the message from its own servers, which breaks SPF. The final receiver then sees a message that fails authentication, even though it was authentic when the intermediary received it.

The Authenticated Received Chain (ARC, RFC 8617) addresses this problem. Each intermediary records the authentication results it saw in a set of three headers, ARC-Authentication-Results, ARC-Message-Signature and ARC-Seal, and signs that set. A later receiver can verify the chain of these sets. If it trusts the intermediaries, it can then take the original results into account. ARC was published as an experimental specification, and it is expected to move to Historic status once its successor is published, as Sealing describes.

Verification

ARC verification is configured with arcVerify on the SenderAuth singleton (found in the WebUI under Settings › MTA › Inbound › Sender Authentication). The field is an expression that returns one of three modes. It is disable by default, so ARC chains are ignored until verification is enabled:

Mode	Effect
relaxed	Verify the chain and record the result for the spam filter (ARC_ALLOW, ARC_REJECT, ARC_INVALID, ARC_DNSFAIL, ARC_NA).
strict	Also refuse a message whose chain fails: 550 5.7.29 ARC validation failed., or 451 4.7.29 for a temporary DNS error. A message without an ARC chain is accepted.
disable	Do not verify.

The following object body enables verification for all messages:

{
  "arcVerify": {"else": "relaxed"}
}

ARC signatures take their a= tag from DKIM, and with it their algorithms (RFC 8617, section 4.1.3). Stalwart verifies chains signed with RSA-SHA256 and with Ed25519. It also verifies chains signed with RSA-SHA1, because some intermediaries still use it. ARC verification runs at the DATA stage, after DKIM.

Sealing

Stalwart verifies ARC chains, but it no longer adds ARC sets to the messages it forwards, and it has no setting to do so. The role of ARC passes to DKIM2, the successor to DKIM. In DKIM2, every system that handles a message adds its own signature and records the changes it makes. RFC 8617 is expected to move to Historic status once DKIM2 is published, and Stalwart stopped sealing ahead of that change.

Messages that Stalwart relays, for example through mailing lists, are still signed with DKIM and DKIM2 when the signing expression selects a domain. They carry no ARC seal of this server.