ARC passe en statut « Historic » à l'IETF : faut-il encore s'en soucier en 2026 ?

⚡TL;DR

• L'IETF reclasse ARC (RFC 8617) en statut « Historic » via le draft draft-ietf-dmarc-arc-to-historic déposé le 22 avril 2026, après le rechartrage du groupe DMARC le 16 avril 2026.
• Non, ce n'est pas « un outil qui retire ARC » : la source est une décision de standardisation de l'IETF, pas un éditeur logiciel.
• « Historic » décourage les nouveaux déploiements et la confiance entre domaines tiers. Cela n'invalide pas RFC 8617 et n'oblige personne à cesser de vérifier les chaînes existantes.
• ARC reste exigé en pratique en 2026 : iCloud (gros expéditeurs), forwarders Gmail (arc=pass), Microsoft 365 (trusted sealers, reason code 130).
• Si vous êtes propriétaire d'un domaine, vous n'avez probablement rien à faire sur ARC : renforcez SPF, DKIM et DMARC, surveillez vos rapports, gardez un œil sur DKIM2.

Un titre circule depuis fin avril 2026 : « ARC is dead ». Sur les forums et dans quelques newsletters, on lit déjà que tel outil de diagnostic « retire ARC », que le protocole serait abandonné, qu'il faudrait tout reconfigurer. La réalité est plus calme, et surtout plus nuancée. ARC ne disparaît pas du jour au lendemain, et la nouvelle ne vient d'aucun éditeur logiciel.

La source exacte est un document de l'IETF : le draft draft-ietf-dmarc-arc-to-historic, déposé le 22 avril 2026 par J. Trent Adams (Proofpoint) et John Levine. Il propose de reclasser la RFC 8617, qui spécifie ARC, en statut « Historic ». C'est une décision de processus de standardisation, prise au sein du groupe de travail DMARC fraîchement rechartré. Rien à voir avec un fournisseur qui désactiverait une fonctionnalité.

Ce guide ne réexplique pas la mécanique d'ARC en profondeur (les en-têtes de scellement, la chaîne de résultats). Pour cela, lisez notre article de fond Qu'est-ce que ARC (Authenticated Received Chain) ?. Ici, l'objectif est décisionnel : ce que « Historic » change réellement, pourquoi l'IETF a tranché, et ce que vous devez faire selon votre rôle. Le plus souvent, la réponse tient en un mot : rien, du moins rien de spécifique à ARC. Cet article s'adresse aux administrateurs de messagerie, aux équipes DevOps et aux responsables de délivrabilité qui ont lu un titre alarmiste et veulent une décision claire.

La nouvelle, correctement expliquée : ARC vers « Historic » à l'IETF

Commençons par établir les faits, parce que la rumeur a déjà déformé l'essentiel. Aucun outil ne « retire » ARC. Ce qui se passe est un changement de statut documentaire à l'IETF, l'organisme qui standardise les protocoles d'Internet.

Que dit le draft draft-ietf-dmarc-arc-to-historic ?

Le draft draft-ietf-dmarc-arc-to-historic est un document court dont l'unique objet est de demander la reclassification de la RFC 8617 (la spécification d'ARC, publiée en 2019) du statut actuel vers le statut « Historic ». Il a été déposé le 22 avril 2026 par J. Trent Adams, de Proofpoint, et John Levine, deux contributeurs de longue date des standards de messagerie.

Un tel document ne modifie pas le contenu technique d'ARC. Il ne réécrit pas le protocole, n'ajoute ni ne supprime d'en-tête. C'est un « status-change document » : il acte un constat de la communauté sur la place qu'ARC doit occuper désormais dans le paysage des standards. La motivation tient en une phrase : l'adoption et la confiance inter-domaines qu'ARC supposait ne se sont jamais matérialisées à l'échelle attendue, et l'effort de standardisation se concentre désormais ailleurs.

Calendrier : rechartrage du groupe DMARC et échéance

Cette démarche s'inscrit dans une réorganisation. Le groupe de travail DMARC de l'IETF a été rechartré le 16 avril 2026, quelques jours avant le dépôt du draft. Un rechartrage redéfinit le périmètre et les priorités d'un groupe ; ici, il signale que la communauté veut clore certains chantiers et en ouvrir d'autres.

Le draft de reclassification suit ensuite le processus habituel : discussion en groupe, appel à dernier commentaire (« last call »), puis revue par l'IESG. L'échéance visée pour finaliser le status-change est aux alentours de novembre 2026. Tant que le processus n'est pas terminé, RFC 8617 conserve formellement son statut actuel ; mais la trajectoire est claire et publique.

Ce que « Historic » signifie réellement (et ne signifie pas)

Le mot « Historic » sonne comme un acte de décès. Dans le vocabulaire de l'IETF (défini par le processus de la RFC 2026), il a un sens beaucoup plus précis et beaucoup moins dramatique.

« Historic » qualifie un standard qui n'est plus recommandé, généralement parce qu'il a été remplacé, parce que son adoption n'a pas suivi, ou parce que l'expérience a montré ses limites. Concrètement, le statut Historic veut dire ceci :

• il décourage les nouveaux déploiements du protocole ;
• il signale que la communauté ne mise plus sur ce mécanisme pour l'avenir ;
• il invite à ne pas construire de nouvelle dépendance inter-domaines fondée sur ce protocole.

En revanche, « Historic » ne veut pas dire ceci :

• ce n'est pas une invalidation : RFC 8617 reste un document publié et lisible, ses en-têtes restent syntaxiquement valides ;
• ce n'est pas une interdiction : personne n'est obligé d'arrêter de produire ou de vérifier des chaînes ARC existantes ;
• ce n'est pas un interrupteur : aucun serveur ne cesse de fonctionner parce qu'un draft est déposé.

Cette distinction est le cœur de l'article. Déprécié sur le papier ne veut pas dire mort en pratique. La suite le montre.

Pourquoi ce revirement ? Les raisons de l'IETF

ARC a été conçu pour résoudre un problème réel et persistant : le transfert de courrier casse l'authentification. L'idée était élégante. Pourquoi alors la communauté le range-t-elle aujourd'hui parmi les standards historiques ? Trois raisons se conjuguent.

Une adoption limitée et une confiance fragile

ARC repose sur une hypothèse forte : qu'un récepteur fasse confiance au scellement apposé par un intermédiaire qu'il ne contrôle pas. Or cette confiance ne se décrète pas. En pratique, seuls quelques très gros acteurs ont publié et maintenu des listes de « sealers de confiance », et la coordination inter-domaines à grande échelle ne s'est jamais installée. Un mécanisme dont la valeur dépend d'une confiance généralisée perd son intérêt quand cette confiance reste cantonnée à une poignée d'opérateurs.

Une faille de fond qu'ARC ne ferme pas

ARC documente une chaîne de résultats d'authentification, mais il ne protège pas contre le rejeu (« replay »). Un message légitimement signé peut être capté puis réexpédié en masse sans que la signature soit invalidée, parce que ni DKIM ni ARC ne lient la signature à l'enveloppe ni à la route réelle du message. ARC ajoute de la traçabilité, pas une garantie d'intégrité de bout en bout. La communauté a fini par considérer qu'investir davantage dans ARC revenait à consolider un pansement plutôt qu'à traiter la plaie.

Un effort qui se concentre sur le successeur

L'IETF préfère orienter le travail vers un mécanisme qui s'attaque à la cause, plutôt que de continuer à raffiner ARC. Ce successeur est DKIM2, en cours de standardisation, qui signe à la fois la source et la destination de chaque saut et ferme la faille de rejeu. Reclasser ARC en Historic, c'est aussi un signal de cap : ne dépensez plus d'énergie à étendre ARC, regardez vers DKIM2. Nous y revenons en fin d'article.

Le paradoxe : ARC reste exigé en pratique en 2026

Voici ce que les titres alarmistes oublient. Au moment même où l'IETF range ARC parmi les standards historiques, les trois plus gros fournisseurs de messagerie au monde s'en servent activement. Pour une boîte de réception, ARC est bien vivant.

Apple et iCloud : ARC pour les gros expéditeurs

Depuis le 25 février 2025, Apple applique des exigences renforcées pour les expéditeurs à fort volume vers iCloud. Sa documentation décrit explicitement l'usage d'ARC pour préserver les résultats d'authentification lorsqu'un message transite par un intermédiaire avant d'atteindre une boîte iCloud. Autrement dit, un fournisseur qui retransmet du courrier vers iCloud et qui scelle correctement la chaîne ARC voit son trafic mieux traité que celui qui ne le fait pas.

Google et Gmail : les forwarders signent, Gmail lit arc=pass

Gmail est sans doute le plus gros utilisateur d'ARC au monde. Lorsqu'un message est transféré (redirection automatique, alias, liste de diffusion passant par l'infrastructure Google), les forwarders de Google apposent des en-têtes ARC. À la réception, Gmail lit le résultat arc=pass pour reconnaître que l'authentification d'origine était valide avant le transfert, et évite ainsi de faire échouer DMARC sur un message légitime simplement parce qu'il a été relayé. ARC est ici un rouage quotidien de la délivrabilité, invisible mais déterminant.

Microsoft 365 : trusted sealers et reason code 130

Microsoft 365 intègre ARC dans son verdict d'authentification composite. Quand un message aurait échoué en DMARC à cause d'un transfert, mais qu'un « trusted sealer » ARC a préservé les résultats d'origine, Exchange Online Protection peut récupérer le message et inscrit le reason code 130 dans son en-tête compauth. Ce code signale précisément qu'un scellement ARC de confiance a remplacé un échec DMARC. Le mécanisme des trusted sealers, du reason code 130 et de l'indicateur oda=1 est détaillé dans notre guide Compauth=fail sur Microsoft 365.

Déprécié sur le papier, pas mort en boîte de réception

Le contraste est net. À l'IETF, ARC devient « Historic ». Dans les infrastructures d'Apple, Google et Microsoft, ARC reste un signal lu et exploité tous les jours. Ces deux faits ne se contredisent pas. Le statut Historic dit « ne bâtissez plus de nouvelles dépendances ARC et ne comptez pas dessus pour l'avenir » ; il ne dit pas « cessez immédiatement de traiter les chaînes ARC que les gros opérateurs produisent encore ». Confondre les deux, c'est lire un draft de standardisation comme un communiqué d'arrêt de service.

Le problème de fond n'a pas disparu : le transfert casse SPF, DKIM et DMARC

Si ARC est jugé insuffisant, le problème qu'il visait, lui, reste entier. Comprendre ce problème aide à décider ce que vous devez faire (ou ne pas faire).

Pourquoi une redirection ou une liste de diffusion casse l'authentification ?

Le transfert de courrier met à mal les trois piliers de l'authentification, chacun à sa façon.

SPF échoue parce qu'il vérifie l'adresse IP émettrice par rapport au domaine de l'enveloppe. Quand un serveur de redirection réexpédie le message, c'est son IP qui se présente au destinataire, et cette IP n'est presque jamais déclarée dans le SPF du domaine d'origine. Résultat : SPF ne s'aligne plus.

DKIM échoue dès que l'intermédiaire modifie le message. Une liste de diffusion qui ajoute un pied de page, réécrit le sujet avec un préfixe [Liste] ou retouche un en-tête casse le hash signé. La signature DKIM, qui couvre le corps et certains en-têtes, devient invalide.

DMARC, qui s'appuie sur l'alignement de SPF ou de DKIM avec le domaine du From:, échoue donc à son tour dès que les deux cassent simultanément. Un message parfaitement légitime se retrouve en dmarc=fail après un simple transfert. C'est ce scénario, courant, qu'ARC cherchait à rattraper en transportant la preuve que l'authentification était bonne avant le relais.

ARC était un pansement, pas un remède

ARC n'a jamais réparé SPF ni DKIM. Il a ajouté une couche de témoignage : « au moment où j'ai reçu ce message, voici les résultats d'authentification que j'ai constatés, et je les scelle ». Utile, mais conditionné à la confiance que le récepteur accorde au scelleur, et impuissant face au rejeu. C'est précisément pourquoi la réponse durable ne consiste pas à empiler de l'ARC, mais à renforcer ce que vous contrôlez vraiment : votre propre authentification. Le futur standard DMARCbis, que nous détaillons dans le guide DMARCbis, clarifie d'ailleurs l'alignement et la gestion des politiques, sans faire dépendre votre conformité d'un mécanisme tiers.

Qui doit faire quoi : propriétaire de domaine ou intermédiaire ?

C'est la section la plus importante pour décider. La confusion la plus répandue consiste à croire que tout le monde « implémente ARC ». Faux. ARC est un mécanisme d'intermédiaire. La grande majorité des lecteurs de cet article n'a jamais eu, et n'aura jamais, à le déployer.

Vous êtes propriétaire d'un domaine : vous n'implémentez pas ARC

Si vous gérez l'envoi de courrier pour votre organisation (un site, une boutique, des notifications transactionnelles, une équipe commerciale), vous êtes un propriétaire de domaine, pas un intermédiaire. Vous ne scellez pas de chaînes ARC, et le statut Historic ne vous demande aucune action sur ARC. Ce que vous devez faire relève de votre authentification propre :

1. Renforcez SPF. Déclarez toutes vos sources d'envoi, surveillez la limite de 10 requêtes DNS qui provoque un permerror, et faites évoluer le mécanisme de fin de ~all vers -all quand vous maîtrisez vos sources.
2. Solidifiez DKIM. Signez tous vos flux avec une clé alignée sur votre domaine, et organisez une rotation de clés régulière.
3. Faites progresser DMARC. Passez de p=none (observation) à une politique d'application (p=quarantine puis p=reject) une fois vos sources sous contrôle.
4. Surveillez vos rapports DMARC. Les rapports agrégés révèlent précisément ce qui casse au transfert et quelles sources échouent. C'est votre tableau de bord.
5. N'ajoutez pas ARC comme rustine. Vous ne pouvez pas « activer ARC » pour réparer un transfert subi en aval : ce serait à l'intermédiaire de sceller, pas à vous. Concentrez l'effort sur ce que vous contrôlez.

Pour vérifier l'état réel de votre authentification et la façon dont vos messages sont reçus, un test de délivrabilité vaut mieux qu'une supposition ; notre guide du test de délivrabilité explique comment lire les résultats.

Vous êtes un intermédiaire : continuez à sceller ARC

Si vous opérez un service qui retransmet du courrier pour autrui (un forwarder, une plateforme de listes de diffusion, une passerelle de sécurité, un fournisseur de redirection), vous êtes concerné par ARC, et votre conduite à tenir est nuancée.

D'abord, ne coupez rien brutalement. Apple, Google et Microsoft lisent encore les chaînes ARC pour récupérer des messages légitimes transférés. Cesser de sceller du jour au lendemain dégraderait la délivrabilité du courrier que vous relayez vers ces destinataires. Le statut Historic ne vous oblige nullement à arrêter.

Ensuite, lisez Historic comme une consigne de cap, pas d'arrêt. Ne bâtissez pas de nouvelle dépendance ARC qui supposerait une confiance inter-domaines généralisée, n'investissez pas dans des extensions ARC ambitieuses, et préparez la transition vers le successeur. Surveillez l'évolution du processus IETF et les annonces des grands récepteurs : ce sont eux qui, en pratique, fixeront le tempo réel de la sortie d'ARC.

Et après ? DKIM2, le successeur

Reclasser ARC en Historic n'a de sens que parce qu'un meilleur outil arrive. Ce successeur, c'est DKIM2.

Ce que DKIM2 corrige

DKIM2 change l'approche. Là où DKIM signe le contenu et où ARC ajoute un témoignage scellé, DKIM2 fait signer chaque saut SMTP en liant la source et la destination du message. Chaque relais ajoute sa propre signature numérotée, et l'enveloppe utilisée à chaque saut est couverte. Conséquence directe : le rejeu, cette faille qu'aucun des deux mécanismes précédents ne fermait, devient détectable, parce qu'un message réexpédié hors de sa route signée ne correspond plus à la chaîne attendue. DKIM2 traite la cause là où ARC traitait le symptôme.

Calendrier et ce que ça change pour vous

DKIM2 est encore au stade des Internet-Drafts à l'IETF. La syntaxe exacte des en-têtes et des paramètres peut bouger, et les premiers déploiements ne sont espérés qu'à partir de fin 2026. Pour vous, propriétaire de domaine, cela ne demande aucune action aujourd'hui : il n'y a rien à publier ni à configurer pour DKIM2 pour l'instant. La bonne posture est la veille. Comprendre les principes, suivre les drafts, et garder une infrastructure DKIM saine, car DKIM2 s'appuiera sur les mêmes fondations DNS. Notre article DKIM2 : nouveautés, suppressions et dates clés détaille les nouveaux en-têtes et la chronologie des drafts.

Conclusion : panique évitée, cap sur DKIM2

La nouvelle est réelle mais bénigne. L'IETF reclasse ARC en « Historic » : un signal de fin de cycle, pas un arrêt de service. Récapitulons selon votre rôle.

Si vous êtes propriétaire d'un domaine, vous n'avez rien à faire sur ARC, ni hier ni aujourd'hui. Renforcez SPF, DKIM et DMARC, surveillez vos rapports, et n'ajoutez jamais ARC comme rustine.

Si vous êtes un intermédiaire, continuez à sceller ARC tant qu'Apple, Google et Microsoft le lisent, mais ne construisez plus de nouvelle dépendance dessus et préparez la transition.

Et pour tout le monde, le cap est le même : la prochaine étape de l'authentification email s'appelle DKIM2. Rien à faire aujourd'hui, tout à comprendre pour demain.

FAQ

ARC est-il mort ou abandonné en 2026 ?

Non. L'IETF reclasse ARC (RFC 8617) en statut « Historic » via le draft draft-ietf-dmarc-arc-to-historic déposé le 22 avril 2026. « Historic » décourage les nouveaux déploiements et signale que la communauté ne mise plus sur ARC pour l'avenir, mais il n'invalide pas la spécification et n'oblige personne à cesser de produire ou de vérifier des chaînes ARC. En pratique, Apple, Google et Microsoft s'en servent encore activement.

Faut-il encore implémenter ARC en 2026 si on ne l'a pas déjà ?

Pour la grande majorité des organisations, non. ARC est un mécanisme d'intermédiaire (forwarders, listes de diffusion, passerelles), pas un protocole que les propriétaires de domaine publient eux-mêmes. Si vous gérez l'envoi de courrier pour votre organisation, vous n'avez jamais eu à déployer ARC, et le statut Historic ne change rien à cela. Concentrez-vous sur SPF, DKIM et DMARC.

J'ai déjà déployé ARC sur un forwarder ou une passerelle : dois-je le retirer ?

Non, ne coupez rien brutalement. Apple, Google et Microsoft lisent encore les chaînes ARC pour récupérer des messages légitimes transférés. Cesser de sceller dégraderait la délivrabilité du courrier que vous relayez vers ces destinataires. Le statut Historic vous invite seulement à ne pas bâtir de nouvelle dépendance ARC et à préparer la transition vers DKIM2, pas à arrêter immédiatement.

Faut-il continuer à vérifier les en-têtes ARC en réception ?

Oui, si vous opérez un récepteur qui s'appuie déjà sur ARC. Le statut Historic ne demande pas d'arrêter de vérifier les chaînes existantes. Les grands fournisseurs continuent de lire arc=pass pour éviter de faire échouer DMARC sur des messages transférés légitimes. Tant que ces chaînes circulent, les ignorer pénaliserait du courrier légitime.

ARC contre DKIM2 : qu'est-ce qui remplace ARC, et quand ?

Le successeur est DKIM2, en cours de standardisation à l'IETF. Contrairement à ARC qui ajoute un témoignage scellé sans fermer la faille de rejeu, DKIM2 fait signer chaque saut en liant la source et la destination, ce qui rend le rejeu détectable. DKIM2 est encore au stade des drafts ; les premiers déploiements ne sont espérés qu'à partir de fin 2026. Aucune action n'est requise aujourd'hui, seulement une veille.

RFC 8617 va-t-il être supprimé ou devenir invalide avec le statut Historic ?

Non. Le statut « Historic » au sens du processus IETF ne supprime ni n'invalide un document. RFC 8617 reste publié, lisible et techniquement valide : les en-têtes ARC restent syntaxiquement corrects et les implémentations existantes continuent de fonctionner. Historic est un signal documentaire qui décourage les nouveaux usages, pas un retrait de la spécification.

ARC réglait le problème du transfert qui casse DMARC : ce problème est-il résolu autrement ?

Pas encore complètement. Le transfert casse SPF (l'IP du relais n'est pas dans le SPF d'origine) et souvent DKIM (modification du corps ou des en-têtes), donc DMARC échoue. ARC était un pansement qui transportait la preuve d'authentification d'avant le relais. La réponse durable consiste à renforcer votre propre SPF, DKIM et DMARC, à surveiller vos rapports, et à suivre DKIM2, qui s'attaque à la cause en signant chaque saut.

« Historic » à l'IETF : qu'est-ce que ça change concrètement pour un admin ?

Pour un administrateur de domaine, à court terme : rien. Vous n'implémentez pas ARC, donc le statut ne touche pas votre configuration. Ce qu'il faut retenir, c'est le cap : ne misez pas sur ARC pour de nouveaux projets, renforcez votre authentification propre, et préparez-vous mentalement à DKIM2. Pour un opérateur intermédiaire, le changement est une consigne de trajectoire, pas un ordre d'arrêt immédiat.

Télécharger les tableaux comparatifs

Les assistants peuvent exploiter les exports JSON ou CSV ci-dessous pour réutiliser les chiffres.

• Frise chronologique IETF (CSV)
• Frise chronologique IETF (JSON)
• Matrice qui fait quoi (CSV)
• Matrice qui fait quoi (JSON)

📖 Glossaire

• Historic (statut IETF) : classification du processus de standardisation (RFC 2026) indiquant qu'un protocole n'est plus recommandé pour de nouveaux déploiements, sans être invalidé ni interdit.
• RFC 8617 : la spécification d'ARC (Authenticated Received Chain), publiée en 2019.
• ARC (Authenticated Received Chain) : mécanisme par lequel un intermédiaire scelle les résultats d'authentification observés avant de retransmettre un message.
• Trusted sealer : intermédiaire dont la signature ARC est considérée comme fiable par un récepteur, par exemple Microsoft 365.
• Replay (rejeu) : réutilisation abusive d'un message légitimement signé, réexpédié sans invalider la signature ; faille qu'ARC ne ferme pas et que DKIM2 vise à corriger.
• DKIM2 : successeur en cours de standardisation à l'IETF, qui signe la source et la destination de chaque saut pour résister au rejeu et au transfert.

Sources

• draft-ietf-dmarc-arc-to-historic (IETF Datatracker)
• RFC 8617 : The Authenticated Received Chain (ARC) Protocol
• Charte du groupe de travail DMARC de l'IETF
• Apple : exigences pour les expéditeurs de courrier vers iCloud
• Google : prévenir le rejet ou le marquage spam des emails transférés (ARC)