Skip to content
Retour aux guides
Guide

Analyser les en-têtes d'un email : guide pratique pour les équipes de sécurité

Guide complet pour lire et interpréter les en-têtes email. Identifiez l'expéditeur réel, vérifiez l'authentification SPF/DKIM/DMARC et détectez les anomalies dans le chemin réseau.

Thomas Ferreira10 min de lecture

Votre équipe de sécurité reçoit un signalement : un employé a reçu un email suspect. Avant de classer l'incident, vous devez déterminer si l'email est une tentative de phishing ou un email légitime mal identifié. La réponse est dans les en-têtes.

Ce guide est une référence pratique pour les équipes de sécurité. Il couvre la lecture des en-têtes email, l'interprétation des résultats d'authentification et l'identification des anomalies. Chaque section inclut des exemples réels et les commandes pour vérifier les informations extraites.

Outil complémentaire. Notre analyseur d'en-têtes email gratuit parse automatiquement les en-têtes et affiche une vue structurée. 100 % côté client, aucune donnée n'est envoyée à nos serveurs.

Structure d'un email

Un email se compose de deux parties : l'enveloppe SMTP (utilisée pour la livraison) et le message (en-têtes + corps). L'analogie avec le courrier papier est utile :

  • Enveloppe SMTP : l'adresse écrite sur l'enveloppe physique (MAIL FROM et RCPT TO). C'est ce que le facteur lit. Le destinataire ne la voit pas.
  • Header From : l'adresse écrite en haut de la lettre, à l'intérieur de l'enveloppe. C'est ce que le destinataire lit. Elle peut être différente de l'adresse sur l'enveloppe.

Cette séparation est au cœur de l'usurpation email. Un attaquant écrit votre adresse sur la lettre (header From) tout en utilisant sa propre adresse sur l'enveloppe (envelope From / Return-Path). Sans DMARC, le serveur destinataire ne compare pas les deux.

Partie 1 : les en-têtes essentiels

From et Return-Path

From: "Direction Financière" <daf@entreprise.fr>
Return-Path: <bounce-5847@mail-marketing.net>

Première vérification : comparez les deux domaines. Ici, le From est entreprise.fr mais le Return-Path est mail-marketing.net. Plusieurs explications possibles :

  • Légitime : l'entreprise utilise un service tiers (Brevo, Mailchimp) pour envoyer cet email. Le Return-Path est celui du service.
  • Suspect : l'email prétend venir de la direction financière mais est envoyé depuis un serveur tiers sans rapport.

Pour trancher : vérifiez si mail-marketing.net est un service connu, et si l'entreprise l'utilise.

Received (la chaîne de transmission)

Les en-têtes Received sont empilés par chaque serveur. Pour lire chronologiquement, partez du bas :

Received: from mail-out.marketing.net (mail-out.marketing.net [198.51.100.23])
        by mx1.entreprise.fr with ESMTPS id xyz789
        for <employe@entreprise.fr>;
        Wed, 26 Mar 2026 14:30:12 +0100 (CET)

Received: from internal-queue.marketing.net (internal-queue.marketing.net [10.0.1.42])
        by mail-out.marketing.net with SMTP id abc456;
        Wed, 26 Mar 2026 14:30:10 +0100 (CET)

Lecture chronologique (du bas vers le haut) :

  1. Le serveur interne internal-queue.marketing.net (IP privée 10.0.1.42) a remis l'email à mail-out.marketing.net à 14:30:10
  2. Le serveur mail-out.marketing.net (IP 198.51.100.23) a remis l'email à mx1.entreprise.fr à 14:30:12
  3. Délai : 2 secondes. Normal.

Signaux d'alerte dans les Received :

SignalExplication
IP d'origine dans un pays inattenduUn email d'une entreprise française envoyé depuis un VPS en Asie du Sud-Est
Délai de plusieurs heures entre deux hopsL'email a stagné sur un serveur intermédiaire (relais compromis, file d'attente suspecte)
Nom de serveur incohérent avec le domainemail.fournisseur.fr résolu vers vps-cheap-hosting.net
Absence de chiffrementwith SMTP au lieu de with ESMTPS (pas de TLS)

Authentication-Results

Cet en-tête est ajouté par votre serveur de réception. Il résume les vérifications effectuées :

Authentication-Results: mx1.entreprise.fr;
       spf=pass (sender IP is 198.51.100.23) smtp.mailfrom=marketing.net;
       dkim=pass (2048-bit key) header.d=marketing.net header.s=s1;
       dmarc=pass (p=REJECT) header.from=marketing.net

Grille de lecture :

RésultatInterprétation
spf=passLe serveur expéditeur est autorisé par le domaine du Return-Path
spf=failLe serveur n'est pas autorisé. Possible usurpation ou mauvaise config
spf=softfailLe serveur n'est pas explicitement autorisé, mais la politique est souple (~all)
spf=neutralLe domaine ne fait aucune déclaration sur ce serveur (?all)
dkim=passLa signature cryptographique est valide. Le message n'a pas été modifié
dkim=failLa signature est invalide. Le message a été modifié ou la clé ne correspond pas
dmarc=passSPF ou DKIM passe avec alignement du domaine (le domaine vérifié correspond au header From)
dmarc=failNi SPF ni DKIM ne passe avec alignement. L'email ne devrait pas être traité comme venant de ce domaine

Le détail qui compte : l'alignement. DMARC ne vérifie pas juste si SPF ou DKIM passent. Il vérifie que le domaine vérifié par SPF ou DKIM correspond au domaine dans le header From. C'est l'alignement. Sans alignement, un spf=pass sur un autre domaine ne protège pas contre l'usurpation du From.

Partie 2 : en-têtes secondaires utiles

Reply-To

Reply-To: support@domaine-piege.com

Si le Reply-To est différent du From, l'attaquant veut capter vos réponses sur une adresse qu'il contrôle. C'est un signal d'alerte classique.

Message-ID

Message-ID: <abc123@mail.entreprise.fr>

Le domaine dans le Message-ID devrait correspondre au serveur d'envoi. Un Message-ID avec un domaine incohérent (ou un format inhabituel) peut indiquer un email forgé.

X-Mailer / User-Agent

X-Mailer: Microsoft Outlook 16.0

Identifie le logiciel client. Un email prétendument envoyé depuis Outlook mais avec X-Mailer: PHPMailer est suspect.

X-Originating-IP

X-Originating-IP: [203.0.113.42]

Certains serveurs de messagerie ajoutent l'IP du poste client qui a composé l'email (pas le serveur de messagerie, mais le PC de l'expéditeur). C'est une information précieuse pour la géolocalisation.

ARC (Authenticated Received Chain)

ARC est un protocole relativement récent qui préserve les résultats d'authentification à travers les transferts et les listes de diffusion. Si vous voyez des en-têtes ARC-Authentication-Results, ils contiennent les résultats d'authentification du serveur intermédiaire avant le transfert.

Partie 3 : commandes de vérification

Vérifier une IP

whois 198.51.100.23

Identifie le propriétaire du bloc IP (AS, organisation, pays). Comparez avec l'expéditeur annoncé.

nslookup 198.51.100.23
# ou
dig -x 198.51.100.23

Reverse DNS : l'IP résout-elle vers un nom de serveur cohérent avec l'expéditeur ?

Vérifier un enregistrement SPF

dig TXT entreprise.fr | grep spf

Comparez la liste des serveurs autorisés dans le SPF avec l'IP d'origine de l'email.

Vérifier un enregistrement DKIM

dig TXT selector1._domainkey.entreprise.fr

Remplacez selector1 par le sélecteur indiqué dans le header.s= de l'en-tête Authentication-Results.

Vérifier un enregistrement DMARC

dig TXT _dmarc.entreprise.fr

Vérifiez la politique (p=none, p=quarantine ou p=reject) et l'adresse de rapport (rua=).

Partie 4 : procédure d'analyse type

Quand un employé signale un email suspect, suivez cette procédure :

1. Récupérer les en-têtes complets. Demandez à l'employé d'utiliser « Afficher l'original » (Gmail) ou « Afficher la source » et de copier l'intégralité.

2. Identifier l'expéditeur réel. Comparez le From, le Return-Path et l'IP d'origine. Cherchez des incohérences.

3. Vérifier l'authentification. Lisez les résultats SPF, DKIM et DMARC. Un triple échec est un signal fort. Un triple pass ne garantit pas la légitimité (l'attaquant peut utiliser son propre domaine bien configuré).

4. Analyser le chemin réseau. Remontez les Received. L'IP d'origine est-elle cohérente avec l'expéditeur ? Les délais sont-ils normaux ?

5. Vérifier le contenu. Le lien pointe-t-il vers un domaine suspect ? La pièce jointe est-elle suspecte (macro, exécutable) ?

6. Classer l'incident. Phishing confirmé, suspect (à surveiller) ou faux positif. Documentez avec les en-têtes complets et les résultats de votre analyse.

7. Agir. Phishing confirmé : bloquez l'expéditeur, ajoutez l'URL à votre liste noire, informez les employés susceptibles d'avoir reçu le même email. Si quelqu'un a cliqué : déclenchez la procédure de réponse à incident.

Automatisez le signalement. Avec nophi.sh, les employés transfèrent les emails suspects en un clic. L'IA analyse l'email et rend un verdict en 30 secondes. L'équipe de sécurité reçoit une alerte avec les détails de l'analyse. Démarrer gratuitement.

Pour aller plus loin