Lire les en-têtes d’e-mail pour détecter l’usurpation

Chaque e-mail transporte une piste d'audit complète dans ses en-têtes — les serveurs traversés, les résultats d'authentification et le véritable expéditeur d'enveloppe. Savoir les lire couramment est le moyen le plus rapide de confirmer ou d'écarter une usurpation suspectée, et c'est une compétence clé pour trier les phishings signalés.

Où trouver les en-têtes bruts

Le message affiché masque tout ce qui est utile. Récupérez la source brute :

Gmail — Afficher l'original.
Outlook — Fichier → Propriétés → En-têtes Internet (ou Afficher la source du message).
Apple Mail — Présentation → Message → Source brute.
Ligne de commande — inspectez directement le fichier .eml.

Les en-têtes de routage se lisent de bas en haut : le saut le plus ancien est en bas, le Received: du serveur destinataire est en haut.

Les identités qui comptent

Il existe deux « expéditeurs », et le phishing exploite l'écart entre eux :

Expéditeur d'enveloppe (Return-Path / MAIL FROM) — sert au routage et aux rejets ; vérifié par SPF.
From d'en-tête (From:) — ce que voit l'utilisateur dans son client.

Une usurpation affiche typiquement un From: de confiance tandis que le Return-Path pointe ailleurs, sans lien.

Return-Path: <bounce@hote-douteux.ru>
From: "Support IT" <support@votrebanque.example>

Le nom affiché (Support IT) est entièrement contrôlé par l'attaquant et ne prouve rien.

Lire Authentication-Results

L'en-tête le plus important est Authentication-Results, ajouté par votre serveur destinataire (ne faites confiance qu'à celui de votre propre domaine, en haut) :

Authentication-Results: mx.votresociete.example;
  spf=pass (sender IP is 198.51.100.10) smtp.mailfrom=bounce@hote-douteux.ru;
  dkim=fail header.d=votrebanque.example;
  dmarc=fail (p=reject) header.from=votrebanque.example

Interprétez-le avec soin :

Le spf=pass est ici un piège — il a réussi pour hote-douteux.ru, pas pour le votrebanque.example visible. SPF vérifie l'enveloppe, pas le From:.
dkim=fail — aucune signature valide alignée avec le domaine du From:.
dmarc=fail (p=reject) — c'est le verdict qui compte : l'authentification du domaine visible n'est pas alignée. Un message qui atteint la boîte malgré un dmarc=fail mérite examen.

Comparez toujours le domaine que chaque mécanisme a authentifié (smtp.mailfrom, header.d) au domaine du From:. Une authentification sans alignement ne signifie rien.

Retracer le chemin avec Received

Chaque saut préfixe une ligne Received:. Lisez de bas en haut :

Received: from mail.relais-malveillant.ru (mail.relais-malveillant.ru [203.0.113.7])
    by mx.votresociete.example ...; Tue, 08 Jul 2026 09:14:22 +0000
Received: from unknown (HELO localhost) (185.220.101.5)
    by mail.relais-malveillant.ru ...

Signaux d'alerte :

L'IP du saut d'origine se géolocalise loin de l'endroit revendiqué par l'expéditeur.
Un HELO falsifié (localhost, ou un nom d'hôte incohérent avec le reverse DNS).
Des écarts suspects ou des sauts de fuseau horaire dans les horodatages.
Le premier saut de confiance est votre propre MX — tout ce qui est en dessous est fourni par l'attaquant et falsifiable ; pondérez en conséquence.

Autres indices dans les en-têtes

Divergence Reply-To — le From: ressemble à un collègue, mais le Reply-To redirige les réponses vers une adresse externe. Classique dans la fraude au président (BEC).
Domaine du Message-ID qui ne correspond pas au domaine émetteur.
En-têtes X-Mailer / X-PHP-Script révélant un outil d'envoi en masse ou un script PHP sur un hôte compromis.
Unicode/punycode dans le domaine du From: (xn--), une attaque par homographe.

Une checklist de tri rapide

1. Domaine From: == domaine Return-Path ?             (différence = suspect)
2. Authentication-Results : dmarc=pass et aligné ?    (échec = suspect)
3. Quel domaine SPF/DKIM a-t-il réellement authentifié ? (doit = From:)
4. Le Reply-To diffère-t-il du From: ?                (oui = suspect)
5. D'où part le saut Received le plus bas ?           (géo inattendue = suspect)
6. Du punycode / homoglyphes dans le domaine From: ?  (oui = suspect)

Un seul en-tête prouve rarement une usurpation à lui seul. Le verdict vient de l'alignement : le domaine qui s'est authentifié correspond-il au domaine que l'humain voit ? DMARC existe précisément pour automatiser cette comparaison — mais sur le courrier entrant provenant d'autres domaines, il faut encore savoir la faire à la main.

Comment GottaPhish aide

Lire les en-têtes est une compétence réactive et réservée aux experts, et la plupart des utilisateurs ne les voient même jamais. GottaPhish et son équipe d'experts vous aident à combler cet écart : des phishings simulés réalistes — écarts d'alignement, permutations de Reply-To, domaines sosies — et des tableaux de bord indiquant précisément qui a signalé, cliqué ou soumis ses identifiants. Nos experts vous accompagnent dans la configuration, conçoivent des scénarios qui exploitent les astuces d'en-têtes réellement utilisées par les attaquants et vous aident à interpréter les résultats — affinant les playbooks de tri des équipes techniques tandis que la sensibilisation apprend à tous les autres les signaux visibles qui se cachent derrière ces en-têtes.