Comment tracer l'origine d'un email suspect grâce aux en-têtes

Un employé vous transfère un email suspect. L'objet mentionne une facture impayée de 12 400 €. L'expéditeur affiche le nom d'un fournisseur avec lequel vous travaillez depuis trois ans. Le lien pointe vers un site qui ressemble à une page de connexion Microsoft 365.

Votre question : est-ce que cet email vient vraiment de ce fournisseur, ou est-ce du phishing ?

La réponse se trouve dans les en-têtes de l'email.

Les en-têtes sont des métadonnées ajoutées par chaque serveur qui traite l'email. Ils forment une trace du parcours complet de l'email, de l'expéditeur réel jusqu'à votre boîte de réception. Savoir les lire, c'est savoir distinguer un email légitime d'une tentative de phishing en quelques minutes.

Ce guide vous montre comment accéder aux en-têtes, les lire, et identifier les signaux d'alerte.

Outil gratuit. Collez vos en-têtes dans notre analyseur d'en-têtes email pour obtenir une vue structurée avec les résultats d'authentification et le chemin réseau. 100 % côté client, rien n'est envoyé à nos serveurs.

Comment accéder aux en-têtes

Chaque client de messagerie propose un moyen d'afficher les en-têtes complets. Voici les plus courants.

Gmail

1. Ouvrez l'email
2. Cliquez sur les trois points verticaux (⋮) en haut à droite
3. Sélectionnez Afficher l'original
4. Gmail affiche les en-têtes bruts avec un résumé des résultats SPF, DKIM et DMARC en haut

Gmail propose aussi un résumé dans le panneau « Afficher l'original » : trois lignes SPF, DKIM, DMARC avec leur résultat (pass/fail). C'est un bon point de départ avant de plonger dans les en-têtes bruts.

Outlook Desktop

1. Ouvrez l'email dans une fenêtre séparée (double-clic)
2. Fichier → Propriétés
3. Les en-têtes apparaissent dans le champ En-têtes Internet

Le champ est petit par défaut. Sélectionnez tout (Ctrl+A), copiez (Ctrl+C) et collez dans un éditeur de texte pour une lecture plus confortable.

Outlook Web (OWA)

1. Ouvrez l'email
2. Cliquez sur les trois points (…) → Afficher → Afficher la source du message

Apple Mail

1. Ouvrez l'email
2. Menu Présentation → Message → Tous les en-têtes (ou Cmd + Shift + H)

Thunderbird

1. Ouvrez l'email
2. Menu Affichage → Code source du message (ou Ctrl + U)

Yahoo Mail

1. Ouvrez l'email
2. Cliquez sur les trois points (…) → Afficher le message brut

Une fois les en-têtes récupérés, vous pouvez les analyser manuellement avec ce guide, ou les coller directement dans notre analyseur d'en-têtes email gratuit qui identifie automatiquement chaque serveur traversé et les résultats d'authentification.

Anatomie d'un en-tête email

Un email contient des dizaines d'en-têtes. Voici ceux qui comptent pour l'analyse de sécurité, dans l'ordre de priorité.

From (l'expéditeur affiché)

From: "Service Facturation" <facturation@fournisseur.fr>

C'est l'adresse que le destinataire voit dans son client de messagerie. Elle peut être falsifiée. N'importe qui peut écrire n'importe quelle adresse dans le champ From. C'est exactement comme écrire une fausse adresse d'expéditeur sur une enveloppe papier.

Ne vous fiez jamais au From seul pour juger de la légitimité d'un email.

Return-Path (l'envelope From)

Return-Path: <bounce-123@serveur-envoi.com>

C'est l'adresse réelle utilisée pour la livraison SMTP (envelope From). C'est cette adresse que SPF vérifie. Si le Return-Path est différent du From, c'est un premier signal d'alerte.

Attention : certains services légitimes (newsletter, transactionnel) utilisent un Return-Path différent pour gérer les bounces. Par exemple, Brevo utilise des adresses de type bounce@abcd.brevo.com pour ses clients. Ce n'est pas forcément suspect, mais ça mérite vérification.

Received (le chemin réseau)

Les en-têtes Received sont les plus informatifs pour tracer le chemin emprunté par un email. Chaque serveur qui traite l'email ajoute un en-tête Received. Ils sont empilés du bas vers le haut : le dernier en-tête Received (en bas du bloc) est le premier serveur, le premier (en haut) est le dernier.

Received: from mail-out.fournisseur.fr (mail-out.fournisseur.fr [203.0.113.42])
        by mx.google.com with ESMTPS id abc123
        Thu, 26 Mar 2026 10:15:23 +0100 (CET)

Cet en-tête dit : le serveur mx.google.com a reçu l'email de mail-out.fournisseur.fr (IP 203.0.113.42) le 26 mars à 10h15.

Ce qu'il faut vérifier :

• L'IP d'origine (premier serveur dans la chaîne) correspond-elle à un serveur connu de l'expéditeur annoncé ? Utilisez un service de recherche IP (ipinfo.io, whois) pour identifier le propriétaire.
• Les noms de serveurs sont-ils cohérents avec le domaine de l'expéditeur ? Un email prétendant venir de fournisseur.fr mais envoyé depuis srv47.hostingprovider.net est suspect.
• Les délais entre serveurs sont-ils raisonnables ? Un email normal traverse les serveurs en quelques secondes. Un délai de plusieurs heures entre deux hops peut indiquer un passage par un serveur intermédiaire (serveur compromis, relais ouvert, mise en file d'attente suspecte).

Authentication-Results

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of facturation@fournisseur.fr
         designates 203.0.113.42 as permitted sender)
       smtp.mailfrom=facturation@fournisseur.fr;
       dkim=pass header.d=fournisseur.fr header.s=selector1;
       dmarc=pass (p=REJECT sp=REJECT) header.from=fournisseur.fr

C'est le verdict du serveur destinataire. Trois résultats à vérifier :

Protocole	Résultat	Signification
SPF	pass	Le serveur expéditeur est autorisé par le domaine
SPF	fail	Le serveur expéditeur n'est pas autorisé - signal d'alerte
SPF	softfail	Le serveur n'est pas autorisé, mais la politique est souple
DKIM	pass	La signature cryptographique est valide, le contenu est intact
DKIM	fail	La signature est invalide ou absente
DKIM	none	Aucune signature DKIM n'a été trouvée
DMARC	pass	SPF ou DKIM passe avec alignement du domaine
DMARC	fail	Ni SPF ni DKIM ne passe avec alignement - signal fort

Un email de phishing classique affichera spf=fail ou dmarc=fail. Mais attention : un spf=pass ne garantit pas que l'email est légitime (l'attaquant peut avoir configuré SPF sur son propre domaine tout en affichant une autre adresse dans le From).

C'est pourquoi DMARC est le résultat le plus fiable : il vérifie l'alignement entre le domaine affiché (From) et les domaines authentifiés par SPF/DKIM.

Reply-To

Reply-To: reponse@domaine-different.com

Si le Reply-To est différent du From, c'est un signal d'alerte. L'attaquant veut que vous répondiez à une adresse qu'il contrôle, pas à l'adresse affichée.

Les emails légitimes de support ou de newsletter utilisent parfois un Reply-To différent (par exemple support@ au lieu de noreply@). Mais un Reply-To pointant vers un domaine complètement différent du From est suspect.

X-Mailer / User-Agent

X-Mailer: PHPMailer 6.0.0

Identifie le logiciel utilisé pour envoyer l'email. Un email de votre fournisseur habituel envoyé depuis PHPMailer ou un script Python au lieu de son serveur de messagerie habituel (Gmail, Exchange, etc.) est suspect. Les attaquants utilisent souvent des bibliothèques d'envoi scriptées.

Message-ID

Message-ID: <abc123@mail-out.fournisseur.fr>

Le Message-ID est un identifiant unique attribué par le serveur d'envoi. Le domaine après le @ devrait correspondre au domaine de l'expéditeur ou à son fournisseur de messagerie. Un Message-ID avec un domaine sans rapport (par exemple @localhost ou @vps-random-42.com) est un signal supplémentaire.

Les 6 signaux d'alerte dans les en-têtes

1. Le Return-Path ne correspond pas au From

From: facturation@fournisseur.fr
Return-Path: <user@serveur-inconnu.ru>

Le From affiche un fournisseur connu. Le Return-Path révèle un serveur russe sans rapport. C'est le signe d'un email usurpé envoyé depuis un serveur tiers.

2. Les résultats d'authentification échouent

spf=fail
dkim=fail
dmarc=fail

Si les trois échouent, l'email n'a passé aucune vérification. C'est un signal fort d'usurpation. Certains emails légitimes peuvent échouer SPF ou DKIM individuellement (transferts, listes de diffusion), mais l'échec simultané des trois est presque toujours suspect.

3. L'IP d'origine est incohérente

L'email prétend venir de la BNP Paribas. L'IP d'origine pointe vers un VPS chez un hébergeur en Europe de l'Est. Les grandes organisations utilisent des ranges IP identifiables et des serveurs de messagerie dédiés.

Pour vérifier une IP : utilisez un service de géolocalisation IP (ipinfo.io, whois) et comparez avec l'infrastructure connue de l'expéditeur.

4. Des délais anormaux entre serveurs

Received: from mx1.intermediaire.com ... Thu, 26 Mar 2026 10:15:23
Received: from serveur-source.net ... Thu, 26 Mar 2026 06:02:41

Plus de 4 heures entre deux hops. Un email légitime traverse les serveurs en quelques secondes, parfois quelques minutes. Un délai de plusieurs heures peut indiquer que l'email a été mis en file d'attente sur un serveur intermédiaire (serveur compromis, relais ouvert, ou tentative de contourner des filtres temporels).

5. Des en-têtes manquants ou incohérents

Un email légitime envoyé depuis un serveur de messagerie professionnel (Google Workspace, Microsoft 365, Exchange) contient des en-têtes cohérents et complets : Message-ID, MIME-Version, Content-Type, Date. Un email forgé à la main ou envoyé depuis un script peut manquer de ces en-têtes standards, ou les contenir avec des valeurs incohérentes.

6. Un Reply-To vers un domaine externe

From: direction@votreentreprise.fr
Reply-To: urgent-reponse@protonmail.com

L'email prétend venir de la direction de votre entreprise, mais demande que les réponses aillent vers une adresse Protonmail externe. C'est un schéma classique de fraude au président (BEC). Le dirigeant réel n'utiliserait pas une adresse externe pour recevoir les réponses.

Cas pratique : analyser un email suspect étape par étape

Prenons un email de phishing réaliste. L'email prétend venir de « Microsoft 365 » et demande de « vérifier votre compte suite à une activité inhabituelle ».

En-têtes extraits :

From: "Microsoft 365 Security" <security@microsoft.com>
Return-Path: <noreply@srv-mail-47.hostingprovider.net>
Received: from srv-mail-47.hostingprovider.net
  (srv-mail-47.hostingprovider.net [185.234.x.x])
  by mx.google.com with ESMTP id abc456
  Thu, 26 Mar 2026 03:42:18 -0700 (PDT)
Authentication-Results: mx.google.com;
       spf=fail (google.com: domain of security@microsoft.com
         does not designate 185.234.x.x as permitted sender);
       dkim=none;
       dmarc=fail (p=REJECT) header.from=microsoft.com
Reply-To: support-verification@outlook-secure.net
X-Mailer: PHPMailer 6.5.0
Message-ID: <random123@srv-mail-47.hostingprovider.net>

Analyse signal par signal :

1. Return-Path : noreply@srv-mail-47.hostingprovider.net - aucun rapport avec microsoft.com. Microsoft utilise ses propres serveurs de messagerie (protection.outlook.com, mail.protection.outlook.com).

2. IP d'origine : 185.234.x.x - un hébergeur tiers, pas un serveur Microsoft. Une vérification whois confirme qu'il s'agit d'un fournisseur VPS sans lien avec Microsoft.

3. SPF : fail - le serveur 185.234.x.x n'est pas autorisé par microsoft.com. L'enregistrement SPF de Microsoft ne liste que ses propres serveurs.

4. DKIM : none - aucune signature DKIM n'a été trouvée. Microsoft signe tous ses emails sortants avec DKIM.

5. DMARC : fail avec p=REJECT - Microsoft a une politique DMARC stricte. Cet email aurait dû être rejeté par le serveur destinataire (il l'a été par Gmail, qui affiche quand même le message avec un avertissement).

6. Reply-To : outlook-secure.net - un domaine qui n'est pas microsoft.com et qui n'appartient pas à Microsoft. L'attaquant veut récupérer les réponses.

7. X-Mailer : PHPMailer - Microsoft n'utilise pas PHPMailer pour envoyer ses notifications.

8. Message-ID : domaine srv-mail-47.hostingprovider.net - confirme que l'email n'a pas été envoyé depuis l'infrastructure Microsoft.

Verdict : phishing certain. Huit signaux d'alerte convergents.

Automatisez cette analyse. Collez les en-têtes dans notre analyseur d'en-têtes email gratuit pour obtenir cette analyse en un clic : IP d'origine, résultats d'authentification, chemin réseau, délais entre serveurs.

ARC : le protocole qui gère les transferts

Un problème fréquent : un email légitime est transféré (forward) par un serveur intermédiaire. Le transfert modifie l'envelope (Return-Path), ce qui casse SPF. Si le serveur intermédiaire modifie aussi le corps du message (ajout de footer, réécriture d'URL), DKIM échoue aussi. Résultat : un email légitime échoue DMARC après transfert.

ARC (Authenticated Received Chain) résout ce problème. Chaque serveur intermédiaire qui modifie l'email ajoute ses propres signatures ARC. Le serveur destinataire peut vérifier la chaîne ARC pour confirmer que l'email était légitime avant le transfert.

ARC est supporté par Gmail, Microsoft 365, Yahoo et la plupart des grands fournisseurs de messagerie. Si vous voyez des en-têtes ARC-Authentication-Results, ARC-Message-Signature et ARC-Seal, c'est le signe d'un email qui a été transféré par un serveur compatible ARC.

ARC-Authentication-Results: i=1; mx.google.com;
       spf=pass (google.com: domain of user@original-sender.com)
       dkim=pass header.d=original-sender.com;
       dmarc=pass header.from=original-sender.com

Le i=1 indique que c'est la première vérification ARC dans la chaîne. Si l'email a traversé plusieurs serveurs, vous verrez i=2, i=3, etc.

Limites de l'analyse d'en-têtes

L'analyse d'en-têtes est utile, mais elle a ses limites.

Les en-têtes Received côté expéditeur peuvent être forgés. Les en-têtes ajoutés par le serveur expéditeur (avant que l'email quitte son réseau) peuvent être inventés. Seuls les en-têtes ajoutés par les serveurs intermédiaires de confiance et le serveur destinataire sont fiables. Commencez toujours votre analyse par le haut (serveur destinataire) et descendez vers le bas avec prudence.

Un email peut être légitime et échouer les vérifications. Mauvaise configuration chez l'expéditeur, enregistrement DNS expiré, transfert intermédiaire. Un échec SPF ou DKIM isolé n'est pas une preuve de phishing. C'est un signal à mettre en contexte avec les autres indicateurs. C'est la convergence des signaux qui compte.

L'analyse d'en-têtes est réactive. Vous analysez un email après l'avoir reçu. La vraie protection consiste à former vos équipes à reconnaître les signaux de phishing avant de cliquer.

Le phishing depuis des domaines tiers. Si un attaquant envoie un email depuis son propre domaine (pas le vôtre), avec son propre SPF et DKIM valides, les vérifications d'authentification passeront. L'analyse d'en-têtes montrera que l'email vient d'un domaine inconnu, mais pas qu'il est malveillant. La vigilance humaine reste nécessaire.

Que faire quand vous identifiez un email frauduleux

En interne

1. Ne cliquez sur aucun lien et n'ouvrez aucune pièce jointe. Si un employé a déjà cliqué, changez immédiatement les mots de passe concernés et vérifiez les connexions récentes au compte.
2. Signalez l'email à votre responsable sécurité ou à votre prestataire informatique. Transférez l'email en tant que pièce jointe (.eml) pour conserver les en-têtes.
3. Bloquez l'expéditeur au niveau de votre serveur de messagerie (pas seulement dans le client de l'utilisateur).
4. Prévenez les collègues qui pourraient recevoir le même email.

Signalement externe

• Cybermalveillance.gouv.fr : plateforme nationale d'assistance et de signalement. En 2024, le site a traité plus de 280 000 demandes d'assistance.
• Signal Spam (signal-spam.fr) : signalez les emails frauduleux pour alimenter les bases de filtrage.
• PHAROS (internet-signalement.gouv.fr) : signalement au ministère de l'Intérieur, notamment pour les tentatives d'escroquerie.
• Dépôt de plainte : si vous avez subi un préjudice financier, déposez plainte auprès de la police ou de la gendarmerie. La plateforme THESEE permet un pré-dépôt de plainte en ligne pour les escroqueries sur internet.

De l'analyse à la prévention

Savoir analyser les en-têtes d'un email est une compétence utile pour votre équipe technique et votre responsable sécurité. Mais vos 50, 100 ou 500 employés ne vont pas ouvrir les en-têtes de chaque email qu'ils reçoivent. Ils ont besoin de réflexes plus simples :

• Vérifier l'adresse de l'expéditeur (pas seulement le nom affiché)
• Survoler les liens avant de cliquer (l'URL de destination apparaît en bas du navigateur ou du client mail)
• Se méfier de l'urgence (« Votre compte sera suspendu dans 24h »)
• Signaler les emails suspects au lieu de les analyser seuls

Ces réflexes se construisent par la pratique, pas par des présentations PowerPoint annuelles. Les simulations de phishing régulières, suivies de micro-formations ciblées, sont le moyen le plus efficace de réduire le taux de clic. D'après le rapport Proofpoint State of the Phish 2025, les entreprises qui simulent mensuellement réduisent leur taux de clic de 75 % en 12 mois.

nophi.sh envoie des simulations de phishing réalistes à vos équipes et forme automatiquement les employés qui cliquent. Votre équipe de sécurité reçoit les signalements et les analyse. Démarrer gratuitement.

Pour aller plus loin

• Analyseur d'en-têtes email gratuit - collez vos en-têtes et obtenez une analyse structurée
• Test de sécurité email - vérifiez la configuration SPF, DKIM, DMARC de votre domaine
• Guide : configurer SPF, DKIM et DMARC pour votre PME
• Sécurité email des PME françaises : pourquoi tester SPF, DKIM et DMARC
• Signaler un email frauduleux sur Cybermalveillance.gouv.fr
• Signal Spam - plateforme de signalement