ARC : conserver la confiance d'un e‑mail quand il traverse des intermédiaires

En deux mots : ARC (Authenticated Received Chain) est un standard qui permet aux relais (listes de diffusion, passerelles anti‑spam, redirections, etc.) de préserver et sceller les résultats d'authentification (SPF, DKIM, DMARC) qu'ils ont observés. Le destinataire peut ainsi décider intelligemment de faire confiance au message même si SPF/DKIM ont logiquement échoué après modification ou redirection.

Pourquoi a‑t‑on besoin d'ARC ?

Sans ARC, un message légitime peut être rejeté après une redirection :

• le SPF échoue car l'IP émettrice devient celle du relais ;
• la signature DKIM d'origine peut devenir invalide si le relais modifie les en‑têtes ou le corps (bannière, footer, antispam) ;
• en conséquence, DMARC échoue côté destinataire, alors que l'e‑mail était correct à l'origine.

ARC permet au relais de dire : « J'ai reçu un message qui passait SPF/DKIM/DMARC, voici mes résultats et je les signe. »
Le serveur final examine la chaîne de sceaux pour décider si l'e‑mail reste digne de confiance.

Comment ARC fonctionne (vue d'ensemble)

À chaque relais, trois en‑têtes ARC sont ajoutés, avec un index i=1, i=2, ... :

1. ARC-Authentication-Results (AAR) - recopie les résultats SPF/DKIM/DMARC tels que vus par le relais.
2. ARC-Message-Signature (AMS) - signature cryptographique du message tel qu'observé par le relais (analogue à DKIM).
3. ARC-Seal (AS) - sceau qui signe l'ensemble (AAR + AMS + sceaux précédents) pour chaîner la confiance.

Exemple d'en‑têtes ARC (simplifié)

ARC-Seal: i=1; a=rsa-sha256; d=relay.example.net; s=arc1; cv=none; b=...
ARC-Message-Signature: i=1; a=rsa-sha256; d=relay.example.net; s=arc1; h=from:to:subject:date:message-id; bh=...; b=...
ARC-Authentication-Results: i=1; relay.example.net; spf=pass smtp.mailfrom=example.org; dkim=pass header.d=example.org; dmarc=pass header.from=example.org

• i= : position dans la chaîne (1 au premier relais, puis +1 à chaque hop).
• d= / s= : domaine et selector (comme DKIM) utilisés pour publier la clé publique DNS.
• cv= (dans ARC-Seal) : Chain Validation déclarée par le relais pour la chaîne qu'il voit ; valeurs usuelles : none, pass, fail.
• h=, bh=, b= : champs classiques de signature (liste d'en‑têtes signés, empreinte du corps, signature).

« Je vois des en‑têtes ARC sans redirection, normal ? »

Oui. De grands fournisseurs (ex. webmails, suites collaboratives, passerelles de sécurité) signent systématiquement les messages entrants avec ARC.
Objectifs : sceller un point de vérité interne, tracer le passage dans leur infrastructure et faciliter d'éventuels transferts ultérieurs sans perdre la confiance.

Comment le destinataire évalue la chaîne ARC ?

1. Vérifier toutes les signatures ARC-Message-Signature et ARC-Seal en partant du plus grand i.
2. Contrôler la continuité : aucun i manquant, chaque sceau couvre les précédents.
3. Observer cv= dans le dernier ARC-Seal (valeur déclarée par le scelleur).
4. Croiser avec DMARC : si SPF/DKIM actuels échouent, décider d'accorder du crédit aux résultats consignés dans les ARC-Authentication-Results fiables.

Important : ARC n'impose pas d'accepter un message ; il apporte un contexte vérifiable pour une décision plus fine côté destinataire.

Bonnes pratiques (côté opérateur)

• Signez et validez ARC sur vos relais (listes, alias, passerelles antispam).
• Conservez les en‑têtes ARC existants ; n'enlevez pas les sceaux valides.
• Gérez vos clés (rotation, TTL DNS, surveillance des échecs de vérif).
• Limitez les modifications de message après la pose du sceau (bannières, réécritures) ou re‑scellez après modification.
• Journalisez les résultats DMARC influencées par ARC pour en mesurer l'impact.

Erreurs fréquentes

• Ajouter un ARC-Authentication-Results sans ARC-Message-Signature et ARC-Seal.
• Casser la chaîne (index i dupliqué/sauté, sceau ne couvrant pas le précédent).
• Faire confiance aveugle à n'importe quel domaine d= inconnu. La réputation du scelleur compte.

Foire aux questions

ARC remplace‑t‑il DKIM/DMARC ?
Non. Il complète SPF/DKIM/DMARC en préservant des résultats observés par les relais.

Qui peut ajouter ARC ?
Tout intermédiaire de transport (MTA, passerelle, service d'e‑mail) qui observe le message.

Que signifie cv= exactement ?
La déclaration du scelleur sur l'état de la chaîne qu'il voit : none (pas de chaîne précédente), pass (chaîne cohérente et vérifiable), fail (chaîne invalide). Le destinataire refait sa propre validation.

Pourquoi un même message a‑t‑il plusieurs i= ?
Chaque relais incrémente i et ajoute son triptyque AAR/AMS/AS.

Pour aller plus loin

• IETF - RFC 8617: Authenticated Received Chain (ARC) : https://datatracker.ietf.org/doc/html/rfc8617
• RFC 8601 - Authentication-Results Header Field (contexte pour AAR) : https://datatracker.ietf.org/doc/html/rfc8601

---

Fiche mémo

• But : préserver et sceller les résultats SPF/DKIM/DMARC à travers les relais.
• 3 en‑têtes : ARC-Authentication-Results (résultats) + ARC-Message-Signature (signature du message) + ARC-Seal (sceau de chaîne).
• Décision côté destinataire : signatures valides + réputation du scelleur + règles DMARC internes.