ARC : la chaîne de réception authentifiée (Authenticated Received Chain)

Les trois en-têtes d'ARC

Chaque participant ARC ajoute trois champs d'en-tête au message, numérotés par « instance » (i=1 pour le premier intermédiaire, i=2 pour le suivant, etc.) :

• ARC-Authentication-Results (AAR) — l'instantané des résultats d'authentification (SPF, DKIM, DMARC) que l'intermédiaire a constatés à l'arrivée, avant toute modification. C'est le témoignage proprement dit.
• ARC-Message-Signature (AMS) — une signature, très proche d'une signature DKIM, calculée sur le message (en-têtes et corps) tel que l'intermédiaire le retransmet. Elle capture l'état du message à ce maillon précis.
• ARC-Seal (AS) — une signature qui couvre l'ensemble des en-têtes ARC des instances précédentes plus l'AAR et l'AMS courants. C'est le sceau qui verrouille la chaîne : il protège son intégrité et son ordre, de sorte qu'un maillon ne puisse pas être retiré ou réordonné sans que ça se voie.

Chaque ARC-Seal porte une étiquette de validation de chaîne, cv= (chain validation), qui vaut none, pass ou fail. Elle indique si la chaîne, jusqu'à ce maillon, tenait la route. Le sceau le plus récent résume l'état global : une chaîne en cv=pass est intacte de bout en bout.

Comment un destinataire s'en sert

Quand un message arrive avec une chaîne ARC, le destinataire final procède en deux temps. D'abord, il valide la chaîne : les sceaux sont-ils cryptographiquement corrects, dans le bon ordre, non altérés ? Si oui, la chaîne est en cv=pass.

Ensuite — et c'est là que tout se joue — il décide s'il fait confiance aux intermédiaires qui ont scellé la chaîne. Si oui, il peut appliquer un override de politique locale : au lieu de rejeter le message parce qu'il échoue à DMARC ici et maintenant, il consulte l'AAR le plus ancien, constate que le message passait l'authentification à l'origine, et le livre malgré tout. Le courrier légitime de la liste de diffusion est sauvé.

Cette décision reste entièrement à la main du destinataire. ARC ne force rien : il fournit une preuve exploitable, et c'est le destinataire qui choisit de s'en servir. Les grands fournisseurs de messagerie — Google, Microsoft et d'autres — apposent et honorent ARC à grande échelle, ce qui rend le mécanisme réellement utile en pratique, même s'il reste formellement expérimental.

Un exemple concret

Soit un message écrit vers une liste de diffusion professionnelle. Il part du serveur de l'expéditeur, parfaitement authentifié : SPF et DKIM alignés pour son domaine. La liste le reçoit, ajoute [Groupe-Métier] au sujet et un pied de page légal, puis le ré-expédie aux trois cents abonnés. En chemin, le SPF d'origine ne vaut plus rien (l'envoi vient désormais de la liste) et la signature DKIM est brisée (le sujet et le corps ont changé). Chez un abonné dont le domaine est en p=reject, ce message devrait finir rejeté.

Mais la liste participe à ARC. Au moment où elle a reçu le message, elle a scellé un maillon attestant « à l'arrivée, ce message passait l'authentification pour ce domaine ». L'abonné est chez un grand fournisseur qui honore ARC : il valide la chaîne, la trouve intacte (cv=pass), fait confiance à la liste, et livre le message malgré l'échec DMARC apparent. Sans ARC, l'intervention sur la liste finissait à la corbeille ; avec, elle arrive. C'est exactement ce scénario, répété des milliers de fois par jour, qui rend le passage à reject moins effrayant qu'il n'y paraît — à condition, comme on va le voir, de ne pas en faire une confiance aveugle.

ARC ne remplace pas DMARC — et n'est pas automatique

Il faut être honnête sur les limites, sinon on se raconte des histoires.

D'abord, ARC repose entièrement sur la confiance. Rien n'empêche techniquement un intermédiaire malveillant de sceller une chaîne affirmant qu'un message frauduleux « passait l'authentification à l'origine ». Un sceau ARC valide prouve seulement que la chaîne n'a pas été altérée après coup — pas que son contenu est honnête. C'est pourquoi le destinataire n'accorde d'override qu'aux intermédiaires qu'il connaît et juge dignes de confiance. ARC déplace le problème vers une question de réputation, il ne l'efface pas.

Ensuite, ARC ne se substitue pas à DMARC ni au travail d'alignement. Il ne rattrape que le courrier indirect légitime qui a été cassé en transit. Il ne fait rien pour un message qui n'était pas authentique au départ, et il ne dispense en rien de publier SPF, DKIM et DMARC correctement. En cas de confusion des rôles, un détour par SPF, DKIM et DMARC expliqués ensemble s'impose d'abord : ARC est une rustine sur les bords, pas le socle.

Enfin, tous les destinataires n'honorent pas ARC, et tous les intermédiaires ne le scellent pas. C'est une couche d'amélioration, déployée inégalement, pas une garantie universelle.

ARC et le passage à p=reject

Pour un responsable qui veut durcir sa politique, ARC change discrètement le calcul du risque. La grande crainte de reject — voir disparaître le courrier légitime qui transite par des listes et des redirections — est précisément le cas qu'ARC est fait pour rattraper, chez les destinataires qui l'honorent. En pratique, une part importante du courrier indirect des utilisateurs traverse Google ou Microsoft, qui savent exploiter la chaîne. Cela ne veut pas dire que le sujet peut être ignoré, mais que le risque est plus faible qu'on ne le croit souvent.

La bonne méthode ne change pas : la montée en politique s'appuie sur l'observation des rapports, sans supposer qu'ARC couvre partout. La trajectoire prudente est détaillée dans atteindre p=reject sans casser ses emails. ARC est un filet supplémentaire tendu par les destinataires, pas une autorisation à durcir les yeux fermés.

Où ARC se voit dans les rapports

ARC laisse une trace observable. Dans les rapports d'agrégation, lus en détail, une source qui échoue à l'alignement mais a tout de même été livrée apparaît souvent avec une disposition évaluée à none assortie d'une raison de type « politique locale » — la signature d'un override, fréquemment lié à une chaîne ARC valide. Repérer ces lignes évite une erreur classique : croire qu'une source « en échec » est un problème à corriger, alors qu'il s'agit de courrier indirect légitime rattrapé par le destinataire. Savoir lire cette nuance fait la différence entre paniquer sur un faux problème et comprendre réellement sa posture.

Faut-il « configurer ARC » ?

Pour la très grande majorité des propriétaires de domaines, la réponse est non — et c'est une bonne nouvelle. Contrairement à SPF, DKIM ou DMARC, ARC ne se publie pas sur le domaine de l'expéditeur sous la forme d'un enregistrement DNS qu'il contrôle. Ce sont les intermédiaires (listes, passerelles, services de redirection) et les destinataires qui l'implémentent. Côté expéditeur, il n'y a rien à activer : le bénéfice d'ARC est passif, quand les messages transitent par des intermédiaires qui scellent et arrivent chez des destinataires qui honorent.

Le seul cas où ARC devient une affaire interne est celui d'une organisation qui opère elle-même une infrastructure recevant puis ré-expédiant du courrier au nom d'autrui — une passerelle de sécurité, un service de redirection, une plateforme qui relaie. Là, apposer correctement les en-têtes ARC devient une responsabilité, pour ne pas casser l'authentification des messages transmis. Ce chantier rejoint la famille des standards avancés que sont MTA-STS et TLS-RPT : utiles, ciblés, et pertinents surtout pour qui opère de l'infrastructure de messagerie.

En résumé

ARC est la chaîne de témoignages qui permet à un destinataire de sauver le courrier légitime cassé par un intermédiaire, en s'appuyant sur l'authentification d'origine plutôt que sur le résultat abîmé qu'il observe. Trois en-têtes (AAR, AMS, AS), une validation de chaîne, un override laissé à la discrétion — et fondé sur la confiance — du destinataire. C'est un filet précieux contre les faux positifs du courrier indirect, honoré par les grands fournisseurs, mais ni un substitut à DMARC, ni une garantie universelle, ni quelque chose qui se configure sur le domaine expéditeur.

La meilleure façon de voir tout cela concrètement reste d'examiner ses propres flux. Un passage du domaine dans l'analyseur DMARC gratuit montre les sources réelles, alignées ou non, et aide à distinguer le vrai problème du courrier indirect que les destinataires savent déjà rattraper.