ARC : conserver les résultats d'authentification à travers les relais

ARC (Authenticated Received Chain) répond à un problème précis : un message légitime qui traverse un intermédiaire (liste de diffusion, redirection de boîte, passerelle de sécurité) perd souvent son authentification. SPF casse parce que l'adresse IP du relais n'est pas autorisée par le domaine d'origine ; DKIM casse si le relais modifie le sujet ou ajoute un pied de page. ARC permet à chaque relais de certifier les résultats qu'il a lui-même observés avant de modifier le message, de façon que le destinataire final puisse en tenir compte. ARC est décrit dans la RFC 8617, publiée avec le statut expérimental.

Comment fonctionne la chaîne#

Chaque relais qui participe ajoute un jeu de trois en-têtes, numérotés par une instance i= croissante :

• ARC-Authentication-Results: (AAR) : copie des résultats SPF, DKIM et DMARC tels que le relais les a constatés à la réception ;
• ARC-Message-Signature: (AMS) : signature de type DKIM sur le message tel que le relais le réémet, après ses modifications ;
• ARC-Seal: (AS) : signature portant sur l'ensemble des en-têtes ARC précédents et sur l'AAR et l'AMS de l'instance courante, avec une étiquette cv= (chain validation) valant none pour le premier maillon, pass si la chaîne reçue était valide, fail sinon.

Le destinataire final vérifie la chaîne de bout en bout : chaque sceau doit être valide et chaque cv= cohérent. Si la chaîne est intacte, il peut lire dans le premier AAR que le message passait DMARC avant d'être touché par la liste de diffusion. Rien ne l'oblige à en tenir compte : ARC fournit une information signée, et c'est la politique locale du routeur, fondée sur la confiance qu'il accorde au domaine qui a scellé, qui décide de passer outre un échec DMARC.

L'enregistrement DNS#

ARC ne définit pas d'enregistrement propre. Les sceaux et signatures sont vérifiés avec une clé publiée exactement comme une clé DKIM, sous _domainkey :

arc2026._domainkey.relay.example.net.  IN TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...IDAQAB"

Le domaine d= des en-têtes ARC est celui du relais, pas celui de l'expéditeur d'origine. Un exemple de maillon tel qu'il apparaît dans un message :

ARC-Seal: i=1; a=rsa-sha256; t=1759276800; cv=none; d=relay.example.net; s=arc2026; b=...
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=relay.example.net; s=arc2026; h=from:to:subject:date:message-id; bh=...; b=...
ARC-Authentication-Results: i=1; relay.example.net; spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com

Qui doit déployer ARC#

ARC concerne les systèmes qui reçoivent puis réémettent des messages : serveurs de listes de diffusion, passerelles antispam ou d'archivage placées devant une messagerie, services de redirection d'adresses, fournisseurs de boîtes qui transfèrent vers d'autres domaines. Un domaine qui envoie directement à ses destinataires n'a rien à faire : SPF, DKIM et DMARC suffisent.

Pour un relais, le déploiement se résume à :

1. Publier une clé sous _domainkey pour le domaine du relais, séparée de la clé DKIM utilisée pour ses propres envois.
2. À la réception, évaluer SPF, DKIM et DMARC et consigner les résultats dans un en-tête Authentication-Results: sous l'identifiant du relais.
3. Avant de réémettre, vérifier la chaîne ARC existante, puis ajouter l'instance suivante (AAR, AMS, AS) avec le cv= approprié.
4. Ne jamais sceller un message dont la chaîne reçue est invalide avec cv=pass.

La plupart des serveurs de listes et des passerelles récentes intègrent ARC ; il s'agit alors de l'activer et de publier la clé.

Pour les destinataires#

Un routeur qui vérifie ARC doit décider quels domaines scellants méritent sa confiance. Une chaîne valide signée par un domaine inconnu n'apporte rien : un attaquant peut tout à fait fabriquer un AAR affirmant que DMARC passait. La valeur d'ARC repose donc entièrement sur la réputation du relais et sur des listes de confiance maintenues par chaque routeur. Les gros fournisseurs de boîtes l'utilisent pour laisser passer les listes de diffusion connues malgré une politique p=reject sur le domaine de l'auteur.

Erreurs fréquentes#

• Attendre d'ARC qu'il corrige un DMARC mal configuré : ARC ne concerne que les messages modifiés par un intermédiaire, pas les flux directs non alignés.
• Sceller avec la clé DKIM de production : fonctionne, mais mélange deux usages et complique la rotation.
• Oublier l'AAR ou y consigner des résultats incomplets : la chaîne est valide mais inutile.
• Réutiliser i= ou sauter un numéro : la chaîne est invalide.
• Modifier le message après avoir calculé l'AMS, par exemple en ajoutant un pied de page en sortie de file.
• Sceller cv=pass sans avoir vérifié la chaîne entrante.

Ce que SenderRadar en montre#

Pour un domaine qui opère des relais, SenderRadar signale les sélecteurs de clés publiés qui servent au scellement ARC lorsqu'ils sont identifiables, et met en regard la configuration DMARC du domaine avec les flux susceptibles de transiter par des intermédiaires. SenderRadar s'appuie sur sa propre base d'analyse pour présenter ces éléments sans préjuger de la confiance que chaque routeur accorde au relais.

Références#

• RFC 8617 – The Authenticated Received Chain (ARC) Protocol
• RFC 8601 – Message Header Field for Indicating Message Authentication Status
• RFC 6376 – DKIM