Il y a quelques années, j’ai passé trois jours à déboguer pourquoi les emails transactionnels d’un client finissaient en spam. Le contenu était correct. SPF et DKIM étaient bien configurés. DMARC passait. Tout semblait parfait — jusqu’à ce que je lise les en-têtes bruts.
Caché dans le message se trouvait un en-tête indiquant « X-Spam-Status: Yes, score=8.2 ». Le propre serveur de messagerie du client marquait les messages comme spam avant même qu’ils ne quittent le bâtiment. Un filtre anti-spam mal configuré ajoutait cet en-tête, et les serveurs en aval lui faisaient confiance.
Les en-têtes email racontent une histoire. Ils enregistrent chaque serveur qui a touché un message, chaque vérification d’authentification effectuée, chaque score de spam calculé. Apprendre à les lire, c’est comme apprendre à lire un dossier médical — soudain, vous pouvez diagnostiquer des problèmes qui semblaient mystérieux.
L’anatomie des en-têtes email
Les en-têtes email apparaissent en haut de chaque message, même si la plupart des clients les masquent par défaut. Ce sont une série de paires clé-valeur, chacune sur sa propre ligne, qui enregistrent des métadonnées sur le message et son parcours.
Les en-têtes sont ajoutés dans l’ordre chronologique inverse. L’en-tête le plus récent est en haut ; les en-têtes d’origine de l’expéditeur sont en bas. Cela compte lorsque vous retracez le chemin d’un message — on lit de bas en haut pour suivre le parcours chronologique.
Certains en-têtes sont définis par l’expéditeur : From, To, Subject, Date. D’autres sont ajoutés par les serveurs en cours de route : en-têtes Received de chaque serveur de messagerie, résultats d’authentification, scores anti-spam. Comprendre quels en-têtes viennent d’où aide à interpréter ce que vous voyez.
En-têtes Received : retracer le chemin
Chaque serveur de messagerie qui traite un message ajoute un en-tête Received. Cela crée un fil d’Ariane montrant précisément comment le message a voyagé de l’expéditeur au destinataire.
Un en-tête Received typique inclut le serveur qui a reçu le message, le serveur dont il l’a reçu, le protocole utilisé et un horodatage. Les lire de bas en haut vous montre le parcours complet.
C’est inestimable pour le débogage. Si un message est retardé, les en-têtes Received montrent où il s’est bloqué. S’il est rejeté, vous pouvez voir quel serveur l’a rejeté. S’il est modifié en transit, vous pouvez identifier quel serveur a fait des changements.
Soyez attentif aux schémas suspects. Un message prétendant venir d’une grande entreprise mais avec des en-têtes Received indiquant qu’il provient d’une adresse IP résidentielle est presque certainement frauduleux. Un email d’entreprise légitime ne vient pas de la connexion internet domestique de quelqu’un.
Authentication-Results : le verdict
L’en-tête Authentication-Results est l’endroit où les serveurs récepteurs enregistrent le résultat des vérifications d’authentification. Cet unique en-tête vous dit si SPF, DKIM et DMARC ont réussi ou échoué, et inclut souvent des détails expliquant pourquoi.
Un en-tête Authentication-Results typique peut montrer un SPF « pass » avec l’adresse IP vérifiée, un DKIM « pass » avec le domaine qui a signé le message, et un DMARC « pass » avec la politique appliquée. Ou il peut montrer des échecs, avec des codes de raison expliquant ce qui n’a pas fonctionné.
Pour dépanner la délivrabilité, c’est souvent le premier en-tête à vérifier. Si l’authentification échoue, la raison est généralement juste là. « SPF softfail » vous dit que votre enregistrement SPF n’est pas tout à fait correct. « DKIM signature verification failed » suggère que le message a été modifié en transit ou que la signature est mal formée.
Les serveurs récepteurs formatent cet en-tête légèrement différemment, mais l’information est similaire. Gmail, Microsoft, Yahoo — ils enregistrent tous les résultats d’authentification, avec seulement de petites variations de syntaxe.
DKIM-Signature : la preuve cryptographique
L’en-tête DKIM-Signature contient la signature cryptographique qui prouve qu’un message n’a pas été altéré depuis qu’il a quitté le serveur signataire. Il a l’air complexe mais suit une structure cohérente.
L’en-tête spécifie l’algorithme utilisé, le domaine qui a signé le message, le sélecteur à utiliser pour la recherche de clé publique, les en-têtes couverts par la signature, un hachage du corps et la signature elle-même.
Pour le débogage, les parties les plus utiles sont le domaine (d=) et le sélecteur (s=). Ils vous indiquent où chercher la clé publique. Si DKIM échoue, vous pouvez vérifier manuellement si l’enregistrement DNS existe et contient une clé valide.
Les en-têtes couverts par la signature (h=) comptent aussi. Si un en-tête listé là a été modifié en transit, la signature se brise. Les coupables courants incluent les lignes d’objet modifiées par des listes de diffusion ou les en-têtes From réécrits par des services de transfert.
En-têtes X-Spam : les signaux de réputation
De nombreux serveurs de messagerie ajoutent des en-têtes indiquant leur évaluation du spam. Ils ne sont pas standardisés — différents serveurs utilisent des noms et formats d’en-têtes différents — mais ils sont extrêmement utiles pour comprendre pourquoi les messages sont filtrés.
SpamAssassin, l’un des filtres anti-spam les plus courants, ajoute les en-têtes X-Spam-Status et X-Spam-Score. Le status indique si le message a été classé comme spam, et le score montre la note numérique. Plus le score est élevé, plus c’est « spam-like ».
X-Spam-Flag est un indicateur oui/non simple. X-Spam-Report contient souvent une ventilation détaillée des règles qui ont été déclenchées et du nombre de points apportés par chacune. Cette ventilation est de l’or pour le débogage — elle vous dit exactement ce que le filtre n’a pas apprécié.
Si vous rencontrez des problèmes de classification en spam, cherchez ces en-têtes. Ils révèlent souvent des problèmes spécifiques : « MISSING_DATE » signifie que vous avez oublié l’en-tête Date, « HTML_IMAGE_ONLY » signifie que votre message n’est que des images sans texte, « RCVD_IN_BRBL » signifie que votre IP d’envoi est sur une blacklist.
List-Unsubscribe : l’en-tête de conformité
L’en-tête List-Unsubscribe n’est pas de la sécurité au sens traditionnel, mais il est crucial pour la délivrabilité et la conformité. Il indique aux clients email comment les destinataires peuvent se désabonner de vos messages.
Les clients email modernes — Gmail, Apple Mail, Outlook — affichent un lien de désabonnement de manière visible lorsque cet en-tête est présent. C’est bon pour les destinataires et bon pour vous : un désabonnement facile signifie moins de signalements de spam, donc une meilleure délivrabilité.
L’en-tête peut contenir un lien mailto, une URL HTTPS, ou les deux. La bonne pratique est d’inclure les deux, afin de donner des options aux clients email. Le nouvel en-tête List-Unsubscribe-Post permet un désabonnement en un clic sans obliger l’utilisateur à visiter une page web ou à envoyer un email.
Pour les emails marketing et en volume, cet en-tête est quasiment obligatoire. Gmail et d’autres fournisseurs pénalisent les messages qui n’en disposent pas. Pour les emails transactionnels, c’est moins critique mais ça reste une bonne pratique pour toute notification récurrente.
Message-ID : l’identifiant unique
Chaque email devrait avoir un en-tête Message-ID unique. Cet identifiant permet aux systèmes de messagerie de suivre les messages, de détecter les doublons et de trier correctement les conversations.
Un Message-ID correct ressemble à une chaîne aléatoire suivie de @ et d’un nom de domaine. Le domaine devrait être un domaine que vous contrôlez — utiliser votre domaine d’envoi est la pratique standard. La partie aléatoire doit être vraiment unique ; les UUID fonctionnent bien.
Les Message-ID manquants ou mal formés causent des problèmes. Certains filtres anti-spam signalent les messages qui n’en ont pas. Le tri des fils de discussion se brise dans les clients email. La détection des doublons échoue, ce qui peut entraîner la livraison multiple du même message.
Si vous construisez des systèmes d’envoi d’emails, générez des Message-ID corrects. C’est un petit détail qui évite des problèmes agaçants par la suite.
Reply-To vs From : le routage des réponses
L’en-tête From indique qui a envoyé le message. L’en-tête Reply-To, lorsqu’il est présent, dit aux clients email où envoyer les réponses. Ils peuvent être différents, et comprendre quand utiliser Reply-To est important.
Un schéma courant : les emails marketing viennent de From [email protected] mais ont Reply-To défini sur [email protected]. Cela vous permet d’envoyer depuis une adresse marketing dédiée tout en dirigeant les réponses vers votre équipe support.
Soyez prudent avec Reply-To. Certains filtres anti-spam regardent avec suspicion les adresses From et Reply-To qui ne correspondent pas, en particulier si les domaines sont différents. C’est une technique utilisée par les fraudeurs pour faire paraître des emails frauduleux légitimes tout en capturant les réponses.
Pour les emails transactionnels, garder From et Reply-To identiques (ou omettre complètement Reply-To) est généralement préférable. Pour les emails marketing, utiliser Reply-To pour router les réponses vers une boîte surveillée a du sens.
Lire les en-têtes en pratique
Lorsque vous dépannez un problème d’email, voici une approche systématique pour lire les en-têtes.
Commencez par Authentication-Results. SPF, DKIM et DMARC ont-ils passé ? Sinon, vous avez probablement trouvé votre problème. Les détails dans cet en-tête expliquent généralement ce qui n’a pas fonctionné.
Ensuite, vérifiez les en-têtes Received. Retracez le chemin du message de bas en haut. Cherchez des serveurs inattendus, de longs délais entre les sauts, ou des serveurs qui auraient pu modifier le message.
Recherchez les en-têtes liés au spam. X-Spam-Status, X-Spam-Score, X-Spam-Flag — l’un quelconque d’entre eux peut révéler pourquoi un message a été filtré. Les rapports détaillés pointent souvent vers des problèmes spécifiques et corrigibles.
Enfin, vérifiez les basiques. Y a‑t‑il un Message-ID valide ? L’en-tête Date est-il présent et raisonnable ? From est-il correctement défini ? Des en-têtes de base manquants ou mal formés déclenchent des filtres anti-spam.
Frequently asked questions
Comment afficher les en-têtes email ?
Dans Gmail, ouvrez le message et cliquez sur le menu à trois points, puis 'Afficher l'original'. Dans Outlook, ouvrez le message, cliquez sur Fichier, puis Propriétés. La plupart des clients email ont une option similaire 'afficher la source' ou 'afficher les en-têtes'.
Les en-têtes email peuvent-ils être falsifiés ?
Les en-têtes définis par l'expéditeur (From, Subject, etc.) peuvent être falsifiés. Les en-têtes ajoutés par les serveurs récepteurs (Received, Authentication-Results) sont plus difficiles à falsifier parce qu'ils sont ajoutés après l'arrivée du message. C'est pourquoi les résultats d'authentification du serveur récepteur sont dignes de confiance.
Pourquoi est-ce que je vois plusieurs en-têtes Authentication-Results ?
Chaque serveur qui effectue des vérifications d'authentification peut ajouter son propre en-tête. Vous pourriez en voir un provenant du serveur entrant de votre fournisseur de messagerie et un autre d'un filtre anti-spam interne. Le plus pertinent est généralement celui du serveur récepteur final.
Quelle est la différence entre Return-Path et From ?
From est l'adresse affichée aux destinataires. Return-Path (aussi appelé envelope sender) est l'endroit où sont envoyés les rebonds. Ils sont souvent identiques mais peuvent différer. SPF vérifie le domaine du Return-Path, pas le domaine du From — c'est pourquoi DMARC existe pour les aligner.