Guides · E-mail et domaines

Comment lire les en-têtes d'un e-mail et repérer le phishing

Écrit par Aldo · threat hunter en blue team
Dernière mise à jour le 9 novembre 2026 · 6 min de lecture

Un e-mail dit venir de votre banque, de votre responsable ou d'un fournisseur. La ligne From visible n'est que du texte écrit par l'expéditeur. Les en-têtes en dessous enregistrent ce que les serveurs de messagerie ont réellement vu, et ils sont bien plus difficiles à falsifier.

Ouvrir les en-têtes complets

Toutes les messageries les cachent par défaut. Les voici (les noms des menus changent d'une version à l'autre, mais ceux-ci sont stables depuis un moment) :

• Gmail (web) : ouvrez l'e-mail, cliquez sur les trois points à côté de Répondre, puis sur Afficher l'original.
• Outlook sur le web et le nouvel Outlook : ouvrez l'e-mail, sélectionnez les trois points, puis Afficher → Afficher les détails du message.
• Outlook classique pour Windows : ouvrez l'e-mail dans sa propre fenêtre, puis Fichier → Propriétés ; les en-têtes se trouvent dans En-têtes Internet.
• Apple Mail sur Mac : Présentation → Message → Tous les en-têtes.
• Thunderbird : Affichage → Source du message (Ctrl+U).
• Les applications de messagerie sur iPhone et Android ne peuvent généralement pas afficher les en-têtes complets. Ouvrez la même boîte aux lettres sur un ordinateur.

Copiez tout, du haut jusqu'à la première ligne vide. Ce bloc, c'est l'en-tête.

Un exemple concret : la facture en retard

Voici l'exemple de l'analyse des en-têtes d'iplover. Les domaines sont des domaines de documentation (example.com, .org, .net) et l'adresse d'envoi est un nœud de sortie Tor public : aucune entreprise ni personne réelle n'est en cause, mais chaque ligne est du genre de celles que vous trouverez dans un vrai phishing :

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.org header.s=s1 header.b=Xy12;
       spf=pass (google.com: domain of bounce@mailer.example.org designates 198.51.100.25 as permitted sender) smtp.mailfrom=bounce@mailer.example.org;
       dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE) header.from=example.com
Return-Path: <bounce@mailer.example.org>
Received: from relay.mailer.example.org (relay.mailer.example.org. [198.51.100.25])
        by mx.google.com with ESMTPS id 5a1b2c3d4e
        for <you@example.net>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 03 Nov 2026 10:14:04 -0800 (PST)
Received: from webmail.example.org (unknown [185.220.101.7])
        by relay.mailer.example.org (Postfix) with ESMTPSA id 7C1A2B3;
        Tue,  3 Nov 2026 16:11:58 +0000 (UTC)
Received: from [10.0.0.12] (localhost [127.0.0.1])
        by webmail.example.org with ESMTP;
        Tue,  3 Nov 2026 16:11:55 +0000 (UTC)
From: "Example Billing" <billing@example.com>
Reply-To: payments-desk@example.net
Subject: Invoice 4471 is overdue
Message-ID: <20261103161152.4471@mailer.example.org>
X-Originating-IP: [185.220.101.7]

(Raccourci ; l'exemple complet contient aussi des en-têtes ARC, qui consignent les contrôles faits par les serveurs en chemin.) Le verdict de l'analyse :

Comment le lire, ligne par ligne

1. Authentication-Results : le verdict du serveur destinataire

Le serveur qui a reçu le message (ici celui de Google) l'a contrôlé et a noté les résultats. Lisez la ligne Authentication-Results la plus haute : c'est celle qu'a ajoutée votre propre fournisseur de messagerie. Toute ligne plus bas a pu être écrite par n'importe qui, y compris l'expéditeur.

L'astuce de cet exemple, c'est que SPF et DKIM ont réussi tous les deux, mais pas pour le bon domaine. SPF a réussi pour mailer.example.org et DKIM pour example.org, alors que l'adresse From indique example.com. DMARC est le contrôle qui rattache le résultat au domaine du From, et il a échoué. Le propriétaire d'example.com avait même publié une politique demandant de refuser ces e-mails. Ce schéma, tout réussi sauf DMARC, est le visage typique du courrier falsifié.

2. From, Reply-To et Return-Path : qui prétend écrire, et où vont les réponses

La ligne From affiche « Example Billing » chez example.com. Reply-To, en revanche, envoie votre réponse vers example.net. Les services clients et les listes de diffusion le font légitimement, mais sur une facture inattendue, cela signifie : celui qui l'a écrite veut votre réponse à un endroit que la vraie entreprise ne contrôle pas. Return-Path est l'adresse où partent les rejets ; y trouver le domaine d'un service d'envoi est normal.

3. Received : le parcours de remise, lu de bas en haut

Chaque serveur qui traite un message ajoute une ligne Received tout en haut : la plus ancienne est donc en bas. Lisez vers le haut : un appareil d'un réseau privé (10.0.0.12) a transmis le courrier au webmail, qui l'a reçu de 185.220.101.7, un nœud de sortie Tor, avant de le passer au relais puis à Google. Cette première adresse publique est ce qui s'approche le plus de l'expéditeur, et ici elle est anonyme à dessein. X-Originating-IP, ajouté par certains webmails, dit la même chose.

Les horaires en disent aussi un peu : deux heures entre le relais et Google. Les retards ont des causes innocentes, mais ils méritent qu'on les remarque.

Si vous voyez ceci, faites cela

Ce que les en-têtes ne peuvent pas vous dire

Les en-têtes prouvent d'où vient un message, pas ce qu'il veut. Un message envoyé depuis un vrai compte piraté passe tous les contrôles. Un domaine imitateur passe DMARC pour lui-même. Et les en-têtes ne disent rien du lien ou de la pièce jointe, là où se trouve généralement le danger. Ce sont donc un indice parmi d'autres : une demande inattendue d'argent, de mots de passe ou de décisions rapides mérite la méfiance, quoi que disent les en-têtes.

L'analyse d'iplover lit les résultats notés par votre fournisseur ; elle ne revérifie pas les signatures DKIM et ne télécharge pas les enregistrements SPF de chaque étape. Elle le précise au bas de chaque rapport, et c'est bon à garder en tête avec n'importe quel outil.