Chaque administrateur email a déjà vu ce ticket de support : "J'ai transféré un email important à mon collègue, et il est arrivé dans son dossier spam. Pourquoi ?" La réponse touche à l’un des cas limites les plus frustrants du courrier électronique : la façon dont le transfert casse l’authentification.
Lorsque vous transférez un email, vous le renvoyez en réalité depuis un autre serveur. L’enregistrement SPF d’origine autorisait le serveur de l’expéditeur, pas le vôtre. La signature DKIM d’origine couvrait le contenu exact du message, que le transfert modifie souvent. Au moment où l’email atteint sa destination finale, tous les contrôles d’authentification échouent. Le message ressemble à une falsification, alors qu’il est parfaitement légitime.
ARC—Authenticated Received Chain—a été conçu pour résoudre ce problème. Il crée une chaîne de traçabilité des résultats d’authentification, permettant à chaque serveur qui traite un message d’attester de ce qu’il a observé.
Pourquoi le transfert fait échouer l'authentification
Pour comprendre ARC, vous devez comprendre précisément comment le transfert casse les choses.
SPF vérifie si l’adresse IP du serveur d’envoi est autorisée pour le domaine dans l’adresse 'from' de l’enveloppe. Lorsque vous transférez un email, votre serveur devient l’expéditeur. Votre IP ne figure pas dans l’enregistrement SPF de l’expéditeur original, donc SPF échoue. C’est le comportement attendu—SPF est censé échouer lorsqu’un serveur non autorisé envoie du courrier.
DKIM est plus délicat. Une signature DKIM couvre des parties spécifiques du message, incluant généralement le corps et certains en-têtes. De nombreux systèmes de transfert modifient les messages : ajout de pieds de page, modification des objets, encapsulation du contenu. Toute modification invalide la signature. Même si le relais ne modifie rien, certaines implémentations DKIM sont assez fragiles pour que de légers changements d’espaces ou d’ordre des en-têtes cassent la validation.
DMARC relie tout cela. Si SPF et DKIM échouent tous les deux, DMARC échoue. Et si l’expéditeur original a une politique DMARC stricte (p=reject), le message transféré est entièrement rejeté. Le destinataire ne le voit jamais.
Cela crée un vrai problème. Les listes de diffusion, les services de transfert d’emails et le routage de courrier en entreprise impliquent tous des transferts légitimes. Sans solution, des politiques d’authentification strictes casseraient de vastes pans de l’usage normal du courrier électronique.
Comment fonctionne ARC
ARC ne corrige pas SPF ni DKIM—il fonctionne à côté d’eux. L’idée est simple : chaque serveur qui traite un message consigne ce qu’il a observé et signe cet enregistrement. Les serveurs en aval peuvent alors voir l’historique complet des résultats d’authentification.
Lorsqu’un message arrive sur un serveur compatible ARC, le serveur effectue les contrôles d’authentification habituels : SPF, DKIM, DMARC. Il crée ensuite trois nouveaux en-têtes.
L’en-tête ARC-Authentication-Results consigne ce que le serveur a observé. SPF a-t-il réussi ou échoué ? DKIM a-t-il été validé ? Quel a été le résultat DMARC ? C’est essentiellement un instantané de l’état de l’authentification à ce stade du parcours du message.
L’en-tête ARC-Message-Signature est une signature de type DKIM couvrant le contenu du message. Cela permet aux serveurs en aval de vérifier que le message n’a pas été modifié depuis que ce serveur l’a traité.
L’en-tête ARC-Seal rassemble le tout. Il signe les en-têtes ARC eux-mêmes, créant une chaîne où toute altération serait détectable. Chaque serveur ajoute son propre ensemble d’en-têtes ARC, incrémente un numéro de séquence et signe l’ensemble des en-têtes ARC précédents plus les siens.
Le résultat est une chaîne de traçabilité. Le destinataire final peut voir : "Le serveur A a reçu ce message et SPF a réussi. Le serveur B l’a transféré et DKIM était toujours valide. Le serveur C est en train de le remettre." Même si l’authentification actuelle échoue, la chaîne montre que l’authentification était valide auparavant.
ARC en pratique
Suivons un scénario réel. Vous envoyez un email depuis le domaine de votre entreprise à une liste de diffusion. La liste le transfère à tous les abonnés.
Votre email quitte votre serveur avec des SPF et DKIM valides. Il arrive sur le serveur de la liste. Le serveur de liste vérifie l’authentification—tout passe. Il ajoute des en-têtes ARC enregistrant ces résultats et les signe.
Le serveur de liste transfère ensuite le message aux abonnés. Ce faisant, il ajoute un pied de page et modifie l’expéditeur de l’enveloppe (afin que les rebonds reviennent à la liste, pas à vous). Ces changements cassent votre signature DKIM d’origine et font échouer SPF.
Lorsque le message arrive sur le serveur de messagerie d’un abonné, l’authentification actuelle échoue. Mais le serveur voit la chaîne ARC. Il peut vérifier les signatures ARC et constater que lorsque la liste de diffusion a reçu le message, l’authentification a réussi. Si le serveur fait confiance à la liste (sur la base de sa réputation), il peut accepter le message malgré les échecs d’authentification actuels.
C’est l’idée clé : ARC ne rend pas automatiquement le courrier transféré digne de confiance. Il fournit des informations que les serveurs destinataires peuvent utiliser pour prendre de meilleures décisions. La confiance dépend toujours de la réputation des intermédiaires.
Implémenter ARC
Si vous exploitez un serveur de messagerie qui transfère des messages—une liste de diffusion, un service de transfert ou un routage de courrier d’entreprise—vous devriez implémenter ARC. C’est vous qui cassez l’authentification ; vous devez fournir la chaîne de traçabilité qui aide les destinataires à faire confiance au résultat.
La plupart des logiciels de serveur de messagerie modernes prennent en charge ARC. Postfix, Exim et Microsoft Exchange ont tous des capacités ARC. La configuration implique généralement de générer une paire de clés (similaire à DKIM), de publier la clé publique dans le DNS et d’activer la signature ARC dans la configuration de votre serveur.
L’enregistrement DNS ressemble à un enregistrement DKIM parce que, essentiellement, c’en est un. ARC utilise le même format de clé et le même mécanisme de validation. Vous publiez un enregistrement TXT à selector._domainkey.yourdomain.com contenant votre clé publique.
Pour les serveurs destinataires, la validation ARC est généralement automatique si votre logiciel la prend en charge. La décision de faire confiance aux résultats ARC—et de déterminer quels intermédiaires sont dignes de confiance—relève d’une politique locale. La plupart des serveurs utilisent des données de réputation : si un opérateur de liste de diffusion bien connu signe une chaîne ARC, cela a plus de poids qu’un serveur inconnu.
Les limites d'ARC
ARC n’est pas une solution miracle. Il comporte de vraies limites que vous devez comprendre.
Premièrement, ARC nécessite la confiance dans les intermédiaires. Si un serveur malveillant ajoute de faux en-têtes ARC affirmant que l’authentification a réussi, les serveurs en aval pourraient être trompés. C’est pourquoi la réputation est importante—vous ne devriez pas faire confiance aux chaînes ARC provenant de sources inconnues ou à faible réputation.
Deuxièmement, ARC n’aide pas si le premier relais est malveillant. Si un attaquant envoie un message usurpé directement à une liste de diffusion, la liste enregistrera fidèlement que l’authentification a échoué et le transférera quand même. ARC préserve les résultats d’authentification ; il ne crée pas une authentification là où il n’y en avait pas.
Troisièmement, l’adoption est encore incomplète. Bien que des acteurs majeurs comme Google et Microsoft valident ARC, de nombreux petits serveurs de messagerie ne le font pas. Votre chaîne ARC soigneusement construite pourrait être complètement ignorée.
Enfin, ARC ajoute de la complexité. Plus d’en-têtes, plus de signatures, plus d’éléments susceptibles de casser. Le diagnostic des problèmes de délivrabilité devient plus difficile lorsque vous devez suivre plusieurs couches de validation ARC.
Interaction entre ARC et DMARC
La relation entre ARC et DMARC est importante. Les politiques DMARC indiquent aux destinataires quoi faire lorsque l’authentification échoue. ARC fournit un contexte supplémentaire susceptible de changer cette décision.
Lorsqu’un message échoue DMARC mais possède une chaîne ARC valide montrant un succès d’authentification antérieur, le destinataire est face à un choix. Suivre strictement la politique DMARC conduirait à rejeter le message. Mais la chaîne ARC suggère qu’il s’agit d’un courrier légitime qui a été transféré.
La plupart des destinataires qui prennent en charge ARC vont outrepasser les échecs DMARC pour les messages avec des chaînes ARC dignes de confiance. C’est tout l’objectif—laisser passer les courriers transférés légitimes malgré des échecs d’authentification. Mais il s’agit d’une décision de politique locale, pas d’une exigence standard.
Si vous êtes propriétaire de domaine avec une politique DMARC stricte, comprenez qu’ARC peut amener à outrepasser votre politique pour les courriers transférés. C’est généralement ce que vous voulez—vous ne souhaitez probablement pas que vos emails soient rejetés simplement parce que quelqu’un les a transférés. Mais si vous avez des exigences de sécurité spécifiques, vous devriez comprendre cette interaction.
Faut-il se soucier d'ARC ?
Si vous exploitez une infrastructure de messagerie qui transfère des messages, oui. Implémenter ARC est un acte de bonne citoyenneté—vous aidez l’écosystème email à mieux fonctionner.
Si vous vous contentez d’envoyer des emails depuis votre domaine, ARC est moins directement pertinent. Vous n’avez rien de spécial à faire ; ARC est géré par les intermédiaires. Mais comprendre ARC vous aide à diagnostiquer des problèmes de délivrabilité lorsque vos emails sont transférés.
Si vous évaluez la délivrabilité des emails, connaître ARC aide à expliquer pourquoi certains messages transférés réussissent quand d’autres échouent. Un message transféré via un grand fournisseur avec une bonne implémentation ARC s’en sortira mieux qu’un message transféré via un petit serveur sans prise en charge d’ARC.
Frequently asked questions
L'ARC remplace-t-il DKIM ?
Non. ARC complète DKIM. Vous avez toujours besoin de DKIM sur vos messages sortants. ARC aide à préserver les résultats d'authentification lorsque les messages sont transférés et que les signatures DKIM se cassent.
Puis-je implémenter ARC sans DKIM ?
Techniquement oui, mais cela n'a guère de sens. ARC est conçu pour préserver les résultats d'authentification, y compris DKIM. Si vous n'utilisez pas DKIM, il y a moins à préserver.
Comment savoir si mes emails sont signés ARC lors du transfert ?
Vérifiez les en-têtes des messages transférés. Recherchez les en-têtes ARC-Authentication-Results, ARC-Message-Signature et ARC-Seal. Ils indiquent qu'un traitement ARC a eu lieu.
Gmail prend-il en charge ARC ?
Oui. Google a été l'un des principaux développeurs d'ARC et prend entièrement en charge la signature et la validation. Les messages transférés via Gmail auront des en-têtes ARC, et Gmail prend en compte les chaînes ARC lors de l'évaluation du courrier entrant.