Analysez les en-têtes d'un email
Le parcours des relais, le délai à chaque saut, les verdicts SPF / DKIM / DMARC et l'expéditeur réel — en un copier-coller. Rien n'est conservé.
Comment ça marche
- Récupérez les en-têtes bruts — « Afficher l'original » dans Gmail, « Afficher les détails du message » dans Outlook, Ctrl+U dans Thunderbird. Copiez tout le bloc situé avant la première ligne vide.
- Collez-les dans le champ ci-dessus — l'outil déplie les lignes repliées, ignore le corps du message si vous l'avez copié par mégarde, et décode les sujets encodés en MIME.
- Lisez le rapport — parcours des relais dans l'ordre chronologique avec le délai à chaque saut, verdicts SPF / DKIM / DMARC tels que le serveur destinataire les a écrits, expéditeur affiché contre expéditeur réel, et les en-têtes qui méritent un coup d'œil.
Cas d'usage
- Vérifier si un message est une tentative d'hameçonnage — un nom affiché rassurant devant une adresse inconnue, un DMARC en échec et un Return-Path sur un domaine sans rapport : trois signaux qui se lisent d'un coup ici.
- Comprendre pourquoi un email est arrivé en retard — le délai par saut désigne précisément le relais qui a retenu le message, au lieu de laisser accuser « internet ».
- Diagnostiquer un problème de délivrabilité sur vos propres envois — envoyez-vous un message depuis votre outil d'emailing, puis lisez ici les verdicts SPF et DKIM réellement obtenus côté destinataire.
- Prouver le trajet d'un message — dans un litige ou un incident, la chaîne des Received horodatée est la seule trace vérifiable de ce qui s'est passé.
- Identifier le logiciel d'envoi — les en-têtes X-Mailer et User-Agent trahissent souvent un envoi en masse déguisé en message personnel.
Ce que l'outil ne fait pas / limites
- L'outil lit les verdicts SPF, DKIM et DMARC ; il ne les recalcule pas. Ces vérifications n'ont de valeur qu'exécutées à la réception, par le serveur destinataire : les refaire après coup, sans l'IP de connexion d'origine, produirait un résultat faux.
- Les en-têtes Received sont déclaratifs : un serveur malveillant peut en fabriquer. Seuls les Received ajoutés par des serveurs de confiance, en fin de chaîne, sont réellement fiables.
- Le corps du message n'est pas analysé : ni les liens, ni les pièces jointes, ni le contenu HTML. Pour ouvrir un message complet, utilisez la visionneuse EML.
- Aucune réputation d'IP ni de domaine n'est consultée ici : la vérification en liste noire fera l'objet d'un outil dédié.
- Rien n'est conservé, donc rien n'est comparable dans le temps : l'outil ne garde pas d'historique de vos analyses.
Questions fréquentes
Où trouver les en-têtes complets d'un email ? +
Dans Gmail : ouvrez le message, menu « ⋮ » puis « Afficher l'original ». Dans Outlook sur le web : « ⋯ » puis « Afficher » et « Afficher les détails du message ». Dans Thunderbird : Ctrl+U, ou menu « Affichage › Code source du message ». Copiez tout le bloc avant la première ligne vide, c'est exactement ce que cet outil attend.
Que raconte la chaîne des en-têtes Received ? +
Chaque serveur qui relaie le message ajoute une ligne Received en tête. Lue à l'envers, cette pile raconte le trajet du message, du poste de l'expéditeur jusqu'à votre boîte. L'outil remet ces lignes dans l'ordre chronologique et calcule le temps passé entre deux relais : un saut de plusieurs heures désigne le serveur qui a retenu le message.
Que signifient les verdicts SPF, DKIM et DMARC ? +
SPF vérifie que le serveur d'envoi était autorisé par le domaine expéditeur. DKIM vérifie une signature cryptographique apposée par le domaine expéditeur. DMARC combine les deux et vérifie qu'ils concordent avec le domaine affiché dans le champ From. Ces verdicts sont écrits par le serveur qui a reçu le message, dans l'en-tête Authentication-Results : l'outil les lit, il ne les recalcule pas.
Un SPF ou un DKIM en échec veut-il dire que le message est frauduleux ? +
Pas nécessairement. Une liste de diffusion, un transfert automatique ou un service d'envoi mal configuré cassent régulièrement SPF ou DKIM sur des messages parfaitement légitimes. En revanche, un DMARC en échec sur un message qui prétend venir d'une banque ou d'un service public est un signal sérieux, surtout combiné à un écart entre le nom affiché et l'adresse réelle.
Pourquoi le nom affiché peut-il mentir sur l'expéditeur ? +
Le nom affiché est un simple texte libre choisi par l'expéditeur : rien n'empêche d'écrire « Service client » ou même « [email protected] » devant une adresse qui n'a aucun rapport. L'outil sépare systématiquement les deux et signale l'écart, ainsi que la différence entre l'adresse affichée et l'adresse de retour technique (Return-Path).
Mes en-têtes sont-ils enregistrés quelque part ? +
Non. L'analyse est faite pendant la requête et le résultat est renvoyé directement : rien n'est écrit en base, rien n'est écrit sur disque, rien n'est envoyé à un service tiers. Rechargez la page et il ne reste rien.
L'outil a-t-il une limite de taille ou de nombre d'analyses ? +
Les en-têtes sont lus jusqu'à 256 Ko, ce qui couvre très largement n'importe quel message réel. Une cadence anti-abus s'applique par adresse IP, identique pour tout le monde : elle ne se remarque pas dans un usage normal, même intensif.