ARC (Authenticated Received Chain)

Le problème : le transfert d’email casse l’authentification

Voici un scénario que toutes les DSI connaissent. Sophie, directrice commerciale chez acme-industrie.fr, a configuré une redirection automatique de sa boîte professionnelle vers son adresse personnelle Gmail. Un client partenaire envoie un email depuis contact@fournisseur-xyz.fr. Le message arrive sur le serveur d’acme-industrie.fr, puis est automatiquement redirigé vers le Gmail de Sophie.

Au moment où Gmail reçoit cet email, il fait ses vérifications d’authentification :

• SPF échoue. L’email arrive depuis l’IP du serveur d’acme-industrie.fr. Mais le SPF de fournisseur-xyz.fr n’autorise que ses propres serveurs — pas ceux d’acme-industrie.fr. Du point de vue de SPF, ce serveur n’a aucun droit d’envoyer un email pour fournisseur-xyz.fr.
• DKIM peut échouer. Si le serveur d’acme-industrie.fr a ajouté un pied de page (“Ce message a été transféré automatiquement”), modifié un en-tête ou changé l’encodage du message, la signature DKIM originale de fournisseur-xyz.fr devient invalide. La moindre altération du contenu signé casse la vérification.
• DMARC échoue. DMARC exige qu’au moins SPF ou DKIM passe avec alignement (le domaine vérifié doit correspondre au domaine From). Ni SPF ni DKIM ne passent. Résultat : échec DMARC.

L’email du fournisseur, parfaitement légitime, atterrit dans le spam de Sophie. Ou pire : il est rejeté silencieusement. Sophie ne le voit jamais. Le fournisseur pense que son message a été reçu.

Ce n’est pas un cas isolé

Ce problème touche des millions de messages chaque jour. Il se produit à chaque fois qu’un email traverse un serveur intermédiaire qui n’est pas le destinataire final :

• Redirections automatiques : un employé redirige sa boîte pro vers un compte personnel ou un alias
• Listes de diffusion : Mailman, Google Groups, Sympa et toute liste qui redistribue les messages aux abonnés
• Passerelles de sécurité : les solutions anti-spam ou antivirus qui analysent et retransmettent les messages
• Services de relais : les passerelles SMTP d’entreprise qui centralisent le trafic email sortant

Avant ARC, il n’existait aucun mécanisme standardisé pour préserver les résultats d’authentification à travers ces étapes intermédiaires. Les administrateurs faisaient face à un choix désagréable : soit durcir DMARC et risquer de perdre des emails légitimes transférés, soit rester en p=none et laisser passer le spoofing.

Comment ARC résout le problème

ARC (Authenticated Received Chain), défini dans la RFC 8617, apporte une réponse élégante : chaque serveur intermédiaire qui touche au message certifie les résultats d’authentification qu’il a observés avant de le modifier et de le transmettre.

Trois en-têtes par étape

Chaque fois qu’un serveur intermédiaire traite et retransmet un email, il ajoute un triplet d’en-têtes ARC :

1. ARC-Authentication-Results (AAR)

Cet en-tête enregistre les résultats d’authentification que le serveur a vérifiés au moment de la réception. C’est un instantané : “quand j’ai reçu ce message, voici ce que SPF, DKIM et DMARC ont donné.”

ARC-Authentication-Results: i=1; mx.acme-industrie.fr;
    dkim=pass header.d=fournisseur-xyz.fr;
    spf=pass smtp.mailfrom=fournisseur-xyz.fr;
    dmarc=pass header.from=fournisseur-xyz.fr

2. ARC-Message-Signature (AMS)

Une signature cryptographique du message tel que le serveur le transmet, construite exactement comme une signature DKIM. Elle permet au serveur final de vérifier que le contenu du message n’a pas été altéré après ce point de la chaîne.

ARC-Message-Signature: i=1; a=rsa-sha256; d=acme-industrie.fr;
    s=arc-2024; h=from:to:subject:date:message-id;
    b=dGVzdC...

3. ARC-Seal (AS)

Une signature qui couvre l’ensemble de la chaîne ARC existante : tous les en-têtes AAR, AMS et AS précédents, plus les nouveaux. Le Seal garantit que personne n’a modifié, supprimé ou réordonné les en-têtes ARC après leur ajout.

ARC-Seal: i=1; a=rsa-sha256; d=acme-industrie.fr;
    s=arc-2024; cv=none;
    b=aW50ZWdyaXR5...

Le compteur d’instance

Chaque triplet porte un numéro d’instance (i=1, i=2, i=3…) qui identifie l’étape dans la chaîne. Le premier serveur intermédiaire ajoute i=1. Si un second relais traite le message, il ajoute i=2, et ainsi de suite. Le champ cv= (chain validation) du Seal indique si la chaîne ARC existante était valide au moment de la vérification : none (premier maillon), pass (chaîne précédente valide) ou fail.

En pratique : le scénario de Sophie résolu

Reprenons l’exemple. Avec ARC activé sur le serveur d’acme-industrie.fr :

1. L’email de fournisseur-xyz.fr arrive. Le serveur d’acme-industrie.fr vérifie SPF, DKIM et DMARC : tout passe.
2. Le serveur ajoute les trois en-têtes ARC (i=1) qui certifient ces résultats.
3. Le serveur ajoute le pied de page de redirection et transmet le message à Gmail.
4. Gmail reçoit le message. SPF échoue (IP d’acme-industrie.fr). DKIM échoue (le pied de page a cassé la signature originale). DMARC échoue.
5. Mais Gmail lit la chaîne ARC. Il voit que le serveur d’acme-industrie.fr a certifié un DMARC pass à i=1. Il vérifie l’ARC-Seal et l’ARC-Message-Signature. La chaîne est intacte.
6. Gmail décide de faire confiance à cette attestation ARC et livre l’email dans la boîte de réception de Sophie.

Qui implémente ARC

Les grands fournisseurs

Gmail supporte ARC depuis 2018, côté validation (il lit les chaînes ARC des messages entrants) et côté signature (il ajoute des en-têtes ARC quand il retransmet des messages). Google a été l’un des moteurs de la conception du protocole, en grande partie parce que Gmail gère des milliards de redirections et de messages de listes de diffusion. L’annonce officielle décrit la motivation et l’implémentation.

Microsoft 365 supporte la validation ARC sur Exchange Online et les en-têtes ARC sont pris en compte dans les décisions de filtrage. Microsoft permet aussi aux administrateurs de déclarer des signataires ARC de confiance pour leurs organisations.

Yahoo Mail supporte la validation ARC pour ses décisions DMARC, contribuant à réduire les faux positifs sur les messages transférés.

Pour les administrateurs serveur

Si vous gérez votre propre infrastructure email, plusieurs implémentations open source permettent d’ajouter le support ARC :

• OpenARC : implémentation de référence en C, sous forme de milter (mail filter) pour Postfix et Sendmail
• rspamd : le module ARC intégré gère la validation et la signature
• Halon et MailerQ : passerelles commerciales avec support ARC natif
• Postfix + OpenDKIM : compatible via le milter OpenARC en complément

Ce que la plupart des organisations n’ont pas à faire

Si votre email est hébergé chez Gmail, Microsoft 365, ou un autre fournisseur majeur, ARC est déjà géré de leur côté. Vous n’avez rien à configurer. Le protocole fonctionne de manière transparente dans les en-têtes, sans configuration DNS côté expéditeur (contrairement à SPF, DKIM ou DMARC qui nécessitent des enregistrements DNS).

ARC et les listes de diffusion

Les listes de diffusion sont le cas d’usage historique qui a motivé la création d’ARC. Et pour cause : elles combinent toutes les modifications qui cassent l’authentification.

Le scénario type

Un employé envoie un email à equipe-projet@lists.entreprise.fr. Le serveur de la liste :

1. Reçoit le message et vérifie SPF/DKIM/DMARC de l’expéditeur original
2. Ajoute le préfixe [equipe-projet] à l’objet du message
3. Ajoute un pied de page avec les instructions de désabonnement
4. Modifie parfois le Reply-To pour pointer vers la liste
5. Renvoie le message à tous les abonnés depuis sa propre IP

Chaque modification du point 2 à 4 peut casser la signature DKIM originale. Le point 5 garantit un échec SPF, puisque le serveur de la liste n’est pas autorisé dans le SPF du domaine de l’expéditeur. Résultat : DMARC échoue chez tous les destinataires.

Avant ARC, les administrateurs de listes avaient recours à des solutions de contournement bancales : réécrire l’adresse From pour la remplacer par celle de la liste (ce qui masque l’expéditeur original), ou demander aux expéditeurs de passer leur DMARC en p=none (ce qui affaiblit leur protection contre le spoofing).

ARC comme solution propre

Avec ARC, le serveur de la liste certifie les résultats d’authentification observés avant ses modifications. Les destinataires finaux voient l’échec DMARC, mais lisent aussi la chaîne ARC qui atteste que le message était authentifié à l’origine.

Les logiciels de listes de diffusion qui supportent ARC :

• Mailman 3 : support natif de la signature ARC
• Google Groups : signe et valide ARC
• Sympa : support via des patches et plugins
• GNU Mailman 2 : support via le milter OpenARC en amont du serveur SMTP

Limites d’ARC

ARC n’est pas une solution magique. Le protocole repose sur une chaîne de confiance, et cette confiance a des limites concrètes.

ARC est une attestation, pas une preuve

Quand un serveur intermédiaire ajoute des en-têtes ARC qui déclarent “DMARC passait quand j’ai reçu ce message”, le serveur final doit faire confiance à ce signataire. Si un serveur malveillant ajoute de faux en-têtes ARC déclarant un faux dmarc=pass, la chaîne entière est compromise.

C’est pourquoi les fournisseurs email maintiennent des listes de signataires ARC de confiance. Gmail et Microsoft ne font pas confiance à n’importe quel serveur qui ajoute des en-têtes ARC. Ils évaluent la réputation du signataire et ne prennent en compte la chaîne ARC que si le signataire figure dans leur liste de confiance — ou s’il a une réputation suffisamment établie.

Pas de standard pour la liste de confiance

Il n’existe pas de mécanisme standardisé pour déclarer “ce serveur est un signataire ARC de confiance”. Chaque fournisseur maintient sa propre liste. Pour un administrateur qui déploie ARC sur son serveur de listes, il n’y a aucune garantie que Gmail ou Microsoft prendront en compte ses en-têtes ARC immédiatement. La confiance se construit avec le volume, la réputation et le temps.

Statut expérimental (mais adopté en pratique)

La RFC 8617 classe ARC comme “Experimental”, pas comme un standard Internet à part entière (Standards Track). En pratique, l’adoption par Gmail, Microsoft 365 et Yahoo en fait un protocole de facto incontournable pour la gestion des transferts email. Le statut expérimental signifie surtout que des évolutions restent possibles dans la manière dont la confiance est établie entre signataires et validateurs.

Ce qu’ARC ne résout pas

• Un message initialement non authentifié (SPF/DKIM/DMARC en échec dès l’envoi) ne bénéficie pas d’ARC. Le protocole préserve des résultats d’authentification existants ; il n’en crée pas de nouveaux.
• Si un intermédiaire non compatible ARC modifie le message entre deux relais compatibles, la chaîne est cassée.
• ARC ne protège pas contre le phishing direct. Un attaquant qui envoie un email de spoofing ne va pas ajouter d’en-têtes ARC qui prouvent que son email échoue à DMARC.

ARC dans l’écosystème d’authentification email

ARC ne fonctionne pas seul. Il fait partie d’un ensemble de protocoles qui, combinés, couvrent les différents aspects de la sécurité email :

Protocole	Rôle	Fonctionne sur
SPF	Déclare les serveurs autorisés à envoyer pour un domaine	Adresse IP de l’expéditeur
DKIM	Garantit l’intégrité du message par signature cryptographique	Contenu et en-têtes du message
DMARC	Politique d’authentification + alignement + reporting	Coordination SPF/DKIM
ARC	Préserve l’authentification à travers les transferts	Chaîne de confiance entre serveurs
MTA-STS	Force le chiffrement du transport email (TLS)	Connexion SMTP entre serveurs
BIMI	Affiche le logo de la marque dans les clients email	Identité visuelle de l’expéditeur

L’ordre logique de déploiement pour une organisation :

1. SPF : déclarer les serveurs autorisés (base)
2. DKIM : signer les emails sortants (intégrité)
3. DMARC : activer la politique et le reporting (application)
4. ARC : préserver l’authentification lors des transferts (robustesse)
5. MTA-STS : forcer le chiffrement du transport (confidentialité)
6. BIMI : afficher le logo vérifié (confiance visuelle)

Vous voulez savoir où en est votre domaine ? Notre test de sécurité email vérifie SPF, DKIM et DMARC en 30 secondes et vous donne un score avec des recommandations concrètes.

Quand configurer ARC

Concrètement, qui a besoin de mettre en place ARC sur son infrastructure ?

Vous devez configurer ARC si :

• Vous gérez un serveur de listes de diffusion (Mailman, Sympa, ou toute liste interne)
• Vous opérez une passerelle de sécurité email qui analyse, modifie ou retransmet les messages (ajout de bandeaux d’avertissement, scan antivirus avec réécriture des liens, DLP)
• Vous gérez un service de redirection email entre domaines (par exemple un MX centralisé qui dispatche vers plusieurs domaines internes)
• Vous opérez un relais SMTP qui ajoute des pieds de page ou modifie les en-têtes des messages en transit

Vous n’avez probablement rien à faire si :

• Votre email est hébergé chez Gmail / Google Workspace : ARC est géré nativement
• Vous utilisez Microsoft 365 / Exchange Online : la validation ARC est active par défaut, et la signature ARC est automatique sur les transferts
• Vous utilisez un fournisseur email managé (OVH, Infomaniak, Gandi) sans relais ou passerelle intermédiaire

La majorité des entreprises n’ont pas à toucher à ARC directement. Les fournisseurs gèrent la validation côté réception, et la signature côté transfert est automatique pour les redirections internes. ARC devient un sujet quand vous opérez l’infrastructure intermédiaire vous-même — et dans ce cas, des outils comme OpenARC ou rspamd rendent l’implémentation raisonnable en quelques heures de configuration.

Sources : RFC 8617 — Authenticated Received Chain, Google Workspace Blog — ARC, Microsoft — Configure trusted ARC sealers