Repérer un e-mail de phishing en lisant ses en-têtes

Chaque e-mail porte, au-dessus du texte que vous lisez, un bloc d'en-têtes. Votre logiciel de messagerie le masque, mais il indique de quel serveur vient le message, quel domaine s'en est porté garant et où votre réponse partirait réellement. C'est généralement là que le phishing se trahit, même quand le message lui-même paraît parfait.

Nous exploitons un serveur de messagerie entrant : quand un message se comporte bizarrement, ce sont les en-têtes bruts que nous lisons. Ce guide parcourt un bloc d'en-têtes de phishing réaliste, une ligne à la fois, puis montre le cas plus difficile où toutes les vérifications réussissent. Vous pouvez coller les en-têtes de n'importe quel message dans notre analyseur d'en-têtes e-mail au fil de la lecture. Il fonctionne dans votre navigateur et les en-têtes ne sont jamais envoyés à nos serveurs.

Première étape : extraire les en-têtes de votre messagerie

Tous les logiciels de messagerie masquent les en-têtes par défaut. Dans Gmail, ouvrez le message, cliquez sur le menu à trois points à côté de « Répondre » et choisissez Afficher l'original. Dans Outlook sur le web, ouvrez le menu à trois points, puis Afficher et Afficher la source du message. Dans Apple Mail sur Mac, choisissez Présentation, Message, Tous les en-têtes. La page de l'analyseur d'en-têtes donne les chemins de menu pour Outlook pour Windows, Yahoo et d'autres.

Copiez tout ce qui se trouve au-dessus de la première ligne vide : c'est le bloc d'en-têtes. Le corps du message vient après et n'est pas nécessaire. Sur iPhone et iPad, l'app Mail intégrée n'affiche pas du tout les en-têtes : transférez le message vers un ordinateur ou consultez-le dans votre webmail.

Les en-têtes d'un e-mail de phishing, ligne par ligne

Voici le bloc d'en-têtes d'un phishing typique de type « alerte de compte », réduit aux lignes qui comptent. Les domaines et adresses sont des exemples fictifs, mais le schéma est celui que nous voyons sans cesse. Les en-têtes sont empilés du plus récent au plus ancien : le serveur qui vous a remis le message est donc près du haut, et son point de départ plus bas.

Return-Path: <[email protected]>
Authentication-Results: mx.example.com;
    spf=pass smtp.mailfrom=mail.example.net;
    dkim=none;
    dmarc=fail (p=none) header.from=examplebank.com
Received: from mail.example.net (unknown [203.0.113.45])
    by mx.example.com with ESMTPS; Thu, 29 Oct 2026 09:14:07 +0000
Received: from desktop-4kq2 (unknown [198.51.100.23])
    by mail.example.net with ESMTPA; Thu, 29 Oct 2026 09:14:05 +0000
From: "Example Bank Security" <[email protected]>
Reply-To: [email protected]
To: [email protected]
Subject: Unusual sign-in: confirm your account within 24 hours
Date: Thu, 29 Oct 2026 09:14:02 +0000
Message-ID: <20261029091402.4471@desktop-4kq2>

Ce que chaque ligne vous apprend

Return-Path

L'adresse où partent les rebonds, aussi appelée expéditeur d'enveloppe. Ici, elle est sur mail.example.net, pas sur le domaine de la banque. À elle seule, elle prouve peu de chose, car les newsletters envoyées via un prestataire d'envoi ont le même aspect. Gardez-la en tête pour les lignes suivantes.

Authentication-Results

Le verdict consigné par votre fournisseur à l'arrivée du message. SPF a réussi, mais pour mail.example.net, le serveur de l'attaquant. Il n'y a pas de signature DKIM. DMARC, la seule vérification qui regarde le domaine From que vous voyez réellement, a échoué pour examplebank.com. C'est la ligne la plus utile de tout le bloc.

Received (en haut)

Ajoutée par le serveur de votre propre fournisseur, mx.example.com, quand il a accepté le message venant de 203.0.113.45. Les lignes écrites par votre fournisseur sont fiables. Tout ce qui se trouve en dessous a été écrit par des machines dont vous ne savez rien.

Received (en bas)

L'étape la plus ancienne : lisez donc la chaîne de bas en haut. Le message est parti d'une machine qui se fait appeler desktop-4kq2 et a été remis à mail.example.net par une soumission authentifiée (ESMTPA). Le système d'alertes d'une banque ne tourne pas sur l'ordinateur de bureau de quelqu'un. Une boîte aux lettres volée ou louée, si.

From

Le nom affiché indique Example Bank Security et l'adresse prétend appartenir à examplebank.com. N'importe qui peut écrire n'importe quoi dans ce champ. L'échec DMARC ci-dessus prouve que cette ligne From est falsifiée.

Reply-To

Si vous cliquez sur « Répondre », votre réponse part vers example.org, un troisième domaine. Une banque qui veut que vous l'appeliez ou que vous vous connectiez n'a aucune raison de recueillir des réponses sur le domaine de quelqu'un d'autre. Le phishing qui vous demande de répondre avec vos informations renseigne presque toujours ce champ.

Subject et Date

L'urgence, plus une échéance. La Date n'est que ce qu'affirme la machine d'envoi, mais comparez-la aux horodatages Received : un écart de plusieurs heures ou jours entre la Date et la première étape peut signifier que le message a attendu dans une file de spam avant de vous parvenir.

Message-ID

Un identifiant unique inventé par le logiciel d'envoi. Les systèmes des grandes entreprises y apposent leur propre domaine. Celui-ci se termine par desktop-4kq2, la même machine domestique que dans la ligne Received du bas. Une discordance ici est un indice, pas une preuve, car beaucoup de logiciels légitimes utilisent des identifiants génériques.

Articles.spot-phishing-email-headers.sample.after

SPF, DKIM et DMARC expliqués simplement

Ces trois vérifications sont la partie des en-têtes qu'écrit un serveur de réception après avoir testé le message, et non du texte saisi par l'expéditeur. Chacune répond à une question différente.

SPF

Ce serveur a-t-il le droit d'envoyer du courrier pour le domaine de l'expéditeur d'enveloppe ? Le propriétaire du domaine publie dans le DNS une liste de serveurs autorisés, et le destinataire la compare à l'adresse IP qui se connecte. SPF vérifie le domaine du Return-Path, pas l'adresse From que vous voyez : c'est pourquoi un phishing peut réussir SPF pour son propre domaine. Voir SPF dans notre glossaire.

DKIM

Le message a-t-il été signé par un domaine, et a-t-il été modifié depuis ? Le serveur d'envoi ajoute une signature cryptographique, et le destinataire la vérifie avec une clé publique publiée dans le DNS du signataire. La valeur header.d= indique le domaine qui a signé. Une signature valide d'un domaine sans rapport ne dit rien de la marque affichée dans la ligne From.

DMARC

Le domaine de la ligne From correspond-il à un domaine qui a réussi SPF ou DKIM ? Cette étape d'alignement relie les vérifications au nom que vous lisez réellement. DMARC permet aussi au propriétaire du domaine de dire aux destinataires quoi faire des échecs : rien (p=none), mise en quarantaine ou rejet. C'est pourquoi un message falsifié peut quand même arriver dans votre boîte de réception lorsque la vraie entreprise n'a pas activé l'application de sa politique.

Ce que signifie chaque résultat

Le cas plus difficile : toutes les vérifications réussissent

Les attaquants soigneux ne falsifient pas du tout le domaine d'une banque. Ils en enregistrent un similaire, configurent correctement SPF, DKIM et DMARC et envoient depuis celui-ci. Les en-têtes paraissent alors irréprochables :

Authentication-Results: mx.example.com;
    spf=pass smtp.mailfrom=examplebank-secure.com;
    dkim=pass header.d=examplebank-secure.com;
    dmarc=pass header.from=examplebank-secure.com
From: "Example Bank" <[email protected]>

L'authentification prouve que examplebank-secure.com a envoyé cet e-mail. Elle ne peut pas vous dire si ce domaine appartient à votre banque. Ça, c'est votre travail, et il se résume à lire le domaine lui-même très lentement. Voici les astuces que nous voyons le plus souvent :

• Des mots en plus. Le vrai nom suivi de -secure, -login, -support ou -verify.
• Des caractères substitués. rn à la place de m, un zéro au lieu de la lettre o, une lettre doublée ou manquante.
• Une autre extension. Le bon nom sur .co, .net ou un nouveau domaine de premier niveau au lieu de celui qu'utilise l'entreprise.
• Le vrai nom en sous-domaine. Dans examplebank.com.account-check.net, le domaine est account-check.net. Lisez les domaines en partant de la droite.
• Des alphabets sosies. Un а cyrillique est identique à un a latin. Dans les en-têtes bruts, ces domaines apparaissent souvent avec le préfixe xn--, qui est la façon dont les noms de domaine non latins sont encodés.
• Un nom affiché qui fait tout le travail. « Example Bank » devant une adresse chez un webmail gratuit. Beaucoup de téléphones n'affichent que le nom : touchez-le pour voir l'adresse.

Si vous n'êtes pas sûr qu'un domaine appartienne à l'entreprise, n'utilisez rien de l'e-mail pour le vérifier. Tapez vous-même l'adresse de l'entreprise dans votre navigateur et comparez.

Les signaux d'alerte dans les en-têtes, par ordre d'importance

Certains signaux sont presque des preuves, d'autres ne comptent que lorsqu'ils s'additionnent. Voici à peu près comment nous les pondérons.

Une routine de cinq minutes pour tout e-mail suspect

1. 1

   Copiez les en-têtes complets

   Utilisez « Afficher l'original » ou « Afficher la source du message », comme décrit plus haut, et copiez le bloc entier, y compris toutes les lignes Received.

2. 2

   Collez-les dans un analyseur d'en-têtes

   Notre analyseur d'en-têtes e-mail place From, Reply-To et Return-Path côte à côte, affiche les résultats SPF, DKIM et DMARC et liste le parcours de distribution du plus ancien au plus récent. L'analyse se fait dans votre navigateur.

3. 3

   Comparez DMARC au domaine From

   Cherchez dmarc= et le domaine qui l'accompagne. Un échec pour une marque que vous connaissez suffit pour vous arrêter là et supprimer le message.

4. 4

   Lisez chaque domaine lentement, en partant de la droite

   From, Reply-To et le domaine qui a réussi DKIM doivent tous appartenir à l'entreprise. Méfiez-vous des astuces de domaines sosies décrites plus haut.

5. 5

   Lisez la chaîne Received en partant du bas

   La ligne la plus basse indique où le message a commencé. Ne faites confiance qu'aux lignes ajoutées par votre propre fournisseur, en haut. Un expéditeur peut insérer en dessous de fausses lignes Received, et même une fausse ligne Authentication-Results.

6. 6

   Vérifiez les liens sans cliquer

   Les en-têtes ne montrent pas les liens du corps du message. Sur ordinateur, survolez chaque bouton et lisez l'adresse affichée dans le coin de la fenêtre. Tout ce qui ne mène pas au vrai domaine de l'entreprise est une raison de partir.

Si vous pensez qu'il s'agit de phishing

• Ne cliquez pas, ne répondez pas, n'ouvrez pas les pièces jointes. Répondre confirme que votre adresse est lue, et les pièces jointes sont le moyen habituel par lequel arrivent les logiciels malveillants.
• Contactez l'entreprise par un autre moyen. Tapez son adresse dans votre navigateur ou utilisez le numéro figurant sur votre carte ou votre contrat, jamais celui de l'e-mail.
• Signalez-le dans votre messagerie. Dans Gmail, utilisez le menu à trois points et Signaler comme hameçonnage. Dans Outlook, utilisez Signaler puis Signaler l'hameçonnage. Cela entraîne le filtre pour tous les utilisateurs de ce service.
• Transférez-le à l'Anti-Phishing Working Group à [email protected], qui partage les signalements avec les éditeurs de sécurité et les navigateurs.
• Aux États-Unis, signalez-le à la FTC sur ReportFraud.ftc.gov, surtout si de l'argent ou des données personnelles sont en jeu.
• Si vous avez déjà saisi un mot de passe, changez-le immédiatement sur le vrai site, activez la connexion en deux étapes et changez-le partout où vous l'avez réutilisé. Notre guide pour vérifier si votre adresse e-mail a fuité couvre la première heure après une exposition.

Sources

• IETF, RFC 7208: Sender Policy Framework (SPF), y compris la signification de pass, fail, softfail et neutral.
• IETF, RFC 6376: DomainKeys Identified Mail (DKIM) Signatures.
• IETF, RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC), publiée en 2026 en remplacement de la RFC 7489.
• IETF, RFC 8601: Message Header Field for Indicating Message Authentication Status, qui définit l'en-tête Authentication-Results.
• Federal Trade Commission des États-Unis, How to Recognize and Avoid Phishing Scams, pour les adresses de signalement de la FTC et de l'APWG.
• Anti-Phishing Working Group, Report Phishing.