Comprendre les en-têtes email : le guide complet pour lire et analyser chaque champ

⚡TL;DR

• Les en-têtes email sont un journal de bord invisible qui enregistre chaque serveur traversé, chaque vérification d'authentification et chaque décision anti-spam
• Les en-têtes Received se lisent de bas en haut : le plus ancien hop est en bas, le plus récent en haut
• Authentication-Results résume les verdicts SPF, DKIM et DMARC en une seule ligne, c'est le champ le plus important pour diagnostiquer un problème
• Les champs From, Return-Path et Reply-To peuvent pointer vers trois adresses différentes, signe potentiel de spoofing
• Un outil d'analyse automatisé transforme des dizaines de lignes techniques en un diagnostic lisible en quelques secondes

Vous recevez un email suspect. L'expéditeur affiche le nom de votre banque, mais quelque chose ne colle pas. Ou bien vos propres emails arrivent en spam chez vos clients, et vous ne comprenez pas pourquoi. Dans les deux cas, la réponse se trouve au même endroit : les en-têtes de l'email. Quand on sait que 60 % des brèches confirmées impliquent une action humaine (Verizon DBIR 2025) et qu'il faut en moyenne 207 jours pour détecter un compromis par phishing (IBM 2025), savoir lire un en-tête n'est plus un luxe technique.

Chaque email transporte un bloc de métadonnées invisibles. Ce bloc contient l'itinéraire complet du message (quels serveurs il a traversés, dans quel ordre), les résultats des vérifications d'authentification (SPF, DKIM, DMARC) et des indices sur la façon dont les filtres anti-spam ont traité le message. C'est un journal de bord complet, mais il faut savoir le lire.

Ce guide vous apprend à extraire ces en-têtes, comprendre chaque champ, interpréter la chaîne de routage et diagnostiquer les problèmes les plus courants. Que vous soyez administrateur système, responsable marketing ou simplement curieux de savoir si un email est légitime, aucune connaissance préalable n'est requise : on part de zéro.

Qu'est-ce qu'un en-tête email et pourquoi s'en soucier ?

L'analogie de l'enveloppe postale

Quand vous envoyez une lettre, l'enveloppe porte l'adresse de l'expéditeur, l'adresse du destinataire et les cachets de la Poste. Le contenu de la lettre est séparé de ces informations de routage.

Un email fonctionne de la même manière. Le corps du message (le texte, les images, les pièces jointes) est séparé des en-têtes qui transportent les métadonnées. La différence : les en-têtes d'un email contiennent bien plus d'informations qu'une enveloppe postale. Chaque serveur traversé ajoute ses propres annotations, comme un cachet postal horodaté.

En-têtes visibles vs en-têtes techniques

Votre client de messagerie affiche quelques en-têtes sous forme lisible :

• De (From) : l'adresse de l'expéditeur
• A (To) : l'adresse du destinataire
• Objet (Subject) : le sujet du message
• Date : l'horodatage d'envoi

Mais sous cette surface, des dizaines d'en-têtes techniques restent cachés. Les plus importants :

En-tête	Rôle
Received	Trace le chemin du message de serveur en serveur
Return-Path	Adresse de rebond (enveloppe SMTP)
Authentication-Results	Verdicts SPF, DKIM et DMARC
DKIM-Signature	Signature cryptographique du message
Message-ID	Identifiant unique du message
X-Spam-Score	Score attribué par le filtre anti-spam

Quatre raisons de lire les en-têtes

1. Diagnostiquer un problème de délivrabilité. Vos emails arrivent en spam ? Les en-têtes du message reçu vous disent exactement pourquoi : échec SPF, signature DKIM invalide, politique DMARC non respectée, ou score anti-spam trop élevé.

2. Vérifier l'identité d'un expéditeur. Un email prétend venir de votre directeur financier ? Comparez le champ From avec le Return-Path et vérifiez que le DKIM est signé par le bon domaine. Un écart entre ces champs est un signal d'alerte fort.

3. Détecter le spoofing et le phishing. Les attaquants falsifient le champ From pour usurper l'identité d'un domaine légitime. Les en-têtes d'authentification révèlent si le message a réellement été émis par le serveur autorisé. Un dmarc=fail combiné à un spf=fail sur un email qui prétend venir de votre banque est un indicateur fiable de fraude. Et le problème est massif : 84,2 % des attaques phishing passent les contrôles DMARC (Egress 2024), soit parce que le domaine n'a pas de politique DMARC, soit parce que la politique est trop permissive (p=none).

4. Tracer un problème de latence. Chaque en-tête Received contient un horodatage. En comparant les timestamps de chaque hop, vous identifiez le serveur qui introduit un délai anormal dans la chaîne de routage.

Comment extraire les en-têtes

Chaque client de messagerie cache les en-têtes techniques par défaut. Voici comment les afficher.

Gmail (web)

1. Ouvrez l'email concerné
2. Cliquez sur le menu trois points verticaux (⋮) en haut à droite du message
3. Sélectionnez "Afficher l'original"
4. Une nouvelle fenêtre affiche les en-têtes complets avec un résumé SPF/DKIM/DMARC en haut

Gmail propose un bouton "Copier dans le presse-papier" pour récupérer l'intégralité des en-têtes. C'est la méthode la plus rapide pour les coller dans un outil d'analyse.

Outlook desktop (Windows/Mac)

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

Le champ est petit : sélectionnez tout (Ctrl+A) puis copiez (Ctrl+C) pour travailler plus confortablement dans un éditeur de texte.

Outlook web (OWA)

1. Ouvrez l'email concerné
2. Cliquez sur le menu trois points (⋮) en haut à droite
3. Sélectionnez "Afficher" puis "Afficher la source du message"
4. Les en-têtes s'affichent dans une nouvelle fenêtre

Apple Mail (macOS)

1. Sélectionnez l'email dans la liste
2. Dans la barre de menu, allez dans Présentation > Message > Tous les en-têtes
3. Les en-têtes techniques apparaissent au-dessus du corps du message

Pour revenir à l'affichage normal : Présentation > Message > En-têtes par défaut.

Thunderbird

1. Sélectionnez l'email
2. Menu Affichage > Source du message (ou raccourci Ctrl+U, Cmd+U sur Mac)
3. Le code source complet s'ouvre dans une nouvelle fenêtre, en-têtes inclus

Thunderbird affiche aussi un résumé des en-têtes directement dans le volet de lecture si vous activez Affichage > En-têtes > Complet.

Yahoo Mail

1. Ouvrez l'email concerné
2. Cliquez sur le menu trois points (⋮) à côté du bouton Répondre
3. Sélectionnez "Afficher le message brut"
4. Les en-têtes complets et le corps du message s'affichent dans un nouvel onglet

ProtonMail

1. Ouvrez l'email concerné
2. Cliquez sur le menu trois points (⋮) en haut à droite du message
3. Sélectionnez "Afficher les en-têtes"
4. ProtonMail affiche les en-têtes dans une fenêtre modale. Utilisez le bouton copier pour récupérer l'intégralité

Note : ProtonMail étant un service chiffré côté client, les en-têtes visibles sont ceux ajoutés lors du transit SMTP. Les en-têtes internes à l'infrastructure ProtonMail restent limités.

Conseil pratique

Quelle que soit la méthode, copiez l'intégralité des en-têtes et collez-les dans un outil d'analyse d'en-têtes. L'outil décompose automatiquement chaque champ, calcule les délais entre les hops et met en évidence les problèmes d'authentification.

Copiez TOUT le contenu. Les en-têtes d'un email professionnel font souvent entre 50 et 200 lignes. Si vous ne copiez que les premières lignes, vous perdez les hops Received les plus anciens (qui sont en bas) et souvent les informations les plus révélatrices.

Erreur courante : ne confondez pas "Afficher la source" (qui affiche le message complet, en-têtes + corps encodé) avec "Afficher les en-têtes" (seulement les métadonnées). Pour un diagnostic complet, la source entière est préférable : elle contient les signatures DKIM vérifiables.

Format et structure des en-têtes (RFC 5322)

Le format clé: valeur

Chaque en-tête suit un format simple défini par la RFC 5322 :

Nom-Du-Champ: valeur du champ

Le nom du champ est insensible à la casse (From et from sont identiques), suivi de deux-points, puis de la valeur. Exemples :

From: contact@captaindns.com
To: support@captaindns.com
Subject: Rapport de monitoring DNS - Mars 2026
Date: Sat, 29 Mar 2026 10:15:00 +0100
Message-ID: <20260329101500.abc123@mail.captaindns.com>

Le folding (continuation sur plusieurs lignes)

Quand une valeur est trop longue pour tenir sur une seule ligne, elle se poursuit sur la ligne suivante avec une indentation (espace ou tabulation). C'est ce qu'on appelle le folding. Exemple avec un en-tête Received :

Received: from mx-out.captaindns.com (mx-out.captaindns.com [203.0.113.10])
    by mx-in.captaindns.com (Postfix) with ESMTPS id ABC123DEF
    for <support@captaindns.com>; Sat, 29 Mar 2026 10:15:02 +0100

Ces trois lignes forment un seul en-tête Received. La règle : toute ligne qui commence par un espace blanc est la continuation de l'en-tête précédent.

L'ordre de lecture : de bas en haut pour les Received

Voici la particularité la plus importante des en-têtes email : les en-têtes Received se lisent de bas en haut.

Chaque serveur SMTP qui traite le message ajoute son en-tête Received au-dessus des en-têtes existants. Le résultat : le premier hop (le serveur d'origine) est en bas, le dernier hop (le serveur de réception) est en haut.

Les autres en-têtes (From, To, Subject, Date, Message-ID) sont ajoutés une seule fois par le serveur d'origine. Leur position dans le bloc est fixe.

Les champs clés expliqués un par un

From

From: Marie Dupont <contact@captaindns.com>

Description : identifie l'expéditeur affiché dans le client de messagerie. C'est le champ que voit le destinataire.

Ce que ça révèle : le From est l'en-tête le plus visible, mais aussi le plus facile à falsifier. N'importe quel serveur SMTP peut envoyer un email avec un From arbitraire. C'est précisément pour ça que SPF, DKIM et DMARC existent : vérifier que le From correspond bien au serveur qui a réellement envoyé le message.

Attention au display name. Le champ From contient deux éléments distincts : le nom affiché (display name) et l'adresse réelle entre chevrons. Dans From: Marie Dupont <contact@captaindns.com>, votre client de messagerie affiche "Marie Dupont" en gras, et l'adresse contact@captaindns.com en plus petit. Le problème : le display name est un texte libre, sans aucune vérification. Un attaquant peut écrire From: Directeur Financier <attaquant@domaine-malveillant.com> et de nombreux clients mobiles n'affichent que le nom, pas l'adresse. Vérifiez toujours l'adresse entre chevrons, pas le nom affiché.

To et Cc

To: support@captaindns.com
Cc: tech@captaindns.com

Description : To liste les destinataires principaux. Cc (copie carbone) liste les destinataires en copie visible.

Ce que ça révèle : si votre adresse n'apparaît ni dans To ni dans Cc, le message vous a été envoyé en copie cachée (Bcc) ou via une liste de distribution. Les campagnes de phishing de masse utilisent souvent un To générique ou vide.

Subject

Subject: =?utf-8?B?UmFwcG9ydCBkZSBtb25pdG9yaW5n?=

Description : le sujet du message. Peut être encodé en Base64 ou Quoted-Printable quand il contient des caractères non-ASCII (accents, caractères spéciaux).

Ce que ça révèle : dans sa forme décodée, c'est le texte que vous voyez dans votre boîte de réception. L'encodage brut dans les en-têtes est normal et ne signale aucun problème.

Date

Date: Sat, 29 Mar 2026 10:15:00 +0100

Description : horodatage défini par le client de l'expéditeur au moment de l'envoi. Le format suit la RFC 5322 : jour, date, heure et décalage UTC.

Ce que ça révèle : comparez cette date avec les timestamps des en-têtes Received. Un écart de plusieurs heures entre le Date et le premier Received peut indiquer un email envoyé par un script mal configuré ou une tentative de manipulation temporelle.

Return-Path

Return-Path: <bounces@mail.captaindns.com>

Description : l'adresse à laquelle les messages de rebond (bounces) sont envoyés. C'est l'adresse de l'enveloppe SMTP (MAIL FROM), ajoutée par le serveur de réception final.

Ce que ça révèle : le Return-Path peut différer du From. C'est normal quand un service tiers envoie des emails en votre nom. Par exemple, un email envoyé via SendGrid affichera Return-Path: <bounces+12345@em.sendgrid.net> même si le From est contact@captaindns.com. Même chose pour Mailgun (bounces@mailgun.org) ou Amazon SES (0123abcd@amazonses.com). Ces services gèrent les bounces via leur propre infrastructure.

C'est anormal quand un email prétend venir de contact@captaindns.com mais a un Return-Path vers un domaine inconnu qui n'a aucun rapport avec un prestataire d'envoi légitime. DMARC vérifie l'alignement entre le domaine du From et le domaine du Return-Path (ou du DKIM). Un désalignement sans DKIM valide provoque un échec DMARC.

Reply-To

Reply-To: reponses@captaindns.com

Description : l'adresse vers laquelle le client de messagerie enverra la réponse quand le destinataire clique sur "Répondre". Optionnel.

Ce que ça révèle : un Reply-To différent du From est courant pour les newsletters (envoi depuis un service marketing, réponse vers le support). C'est suspect quand le Reply-To pointe vers un domaine complètement différent du From, typique des arnaques au président (Business Email Compromise).

Message-ID

Message-ID: <20260329101500.abc123@mail.captaindns.com>

Description : identifiant unique du message, généré par le serveur d'envoi. Le format habituel est un horodatage ou un identifiant aléatoire suivi du nom d'hôte du serveur, le tout entre chevrons.

Ce que ça révèle : le domaine dans le Message-ID indique quel serveur a réellement créé le message. Si un email prétend venir de captaindns.com mais a un Message-ID contenant un domaine différent, c'est un indice d'usurpation. C'est aussi un indicateur précieux du service d'envoi réel : un Message-ID en @amazonses.com trahit un envoi via Amazon SES, @smtpservice.net indique SendGrid, @mail.gmail.com indique Google Workspace. Le Message-ID est un des en-têtes les plus difficiles à falsifier de manière convaincante, car il est généré automatiquement par le serveur SMTP.

MIME-Version et Content-Type

MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="boundary123abc"

Description : MIME-Version indique que le message utilise le format MIME (quasiment toujours 1.0). Content-Type décrit le format du corps : text/plain (texte brut), text/html (HTML), multipart/alternative (les deux versions), multipart/mixed (avec pièces jointes).

Ce que ça révèle : un email qui prétend être un simple texte mais contient un Content-Type: multipart/mixed avec une pièce jointe exécutable est suspect. Le Content-Type aide à comprendre la structure réelle du message.

Received

Received: from mx-out.captaindns.com (mx-out.captaindns.com [203.0.113.10])
    by mx-in.captaindns.com (Postfix) with ESMTPS id ABC123DEF
    for <support@captaindns.com>; Sat, 29 Mar 2026 10:15:02 +0100

Description : chaque serveur SMTP qui traite le message ajoute un en-tête Received. C'est la trace de routage du message.

Ce que ça révèle : l'itinéraire complet du message, serveur par serveur. Les détails de chaque hop (identité du serveur, protocole utilisé, horodatage) permettent de vérifier la légitimité du routage. Section dédiée plus bas.

Le protocole indiqué après with est un signal de sécurité important. with ESMTPS signifie que la connexion entre les deux serveurs était chiffrée via TLS : c'est le standard attendu en 2026. with ESMTP (sans le S) signifie que le message a transité en clair, sans chiffrement. Si vous voyez with ESMTP sur un hop externe (entre deux organisations différentes), c'est un problème : le contenu du message, pièces jointes comprises, a circulé lisible par quiconque intercepte le trafic réseau. with ESMTPSA indique une connexion authentifiée et chiffrée (typiquement un client de messagerie qui se connecte au serveur SMTP avec login/mot de passe + TLS).

DKIM-Signature

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=captaindns.com; s=s202603; t=1743238500;
    h=from:to:subject:date:message-id;
    bh=LjIq2t4u3qH0OwZ1E4fDn5t3nVz2Ay+KqR0kbD1XXXA=;
    b=dGVzdCBzaWduYXR1cmUgZXhhbXBsZQ==...

Description : signature cryptographique ajoutée par le serveur d'envoi. Le serveur de réception vérifie cette signature via la clé publique publiée dans le DNS.

Ce que ça révèle : les balises clés sont d= (domaine signataire), s= (sélecteur de la clé), a= (algorithme, rsa-sha256 est le standard), h= (en-têtes couverts par la signature), bh= (hash du corps du message) et b= (la signature elle-même). Si d=captaindns.com et que Authentication-Results montre dkim=pass, le message est authentifié par le domaine.

La balise bh= (body hash) est un condensé cryptographique du corps du message. Le serveur de réception recalcule ce hash et le compare à la valeur dans l'en-tête. Si le corps a été modifié en transit (par une liste de diffusion qui ajoute un pied de page, par exemple), le hash ne correspond plus et DKIM échoue. La balise c= (canonicalization) définit la tolérance aux modifications mineures : relaxed/relaxed est le plus permissif (ignore les espaces superflus), simple/simple est strict.

Authentication-Results

Authentication-Results: mx.captaindns.com;
    spf=pass (sender IP is 203.0.113.10) smtp.mailfrom=mail.captaindns.com;
    dkim=pass header.d=captaindns.com header.s=s202603;
    dmarc=pass (p=reject) header.from=captaindns.com

Description : résumé des vérifications d'authentification effectuées par le serveur de réception. Un seul en-tête qui regroupe les verdicts SPF, DKIM et DMARC.

Ce que ça révèle : c'est le champ le plus important pour diagnostiquer un problème d'authentification email. Section dédiée plus bas.

X-Mailer et User-Agent

X-Mailer: CaptainDNS Mailer 2.1

Description : identifie le logiciel client utilisé pour envoyer le message. Champ optionnel et non standardisé.

Ce que ça révèle : un email professionnel envoyé par un X-Mailer inhabituel (un script Python brut, un outil de mass-mailing) peut être suspect. C'est un indice complémentaire, jamais un critère décisif.

X-MS-Exchange-Organization-SCL

X-MS-Exchange-Organization-SCL: 1

Description : Spam Confidence Level attribué par Microsoft Exchange. Échelle de -1 (message de confiance) à 9 (spam certain). Le seuil par défaut de mise en quarantaine est 5.

Ce que ça révèle : si vous utilisez Exchange ou Microsoft 365, ce score vous dit directement comment le filtre anti-spam de Microsoft a évalué le message. Un SCL de 5 ou plus explique pourquoi un email a été classé en courrier indésirable.

Les en-têtes ARC

ARC-Seal: i=1; a=rsa-sha256; d=captaindns.com; s=arc202603; cv=none; ...
ARC-Message-Signature: i=1; a=rsa-sha256; d=captaindns.com; ...
ARC-Authentication-Results: i=1; mx.captaindns.com;
    spf=pass; dkim=pass; dmarc=pass

Description : ARC (Authenticated Received Chain) préserve les résultats d'authentification quand un message traverse des intermédiaires (listes de diffusion, transferts automatiques). Trois en-têtes travaillent ensemble : ARC-Authentication-Results (résultats au point de passage), ARC-Message-Signature (signature du message à ce point) et ARC-Seal (scellé de la chaîne).

Ce que ça révèle : quand un email est transféré et que SPF/DKIM échouent à cause de la modification en transit, ARC permet au serveur final de vérifier que l'authentification était valide au départ. Le champ cv= (chain validation) indique si la chaîne est intacte : none (premier hop), pass (chaîne valide) ou fail (chaîne rompue). Pour en savoir plus sur le fonctionnement d'ARC, consultez notre guide sur Authenticated Received Chain.

Les en-têtes qui trahissent un service tiers

Quand une entreprise envoie un email via un service tiers (plateforme marketing, CRM, outil transactionnel), les en-têtes conservent la trace de l'infrastructure réelle d'envoi. C'est un outil puissant pour identifier qui envoie vraiment un email, même si le From affiche un domaine d'entreprise.

Tableau des signatures par fournisseur

Fournisseur	En-têtes révélateurs	Return-Path typique	Message-ID / DKIM
SendGrid	X-SG-EID, X-SG-ID	@sendgrid.net ou @em.sendgrid.net	DKIM d=sendgrid.net (si pas de DKIM custom)
Amazon SES	X-SES-Outgoing	@amazonses.com	Message-ID: @amazonses.com, DKIM d=amazonses.com
Mailgun	X-Mailgun-Sid, X-Mailgun-Variables	@mailgun.org	DKIM d=mailgun.org
Google Workspace	Received: from mail-*.google.com	@*.google.com	Message-ID: @mail.gmail.com
Microsoft 365	X-MS-Exchange-Organization-*, X-MS-Has-Attach	@*.outlook.com	DKIM d=*.onmicrosoft.com
Brevo (ex-Sendinblue)	X-Mailin-EID, X-Mailin-*	@mail-sib.com	DKIM d=sendinblue.com ou custom
Postmark	X-PM-Message-Id	@pm.mtasv.net	DKIM d=pm.mtasv.net
Mailchimp	X-MC-User, X-Mailer: MailChimp Mailer	@mcsv.net ou @mail*.suw*.mcdlv.net	DKIM d=*.mcsv.net

Comment utiliser ce tableau

Quand vous analysez un email suspect, repérez les en-têtes X-* non standards et le domaine du Return-Path. Si un email prétend venir de contact@captaindns.com et que les en-têtes contiennent X-SG-EID avec un Return-Path en @sendgrid.net, vous savez que l'email a transité par SendGrid. Ce n'est pas forcément suspect : il suffit de vérifier que captaindns.com utilise bien SendGrid comme prestataire d'envoi.

En revanche, si un email prétend venir de votre banque mais que les en-têtes révèlent un envoi depuis un petit fournisseur SMTP inconnu, avec un DKIM signé par un domaine tiers sans rapport, c'est un signal d'alerte.

Lire la chaîne Received (de bas en haut)

La chaîne des en-têtes Received est la colonne vertébrale du routage email. Chaque serveur qui touche le message laisse sa trace.

Le principe : chaque serveur ajoute en haut

Imaginez une pile de cachets postaux. Le bureau de poste d'origine appose le premier cachet. Chaque bureau intermédiaire ajoute le sien par-dessus. Le bureau de destination se retrouve en haut de la pile.

C'est exactement ce qui se passe avec les en-têtes Received : le serveur de réception finale ajoute son en-tête tout en haut. Le serveur d'origine est tout en bas. Pour reconstituer le trajet chronologique du message, lisez les en-têtes Received de bas en haut.

Anatomie d'un hop

Chaque en-tête Received contient quatre informations clés :

Élément	Signification	Exemple
from	Serveur qui a transmis le message	mx-out.captaindns.com
by	Serveur qui a reçu le message	mx-in.captaindns.com
with	Protocole utilisé	ESMTPS (SMTP chiffré TLS)
Timestamp	Date et heure de réception	Sat, 29 Mar 2026 10:15:02 +0100

Le protocole with est révélateur :

• ESMTPS : SMTP avec TLS (chiffré, c'est le standard attendu)
• ESMTP : SMTP sans TLS (non chiffré, problème potentiel)
• LMTP : protocole de livraison locale (dernier hop, normal)

Exemple concret avec 4 hops

Voici une chaîne Received réaliste pour un email reçu par captaindns.com, envoyé par un collaborateur externe via Gmail et filtré par Mimecast. Les en-têtes sont présentés dans l'ordre dans lequel ils apparaissent dans le message brut (du plus récent au plus ancien) :

(1) Received: from mx2.captaindns.com (10.0.0.5)
        by exchange.captaindns.com (10.0.0.10) with ESMTP;
        Fri, 29 Mar 2026 10:42:15 +0100

(2) Received: from gateway.mimecast.com (91.220.42.50)
        by mx2.captaindns.com with ESMTPS id A1B2C3D4;
        Fri, 29 Mar 2026 10:42:13 +0100

(3) Received: from mail-sor-f41.google.com (209.85.220.41)
        by gateway.mimecast.com with ESMTPS id E5F6G7H8;
        Fri, 29 Mar 2026 10:42:11 +0100

(4) Received: from [192.168.1.100] by smtp.gmail.com with ESMTPSA
        id I9J0K1L2; Fri, 29 Mar 2026 10:42:09 +0100

Lecture de bas en haut (ordre chronologique) :

1. Hop 4 (10:42:09, le plus ancien, en bas) : l'expéditeur envoie depuis son PC (IP privée 192.168.1.100) via le serveur SMTP de Gmail. Le protocole ESMTPSA confirme une connexion authentifiée et chiffrée
2. Hop 3 (10:42:11) : Gmail transmet le message au gateway Mimecast. ESMTPS indique une connexion TLS entre Google et Mimecast (filtre anti-spam/sécurité du destinataire)
3. Hop 2 (10:42:13) : Mimecast, après analyse du message, le transmet au serveur MX de captaindns.com. Connexion ESMTPS, chiffrement maintenu
4. Hop 1 (10:42:15, le plus récent, en haut) : le MX interne transmet au serveur Exchange final pour livraison dans la boîte du destinataire. ESMTP sans TLS entre serveurs internes, acceptable dans un réseau privé

Temps total de transit : 6 secondes. C'est normal. Au-delà de 30 secondes entre deux hops consécutifs, il y a probablement un problème de performance sur le serveur responsable du délai.

Détecter les anomalies dans la chaîne

Timestamps incohérents. Un hop 3 daté avant le hop 2 ? C'est soit une horloge désynchronisée (fréquent sur des serveurs mal configurés), soit un en-tête Received injecté manuellement par un attaquant. Vérifiez si le serveur concerné est légitime.

Hops manquants. Le message passe de votre serveur directement à un serveur inconnu, sans passer par votre gateway ? Un intermédiaire non autorisé a peut-être relayé le message, ou un serveur de la chaîne ne génère pas d'en-tête Received (rare mais possible).

Serveurs inconnus. Un nom d'hôte ou une IP que vous ne reconnaissez pas dans la chaîne ? Vérifiez le reverse DNS de l'IP. Un serveur légitime a un PTR cohérent avec son nom d'hôte. Un serveur compromis ou un relais ouvert a souvent un PTR générique ou inexistant.

IP privées en milieu de chaîne. Des adresses en 10.x.x.x ou 192.168.x.x sont normales pour le premier hop (réseau interne de l'expéditeur). Elles sont suspectes si elles apparaissent plus loin dans la chaîne, car elles suggèrent un routage anormal.

Authentication-Results : SPF, DKIM, DMARC

L'en-tête Authentication-Results est le tableau de bord de la sécurité email. Il résume en une ligne les résultats des trois protocoles d'authentification. C'est le premier en-tête à vérifier quand vous diagnostiquez un problème.

Structure du champ

Authentication-Results: mx.captaindns.com;
    spf=pass (sender IP is 203.0.113.10) smtp.mailfrom=mail.captaindns.com;
    dkim=pass (2048-bit key) header.d=captaindns.com header.s=s202603;
    dmarc=pass (p=reject dis=none) header.from=captaindns.com

Le premier élément (mx.captaindns.com) identifie le serveur qui a effectué les vérifications. Chaque verdict est séparé par un point-virgule.

Champ	Résultat	Signification
spf=pass	✓	Le serveur expéditeur est autorisé par le record SPF
dkim=pass	✓	La signature cryptographique est valide (sélecteur : s202603)
dmarc=pass	✓	SPF et DKIM sont alignés avec le domaine From (politique : reject)

SPF : le serveur est-il autorisé ?

SPF (Sender Policy Framework) vérifie si l'adresse IP du serveur d'envoi est autorisée par l'enregistrement DNS SPF du domaine.

Verdict	Signification	Action typique
pass	L'IP est explicitement autorisée	Accepté
fail	L'IP est explicitement interdite (-all)	Rejeté ou spam
softfail	L'IP n'est pas autorisée mais pas explicitement interdite (~all)	Accepté avec méfiance
neutral	Le domaine ne se prononce pas (?all)	Aucun impact
none	Pas d'enregistrement SPF publié	Aucune vérification possible
temperror	Erreur DNS temporaire	Réessai ultérieur
permerror	Erreur de syntaxe dans l'enregistrement SPF	Varie selon le serveur

Le détail entre parenthèses (sender IP is 203.0.113.10) vous donne l'IP qui a été vérifiée. Le champ smtp.mailfrom indique le domaine de l'enveloppe SMTP.

DKIM : le message est-il intègre ?

DKIM vérifie la signature cryptographique du message. Si la signature est valide, le contenu n'a pas été modifié en transit et le domaine signataire est authentifié.

Verdict	Signification	Action typique
pass	Signature valide	Authentifié
fail	Signature invalide (message modifié ou clé incorrecte)	Suspect
none	Aucune signature DKIM présente	Aucune vérification possible
neutral	Signature présente mais non vérifiable	Aucun impact
temperror	Erreur DNS temporaire lors de la récupération de la clé	Réessai
permerror	Erreur dans l'enregistrement DKIM	Varie

Les détails importants : header.d= indique le domaine signataire, header.s= indique le sélecteur utilisé. Ces informations vous permettent de vérifier quel domaine a réellement signé le message et avec quelle clé.

DMARC : l'alignement est-il correct ?

DMARC vérifie que le domaine du From (visible par le destinataire) est aligné avec les domaines authentifiés par SPF et/ou DKIM. C'est la couche qui empêche le spoofing du champ From.

Verdict	Signification	Action typique
pass	Alignement SPF ou DKIM vérifié	Accepté
fail	Aucun alignement valide	Applique la politique p=
bestguesspass	Pas de politique DMARC publiée, mais le serveur estime que le message est légitime	Accepté
none	Pas de politique DMARC publiée	Aucune action

Les détails DMARC incluent :

• p= : la politique publiée par le domaine (none, quarantine, reject)
• dis= : la disposition réellement appliquée par le serveur
• header.from= : le domaine du From vérifié

Exemple combiné : lecture complète

Voici un Authentication-Results problématique :

Authentication-Results: mx.captaindns.com;
    spf=softfail (sender IP is 198.51.100.42) smtp.mailfrom=notifications.captaindns.com;
    dkim=fail (signature verification failed) header.d=captaindns.com header.s=s202603;
    dmarc=fail (p=quarantine dis=quarantine) header.from=captaindns.com

Diagnostic :

• SPF softfail : l'IP 198.51.100.42 n'est pas dans l'enregistrement SPF de notifications.captaindns.com. Peut-être un nouveau serveur d'envoi non encore déclaré
• DKIM fail : la signature est invalide. Causes possibles : clé DNS obsolète, message modifié en transit, ou rotation de clé mal synchronisée
• DMARC fail : ni SPF ni DKIM ne passent avec alignement. La politique quarantine est appliquée : le message est placé en spam

Ce type de résultat signale un problème de configuration côté expéditeur, pas une attaque. La correction passe par la mise à jour de l'enregistrement SPF et la vérification de la clé DKIM.

Les en-têtes anti-spam

Au-delà de SPF/DKIM/DMARC, les filtres anti-spam ajoutent leurs propres en-têtes pour justifier leurs décisions.

X-Spam-Score et X-Spam-Status

X-Spam-Status: No, score=-2.1 required=5.0
    tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_PASS
X-Spam-Score: -2.1

SpamAssassin utilise un système de score cumulatif. Chaque test ajoute ou retire des points. Un score au-dessus du seuil (généralement 5.0) classe le message en spam.

Les tests courants :

Test	Score typique	Signification
BAYES_00	-1.9	Le contenu ressemble à du ham (non-spam) selon le filtre bayésien
DKIM_VALID_AU	-0.1	DKIM valide et aligné avec le domaine auteur
SPF_PASS	-0.0	SPF réussi
HTML_MESSAGE	+0.0	Le message contient du HTML (neutre)
URIBL_BLOCKED	+0.0	Les listes d'URL n'ont pas pu être consultées
BAYES_99	+3.5	Le contenu ressemble fortement à du spam
MISSING_MID	+0.5	Pas de Message-ID (suspect)

Le score SCL de Exchange

L'en-tête X-MS-Exchange-Organization-SCL attribue un score de 0 à 9 :

SCL	Classification	Action par défaut
-1	Expéditeur de confiance (liste blanche)	Livraison directe
0-1	Non-spam	Boîte de réception
2-4	Probablement non-spam	Boîte de réception
5-6	Spam probable	Dossier courrier indésirable
7-9	Spam certain	Rejet ou quarantaine

Les en-têtes Google

Gmail n'expose pas de score anti-spam dans les en-têtes bruts. En revanche, vous trouverez :

• X-Google-DKIM-Signature : signature DKIM ajoutée par Google en plus de celle de l'expéditeur
• X-Gm-Message-State : état interne du message dans l'infrastructure Google (encodé, non interprétable)
• X-Google-Smtp-Source : identifiant du serveur Google qui a traité le message

La vue "Afficher l'original" de Gmail affiche un résumé SPF/DKIM/DMARC en haut de la page, plus lisible que les en-têtes bruts.

Comment interpréter les verdicts

Quand un filtre anti-spam classe un message en spam, cherchez d'abord l'en-tête Authentication-Results. Si SPF, DKIM et DMARC sont tous en pass, le problème vient probablement du contenu (mots-clés suspects, ratio texte/image, liens raccourcis). Si l'un des trois échoue, corrigez d'abord l'authentification avant de toucher au contenu.

Pour comprendre comment les attaquants exploitent les failles dans les en-têtes pour contourner les filtres, consultez notre article sur les signaux d'alerte dans les en-têtes email.

6 scénarios pratiques de diagnostic

Scénario 1 : mon email arrive en spam

En-têtes à vérifier : Authentication-Results, X-Spam-Score (ou SCL)

Méthode :

1. Demandez au destinataire d'extraire les en-têtes du message reçu en spam
2. Vérifiez Authentication-Results : si spf=fail ou dkim=fail, c'est la cause probable
3. Si SPF/DKIM/DMARC sont tous en pass, regardez le score anti-spam. Un X-Spam-Score supérieur à 5.0 ou un SCL de 5+ indique un filtrage basé sur le contenu
4. Vérifiez la réputation de votre IP d'envoi via un outil de vérification de liste noire

Exemple concret : voici l'en-tête qui explique pourquoi un email légitime finit en spam.

Authentication-Results: mx.destinataire.com;
    spf=pass smtp.mailfrom=mail.captaindns.com;
    dkim=pass header.d=captaindns.com;
    dmarc=fail (p=quarantine dis=quarantine) header.from=captaindns.com

Ici, SPF et DKIM passent, mais DMARC échoue. La cause probable : le domaine SPF (mail.captaindns.com) n'est pas aligné avec le domaine From (captaindns.com) et DMARC exige un alignement strict (aspf=s). La disposition dis=quarantine confirme que le message a été envoyé en spam.

Correction rapide : publiez ou corrigez votre enregistrement SPF, vérifiez votre signature DKIM, et déployez une politique DMARC au minimum en p=none pour commencer à recevoir des rapports.

Scénario 2 : cet email vient-il vraiment de mon directeur ?

En-têtes à vérifier : From, Return-Path, DKIM-Signature, Authentication-Results

Exemple concret : un email qui semble venir de votre CEO mais qui est une arnaque au président.

From: Jean-Marc Duval - CEO <jm.duval@captaindns.com>
Return-Path: <jmduval.ceo@gmail.com>
Reply-To: jmduval.urgent@protonmail.com
Authentication-Results: mx.captaindns.com;
    spf=pass smtp.mailfrom=gmail.com;
    dkim=pass header.d=gmail.com;
    dmarc=fail header.from=captaindns.com

Le display name affiche "Jean-Marc Duval - CEO" et l'adresse From montre captaindns.com. Mais le Return-Path pointe vers un compte Gmail, le Reply-To vers ProtonMail, et DMARC échoue car DKIM est signé par gmail.com, pas par captaindns.com. C'est une arnaque au président classique.

Méthode :

1. Comparez le From avec le Return-Path. S'ils pointent vers des domaines différents sans raison légitime (pas de service tiers d'envoi connu), c'est un signal d'alerte
2. Vérifiez Authentication-Results : un dmarc=fail sur un email qui prétend venir du domaine de votre entreprise confirme une usurpation
3. Examinez DKIM-Signature : le d= devrait correspondre au domaine de votre entreprise
4. Regardez le Reply-To : s'il pointe vers un domaine externe (gmail.com, protonmail.com), c'est une arnaque au président classique

Règle d'or : si From dit une chose et que Authentication-Results en dit une autre, fiez-vous aux résultats d'authentification. Seulement 4 % des domaines appliquent une politique DMARC p=reject (Valimail 2025), ce qui laisse la porte ouverte à ce type d'usurpation sur la grande majorité des domaines.

Scénario 3 : depuis quand mon email traîne-t-il ?

En-têtes à vérifier : les timestamps de chaque en-tête Received

Méthode :

1. Listez tous les en-têtes Received de bas en haut
2. Notez l'horodatage de chaque hop
3. Calculez le délai entre chaque paire de hops consécutifs
4. Le hop avec le plus grand délai est le goulot d'étranglement

Seuils indicatifs :

• Moins de 5 secondes entre deux hops : normal
• 5 à 30 secondes : acceptable pour un serveur chargé
• Plus de 30 secondes : problème de greylisting, de file d'attente saturée ou de DNS lent
• Plus de 5 minutes : le serveur a probablement mis le message en file d'attente et l'a réessayé

Scénario 4 : mon DKIM est-il bien signé ?

En-têtes à vérifier : DKIM-Signature, Authentication-Results

Méthode :

1. Localisez l'en-tête DKIM-Signature dans le message brut
2. Vérifiez que d= correspond à votre domaine d'envoi
3. Notez le sélecteur s= et vérifiez que l'enregistrement DNS correspondant est publié
4. Regardez le verdict DKIM dans Authentication-Results : dkim=pass confirme que tout fonctionne

Causes fréquentes d'échec DKIM :

• Clé DNS supprimée ou mal publiée
• Rotation de clé sans mise à jour du serveur d'envoi
• Modification du message en transit (par une liste de diffusion ou un outil de réécriture d'URL)
• En-tête h= qui ne couvre pas tous les en-têtes modifiés

Scénario 5 : ce lien est-il un phishing ?

En-têtes à vérifier : From, Reply-To, Return-Path, Authentication-Results, ARC-*

Méthode :

1. Vérifiez le From : le domaine est-il exactement celui attendu ? Attention aux homoglyphes (captaindns.com vs captaindnss.com vs captaindns.co)
2. Comparez avec le Return-Path : un domaine complètement différent est suspect
3. Vérifiez Authentication-Results : spf=fail + dkim=fail + dmarc=fail sur un email supposé légitime est un signal fort de phishing
4. Si le message a été transféré, vérifiez les en-têtes ARC-Authentication-Results pour voir si l'authentification était valide au point d'origine
5. Un Reply-To vers un domaine gratuit (gmail.com, yahoo.com) sur un email d'entreprise est un classique du phishing

Pour approfondir les techniques de spoofing lors du routage email, lisez notre analyse sur le spoofing via le routage email et l'alerte Microsoft.

Scénario 6 : un fournisseur prétend avoir envoyé un email jamais reçu

En-têtes à vérifier : les timestamps Received, Authentication-Results

Contexte : votre fournisseur affirme avoir envoyé une facture le 15 mars. Vous ne l'avez jamais reçue. Qui a raison ?

Méthode :

1. Demandez au fournisseur de vous transmettre les en-têtes complets du message original (pas un transfert, mais les en-têtes du message envoyé)
2. Vérifiez le premier Received (en bas) : il contient l'horodatage de l'envoi initial. Si le timestamp correspond bien au 15 mars, le message a effectivement été soumis au serveur SMTP
3. Suivez la chaîne Received hop par hop. Si le dernier hop montre une livraison à votre serveur MX, le message a bien été reçu par votre infrastructure et le problème est côté filtrage
4. Si la chaîne s'arrête avant votre MX, vérifiez Authentication-Results : un spf=fail ou dmarc=fail peut avoir provoqué un rejet silencieux par votre serveur

Astuce : les timestamps des en-têtes Received constituent une preuve technique horodatée du transit du message. En cas de litige, ils documentent objectivement si l'email a été envoyé, quand, et jusqu'où il est allé dans la chaîne de routage.

Plan d'action : 5 étapes pour maîtriser les en-têtes

Vous avez maintenant les connaissances théoriques. Voici comment les mettre en pratique.

Étape 1 : extraire et analyser un premier email

Choisissez un email que vous avez envoyé vous-même (ou un email de test). Extrayez les en-têtes avec la méthode adaptée à votre client de messagerie. Collez-les dans l'outil d'analyse d'en-têtes et comparez le résultat automatique avec votre lecture manuelle.

Étape 2 : vérifier votre authentification

Envoyez un email depuis votre domaine vers une adresse Gmail. Ouvrez les en-têtes et vérifiez que SPF, DKIM et DMARC affichent tous pass. Si l'un des trois échoue, identifiez et corrigez la cause avant de passer à l'étape suivante.

Étape 3 : apprendre à repérer les anomalies

Entraînez-vous sur des emails légitimes pour calibrer votre sens de la normalité. Quand vous savez à quoi ressemble un email "sain", les anomalies dans un email suspect deviennent évidentes : serveurs inconnus dans la chaîne Received, domaines qui ne correspondent pas entre From et Return-Path, signatures DKIM invalides.

Étape 4 : automatiser la surveillance

Ne vérifiez pas les en-têtes manuellement à chaque email. Configurez DMARC avec rua= pour recevoir des rapports agrégés quotidiens. Ces rapports vous alertent automatiquement quand des emails échouent l'authentification pour votre domaine.

Étape 5 : documenter vos flux d'envoi

Listez tous les services qui envoient des emails en votre nom (CRM, outil marketing, ticketing, facturation). Pour chacun, vérifiez que SPF et DKIM sont correctement configurés. Un flux d'envoi oublié est la cause la plus fréquente d'échecs DMARC inattendus.

Conservez un document partagé avec votre équipe qui liste chaque service, l'IP ou le domaine d'envoi, le sélecteur DKIM utilisé, et la date de la dernière vérification. Ce référentiel vous évitera de chercher la cause d'un échec DMARC pendant des heures quand un collègue ajoute un nouvel outil d'envoi sans prévenir l'équipe technique.

FAQ

Qu'est-ce qu'un en-tête email ?

Un en-tête email est une ligne de métadonnées au format "Nom: Valeur" qui accompagne chaque message. Les en-têtes contiennent les informations de routage (serveurs traversés), les résultats d'authentification (SPF, DKIM, DMARC), l'identité de l'expéditeur et du destinataire, et des annotations ajoutées par les filtres anti-spam. Le corps du message (texte, images, pièces jointes) est séparé des en-têtes par une ligne vide.

Comment voir les en-têtes dans Gmail ?

Ouvrez l'email concerné, cliquez sur le menu trois points verticaux en haut à droite du message, puis sélectionnez "Afficher l'original". Gmail ouvre une nouvelle page avec les en-têtes complets et un résumé des résultats SPF, DKIM et DMARC en haut. Vous pouvez copier l'intégralité des en-têtes avec le bouton "Copier dans le presse-papier".

Pourquoi les en-têtes Received se lisent-ils de bas en haut ?

Chaque serveur SMTP qui traite un email ajoute son en-tête Received au-dessus des en-têtes existants. Le premier serveur (origine) est donc en bas et le dernier serveur (réception) est en haut. Pour reconstituer le trajet chronologique du message, il faut lire les en-têtes Received du bas vers le haut. C'est un mécanisme défini par la RFC 5321.

Que signifie spf=softfail dans Authentication-Results ?

Un verdict spf=softfail signifie que l'adresse IP du serveur d'envoi n'est pas explicitement autorisée par l'enregistrement SPF du domaine, mais n'est pas non plus explicitement interdite. Cela correspond au mécanisme ~all (tilde) dans l'enregistrement SPF. Le serveur de réception accepte généralement le message mais le traite avec méfiance. C'est souvent le signe d'un serveur d'envoi oublié dans la configuration SPF.

Comment détecter un email spoofé via les en-têtes ?

Comparez trois éléments : le champ From (adresse affichée), le Return-Path (adresse de rebond), et le domaine dans DKIM-Signature (d=). Si le From affiche un domaine légitime mais que le Return-Path pointe vers un domaine différent et que Authentication-Results montre dmarc=fail, le message est probablement usurpé. Un SPF fail combiné à un DKIM fail confirme que le serveur d'envoi n'est pas autorisé par le domaine affiché.

Les en-têtes peuvent-ils être falsifiés ?

Certains en-têtes peuvent être falsifiés par l'expéditeur : From, Reply-To, Subject et même certains en-têtes Received. En revanche, les en-têtes ajoutés par le serveur de réception (Authentication-Results, Received du serveur final, X-Spam-Score) sont fiables car ils sont générés par votre propre infrastructure. C'est pourquoi il faut toujours se baser sur les résultats d'authentification du serveur de réception, pas sur les en-têtes définis par l'expéditeur.

Quelle est la différence entre From et Return-Path ?

Le From est l'adresse affichée dans le client de messagerie, définie par l'expéditeur dans le corps des en-têtes du message. Le Return-Path est l'adresse de l'enveloppe SMTP (MAIL FROM), utilisée pour les notifications de rebond. Ils peuvent légitimement différer quand un service tiers envoie des emails en votre nom. DMARC vérifie l'alignement entre ces deux adresses : si les domaines sont trop différents sans raison valable, le message peut échouer la vérification DMARC.

Comment automatiser l'analyse des en-têtes ?

Collez vos en-têtes bruts dans un outil d'analyse comme celui de CaptainDNS. L'outil décompose chaque champ, calcule les délais entre les hops Received, vérifie les résultats d'authentification et met en évidence les anomalies. Pour une surveillance continue, configurez DMARC avec une adresse rua= pour recevoir des rapports agrégés quotidiens sur l'authentification de tous les emails envoyés depuis votre domaine.

Glossaire

• En-tête email (header) : ligne de métadonnées au format "Nom: Valeur" qui accompagne chaque message, contenant les informations de routage, d'authentification et de traitement.
• Received : en-tête ajouté par chaque serveur SMTP traversé, formant la trace de routage du message. Se lit de bas en haut pour reconstituer l'ordre chronologique.
• Return-Path : adresse de l'enveloppe SMTP (MAIL FROM) vers laquelle les messages de rebond sont envoyés. Ajouté par le serveur de réception final.
• Authentication-Results : en-tête ajouté par le serveur de réception qui résume les verdicts des vérifications SPF, DKIM et DMARC.
• SPF (Sender Policy Framework) : protocole qui vérifie si l'adresse IP du serveur d'envoi est autorisée par le DNS du domaine expéditeur (RFC 7208).
• DKIM (DomainKeys Identified Mail) : protocole d'authentification par signature cryptographique qui vérifie l'intégrité et l'origine d'un message (RFC 6376).
• DMARC (Domain-based Message Authentication, Reporting and Conformance) : protocole qui vérifie l'alignement du domaine From avec les domaines authentifiés par SPF et DKIM (RFC 7489).
• ARC (Authenticated Received Chain) : mécanisme qui préserve les résultats d'authentification quand un message traverse des intermédiaires comme les listes de diffusion.
• Folding : technique de continuation d'un en-tête sur plusieurs lignes, identifiée par une indentation (espace ou tabulation) au début de la ligne suivante.
• SCL (Spam Confidence Level) : score de spam attribué par Microsoft Exchange, de -1 (confiance) à 9 (spam certain).
• Hop : passage d'un message d'un serveur SMTP à un autre dans la chaîne de routage. Chaque hop est documenté par un en-tête Received.
• ESMTPS : Extended SMTP avec TLS, indiquant une transmission chiffrée entre deux serveurs.

Sources

• RFC 5322 - Internet Message Format
• RFC 7601 - Message Header Field for Indicating Message Authentication Status
• RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures
• RFC 7208 - Sender Policy Framework (SPF)
• Google Support - Afficher les en-têtes de message complets
• Verizon 2025 Data Breach Investigations Report (DBIR)
• IBM Cost of a Data Breach Report 2025
• Egress Email Security Risk Report 2024
• Valimail Email Authentication Report 2025