Décoder les en-têtes d'un email : comprendre Authentication-Results et corriger la délivrabilité

Lorsqu'un e-mail atterrit en spam ou est rejeté par un serveur de messagerie récepteur (MX), les métriques d'un tableau de bord d'envoi ne suffisent pas à déterminer l'origine exacte du problème. L'en-tête brut du message constitue la seule source de vérité. Il contient les métadonnées de routage, les signatures cryptographiques et le verdict d'authentification généré directement par le serveur récepteur.

Comment afficher et extraire l'en-tête brut d'un email

Pour analyser la délivrabilité d'un message, il est nécessaire d'accéder à sa source brute :

• Gmail / Google Workspace : Ouvrez le message, cliquez sur les trois points verticaux en haut à droite, puis sélectionnez « Afficher l'original ».
• Outlook (Web) : Cliquez sur les trois points dans le panneau de lecture, sélectionnez Afficher > Afficher la source du message.
• Outlook (Desktop) : Double-cliquez sur le message pour l'ouvrir dans une nouvelle fenêtre, allez dans Fichier > Propriétés, puis examinez la zone En-têtes d'Internet.
• Thunderbird : Sélectionnez le message et utilisez le raccourci Ctrl + U (ou Cmd + U sous macOS).

L'en-tête se situe au début du fichier source et s'arrête à la première ligne vide, laquelle marque le début du corps du message (body).

Anatomie du champ Authentication-Results

Le champ Authentication-Results est inséré par le Mail Transfer Agent (MTA) récepteur après évaluation des protocoles de sécurité (RFC 7601). Sa syntaxe suit une structure normée :

Authentication-Results: mx.google.com;
       dkim=pass header.i=@domaine.com header.s=s1 header.b=aB123c;
       spf=pass (google.com: domain of bounces@domaine.com designates 192.0.2.1 as permitted sender) smtp.mailfrom=bounces@domaine.com;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=domaine.com

Ce champ se décompose en plusieurs sous-éléments clés :

• authserv-id (mx.google.com) : Identifiant du serveur récepteur qui a réalisé l'évaluation. Seule la ligne ajoutée par le dernier MX traversé est digne de confiance.
• spf : Indique si l'adresse IP du serveur d'envoi est autorisée par l'enregistrement SPF du domaine d'enveloppe (smtp.mailfrom ou Return-Path).
• dkim : Indique le résultat de la vérification cryptographique. Le paramètre header.i (ou header.d) précise le domaine signataire, et header.s identifie le sélecteur DNS utilisé.
• dmarc : Résultat final de l'évaluation DMARC. Il affiche la politique du domaine expéditeur (p=none, quarantine, ou reject) ainsi que la décision d'action appliquée par le serveur (dis=none, dis=quarantine, etc.).

Évaluation de l'alignement DMARC par le serveur récepteur

Obtenir un statut spf=pass et dkim=pass est une condition nécessaire mais insuffisante pour valider DMARC. Pour obtenir un verdict dmarc=pass, au moins un des deux protocoles (SPF ou DKIM) doit être valide ET aligné avec le domaine présent dans l'en-tête From: visible par le destinataire.

L'alignement est évalué selon deux règles :

1. Alignement SPF : Le domaine de l'adresse de rebond (Return-Path / smtp.mailfrom) doit correspondre au domaine de l'en-tête From:.

   • Mode Relaxed (par défaut) : mail.domaine.com et domaine.com sont considérés comme alignés.
   • Mode Strict : Le domaine et le sous-domaine doivent être rigoureusement identiques.

2. Alignement DKIM : Le domaine spécifié dans la balise d= de la signature DKIM doit correspondre au domaine de l'en-tête From:.

Si un service tiers (ex: plateforme de routage marketing) émet des e-mails en utilisant son propre domaine pour le Return-Path ( bounce.plateforme.com), le test SPF brut sera pass, mais l'alignement DMARC SPF sera fail. Si la signature DKIM n'est pas personnalisée avec votre propre domaine (d=votre-domaine.com), l'évaluation DMARC globale échouera.

Diagnostic : isoler la cause exacte d'un échec

L'examen des paramètres spécifiques du champ Authentication-Results permet de cibler la cause exacte d'une rupture d'authentification :

1. spf=softfail ou spf=fail

• Cause : L'adresse IP du serveur émetteur n'est pas présente dans l'enregistrement TXT SPF du domaine smtp.mailfrom.
• Analyse : Vérifiez l'adresse IP spécifiée dans la mention designates X.X.X.X as permitted sender.
• Solution : Ajoutez le bloc IP ou l'instruction include: correspondante dans votre zone DNS, tout en veillant à ne pas dépasser la limite stricte de 10 résolutions DNS (DNS Lookups) imposée par la RFC 7208.

2. dkim=fail (bad signature)

• Cause : La clé publique récupérée dans le DNS ne permet pas de déchiffrer la signature, ou le message a été altéré pendant son transit.
• Analyse : Repérez le sélecteur via header.s=.
• Solution : Vérifiez que l'enregistrement TXT situé à l'emplacement sélecteur._domainkey.domaine.com correspond exactement à la clé enregistrée sur le serveur d'