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

Par CaptainDNS
Publié le 23 octobre 2025

Qu'est-ce que ARC (Authenticated Received Chain) ?

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.

Statut IETF 2026 : ARC fait l'objet d'une demande de reclassification en statut « Historic » à l'IETF (draft draft-ietf-dmarc-arc-to-historic, 2026). Cet article décrit le fonctionnement d'ARC, qui reste valable. Pour le statut en évolution et la décision d'implémenter ou non, voir Faut-il encore implémenter ARC en 2026 ?.

Schéma : parcours d'un e-mail et ajout des sceaux ARC à chaque relais

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, ... :

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

Les trois en-têtes ARC et leur rôle (AAR, AMS, AS)

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

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

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 ?

Vérifier toutes les signatures ARC-Message-Signature et ARC-Seal en partant du plus grand i.
Contrôler la continuité : aucun i manquant, chaque sceau couvre les précédents.
Observer cv= dans le dernier ARC-Seal (valeur déclarée par le scelleur).
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.

C'est exactement ce que fait Microsoft 365 lorsqu'un trusted ARC sealer annule un échec DMARC : l'en-tête Authentication-Results affiche alors compauth=pass reason=130. Pour décrypter ce verdict et les autres codes (000, 001, 601), voir le guide sur l'authentification composite et les reason codes compauth.

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

Légende des valeurs cv=none/pass/fail dans ARC-Seal

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.