E-mail. Intelligent. Concentré.
Un e-mail rapide et multiplateforme conçu pour filtrer le bruit.
Définition
💡 ARC (Authenticated Received Chain) : un protocole d’authentification des e-mails qui, en gros, garde une trace de ce qui arrive à votre message lorsqu’il transite par différents serveurs. Lorsque des e-mails sont transférés ou modifiés par des listes de diffusion, ARC préserve les résultats d’authentification d’origine afin que les messages légitimes ne soient pas marqués comme spam.
Pourquoi ARC est important
Voici le problème qu’il résout : vous envoyez un e-mail qui passe toutes les vérifications d’authentification (SPF, DKIM, DMARC). Parfait. Mais ensuite, quelqu’un le transfère via le serveur de messagerie de son entreprise, ou il passe par une liste de diffusion qui ajoute un pied de page. Ces modifications peuvent invalider les signatures d’authentification d’origine.
Que se passe-t-il ensuite ? Le serveur de réception voit un message qui prétend venir de vous mais qui ne passe plus l’authentification. Dossier spam. Ou pire, rejeté complètement.
ARC résout ce problème en créant une chaîne de confiance. Chaque serveur qui traite le message ajoute sa propre signature ARC, en indiquant que oui, cet e-mail était légitime lorsqu’il est arrivé ici, même si nous l’avons légèrement modifié avant de le transmettre. Imaginez cela comme une course de relais où chaque coureur signe pour confirmer qu’il a bien reçu le témoin de manière légitime.
Selon les consignes de Google pour les expéditeurs d’e-mails, les e-mails transférés ont beaucoup plus de chances d’échouer aux vérifications d’authentification sans ARC. Cela fait beaucoup d’e-mails légitimes bloqués.
Comment ARC fonctionne-t-il ?
Le protocole ajoute trois en-têtes clés à votre e-mail au fur et à mesure qu’il passe par les serveurs :
ARC-Authentication-Results consigne quelles vérifications d’authentification ont été effectuées et si elles ont réussi. C’est comme un bulletin de notes indiquant que votre e-mail avait un DKIM et un SPF valides lorsqu’il est arrivé pour la première fois sur ce serveur.
ARC-Message-Signature crée une signature cryptographique du contenu du message à cette étape du parcours. Cela prouve que le message n’a pas été altéré de manière malveillante entre les relais (de petites modifications pour le transfert sont normales et attendues).
ARC-Seal relie le tout avec une autre signature qui valide l’ensemble de la chaîne. Chaque serveur ajoute son propre sceau, créant ainsi une séquence liée. Si un maillon de la chaîne est rompu ou suspect, les serveurs de réception peuvent le détecter.
Point intéressant : la chaîne est numérotée. ARC-Seal: i=1, puis i=2, puis i=3. Les serveurs de réception peuvent vérifier qu’il ne manque rien et que chaque serveur intermédiaire légitime a correctement authentifié l’étape précédente.
Et contrairement aux anciens protocoles qui se cassent quand le contenu change, ARC s’attend à des modifications. C’est tout le principe. Il se contente de documenter que ces changements ont eu lieu sur des serveurs de confiance, et non à cause d’un attaquant interceptant votre courrier.
Configurer ARC
ARC nécessite une configuration à la fois sur les serveurs intermédiaires (ceux qui transfèrent ou modifient les messages) et sur les serveurs de réception (ceux qui valident la chaîne ARC). La plupart des utilisateurs n’ont rien à faire, sauf s’ils exploitent leur propre infrastructure de messagerie.
Dans Gmail :
Gmail valide les signatures ARC lors de la réception de messages transférés. Si vous transférez des e-mails vers Gmail, le serveur intermédiaire doit ajouter des en-têtes ARC. Si vous utilisez Google Workspace et transférez des e-mails via vos serveurs vers d’autres destinations, configurez vos serveurs de messagerie pour qu’ils ajoutent des en-têtes ARC. Google fournit des instructions détaillées dans ses consignes pour les expéditeurs d’e-mails aux administrateurs qui gèrent des services de transfert.
Dans Outlook :
Exchange Online prend en charge la validation ARC, mais les administrateurs doivent configurer les scelleurs ARC de confiance. Accédez au portail Microsoft Defender, puis ouvrez Email & Collaboration > Stratégies & règles > Stratégies de menace > Paramètres d’authentification Email > ARC. Ajoutez les domaines de tous les services intermédiaires qui traitent votre messagerie (ils doivent correspondre à la balise « d » dans l’en-tête ARC-Seal). Bonne nouvelle : les organisations Microsoft 365 font automatiquement confiance aux signatures ARC des autres organisations Microsoft 365, donc cette partie est déjà prise en charge.
Dans Spark :
Spark s’appuie sur les paramètres d’authentification des e-mails configurés par votre fournisseur de messagerie (Gmail, Outlook, serveur IMAP personnalisé ou comptes EWS comme Microsoft 365). En tant que client de messagerie, Spark ne gère pas directement la signature ou la validation ARC. Cela se passe au niveau du serveur avant même que les messages n’arrivent dans votre boîte de réception.
Pour les serveurs de messagerie personnalisés :
Si vous gérez votre propre infrastructure, vous devrez ajouter la prise en charge d’ARC à votre serveur SMTP. OpenARC est l’implémentation la plus courante pour Postfix et Sendmail. Vous devrez l’installer, le configurer pour signer les e-mails sortants et valider les chaînes entrantes, puis ajouter la configuration nécessaire (semblable à la configuration DKIM, mais sans enregistrements DNS requis pour ARC).
La partie délicate ? ARC n’aide que si les serveurs intermédiaires et le serveur de réception final le prennent tous les deux en charge. Si la destination ne valide pas ARC, la chaîne n’a aucune importance. Mais son adoption progresse rapidement. Gmail, Yahoo, Microsoft et la plupart des grands fournisseurs valident désormais les chaînes ARC.
Bonnes pratiques ARC
Configurez d’abord les protocoles de base. ARC complète SPF, DKIM et DMARC, il ne les remplace pas. Configurez ces méthodes d’authentification avant de vous préoccuper d’ARC. Sans authentification de base correcte, ARC n’a rien d’utile à préserver.
Surveillez vos résultats d’authentification. La plupart des fournisseurs de services de messagerie proposent des rapports indiquant à quelle fréquence vos messages passent les vérifications d’authentification. Si vous constatez des taux d’échec élevés sur les e-mails transférés même avec ARC, quelque chose est mal configuré. Vérifiez vos en-têtes.
Gardez vos clés DKIM en sécurité. ARC s’appuie sur les signatures DKIM, donc si vos clés DKIM sont compromises, la chaîne ARC n’est pas fiable non plus. Faites tourner les clés périodiquement (tous les six à 12 mois est la norme).
Testez les scénarios de transfert. Envoyez des e-mails de test via des listes de diffusion, des services de transfert et différents clients de messagerie pour vérifier qu’ARC fonctionne correctement. Des outils comme MXToolbox peuvent vous aider à valider votre configuration et à vérifier les en-têtes.
Documentez vos scelleurs de confiance. Si vous configurez la validation ARC, tenez à jour une liste des services intermédiaires auxquels vous faites confiance. Revoyez cette liste chaque trimestre. Les services changent de propriétaire, sont compromis ou ferment. Ne faites pas confiance aux signatures ARC de services que vous n’utilisez plus.
Acceptez que tout le monde ne le prenne pas encore en charge. Certains petits fournisseurs de messagerie n’ont pas encore implémenté la validation ARC. Vos e-mails transférés peuvent donc encore être signalés chez eux. Mais tous les grands acteurs le prennent en charge, ce qui couvre la grande majorité de vos destinataires.
Termes associés