ARC (Authenticated Received Chain) : forwarding email sécurisé 2026

Introduction

Vous avez soigneusement configuré SPF, DKIM et DMARC sur votre domaine. Les emails directs arrivent parfaitement dans la boîte de réception de vos destinataires. Mais dès qu’un collègue transfère un de vos messages depuis son compte universitaire, ou qu’une mailing-list redistribue votre communication d’entreprise, le message finit en spam — parfois rejeté purement et simplement. L’objet de ce tutoriel est précisément ce scénario, qui touche des dizaines d’équipes professionnelles et étudiantes en Afrique de l’Ouest chaque jour.

Le protocole ARC (Authenticated Received Chain), standardisé dans la RFC 8617 publiée en juillet 2019 par l’IETF, a été conçu exactement pour résoudre ce problème. Son principe est élégant : chaque intermédiaire de confiance (serveur de forwarding, gestionnaire de mailing-list) signe et préserve les résultats d’authentification qu’il a observés, constituant une chaîne cryptographiquement vérifiable. Le destinataire final — Gmail, Outlook, Zoho — peut alors remonter cette chaîne et comprendre que le message a été légitimement relayé, même si les contrôles SPF et DKIM originaux ne peuvent plus passer.

Sans ARC, la situation est la suivante : un email de equipe@votreentreprise.sn passe parfaitement SPF et DKIM. Il est ensuite transféré par la plateforme de mailing-list de votre partenaire basé à Abidjan. Le serveur de réception de l’employé final vérifie le DMARC de votreentreprise.sn : SPF fail (le mail vient d’un IP inconnu), DKIM possiblement cassé si la liste a modifié le sujet ou le pied de page. Résultat : DMARC fail, message en spam ou rejeté. ARC interrompt ce cycle en insérant une preuve cryptographique que l’intermédiaire était légitime et que l’email était authentifié à son entrée.

Ce tutoriel vous guide à travers l’activation d’ARC sur les deux solutions MTA les plus utilisées dans les infrastructures auto-hébergées d’Afrique de l’Ouest en 2026 : Postfix avec OpenARC et Mailcow. Vous apprendrez ensuite à vérifier que tout fonctionne et à monitorer vos rapports DMARC pour confirmer que la chaîne ARC est respectée par les grands récepteurs de messagerie.

Prérequis

Avant de commencer ce tutoriel, vous devez disposer d’une compréhension fonctionnelle des trois protocoles d’authentification email fondamentaux. SPF (Sender Policy Framework, RFC 7208) autorise des IP spécifiques à envoyer au nom de votre domaine via un enregistrement DNS TXT. DKIM (DomainKeys Identified Mail, RFC 6376) signe cryptographiquement chaque message avec une clé privée dont la clé publique est publiée en DNS. DMARC (RFC 7489) unifie ces deux mécanismes et indique aux récepteurs quoi faire en cas d’échec (rien, quarantaine ou rejet). Si ces concepts ne sont pas clairs, consultez d’abord le pilier du cluster avant de revenir ici.

Du côté infrastructure, vous avez besoin d’un accès root sur un serveur Linux exécutant soit Postfix (version 2.6 minimum, idéalement 3.x), soit une instance Mailcow à jour (build 2024 ou 2025 recommandé). Le tutoriel Postfix utilise l’interface Milter (Mail Filter) — la même qu’OpenDKIM et SpamAssassin. Si vous avez déjà OpenDKIM en place, la configuration ARC s’intègre proprement à côté. Pour Mailcow, l’activation se fait entièrement via l’interface web, sans toucher à la CLI.

Comptez environ 30 minutes pour la configuration initiale, plus 24 à 48 heures pour observer les premiers rapports DMARC confirmatoires. Une entrée DNS supplémentaire sera nécessaire pour publier la clé publique ARC de votre intermédiaire — le même type d’enregistrement TXT que pour DKIM.

Étape 1 — Pourquoi DMARC échoue sur les emails transférés

Pour comprendre pourquoi ARC est nécessaire, il faut d’abord comprendre précisément ce qui se casse lors d’un forwarding. Prenons un exemple concret : Alice envoie un email depuis alice@companyA.sn vers liste@groupeB.ci, une mailing-list hébergée sur le serveur Mailman de groupeB.ci. Mailman redistribue cet email à tous les membres de la liste, dont Bob qui utilise bob@outlook.com.

Quand Outlook reçoit ce message, il effectue ses contrôles d’authentification. La vérification SPF consulte l’enregistrement SPF de companyA.sn et vérifie si l’IP émettrice (celle du serveur Mailman de groupeB.ci) est autorisée à envoyer pour ce domaine. La réponse est non — cette IP n’appartient pas à companyA.sn et ne figure pas dans son enregistrement SPF. SPF fail.

La vérification DKIM tente de valider la signature cryptographique insérée par le serveur de companyA.sn sur le message original. Mais Mailman a (très souvent) modifié le message : ajout d’un pied de page avec les instructions de désinscription, modification du sujet avec le nom de la liste entre crochets, ou réencapsulation du corps. Ces modifications, même minimes, invalident la signature DKIM car celle-ci couvre précisément le corps et certains en-têtes du message. DKIM fail.

DMARC vérifie ensuite l’alignement : est-ce qu’au moins un des deux mécanismes (SPF ou DKIM) passe ET est-ce que le domaine authentifié est aligné avec le domaine dans l’en-tête From ? Ici les deux ont échoué. Si la politique DMARC de companyA.sn est p=reject, Outlook rejette le message. Si c’est p=quarantine, il va en spam. Ce comportement est techniquement correct du point de vue DMARC : le protocole ne sait pas que Mailman est un intermédiaire légitime — il voit simplement un email de companyA.sn envoyé par une IP non autorisée avec une signature cassée.

C’est exactement là qu’ARC intervient. Si le serveur Mailman de groupeB.ci supporte ARC, il va attester : « J’ai reçu ce message, j’ai vérifié son authentification à l’entrée (SPF pass, DKIM pass, DMARC pass), je l’ai relayé en modifiant le corps, et je signe cette attestation avec ma propre clé ARC. » Outlook, recevant ce message avec la chaîne ARC intacte, peut décider d’honorer cette attestation si groupeB.ci est un intermédiaire de confiance connu, et livrer le message normalement malgré les échecs SPF/DKIM du message relayé.

Étape 2 — Les trois en-têtes ARC

Le standard ARC, tel que défini dans la RFC 8617, introduit trois nouveaux en-têtes email que chaque intermédiaire ARC-compatible insère dans le message. Ces en-têtes forment une séquence numérotée : si un message passe par trois intermédiaires ARC successifs, on trouve trois jeux d’en-têtes numérotés de 1 à 3. Comprendre leur rôle respectif est indispensable pour diagnostiquer les problèmes.

Le premier en-tête est ARC-Authentication-Results (AAR). Il documente les résultats d’authentification observés par l’intermédiaire au moment où le message lui est parvenu, avant toute modification. Il contient les résultats SPF, DKIM et DMARC tels qu’ils existaient à l’entrée du serveur relayeur, ainsi que l’identifiant de l’instance (i=1 pour le premier intermédiaire). Cet en-tête est le témoignage brut de ce que l’intermédiaire a observé.

Le deuxième en-tête est ARC-Message-Signature (AMS). Il fonctionne exactement comme une signature DKIM : il couvre le corps du message et les en-têtes importants (y compris le AAR qui vient d’être ajouté), et est signé avec la clé privée ARC de l’intermédiaire. Si quelqu’un modifie le message après ce point, l’AMS devient invalide — ce qui permet au récepteur final de détecter toute altération survenue après l’intermédiaire. La clé publique correspondante est publiée en DNS sous le sélecteur ARC du domaine intermédiaire.

Le troisième en-tête est ARC-Seal (AS). C’est le mécanisme le plus subtil des trois. Il couvre l’ensemble des en-têtes ARC de toutes les instances précédentes (tous les AAR, AMS et AS antérieurs), plus le AAR et AMS courants. Son rôle est de sceller la chaîne ARC : il devient impossible d’insérer ou supprimer un maillon intermédiaire sans casser le sceau. Contrairement à AMS, le ARC-Seal ne couvre pas le corps du message — son seul rôle est de garantir l’intégrité de la chaîne des attestations.

En pratique, quand vous examinez les en-têtes d’un email qui a traversé un intermédiaire ARC, vous verrez quelque chose comme :

ARC-Seal: i=1; a=rsa-sha256; t=1700000000; cv=none;
    d=groupeB.ci; s=arc-2024;
    b=BASE64SIGNATURE...
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
    d=groupeB.ci; s=arc-2024; t=1700000000;
    h=from:to:subject:date:dkim-signature;
    bh=BODYHASH...;
    b=BASE64SIGNATURE...
ARC-Authentication-Results: i=1; groupeB.ci;
    dkim=pass header.d=companyA.sn;
    spf=pass smtp.mailfrom=companyA.sn;
    dmarc=pass action=none header.from=companyA.sn

La valeur cv=none dans le ARC-Seal du premier intermédiaire indique qu’il n’y avait pas de chaîne ARC préexistante à ce point. Les intermédiaires suivants mettront cv=pass si la chaîne précédente est valide, ou cv=fail si elle est corrompue. Un récepteur qui voit cv=fail sur un lien de la chaîne sait que le message a été altéré après ce point.

Étape 3 — Activer ARC dans Postfix avec OpenARC

OpenARC est l’implémentation de référence du protocole ARC pour les serveurs Postfix et autres MTA compatibles Milter. Elle est maintenue par le Trusted Domain Project, le même groupe qui gère OpenDKIM. Son dépôt officiel est disponible à l’adresse github.com/trusteddomainproject/OpenARC. Sur la plupart des distributions Linux modernes, le paquet est directement disponible dans les dépôts officiels.

Commencez par installer OpenARC. Sur Debian/Ubuntu, le paquet s’appelle openarc :

apt update
apt install openarc

Le démon openarc s’installe avec un fichier de configuration principal à /etc/openarc.conf. Ouvrez ce fichier et configurez les paramètres essentiels. La clé AuthservID doit correspondre à votre nom de domaine ou à l’identifiant de votre serveur de messagerie — c’est la valeur qui apparaîtra comme identifiant dans les en-têtes ARC générés. Le Signer indique le domaine sous lequel vous signez, et Selector pointe vers l’enregistrement DNS où vous publierez la clé publique :

## /etc/openarc.conf — configuration minimale fonctionnelle
PIDfile /run/openarc/openarc.pid
Syslog yes
SyslogSuccess yes
Socket inet:8891@localhost

# Identifiant de votre serveur dans les en-têtes ARC
AuthservID mail.groupeB.ci

# Domaine et sélecteur pour la signature ARC
Domain groupeB.ci
Selector arc-2024

# Clé privée (générée juste après)
KeyFile /etc/openarc/keys/arc-2024.private

# Mode : signing (on signe les messages qu'on relaye)
Mode sv

# Vérification : activer pour les messages entrants
PermitAuthenticationOverrides yes

# Domaines de confiance pour les intermédiaires ARC précédents
# Ajouter ici les domaines d'intermédiaires ARC que vous faites confiance
TrustedAuthservIDs mail.autreserveur.ci

La directive Mode sv active à la fois la signature (s) et la vérification (v). Pour un pur intermédiaire (mailing-list), vous voudrez les deux : vérifier les chaînes ARC entrantes et signer les messages sortants. Le paramètre TrustedAuthservIDs est optionnel mais important en contexte multi-serveurs : il liste les intermédiaires ARC dont vous acceptez de faire confiance aux attestations.

Générez maintenant la paire de clés RSA pour la signature ARC. Créez d’abord le répertoire, puis générez la clé privée de 2048 bits minimum :

mkdir -p /etc/openarc/keys
openssl genrsa -out /etc/openarc/keys/arc-2024.private 2048
openssl rsa -in /etc/openarc/keys/arc-2024.private -pubout -out /etc/openarc/keys/arc-2024.public
chown openarc:openarc /etc/openarc/keys/arc-2024.private
chmod 600 /etc/openarc/keys/arc-2024.private

Les permissions 600 sur la clé privée sont obligatoires : le démon OpenARC refusera de démarrer si la clé est lisible par d’autres utilisateurs. Extrayez maintenant la valeur de la clé publique pour la publier en DNS :

openssl rsa -in /etc/openarc/keys/arc-2024.private -pubout 2>/dev/null | grep -v '^---' | tr -d '\n'

Créez l’enregistrement DNS TXT suivant chez votre registrar ou dans votre zone DNS. Le format est identique à celui d’un enregistrement DKIM :

arc-2024._domainkey.groupeB.ci.  IN TXT  "v=DKIM1; k=rsa; p=VOTRE_CLE_PUBLIQUE_BASE64"

Maintenant, configurez Postfix pour qu’il envoie les messages au Milter OpenARC. Dans /etc/postfix/main.cf, ajoutez ou complétez la directive milter_default_action et ajoutez le socket OpenARC à la liste des Milters. Si vous utilisez déjà OpenDKIM sur le port 8892, les deux coexistent sans conflit :

## Ajout dans /etc/postfix/main.cf
milter_default_action = accept
milter_protocol = 6

# Séparer les milters par virgule si vous avez déjà OpenDKIM
smtpd_milters = inet:localhost:8892, inet:localhost:8891
non_smtpd_milters = inet:localhost:8892, inet:localhost:8891

Démarrez OpenARC et rechargez Postfix pour appliquer la configuration :

systemctl enable openarc
systemctl start openarc
systemctl reload postfix
systemctl status openarc

Si le statut affiche Active: active (running), le démon est opérationnel. Les logs dans /var/log/mail.log (ou journalctl -u openarc) afficheront les opérations de signature et de vérification ARC sur chaque message transitant par le serveur. Cherchez les lignes contenant ARC-Seal added ou ARC signing succeeded pour confirmer que les en-têtes sont bien insérés.

Étape 4 — Activer ARC dans Mailcow

Mailcow est une suite de messagerie auto-hébergée basée sur Docker qui intègre Postfix, Dovecot, rspamd et de nombreux autres composants. Bonne nouvelle : depuis les builds 2023 de Mailcow, le support ARC est intégré nativement via rspamd, qui gère déjà la signature DKIM. Aucune installation supplémentaire n’est nécessaire — l’activation se fait entièrement depuis l’interface d’administration web.

Connectez-vous à votre interface Mailcow (https://mail.votredomaine.tld) avec un compte administrateur. Dans le menu de gauche, naviguez vers Configuration → ARC (dans certaines versions, vous trouverez ARC sous Configuration → Domaines en éditant un domaine spécifique). L’écran ARC présente, pour chaque domaine hébergé, la possibilité d’activer la signature ARC et d’afficher la clé publique à publier en DNS.

Pour chaque domaine sur lequel vous souhaitez activer la signature ARC, cliquez sur le bouton de génération de clé. Mailcow génère automatiquement la paire RSA, stocke la clé privée de manière sécurisée dans le conteneur rspamd, et vous affiche la valeur de l’enregistrement DNS TXT à créer. Copiez cette valeur et créez l’enregistrement dans votre zone DNS chez votre hébergeur (OVH, Hetzner, ou un registrar local comme NIC Sénégal ou Côte d’Ivoire Telecom pour les domaines .sn et .ci).

Le délai de propagation DNS est généralement de 5 à 30 minutes sur la plupart des hébergeurs africains, mais peut aller jusqu’à 48 heures dans certains cas. Vous pouvez vérifier la propagation avec la commande dig depuis votre serveur :

dig TXT arc-selector._domainkey.votredomaine.tld +short

Une réponse contenant v=DKIM1; k=rsa; p=... confirme que l’enregistrement est publié et accessible. Une fois l’enregistrement DNS propagé, revenez dans l’interface Mailcow et activez la signature ARC pour le domaine. rspamd commencera immédiatement à insérer les trois en-têtes ARC sur chaque message relayé par votre infrastructure Mailcow.

Pour vérifier que rspamd insère bien les en-têtes, envoyez un email test depuis un compte externe vers une adresse hébergée sur votre Mailcow, puis faites-le transférer. Examinez les en-têtes du message reçu par le destinataire final : vous devriez trouver les trois en-têtes ARC-Seal, ARC-Message-Signature et ARC-Authentication-Results avec le numéro d’instance correspondant à votre serveur Mailcow dans la chaîne.

Étape 5 — Test avec Microsoft Remote Connectivity Analyzer

Une fois ARC configuré et les enregistrements DNS propagés, il est essentiel de valider le bon fonctionnement avant de considérer la tâche terminée. Microsoft propose un outil de test d’authentification email particulièrement utile, car Outlook/Exchange Online est l’un des récepteurs qui honore ARC le plus rigoureusement en 2026. L’outil est accessible à testconnectivity.microsoft.com.

Dans l’interface Microsoft Remote Connectivity Analyzer, sélectionnez l’onglet Email puis le test Inbound SMTP Email. Entrez l’adresse email de destination que vous contrôlez (de préférence une adresse Outlook.com ou Microsoft 365) et cliquez sur Perform Test. L’outil va simuler un envoi complet et vous renvoyer une analyse détaillée des en-têtes, incluant les résultats SPF, DKIM, DMARC et, si présents, la chaîne ARC.

Pour tester spécifiquement le scénario de forwarding, la méthode la plus directe est la suivante : configurez une règle de redirection automatique depuis une boîte Gmail ou Yahoo vers votre adresse test Outlook, envoyez un message depuis votre domaine vers Gmail, et vérifiez les en-têtes du message arrivé dans Outlook après la redirection. Les en-têtes devraient contenir les en-têtes ARC insérés par Gmail (qui supporte ARC) attestant de l’authentification originale.

Un autre outil utile est MXToolbox Email Header Analyzer (mxtoolbox.com/EmailHeaders.aspx). Copiez-collez les en-têtes complets d’un email test et l’outil les analyse visuellement, identifiant chaque en-tête ARC et son statut. Pour extraire les en-têtes bruts dans Gmail : ouvrez le message, cliquez sur les trois points verticaux en haut à droite, choisissez Afficher l’original. Dans Outlook : ouvrir le message, Fichier → Propriétés → Zone de texte En-têtes Internet.

Si les en-têtes ARC sont présents et que la valeur cv=pass apparaît dans le ARC-Seal (pour les messages ayant traversé un intermédiaire ARC), la configuration est opérationnelle. Si vous voyez cv=fail, un problème est survenu dans la chaîne — reportez-vous à la section Erreurs fréquentes ci-dessous.

Étape 6 — Monitoring des rapports DMARC pour vérifier qu’ARC est respecté

La configuration ARC ne se vérifie pas seulement par des tests ponctuels. Le vrai indicateur de succès à long terme est l’évolution de vos rapports DMARC agrégés (RUA — Reporting URI for Aggregate). Ces rapports XML, envoyés quotidiennement par les grands récepteurs (Gmail, Outlook, Yahoo, etc.), contiennent des statistiques sur les messages reçus depuis votre domaine et leurs résultats d’authentification. En observant ces rapports avant et après l’activation d’ARC, vous pouvez quantifier l’amélioration.

Pour recevoir les rapports DMARC, votre enregistrement DNS DMARC doit inclure une adresse rua=. Si ce n’est pas encore fait, voici un exemple d’enregistrement DMARC avec reporting activé :

_dmarc.votredomaine.tld.  IN TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-rapports@votredomaine.tld; ruf=mailto:dmarc-forensic@votredomaine.tld; pct=100"

Les rapports XML bruts sont difficiles à lire directement. Plusieurs outils gratuits et payants les parsent et les visualisent. Pour les PME avec un budget limité, dmarcian propose un plan gratuit limité, et Postmark’s DMARC Digests (dmarc.postmarkapp.com) offre un service d’agrégation et de parsing entièrement gratuit. Pour une solution auto-hébergée, Parsedmarc (github.com/domainaware/parsedmarc) est un outil Python qui parse les rapports et les injecte dans Elasticsearch ou génère des rapports HTML.

Dans vos rapports DMARC, cherchez les lignes correspondant aux IP de vos intermédiaires connus (serveurs Mailman, plateformes de mailing-list partenaires, redirecteurs d’universités). Avant l’activation d’ARC, ces lignes devraient montrer des dkim=fail et spf=fail avec disposition=quarantine ou disposition=reject. Après l’activation d’ARC et la mise à jour des politiques de confiance par les récepteurs, ces mêmes IP devraient progressivement afficher disposition=none, ce qui signifie que le récepteur honore la chaîne ARC et livre le message normalement.

Notez que ce changement n’est pas immédiat : les grands récepteurs mettent à jour leurs politiques de confiance ARC sur la base de l’historique et de la réputation de chaque intermédiaire. Gmail et Outlook, par exemple, maintiennent des listes internes d’intermédiaires ARC de confiance qui évoluent progressivement. En pratique, comptez de quelques jours à quelques semaines pour observer une amélioration significative dans vos rapports DMARC après l’activation d’ARC.

Erreurs fréquentes

Le tableau suivant recense les problèmes les plus courants rencontrés lors de la mise en place d’ARC, leurs causes profondes et les solutions éprouvées :

Adaptation au contexte ouest-africain

Le problème du DMARC fail sur forwarding n’est pas qu’un problème théorique pour les équipes d’Afrique de l’Ouest : c’est une réalité quotidienne qui impacte concrètement la communication professionnelle et académique dans la région.

Considérons d’abord les mailing-lists professionnelles. De nombreuses entreprises et organisations professionnelles à Dakar et Abidjan utilisent des mailing-lists pour coordonner leurs équipes distribuées. Une association professionnelle comme un groupement d’entreprises ou une chambre de commerce peut gérer une mailing-list hébergée sur un serveur Mailman mutualisé d’un hébergeur local. Quand les membres de cette liste, utilisant des domaines d’entreprise avec DMARC strict, envoient des messages via la liste, les destinataires utilisant Gmail ou Outlook reçoivent ces messages en spam ou ne les reçoivent pas du tout si le serveur Mailman ne supporte pas ARC. La solution est double : d’abord, mettre à jour le serveur Mailman vers la version 3.x qui inclut le support ARC nativement (via la bibliothèque authheaders), et ensuite configurer les signatures ARC sur ce serveur.

Les redirections universitaires constituent un cas particulièrement répandu. L’Université Cheikh Anta Diop (UCAD) de Dakar et l’Université Félix Houphouët-Boigny (UFHB) d’Abidjan maintiennent des systèmes de messagerie institutionnelle où les étudiants et enseignants reçoivent des adresses en @ucad.edu.sn et @ufhb.edu.ci respectivement. Il est courant que ces adresses soient configurées pour rediriger automatiquement les messages vers des boîtes Gmail ou Yahoo personnelles, pour une accessibilité maximale depuis les appareils mobiles. Sans ARC sur le serveur relayeur universitaire, les communications officielles envoyées aux adresses institutionnelles et redirigées vers Gmail peuvent échouer les contrôles DMARC si le domaine expéditeur a une politique stricte. Les DSI de ces établissements ont tout intérêt à activer ARC sur leurs serveurs MTA — la procédure décrite dans ce tutoriel s’applique directement à leurs infrastructures Postfix.

La conformité de gouvernance sous l’espace OHADA est un autre angle à considérer. Les entreprises opérant sous le droit OHADA (Organisation pour l’Harmonisation en Afrique du Droit des Affaires, couvrant 17 États membres dont le Sénégal et la Côte d’Ivoire) sont de plus en plus confrontées à des exigences d’intégrité des communications électroniques dans leurs procédures légales et contractuelles. Un email transféré et livré en spam, ou pire rejeté, peut créer des problèmes de preuve dans un contexte de litige commercial. Mettre en place ARC pour préserver l’intégrité des communications relayées, combiné avec une archivage email conforme, constitue une bonne pratique de gouvernance applicable à ces contextes.

Concernant les contraintes d’infrastructure spécifiques à la région : les coupures électriques fréquentes dans certaines zones peuvent interrompre temporairement les serveurs Postfix, causant des redémarrages qui, si le socket OpenARC n’est pas démarré automatiquement, laissent Postfix opérer sans signature ARC. Vérifiez que systemctl enable openarc a bien été exécuté et que la directive milter_default_action = accept dans Postfix est configurée pour accepter les messages même si le Milter est temporairement indisponible, au lieu de les rejeter avec tempfail.

Tutoriels frères

• SPF, DKIM et DMARC : configuration pas-à-pas sur VPS Linux — les fondations d’authentification email avant d’aller plus loin avec ARC
• MTA-STS et TLS-RPT : sécuriser le transport email en 2026 — complémentaire à ARC pour une délivrabilité email complète
• BIMI : afficher le logo de votre marque dans les clients email — l’étape visuelle après avoir sécurisé l’authentification
• Mailcow : installer sa propre infrastructure email sur VPS — pour ceux qui n’ont pas encore leur serveur Mailcow

Pour aller plus loin

• Retour au pilier : Email pro deliverability 2026 : SPF, DKIM, DMARC, MTA-STS, BIMI, ARC
• RFC 8617 — Spécification officielle ARC : rfc-editor.org/rfc/rfc8617 — la source primaire pour comprendre chaque en-tête et les détails cryptographiques
• OpenARC GitHub — Implémentation de référence : github.com/trusteddomainproject/OpenARC — code source, issues, wiki de configuration
• RFC 8601 — Message Header Field for Indicating Message Authentication Status : rfc-editor.org/rfc/rfc8601 — le format des en-têtes Authentication-Results sur lesquels ARC s’appuie
• Trusted Domain Project — Groupe de travail maintenant OpenARC, OpenDKIM et d’autres outils d’authentification email : trusteddomainproject.org
• Prochaine étape suggérée : après ARC, configurez BIMI pour afficher le logo de votre organisation directement dans Gmail et Outlook — tutoriel disponible dans le cluster.

FAQ

Q : ARC est-il obligatoire si ma politique DMARC est p=none ?

Non, ARC n’est pas obligatoire dans ce cas — avec p=none, les messages ne sont ni mis en quarantaine ni rejetés lors d’un DMARC fail, ils arrivent quand même. Mais ARC reste utile pour préparer une future migration vers p=quarantine ou p=reject, et pour améliorer la délivrabilité même sans politique stricte, car certains filtres antispam utilisent les résultats d’authentification pour scorer les messages indépendamment de la politique DMARC.

Q : Est-ce qu’ARC remplace SPF et DKIM ?

Non, ARC ne remplace aucun de ces protocoles. ARC est un mécanisme complémentaire qui préserve les résultats d’authentification à travers les relais. SPF et DKIM doivent être configurés et fonctionnels sur votre domaine source pour qu’ARC ait quelque chose à attester. Un message dont SPF et DKIM échouent dès l’envoi initial ne peut pas être « sauvé » par ARC dans un relais ultérieur.

Q : Comment savoir si un récepteur honore ARC ?

Les principaux récepteurs qui supportent ARC en 2026 incluent Gmail, Outlook/Exchange Online, Yahoo Mail et Fastmail. La plupart des autres grands fournisseurs de messagerie sont en cours d’adoption. Pour vérifier spécifiquement un récepteur, envoyez un message test via un forwarding connu et examinez les en-têtes de réception : un récepteur qui honore ARC le mentionnera généralement dans l’en-tête Authentication-Results avec quelque chose comme arc=pass.

Q : Mailman 2 supporte-t-il ARC ou faut-il migrer vers Mailman 3 ?

Mailman 2 ne supporte pas ARC nativement. Il faut soit migrer vers Mailman 3 (qui intègre ARC via la bibliothèque Python authheaders), soit utiliser un wrapper externe qui insère les en-têtes ARC en amont du démon Mailman 2. En pratique, la migration vers Mailman 3 est recommandée car Mailman 2 est en fin de vie active et ne reçoit plus de mises à jour de sécurité.

Q : ARC fonctionne-t-il avec Exchange Server on-premise ?

Exchange Server 2019 (Cumulative Update 12 et suivants) supporte la vérification ARC en réception. Pour la signature ARC en émission depuis Exchange (par exemple quand Exchange est utilisé comme relais SMTP interne qui forward vers l’extérieur), des outils tiers ou un proxy Milter sont nécessaires, Exchange n’étant pas compatible Milter nativement. Dans un contexte hybride Office 365 + Exchange on-premise, Exchange Online gère ARC automatiquement pour les flux qui passent par ses serveurs.

Q : Faut-il une clé ARC par domaine hébergé ou une seule pour tout le serveur ?

Dans la plupart des implémentations (OpenARC, rspamd/Mailcow), une seule paire de clés ARC est utilisée pour l’ensemble du serveur de messagerie, indépendamment des domaines hébergés. La clé ARC identifie le serveur relayeur, pas le domaine expéditeur. L’enregistrement DNS de cette clé est publié sous le domaine du serveur relayeur lui-même (par exemple arc-2024._domainkey.votreserveur.tld), et non sous les domaines des clients hébergés.

Q : Est-ce qu’activer ARC peut nuire à la délivrabilité si mal configuré ?

Un ARC mal configuré (clé invalide, DNS mal publié, signature qui échoue) se manifeste principalement par cv=fail dans les en-têtes ARC, ce qui peut légèrement dégrader la confiance accordée aux messages. Mais la plupart des récepteurs sont configurés pour ignorer gracieusement une chaîne ARC invalide plutôt que de rejeter le message sur cette base — ils retombent simplement sur le comportement sans ARC. Le risque de casser la délivrabilité est donc faible, mais il est préférable de tester en environnement de staging avant la mise en production.