Si vous êtes un expéditeur ordinaire et qu’un guide vous a dit de déployer ARC, ce guide se trompe deux fois. ARC est ajouté par un intermédiaire pendant qu’il relaie le message de quelqu’un d’autre : un expéditeur d’origine n’a donc rien à sceller. Et le groupe de travail de l’IETF qui en a la charge a publié en avril 2026 un document demandant que la spécification soit reclassée en Historic, au motif que l’expérience est terminée.
Rien de tout cela ne rend ARC inutile à lire. Il explique toujours pourquoi un message réacheminé a été remis ou refusé, et Apple le demande toujours sur le courrier réacheminé vers ses boîtes. Le lire et le déployer sont deux décisions différentes, et une seule des deux prend fin.
ARC consigne ce qu’un intermédiaire a vu, et c’est pourquoi un expéditeur n’a rien à sceller
DMARC casse au réacheminement. Une liste de diffusion ou une adresse de réacheminement relaie votre message depuis ses propres serveurs, donc SPF échoue sur un domaine d’enveloppe qui n’est pas le vôtre, et la moindre modification des en-têtes ou du corps casse votre signature DKIM. Le message était légitime quand vous l’avez envoyé et échoue à l’authentification quand il arrive.
ARC était la réponse proposée. Chaque intermédiaire consigne les résultats d’authentification qu’il a vus à l’arrivée, signe cette consignation et scelle la chaîne de tout ce qui précède. Un destinataire final peut alors voir le résultat d’origine tel que le premier saut l’a observé, alors même que la preuve elle-même a disparu.
Celui qui signe est l’intermédiaire, pas vous. Pour ARC vous ne publiez rien, il n’existe aucun enregistrement DNS sur votre domaine au-delà de la clé DKIM qu’un intermédiaire utiliserait si vous en étiez un, et le jeu d’en-têtes n’apparaît que sur des messages relayés. Un guide qui dit à un domaine d’envoi ordinaire d’« activer ARC » l’a confondu avec DKIM.
La chaîne fait trois en-têtes par saut, et la numérotation est la vérification
Chaque saut ajoute trois en-têtes, et la RFC 8617, section 5.2, rend le jeu et la séquence stricts.
| En-tête | Ce qu’il porte |
|---|---|
| ARC-Authentication-Results | Les résultats d’authentification vus par ce saut à l’arrivée |
| ARC-Message-Signature | Une signature du message tel que ce saut l’a reçu |
| ARC-Seal | Une signature de la chaîne jusqu’ici, portant l’état de validation de la chaîne |
Quatre règles font de ces en-têtes une chaîne et non un tas :
- Les numéros d’instance vont de 1 vers le haut, sans interruption, jusqu’à 50 au maximum. Un trou ou une répétition donne une chaîne malformée, pas une chaîne à laquelle il manque un maillon.
- Chaque instance porte exactement un exemplaire de chacun des trois en-têtes. Un doublon est un défaut.
- Le sceau de l’instance 1 doit porter
cv=none, et toute instance ultérieure doit portercv=pass. Cette valeur est la déclaration du signataire sur tout ce qui précède. - Un
cv=failà l’instance la plus haute met fin à la chaîne à cet endroit. Une fois qu’un saut a consigné un échec, rien après lui ne rétablit la chaîne.
La structure se vérifie hors ligne et les signatures non, et c’est toute la forme de ce qu’un outil d’en-têtes peut honnêtement vous dire. Un lecteur qui regarde l’instance la plus haute et rapporte la valeur qu’il y trouve a sauté la vérification qui compte, car c’est la continuité depuis 1 qui donne un sens à la séquence.
L’IETF met fin à ARC, et le dit en toutes lettres
draft-ietf-dmarc-arc-to-historic-00, publié le 22 avril 2026 par Todd Adams, de Proofpoint, et John Levine, de Taughannock Networks, est un document de groupe de travail et non une proposition individuelle. Il rend la RFC 8617 obsolète s’il est approuvé et demande que la spécification soit marquée Historic.
Ses conclusions sont inhabituellement directes. L’expérience est terminée. Ceux qui l’implémentent et l’exploitent ne devraient plus compter sur ARC et devraient cesser tout nouveau déploiement à l’échelle d’Internet. Ceux qui l’ont déjà déployé devraient planifier son retrait ou confiner son usage à des contextes contrôlés au sein d’un même domaine. Les nouveaux déploiements sont déconseillés parce qu’ils ont peu de chances d’apporter une information utile au traitement du courrier.
La raison donnée n’est pas que la cryptographie ait échoué. C’est que la vérification sans réputation ne peut pas écarter en toute sécurité une politique d’application. Celui qui évalue doit décider s’il fait confiance à chaque signataire de la chaîne avant d’agir sur ses affirmations, ce qui suppose d’exploiter un système de réputation pour intermédiaires, et après dix ans personne n’en a construit un qui fonctionne à l’échelle d’Internet. Ce que les déployeurs ont construit à la place, ce sont des listes d’autorisation d’intermédiaires en qui ils avaient déjà confiance, ce qui marche en bilatéral et ne se généralise pas. Le document en fait la leçon centrale : les signatures ne sont pas de la confiance.
Une seconde limite est plus précise. Quand un intermédiaire modifie un message, ARC désigne bien qui l’a modifié mais n’a aucun mécanisme pour dire ce qui a changé ni pourquoi, et le destinataire en revient donc à juger la réputation de l’intermédiaire. Les éléments utiles sont repris dans les travaux successeurs de DKIM, appelés pour l’instant DKIM2, qui évitent une chaîne parallèle et un tissu de confiance distinct saut par saut.
Notez le statut honnêtement : c’est un Internet-Draft et non une RFC. Il expire en octobre 2026 s’il n’avance pas. Ce qu’il documente, en revanche, tient moins d’une proposition que d’une description de l’endroit où l’effort s’est déjà arrêté.
Apple est le seul fournisseur à le demander encore, et il le demande à l’intermédiaire
Les exigences d’Apple pour les expéditeurs, publiées en février 2025, demandent ARC sur le courrier réacheminé vers les boîtes Apple. C’est le seul des quatre grands fournisseurs à le demander, et c’est la raison honnête de montrer ARC dans un outil plutôt que de l’ignorer.
Lisez la portée avec attention, car c’est là que la chose est mal rapportée. La demande couvre le courrier réacheminé, et celui qui est en mesure d’y répondre est le service de réacheminement. Si vous exploitez un service de réacheminement, une liste de diffusion ou une passerelle de messagerie, cela vous concerne. Si vous envoyez du courrier marketing ou transactionnel depuis votre propre domaine, non, et aucun changement de configuration de votre côté ne produit une chaîne ARC.
Les trois autres grands fournisseurs de boîtes demandent SPF, DKIM et DMARC, et aucun ne mentionne ARC. Sur les domaines que nous testons pour le Unspam 2026 Email Deliverability Benchmark, 48 % publient une politique DMARC, et c’est là le travail réellement inachevé.
Que faire à la place quand le réacheminement casse votre DMARC
Le problème pour lequel ARC a été construit est réel et demande toujours une réponse. Les réponses disponibles sont moins exotiques.
- Assurez-vous que DKIM est aligné et signe les en-têtes qui survivent. DKIM est l’identifiant qui passe un réacheminement, parce qu’il couvre le message et non la connexion. Si seul SPF est aligné, le réacheminement vous retire le seul identifiant qui réussissait.
- Gardez la liste des en-têtes signés conservatrice. Une signature portant sur des en-têtes que les intermédiaires réécrivent couramment casse plus souvent qu’une signature portant sur l’essentiel.
- Lisez vos rapports DMARC avant de supposer que la cause est le réacheminement. Les services de réacheminement apparaissent comme des sources que vous ne reconnaissez pas, réussissant DKIM et échouant à SPF, une forme distinctive et facile à séparer des vrais problèmes.
- Ne restez pas en
p=noneà cause du réacheminement. Le courrier qui réussit un DKIM aligné survit au réacheminement, et les rapports vous disent quelles sources n’y parviennent pas avant toute application. - Si vous exploitez un intermédiaire, suivez les travaux DKIM2 plutôt que de lancer maintenant un déploiement ARC.
Notre guide des enregistrements DMARC couvre la politique et les rapports, et l’identifiant que le réacheminement casse en premier fait l’objet de notre guide du Return-Path.
Ce qu’un outil peut rapporter, et ce qu’il devrait refuser de rapporter
Une chaîne ARC dans un message reçu est une preuve sur son parcours, et elle mérite d’être lue exactement à ce titre.
Notre analyseur d’en-têtes d’e-mail rapporte la structure de la chaîne : combien de jeux sont présents, si les numéros d’instance forment une séquence continue depuis 1, si chaque jeu est complet, si les valeurs cv suivent la règle de leur position, et le domaine qui a scellé chaque saut. Il rapporte un cv=fail comme le point où la chaîne a pris fin.
Ce qu’il ne fait pas, c’est vérifier les signatures, et il ne vous dit pas que la chaîne est digne de confiance. Ce sont des affirmations différentes, et le document est explicite : la validité d’une chaîne sans jugement de réputation n’est pas une base pour une décision de remise. Un outil qui affiche un badge ARC vert affirme quelque chose sur quoi aucun destinataire n’agirait.
Pour les enregistrements qui décident réellement de la remise, notre guide de l’authentification des e-mails explique comment SPF, DKIM et DMARC dépendent les uns des autres. Pour voir les résultats d’authentification sur un vrai message, y compris toute chaîne ARC ramassée en chemin, faites un test de spam gratuit.
