Analyseur d'en-têtes d'e-mail

Ce que ça fait

L’Analyseur d’en-têtes d’e-mail analyse les en-têtes bruts d’un message (RFC 5322) et les transforme en rapport d’expertise lisible : une bande de verdict qui condense toutes les découvertes en un seul appel d’un coup d’œil (indicateurs d’usurpation trouvés / signes suspects / propre), une chronologie de livraison saut par saut de chaque serveur Received traversé par le message avec le délai entre les sauts, les verdicts d’authentification SPF / DKIM / DMARC, et la liste complète des anomalies — signaux d’usurpation tels qu’une adresse From qui ne correspond pas au Return-Path, un Reply-To qui pointe quelque part d’inattendu, des chaînes de mailer suspectes, ou des horodatages qui remontent le temps.

La disposition est divisée : saisie des en-têtes bruts à gauche, rapport d’analyse en direct dans un panneau fixe à droite qui reste visible pendant que vous faites défiler les découvertes. C’est l’outil que vous utilisez quand un message ressemble à du hameçonnage et que vous voulez des preuves plutôt qu’une intuition.

Comment l’utiliser

1. Récupérez les en-têtes bruts : dans Gmail, ouvrez le message → ⋮ → Afficher l’original, puis copiez tout ce qui précède le corps du message. Outlook : Fichier → Propriétés → En-têtes Internet.
2. Collez-les dans En-têtes d’e-mail bruts (ou appuyez sur Exemple pour charger un message de démonstration intégré).
3. Appuyez sur Analyser les en-têtes. Le rapport apparaît à droite, sous la bande de verdict.
4. Lisez d’abord la bande de verdict : rouge (danger) = au moins un indicateur critique d’usurpation, ambre = avertissements seulement, vert = aucune anomalie. Les compteurs de sévérité se trouvent à droite de la bande (critical × 1, warnings × 2, notices × 1).
5. Parcourez les sections : Chemin de livraison (le saut le plus ancien en premier, badges de délai codés par couleur), Authentification (lignes SPF/DKIM/DMARC), Anomalies (chaque découverte avec sa preuve), et Tous les en-têtes (la table complète des en-têtes dépliés).
6. Appuyez sur Copier le lien de partage pour obtenir une URL qui transporte votre entrée exacte — quiconque l’ouvre voit la même analyse.

Lire les lignes d’authentification. Chaque ligne affiche le nom du mécanisme, son mot de résultat, et la clause de preuve dont il provient :

• SPF — l’IP du serveur émetteur a-t-elle été autorisée par le domaine de l’enveloppe (smtp.mailfrom) ? pass = autorisée ; softfail = non autorisée, mais le domaine demande seulement aux destinataires de la traiter comme suspecte ; fail = explicitement non autorisée, usurpation probable ; neutral = le domaine ne fait aucune revendication ; none = aucune politique publiée ; temperror = défaillance DNS transitoire ; permerror = enregistrement cassé ou mal formé. Le texte supplémentaire de la ligne montre l’adresse d’enveloppe qui a été vérifiée.
• DKIM — le message a-t-il été signé cryptographiquement, et la signature se vérifie-t-elle ? pass = signature valide (la ligne montre le selector signataire et, quand il est publié, le domaine signataire issu de header.d) ; fail = signature présente mais cassée — des en-têtes ou le corps ont été modifiés en transit ; none = non signé ; temperror/permerror = la clé publique n’a pas pu être récupérée. La ligne de détail montre la clause brute, ex. dkim=pass header.s=sel2026 header.b=AbCdEf.
• DMARC — la politique du domaine du From: visible a-t-elle accepté ce message ? pass = alignement et vérifications sous-jacentes satisfaites (la ligne montre le domaine header.from évalué et la politique p= du domaine : none, quarantine ou reject) ; fail = le message revendique une identité que sa propre politique n’accepte pas ; none = le domaine du From ne publie aucun enregistrement DMARC.

Une mise en garde cruciale, que l’exemple intégré démontre : les trois peuvent passer et le message peut quand même être un appât de hameçonnage. SPF/DKIM/DMARC vérifient que le domaine émetteur a réellement envoyé ce message — pas que l’expéditeur est digne de confiance, ni que le Reply-To va où vous pensez. C’est pourquoi la liste d’anomalies compte, même sur un panneau d’authentification entièrement « vert ».

Lire la chaîne Received. Les serveurs de messagerie préfixent chaque en-tête Received, donc l’outil les analyse de bas en haut : le saut 1 est le serveur d’origine, le dernier saut est votre boîte aux lettres. Entre deux sauts consécutifs, il affiche un badge de délai — le temps écoulé calculé depuis les horodatages des deux sauts :

• vert, moins d’une seconde (affiché en millisecondes) : relais normal.
• ambre, 1–60 s : un peu de file d’attente ou de greylisting — généralement sans importance.
• orange, plus de 60 s : relais lent, bridage du fournisseur de messagerie, ou message resté dans une file.
• « délai inconnu » gris : le saut n’a pas d’horodatage analysable, donc cette portion ne peut pas être mesurée (elle est aussi signalée comme anomalie d’information).

Les horodatages qui remontent le temps (saut N daté avant le saut N−1) reçoivent leur propre avertissement : soit les horloges de deux serveurs sont en désaccord, soit quelqu’un a forgé un en-tête Received.

Exemples

Chargez l’Exemple intégré et appuyez sur Analyser les en-têtes pour voir toutes les fonctionnalités d’un coup. Sortie vérifiée pour l’exemple :

• Chemin de livraison — 3 sauts, le plus ancien en premier : sender.evil.example → mail.relay.example (ESMTP), puis mail-sor-f41.google.com → mx.google.com (ESMTPS, +7.0 s), puis mx.google.com (SMTP, +3.0 s).
• Authentification — tout passe : SPF pass pour billing@legit-shop.com, DKIM pass avec le sélecteur sel2026, DMARC pass avec la politique quarantine pour legit-shop.com.
• Bande de verdict — rouge : critical × 1, warnings × 2, parce que les anomalies sont :

From: "Legit Shop Support" <support@legit-shop.com>
Reply-To: billing@evil.example
Return-Path: bounce@evil.example
X-Mailer: SuperBulk Mass Mailer 4.2

→ Critique : Return-Path (bounce@evil.example) does not match From (support@legit-shop.com) — the envelope sender differs from the displayed sender. Plus des avertissements pour le Reply-To détourné et le X-Mailer d’envoi massif. L’authentification est passée parce que legit-shop.com l’a réellement envoyé — le message est pourtant fabriqué pour ressembler à ce qu’il n’est pas.

Un message propre (enveloppe identique au From, signé, authentifié) :

Received: from mail.example.com by mx.google.com with ESMTPS; Tue, 12 Aug 2026 10:15:42 -0700
Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=billing@legit-shop.com; dkim=pass header.s=sel2026; dmarc=pass (p=quarantine) header.from=legit-shop.com
From: Billing <billing@legit-shop.com>
Return-Path: <billing@legit-shop.com>

→ Verdict vert, “No spoofing indicators found”, zéro anomalie.

Un panneau en échec — les trois mécanismes s’affichent en rouge :

Authentication-Results: mx.example.com; spf=softfail smtp.mailfrom=spoof@wrong.example; dkim=fail header.s=sel1; dmarc=fail (p=reject) header.from=bank.example

→ SPF softfail pour spoof@wrong.example, DKIM fail (sélecteur sel1), DMARC fail avec la politique reject — un message qu’un destinataire strict aurait dû refuser.

Un saut forgé — des horodatages qui remontent le temps :

Received: by mx.example.com; Tue, 12 Aug 2026 10:15:40 -0700
Received: from a.example by b.example; Tue, 12 Aug 2026 10:15:50 -0700

→ Avertissement : Hop 2 is timestamped 10.0s BEFORE hop 1 — clock skew between servers or a forged Received header.

Bon à savoir

Tous les signaux vérifiés par l’analyseur (sévérité entre parenthèses) :

1. Return-Path différent du From (critique) — l’expéditeur d’enveloppe (Return-Path, là où vont les rebonds) utilise une adresse différente du From affiché. Usurpation classique ; fréquente aussi dans le relais légitime de listes de diffusion.
2. Reply-To différent du From (avertissement) — les réponses seraient détournées vers une tierce adresse. Légitime pour les supports techniques, accablant quand le From est votre banque.
3. Chaîne de mailer suspecte (avertissement) — X-Mailer ou User-Agent contient un jeton associé aux outils d’envoi massif : bulk, mass mail, massmail, storm, flood, bomber, grabber, harvest, spambot, stealth, anonymous, dark, crack (recherchés comme sous-chaînes, sans distinction de casse).
4. Saut sans horodatage analysable (info) — le délai de cette portion ne peut pas être calculé ; affiché comme badge « délai inconnu ».
5. Temps qui remonte (avertissement) — un saut horodaté avant le saut précédent : décalage d’horloge ou en-tête Received forgé.
6. Aucun en-tête Authentication-Results (info) — le statut SPF/DKIM/DMARC ne peut pas du tout être vérifié depuis ce message.

Détails de l’analyseur à connaître :

• Privé : toute l’analyse est 100 % côté client — vos en-têtes ne quittent jamais le navigateur.
• Les en-têtes sont dépliés selon la RFC 5322 (les lignes de continuation commencent par un espace) ; l’analyse s’arrête à la première ligne vide (le séparateur de corps) ; les lignes parasites qui ne sont pas des en-têtes sont ignorées.
• Quand un message transporte plusieurs en-têtes Authentication-Results, le premier verdict pour chaque mécanisme gagne ; le reste est ignoré.
• Les horodatages des sauts sont lus après le dernier ; de chaque ligne Received (avec repli sur le premier jeton ressemblant à une date), et les commentaires de fuseau en fin de ligne comme (PDT) sont ignorés.
• Une pièce manquante est signalée, jamais devinée : délais inconnus, authentification invérifiable et trous de chaîne remontent tous comme des découvertes explicites plutôt que comme des blancs silencieux.
• Outils liés : PII Redactor, Defang / Refang,

  Base64Base64An encoding representing binary data as 64 safe ASCII characters, so it survives transport through text-only channels. It encodes — it does not encrypt.

  .