technique · réponse sourcée
Authenticated Received Chain (ARC) : définition et fonctionnement
L’Authenticated Received Chain (ARC) est une norme d’authentification des e-mails qui permet aux serveurs de messagerie intermédiaires de signer les résultats des contrôles SPF, DKIM et DMARC. Ainsi, lorsqu’un e-mail est transféré, le serveur destinataire final peut se fier au statut d’authentification d’origine, même si le transfert a cassé les signatures SPF ou DKIM d’origine.
Le fonctionnement technique d’ARC
ARC ajoute trois en-têtes spécifiques à un e-mail lorsqu’il transite par un serveur intermédiaire. L’authentification ARC-Seal fournit une signature numérique sur l’ARC-Message-Seal, qui contient l’ARC-Authentication-Results. Cette chaîne crée un enregistrement vérifiable du statut d’authentification à chaque saut. Si un message est transféré, le serveur suivant peut vérifier la chaîne ARC pour constater que le message était légitime avant que le serveur de transfert ne modifie l’enveloppe ou les en-têtes.
Pourquoi c’est important pour les expéditeurs
ARC est essentiel pour les expéditeurs dont les e-mails sont souvent transférés par des utilisateurs ou des listes de diffusion. Sans ARC, un serveur de transfert modifie souvent l’adresse de l’expéditeur ou le corps du message, ce qui fait échouer SPF et DKIM. Si l’expéditeur applique une politique DMARC stricte en reject, ces e-mails transférés légitimes seront bloqués. ARC offre au destinataire final un mécanisme pour ignorer un échec DMARC si un serveur intermédiaire de confiance a déjà validé le message.
Notes opérationnelles et erreurs courantes
Une erreur courante consiste à croire qu’ARC remplace DKIM ou SPF. ARC est une couche complémentaire qui dépend de ces protocoles. Il ne fonctionne que si le serveur intermédiaire prend en charge ARC et si le serveur destinataire final fait confiance au scelleur ARC. Les expéditeurs doivent tout de même utiliser les outils gratuits de SendHQ (https://sendhq.cc/tools) pour s’assurer que leurs enregistrements DKIM et SPF principaux sont correctement configurés avant de compter sur ARC dans les scénarios de transfert.
Exemple concret de mise en œuvre
Prenons l’exemple d’un utilisateur qui transfère ses e-mails professionnels vers un compte Gmail personnel. Le serveur de l’entreprise signe le message avec DKIM. Le serveur de transfert le reçoit, valide DKIM et ajoute un sceau ARC. Lorsque Gmail reçoit le message, le SPF d’origine échoue, car le serveur de transfert n’est pas un expéditeur autorisé. Cependant, Gmail voit le sceau ARC du serveur de transfert de confiance, vérifie le résultat DKIM d’origine stocké dans l’en-tête ARC et délivre le message au lieu de le rejeter.
Interaction entre ARC et DMARC
ARC sert de filet de sécurité pour DMARC. Alors que DMARC évalue l’état actuel du message, ARC fournit un historique de l’authentification. Si le contrôle DMARC actuel échoue mais qu’une chaîne ARC valide provenant d’une source de confiance existe, le mail transfer agent destinataire peut choisir de passer outre la politique DMARC et d’accepter le message, ce qui réduit les faux positifs des filtres anti-spam.
Les questions que posent les équipes
ARC remplace-t-il DMARC ?
Non, ARC ne remplace pas DMARC. Il permet de préserver les résultats d’authentification afin que DMARC puisse être évalué plus précisément après le transfert d’un message.
Qui doit mettre en œuvre ARC ?
ARC est principalement mis en œuvre par les intermédiaires de messagerie, comme les gestionnaires de listes de diffusion, les services de transfert et les passerelles e-mail d’entreprise.
ARC bloque-t-il tout le spam ?
Non, ARC est conçu pour éviter que des e-mails transférés légitimes soient classés comme spam, pas pour bloquer le spam lui-même. Il repose sur la confiance entre le scelleur et le destinataire.
ARC est-il pris en charge par tous les fournisseurs de messagerie ?
La plupart des grands fournisseurs comme Gmail et Microsoft 365 prennent en charge ARC, mais son adoption varie selon les petits serveurs de messagerie et les systèmes anciens.