Les points à retenir avant d’ouvrir les en-têtes
- Un en-tête montre la trajectoire technique du message, pas seulement l’expéditeur affiché.
- Les champs les plus utiles sont Received, Authentication-Results, SPF, DKIM, DMARC et Message-ID.
- Le champ From peut être trompeur ; je le croise toujours avec les résultats d’authentification.
- La lecture se fait en remontant les sauts serveur, pas en suivant l’ordre visuel de haut en bas.
- Les outils web accélèrent l’analyse, mais ils ne remplacent pas une lecture méthodique du header brut.
Ce que révèle réellement un en-tête de mail
Je commence toujours par rappeler une chose simple : un en-tête n’est pas un accessoire technique, c’est la fiche d’identité du message. On y trouve des informations sur l’expéditeur affiché, les destinataires, la date, le message-id, le format MIME et surtout les traces laissées par chaque serveur traversé.
Autrement dit, un en-tête sert à distinguer ce qui est affiché au lecteur de ce qui s’est réellement passé pendant le transport du mail. C’est précisément pour cela qu’il est si utile pour repérer les retards, les erreurs de routage et les tentatives de spoofing.
| Champ | Ce qu’il indique | Ce que j’en retire |
|---|---|---|
| From | L’adresse visible de l’expéditeur | Je la lis, mais je ne la considère jamais comme une preuve d’authenticité |
| Reply-To | Adresse utilisée si le destinataire répond | Très utile pour repérer un détournement discret de réponses |
| Return-Path | Adresse de retour liée au transport SMTP | Souvent plus proche de l’identité technique réelle que le From |
| Received | Chaque serveur relais traversé | Je reconstitue le trajet et les délais |
| Message-ID | Identifiant unique du message | Pratique pour suivre un mail précis dans des logs ou un ticket |
| Authentication-Results | Résultat des contrôles de sécurité effectués par le serveur receveur | Le premier endroit où je vérifie SPF, DKIM et DMARC |
Quand ces champs sont cohérents, le message inspire davantage confiance. Quand ils se contredisent, je passe tout de suite à la lecture du trajet et de l’authentification, parce que c’est là que les anomalies deviennent visibles. Pour les lire correctement, encore faut-il savoir où les récupérer dans Gmail, Outlook ou un outil web.
Comment récupérer les bons en-têtes dans Gmail et Outlook
Le plus gros piège, c’est de copier seulement le message affiché et non le header complet. Dans Gmail, je passe par Afficher l’original ; dans Outlook, j’ouvre les détails du message pour accéder à la partie technique. C’est cette version brute qu’il faut coller dans un analyseur, pas le contenu du mail lui-même.
- Dans Gmail : ouvrir le message, cliquer sur le menu à trois points, puis sur Afficher l’original pour récupérer l’en-tête complet.
- Dans Outlook : afficher les détails du message ou les en-têtes Internet selon la version utilisée, puis copier le bloc brut.
- Dans un outil web : coller le header complet dans le champ prévu et lancer l’analyse sans modifier la structure des lignes.
Sur un webmail, je conseille de conserver le texte brut tel quel, avec toutes les lignes Received intactes. Si vous supprimez une partie du header, vous perdez justement les indices qui permettent de comprendre le problème. À partir de là, la vraie valeur est dans la lecture des champs d’authentification.
Les champs qui disent si le message est authentique
Dans mes diagnostics, je regarde d’abord les preuves d’authentification, pas le libellé du message. SPF vérifie si l’IP qui envoie le mail est autorisée pour le domaine utilisé dans l’envoi SMTP ; DKIM confirme qu’une signature n’a pas été altérée ; DMARC vérifie l’alignement entre le domaine visible dans le champ From et les mécanismes d’authentification réellement validés.
| Signal | Ce que cela veut dire | Lecture prudente |
|---|---|---|
| spf=pass / fail | Le serveur source est ou non autorisé par le domaine envoyé | Un fail n’est pas toujours une fraude, surtout en cas de transfert ou de relais mal configuré |
| dkim=pass / fail | La signature cryptographique du message est valide ou non | Un pass rassure, mais je vérifie quand même le domaine signé et le From |
| dmarc=pass / fail | Les contrôles et l’alignement de domaine sont cohérents | Le plus utile pour repérer une identité d’expéditeur qui ne tient pas la route |
| Authentication-Results | Le résumé renvoyé par le serveur receveur | Le meilleur point d’entrée quand je veux une lecture rapide |
| Received-SPF | Trace éventuelle du résultat SPF | Pratique, mais pas toujours présent selon les serveurs |
Le réflexe important, c’est de ne pas confondre pass technique et confiance totale. Un message authentifié peut quand même être indésirable, tandis qu’un message légitime peut échouer après un transfert ou une passerelle intermédiaire mal gérée. C’est pour cela que je complète toujours cette lecture par l’analyse du chemin parcouru.
Lire le trajet du mail et repérer un retard
Les lignes Received racontent l’itinéraire du message, saut par saut. Je les lis de bas en haut, car la ligne la plus basse correspond en général au premier serveur qui a accepté le courrier, tandis que les lignes du dessus décrivent les relais suivants jusqu’à la boîte finale.
Ma méthode est simple : je repère l’adresse IP ou le nom de serveur, je compare les heures, puis je cherche les écarts anormaux. Un retard de quelques secondes entre deux relais est normal ; un trou beaucoup plus long ou un relais inattendu mérite une vérification, surtout si le mail a été réexpédié plusieurs fois.
- Identifier le premier relais réellement visible dans la chaîne Received.
- Comparer les fuseaux horaires et les timestamps pour éviter une fausse alerte.
- Chercher les sauts inhabituels, les IP privées ou les domaines qui ne correspondent pas à l’expéditeur attendu.
- Vérifier si le message a traversé une liste de diffusion, une passerelle de sécurité ou un service de transfert.
Je garde une réserve importante : un message transféré peut casser SPF sans être suspect, simplement parce que le relais intermédiaire n’est pas autorisé à envoyer au nom du domaine d’origine. Dès qu’on a compris ce point, on choisit mieux les outils pour aller plus vite sans perdre en fiabilité.
Les outils web que j’utilise pour gagner du temps
Pour un diagnostic rapide, j’aime les outils qui transforment le header brut en lecture claire sans me faire perdre la structure d’origine. Les trois que je vois le plus souvent en pratique sont l’outil d’en-tête de Google, MxToolbox et le Message Header Analyzer de Microsoft. Chacun a un usage légèrement différent, et le bon choix dépend surtout de ce que vous essayez de prouver.| Outil | Point fort | Quand je le privilégie |
|---|---|---|
| Google Admin Toolbox Messageheader | Lecture très claire du trajet et des délais | Quand je veux visualiser rapidement où le message a ralenti ou bloqué |
| MxToolbox Email Header Analyzer | Bon niveau de détail et lecture orientée diagnostic | Quand je soupçonne un souci d’authentification ou de routage |
| Microsoft Message Header Analyzer | Approche simple pour décoder les informations techniques | Quand l’environnement de messagerie est plutôt Microsoft ou Outlook |
| Analyseur interne ou local | Meilleure maîtrise des données sensibles | Quand l’e-mail contient des éléments confidentiels ou contractuels |
Je choisis rarement l’outil pour lui-même ; je le choisis pour son degré de lisibilité et pour le niveau de confidentialité du cas. Si le message contient des données sensibles, je préfère éviter de le coller dans un service tiers sans réfléchir. L’objectif n’est pas seulement de décoder vite, mais de conserver un diagnostic exploitable sans exposer inutilement le contenu.
Les erreurs que je vois le plus souvent
Les mauvaises conclusions viennent rarement d’un manque d’outillage ; elles viennent surtout d’une lecture trop rapide. Je vois toujours les mêmes confusions, et elles faussent le diagnostic plus souvent qu’on ne le croit.
- Confondre From et expéditeur réel : le champ visible n’est pas une preuve d’origine.
- Lire les Received dans le mauvais sens : il faut remonter la chaîne, pas la suivre naïvement de haut en bas.
- Conclure qu’un SPF fail prouve un spam : un transfert, une liste ou une passerelle peuvent casser le contrôle.
- Ignorer DKIM parce que le mail s’affiche correctement : l’affichage ne dit rien sur l’intégrité du message.
- Oublier le contexte d’envoi : formulaire WordPress, newsletter, relance automatique et mail personnel n’obéissent pas aux mêmes chemins.
Quand j’explique un résultat à un client, je rappelle toujours qu’un header ne donne pas une vérité absolue ; il donne un faisceau d’indices. C’est cette nuance qui évite de corriger le mauvais maillon, et elle mène directement à la question la plus utile : que faire une fois le problème identifié ?
Ce que je fais ensuite quand le diagnostic est clair
Une fois la cause isolée, je passe à une correction concrète : alignement du domaine, vérification des enregistrements DNS, réglage du relais SMTP, ou nettoyage d’un plugin d’envoi dans WordPress. Je refais ensuite un test avec un mail neuf pour comparer les en-têtes avant et après la modification.
- Garder un exemple de header “bon” et un header “mauvais” pour comparer les changements.
- Vérifier que SPF, DKIM et DMARC racontent la même histoire.
- Contrôler le chemin d’envoi après toute modification de serveur, de plugin ou de passerelle.
- Documenter le cas si l’équipe doit reproduire le diagnostic plus tard.
Dans un environnement WordPress, cette routine évite beaucoup d’essais hasardeux. En pratique, l’analyse des en-têtes devient vite l’outil le plus fiable pour savoir si le problème vient du contenu, de l’authentification ou du chemin de livraison, et c’est souvent ce qui fait gagner le plus de temps.
