Il existe un protocole présenté depuis sept ans comme la solution au problème le plus ancien de l’authentification des emails. Il porte un nom sérieux, une RFC, et le soutien de Google, LinkedIn et Valimail.
En mai 2026, l’IETF a publié la nouvelle norme DMARC. Elle consacre un paragraphe à ce protocole, et ce paragraphe est un constat d’échec.
Le problème, qui est réel
Un message qui transite par un intermédiaire perd ses garanties. C’est écrit dès l’introduction de la RFC 8617, en juillet 2019 :
« The utility of widely deployed email authentication technologies such as Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) is impacted by the processing of Internet Mail by intermediate handlers. »
Le mécanisme est simple à comprendre. Une liste de diffusion reçoit votre message, ajoute un préfixe au sujet, colle un pied de page de désabonnement, puis le réexpédie depuis ses propres serveurs.
SPF tombe, parce que l’adresse IP d’envoi a changé. DKIM tombe, parce que le contenu a été modifié après la signature. Et DMARC, qui repose sur les deux, tombe à son tour.
La RFC 8617 le formule ainsi : « Failures of authentication caused by the actions of intermediate handlers can cause legitimate mail to be incorrectly rejected or misdirected. »
Ce que ARC propose
ARC ajoute au message une chaîne de garde. Chaque intermédiaire qui manipule le courrier consigne le verdict d’authentification tel qu’il l’a constaté à son arrivée, et signe cette consignation.
L’abstract décrit l’intention sans emphase :
« The Authenticated Received Chain (ARC) protocol provides an authenticated « chain of custody » for a message, allowing each entity that handles the message to see what entities handled it before and what the message’s authentication assessment was at each step in the handling. »
Le destinataire final peut alors décider de faire confiance au verdict rendu en amont, plutôt qu’au sien, cassé par le transit.
Un point de statut mérite d’être noté, parce qu’il est rarement mentionné : la RFC 8617 est classée Experimental. Elle l’était en juillet 2019, elle l’est toujours en septembre 2026. Le document le dit lui-même : « This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. »
Ce que l’IETF en dit en mai 2026
La nouvelle norme DMARC, RFC 9989, traite la question des listes de diffusion dans sa section 7. Elle commence par décrire ce que les gestionnaires de listes ont réellement fait, faute de mieux :
« In the ten years since large consumer mail systems started publishing p=reject policies, mailing list software has all adopted workarounds to make the From: header line DMARC aligned. […] While these workarounds are far from ideal, they are firmly established and list operators treat them as a fact of life. »
Puis vient le paragraphe qui nous intéresse :
« Mail developers have been trying for a decade to invent technical methods to allow mailing lists to continue to work without modifying the From: header line, with a prominent example being the Authenticated Received Chain (ARC) protocol described in [RFC8617]. While work continues, as of this document’s publication, none of the methods have become widely used. »
« None of the methods have become widely used. » Ce n’est pas l’avis d’un observateur. C’est le texte de la norme qui régit l’authentification des emails, publié par l’organisme qui a également publié ARC.
Qui l’a tout de même déployé
Microsoft, et de manière documentée. Sa page de configuration des expéditeurs ARC de confiance, mise à jour le 3 août 2026, décrit précisément le cas d’usage :
« Authenticated Received Chain (ARC) helps reduce inbound email authentication failures from message modification by legitimate email services. ARC preserves the original email authentication information at the email service. You can configure your Microsoft 365 organization to trust the service that modified the message. »
Notez le sens de la manœuvre. Ce n’est pas l’expéditeur qui active ARC : c’est l’administrateur du domaine destinataire qui déclare faire confiance à un intermédiaire nommé. Microsoft insiste d’ailleurs sur la parcimonie : « Add only legitimate, required services as trusted ARC sealers in your Microsoft 365 organization. »
ARC n’est donc pas un réglage d’expéditeur. C’est une décision de réception, prise par quelqu’un d’autre, à propos d’un tiers.
Ce que Google en dit, et ce qu’il n’en dit pas
Google ne publie aucune page de documentation consacrée à ARC. Ni dans l’aide administrateur, ni dans la documentation développeur, ni dans ses lignes directrices pour expéditeurs, où le mot n’apparaît pas.
La seule mention normative se trouve dans une page d’aide utilisateur sur l’authentification des messages, et elle va dans un sens que personne n’attend :
« ARC checks the previous authentication status of forwarded messages. If a forwarded message passes SPF or DKIM authentication, but ARC shows it previously failed authentication, Gmail treats the message as unauthenticated. »
Chez Google, ARC peut donc dégrader un verdict, pas seulement le sauver. Un message qui passerait SPF ou DKIM à l’arrivée sera traité comme non authentifié si la chaîne révèle un échec en amont.
Et il n’existe, côté Google Workspace, aucun équivalent des expéditeurs ARC de confiance de Microsoft. Rien à configurer, rien à déclarer.
La phrase qui règle la question pour l’expéditeur
Elle est dans la foire aux questions des lignes directrices expéditeurs de Google, et elle vaut d’être encadrée :
« DMARC alignment isn’t required for forwarded or mailing list messages, which are sometimes referred to as indirect messages. »
Autrement dit : le cas que ARC prétend résoudre n’est pas, pour Google, un cas qui vous est reproché. Vos messages transférés qui échouent à l’alignement ne comptent pas contre vous.
Cela change complètement l’ordre des priorités. ARC est un sujet passionnant pour qui exploite une liste de diffusion, une passerelle de sécurité ou un service de transfert. Pour l’expéditeur qui envoie une newsletter, c’est un sujet que d’autres traitent à sa place.
Ce que vous faites demain matin
Si vous êtes expéditeur, rien. Vérifiez simplement que vos rapports DMARC ne vous font pas paniquer sur des flux indirects : un transfert qui casse l’alignement est un comportement normal, documenté comme tel par Google, et il ne se corrige pas par une modification de votre côté.
Si vous exploitez une liste de diffusion, la solution éprouvée n’est pas ARC. C’est la réécriture de l’en-tête From, que la RFC 9989 décrit comme universellement adoptée et considérée par les gestionnaires de listes comme un fait acquis.
Si vous administrez un tenant Microsoft 365 et que du courrier légitime arrive cassé après passage par un prestataire identifié, alors la page des expéditeurs ARC de confiance vous concerne vraiment. C’est le seul des trois cas où quelque chose se configure.
Reste une leçon plus générale. Sept ans après sa publication, un protocole soutenu par les plus grands acteurs du courrier reste expérimental et peu déployé. Ce n’est pas une anomalie : c’est le rythme normal de cet écosystème, et il devrait tempérer l’enthousiasme pour la prochaine solution définitive.
Sources
- IETF (juillet 2019). RFC 8617, The Authenticated Received Chain (ARC) Protocol, Experimental
- IETF (mai 2026). RFC 9989, Domain-based Message Authentication, Reporting, and Conformance (DMARC), Standards Track, section 7
- Microsoft (mise à jour le 3 août 2026). Configure trusted ARC sealers, Microsoft Learn
- Google. Check if your Gmail message is authenticated, Gmail Help
- Google. Email sender guidelines FAQ, Google Workspace Admin Help
LaFactory travaille l’emailing sur pièces : en-têtes, enregistrements DNS, journaux de rejet. Aucune promesse de taux d’ouverture, jamais. Contactez-nous pour un audit de délivrabilité.