Un·e ingénieur·e support a passé deux jours à comprendre pourquoi les emails d’un client spécifique arrivaient avec 6 heures de retard. Le client jurait les avoir envoyés immédiatement. Le destinataire jurait qu’ils arrivaient des heures plus tard. Tout le monde blâmait le système d’email de l’autre.
La réponse se trouvait dans les en-têtes. En parcourant les en-têtes Received, on a découvert que le message était resté dans une file d’attente sur un serveur relais intermédiaire pendant 5 heures et 47 minutes. Le relais était un système legacy que le client avait oublié, mal configuré et en difficulté sous la charge. Dix minutes d’analyse des en-têtes ont résolu une énigme de deux jours.
Les en-têtes d’email sont la boîte noire de chaque message. Ils documentent le voyage complet de l’expéditeur au destinataire, chaque serveur touché, chaque vérification effectuée. Apprendre à les lire est l’une des compétences de debugging les plus précieuses en email.
La structure des en-têtes d’email
Les en-têtes d’email apparaissent au début de chaque message, avant le contenu du corps. Ce sont une série de paires champ-valeur, chacune sur sa propre ligne, suivant un format simple : "Nom-du-champ: valeur du champ".
Les en-têtes ont plusieurs objectifs. Certains identifient le message : From, To, Subject, Date, Message-ID. Certains enregistrent le chemin de livraison : les en-têtes Received de chaque serveur. Certains documentent les contrôles de sécurité : Authentication-Results, DKIM-Signature. Certains contrôlent le comportement : Reply-To, List-Unsubscribe.
L’ordre des en-têtes compte dans certains cas. Les en-têtes Received sont ajoutés en ordre chronologique inverse — le plus récent en haut, l’original en bas. Les lire de bas en haut retrace le parcours du message dans le temps.
La plupart des clients email masquent les en-têtes par défaut, n’affichant que From, To, Subject et Date. Pour voir les en-têtes complets, il faut accéder à "view source", "show original", ou des options similaires selon votre client email.
Les en-têtes Received : la piste de livraison
Chaque serveur de messagerie qui traite un message ajoute un en-tête Received documentant son intervention. Ces en-têtes créent une piste d’audit du chemin complet du message.
Un en-tête Received typique contient plusieurs informations : le serveur qui a reçu le message (celui qui ajoute l’en-tête), le serveur dont il l’a reçu, le protocole utilisé (SMTP, ESMTP, etc.), et un horodatage.
En lisant de bas en haut, vous pouvez retracer le parcours du message. L’en-tête Received tout en bas montre le premier serveur qui a traité le message après qu’il a quitté le client de messagerie de l’expéditeur. Chaque en-tête suivant montre le saut (hop) suivant. L’en-tête Received tout en haut montre la livraison finale dans la boîte du destinataire.
Les horodatages dans les en-têtes Received aident à identifier les retards. S’il y a un écart de 3 heures entre deux en-têtes consécutifs, le message est resté sur ce serveur pendant 3 heures. Cela permet de localiser où les retards se produisent.
Les champs "from" et "by" identifient les serveurs. "From" montre d’où vient le message ; "by" montre le serveur qui ajoute l’en-tête. Des divergences ou des entrées suspectes peuvent indiquer un transfert, un relais, ou potentiellement du spoofing.
En-têtes d’authentification
Les emails modernes incluent des en-têtes documentant les contrôles d’authentification. Ils indiquent si SPF, DKIM et DMARC ont réussi ou échoué.
L’en-tête Authentication-Results est ajouté par les serveurs destinataires après avoir effectué les contrôles d’authentification. Il résume les résultats dans un format structuré : quels contrôles ont été effectués, s’ils ont réussi ou échoué, et des détails pertinents comme le domaine vérifié ou la clé utilisée.
Un résultat d’authentification réussi peut montrer SPF pass avec l’adresse IP vérifiée, DKIM pass avec le domaine de signature, et DMARC pass avec la politique appliquée. Les échecs incluent des codes de raison expliquant ce qui n’a pas fonctionné.
L’en-tête DKIM-Signature contient la signature cryptographique réelle ajoutée par le serveur d’envoi. Il précise l’algorithme de signature, le domaine responsable, le sélecteur pour la recherche de clé, quels en-têtes sont signés, et la signature elle-même.
Lors du debugging des échecs d’authentification, ces en-têtes vous disent exactement ce qui s’est passé. "DKIM signature verification failed" dans Authentication-Results, combiné à l’examen de l’en-tête DKIM-Signature, révèle souvent si la signature était mal formée, si la clé manquait, ou si le message a été modifié en transit.
Identifier l’expéditeur réel
Plusieurs en-têtes concernent l’identité de l’expéditeur, et comprendre leurs différences importe à la fois pour le debugging et la sécurité.
L’en-tête From est ce que les destinataires voient — l’adresse affichée dans leur client email. Cela se falsifie facilement ; n’importe qui peut mettre n’importe quelle adresse dans l’en-tête From.
Le Return-Path (ou Envelope-From) est l’adresse où sont envoyés les bounces. Elle est définie pendant la transaction SMTP, pas dans les en-têtes du message, bien qu’elle soit souvent consignée dans les en-têtes par les serveurs destinataires. SPF vérifie cette adresse, pas l’adresse From.
L’en-tête Sender, lorsqu’il est présent, indique qui a effectivement envoyé le message au nom de l’adresse From. Il est utilisé quand quelqu’un envoie un email pour une autre personne, comme un·e assistant·e qui envoie au nom d’un·e dirigeant·e.
Reply-To spécifie où les réponses doivent aller, ce qui peut différer de From. Des usages légitimes incluent l’envoi depuis une adresse no-reply tout en dirigeant les réponses vers une boîte surveillée. Des usages illégitimes incluent des emails de phishing qui affichent une adresse From de confiance mais récupèrent les réponses ailleurs.
Pour l’analyse de sécurité, comparez ces en-têtes. Les décalages ne sont pas toujours malveillants — il existe des raisons légitimes à ces différences — mais ils méritent votre attention.
Horodatages et délais
Chaque en-tête Received inclut un horodatage. Comparer ces horodatages révèle où les messages ont passé du temps.
L’en-tête Date montre quand le message a été rédigé (selon l’horloge de l’expéditeur). L’horodatage du premier en-tête Received montre quand il est entré dans le système de messagerie. Les horodatages suivants montrent chaque hop. L’horodatage final montre la livraison.
Des écarts importants entre deux en-têtes Received consécutifs indiquent une mise en file d’attente. Le message est arrivé sur un serveur mais n’a pas été immédiatement transféré. Cela peut être intentionnel (le greylisting retarde les nouveaux expéditeurs) ou problématique (serveur surchargé, problèmes réseau).
Les différences de fuseaux horaires peuvent perturber l’analyse des horodatages. Les en-têtes peuvent afficher des heures dans des zones différentes. Convertissez tout dans un seul fuseau (UTC est conventionnel) avant de calculer les intervalles.
Un décalage d’horloge entre serveurs peut créer des anomalies apparentes — un message semblant arriver avant d’avoir été envoyé. De petites divergences (de quelques secondes à quelques minutes) sont normales. De grands écarts suggèrent des horloges de serveur mal configurées.
En-têtes de spam et de filtrage
De nombreux serveurs de messagerie ajoutent des en-têtes indiquant leur évaluation de spam. Ils ne sont pas standardisés mais suivent des schémas courants.
X-Spam-Status montre généralement si le message a été classé comme spam et le score qu’il a reçu. X-Spam-Score affiche simplement le score numérique. X-Spam-Flag est un indicateur oui/non simple.
SpamAssassin, un filtre de spam courant, ajoute des en-têtes détaillés montrant quelles règles ont été déclenchées et leurs valeurs en points. Cette ventilation est précieuse pour comprendre pourquoi un message a été filtré. "MISSING_SUBJECT: 2.5 points" vous dit exactement quoi corriger.
Certains serveurs ajoutent des en-têtes indiquant quelles blacklists ont été vérifiées et si l’expéditeur y apparaissait. Cela aide à diagnostiquer des problèmes de livraison liés aux blacklists.
Les en-têtes spécifiques aux fournisseurs varient. Gmail ajoute des en-têtes liés à son système de catégorisation. Microsoft ajoute des en-têtes sur leurs décisions de filtrage. Apprendre à les reconnaître aide lors du debugging des livraisons vers des fournisseurs spécifiques.
Analyse pratique des en-têtes
Lors du debugging de problèmes email, une approche systématique de l’analyse des en-têtes aide beaucoup.
Commencez par l’en-tête Authentication-Results. SPF, DKIM et DMARC ont-ils réussi ? Sinon, vous avez probablement trouvé votre problème. Les détails expliquent ce qui a échoué et pourquoi.
Ensuite, retracez les en-têtes Received de bas en haut. Le chemin a-t-il du sens ? Y a-t-il des serveurs inattendus ? Y a-t-il de longs délais entre les hops ? Les anomalies ici expliquent souvent les problèmes de livraison.
Cherchez des en-têtes liés au spam. Le message a-t-il été noté comme spam ? Quelles règles ont été déclenchées ? Cela vous indique ce que le serveur destinataire n’a pas apprécié dans le message.
Vérifiez la cohérence des en-têtes d’expéditeur. Le domaine From correspond-il au domaine Return-Path (pour l’alignement DMARC) ? Reply-To pointe-t-il vers un endroit inattendu ? Des incohérences peuvent expliquer un filtrage ou indiquer un spoofing.
Regardez les horodatages. Quand le message a-t-il été envoyé ? Quand a-t-il été livré ? Où a-t-il passé du temps ? Les délais deviennent visibles dans la piste d’horodatage.
Outils pour l’analyse des en-têtes
Bien que vous puissiez lire les en-têtes manuellement, des outils rendent l’analyse plus rapide et détectent ce qui pourrait vous échapper.
Le Message Header Analyzer de Google (dans Google Admin Toolbox) analyse les en-têtes et les présente dans un format lisible, en mettant en évidence les retards et les résultats d’authentification.
L’analyseur d’en-têtes de MXToolbox analyse et formate également les en-têtes, avec un contexte supplémentaire sur la signification de chaque champ.
Les outils intégrés des clients email varient en qualité. Certains n’affichent que les en-têtes bruts ; d’autres proposent un parsing basique. Pour un debugging sérieux, des outils dédiés à l’analyse valent la peine d’être utilisés.
Pour l’analyse programmatique, il existe des bibliothèques dans la plupart des langages pour parser les en-têtes d’email. Cela permet une surveillance et des alertes automatisées basées sur le contenu des en-têtes.
Frequently asked questions
Les en-têtes d’email peuvent-ils être falsifiés ?
Les en-têtes ajoutés par l’expéditeur (From, Subject, etc.) peuvent être falsifiés. Les en-têtes ajoutés par les serveurs destinataires (Received, Authentication-Results) sont fiables parce qu’ils sont ajoutés après l’arrivée du message. C’est pourquoi les résultats d’authentification du serveur destinataire sont importants.
Pourquoi vois-je plusieurs en-têtes Received ?
Chaque serveur qui traite le message ajoute son propre en-tête Received. Un message qui passe par 5 serveurs aura 5 en-têtes Received. C’est normal et cela crée la piste d’audit qui rend le debugging possible.
Comment afficher les en-têtes dans Gmail ?
Ouvrez le message, cliquez sur le menu à trois points en haut à droite, et sélectionnez 'Show original'. Cela affiche la source complète du message, y compris tous les en-têtes.
Que signifie 'with ESMTPS' dans les en-têtes Received ?
Cela indique que le message a été transféré en utilisant SMTP avec un chiffrement TLS (le S signifie Secure). 'ESMTP' sans le S signifie un transfert non chifré. Les emails modernes devraient montrer des transferts chifrés entre serveurs.