🔥 Soyez prêt pour le Black Friday, Cybermonday... 20% de remise* avec le code BF26 👉🏻 Je m'inscris

Votre messagerie n’affiche que quelques champs de l’en-tête d’un email : De, À, Objet et Date. Le reste du bloc technique reste masqué. C’est là que se trouvent le trajet du message et le verdict d’authentification.

L’en-tête d’un email (email header en anglais) est la suite de lignes « Nom : valeur » placée avant le corps du message. Elle indique qui a envoyé le mail, par quels serveurs il est passé et si SPF, DKIM et DMARC ont été validés. Pour la lire, ouvrez « Afficher l’original » dans Gmail ou « Détails du message » dans Outlook, puis remontez les lignes Received de bas en haut.

Afficher l’en-tête d’un email dans Gmail, Outlook, Apple Mail et Yahoo

Chaque messagerie cache l’en-tête brut derrière un menu différent. Voici les chemins à suivre, d’après l’aide Gmail et la documentation Microsoft :

  • Gmail : ouvrez le message, cliquez sur les trois points à côté de Répondre, puis sur « Afficher l’original ». Le bouton « Copier dans le presse-papiers » récupère l’en-tête complet. Gmail résume aussi en haut de la fenêtre les résultats SPF, DKIM et DMARC (Pass ou Fail).
  • Outlook sur le web et nouvel Outlook : ouvrez le message, puis Plus d’actions > Afficher > Détails du message.
  • Outlook classique pour Windows : double-cliquez sur le message pour l’ouvrir hors du volet de lecture, puis Fichier > Propriétés. L’en-tête se trouve dans la zone « En-têtes Internet ».
  • Apple Mail : ouvrez le message, puis Présentation > Message > Tous les en-têtes.
  • Yahoo Mail : ouvrez le message, cliquez sur Plus, puis sur « Afficher le message en texte brut ».

Copiez le résultat dans un éditeur de texte comme Notepad++ ou TextEdit. Un en-tête se lit mal dans une fenêtre étroite.

Un exemple d’en-tête d’email annoté

Voici un en-tête réduit à l’essentiel, avec le domaine fictif example.com et des adresses IP de la plage de documentation 203.0.113.0/24. Un message réel de 2026 compte souvent plus de lignes, notamment les champs Delivered-To et DKIM-Signature.

Return-Path: <bounce+8f2a@bounce.example.com>
Authentication-Results: mx.destinataire.example;
 spf=pass smtp.mailfrom=bounce.example.com;
 dkim=pass header.d=example.com;
 dmarc=pass header.from=example.com
Received: from smtp1.example.com (smtp1.example.com [203.0.113.25])
 by mx.destinataire.example with ESMTPS;
 Tue, 3 Nov 2026 09:14:07 +0100
Received: from app.example.com (app.example.com [203.0.113.10])
 by smtp1.example.com with ESMTP;
 Tue, 3 Nov 2026 09:14:02 +0100
From: Camille Martin <camille@example.com>
Reply-To: <support@example.com>
To: <lea@destinataire.example>
Subject: Votre facture d'octobre
Date: Tue, 3 Nov 2026 09:14:01 +0100
Message-ID: <20261103091401.8f2a@app.example.com>
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8

Le message est rédigé à 09:14:01 (champ Date) le 3 novembre 2026. Il est reçu par smtp1.example.com depuis app.example.com (203.0.113.10) à 09:14:02, puis par mx.destinataire.example à 09:14:07. Cela fait 5 secondes entre les deux serveurs et 6 depuis la rédaction. Les 3 contrôles d’authentification affichent « pass ».

Lire les champs de l’en-tête, du plus visible au plus technique

Les 4 premiers champs ci-dessous sont lisibles dans la boîte de réception. Les suivants exigent l’affichage complet.

  • From : l’adresse affichée comme expéditeur. L’expéditeur la rédige lui-même : elle seule ne prouve rien.
  • To et Date : le destinataire déclaré et l’horodatage de rédaction, posé par le client de messagerie ou le serveur de soumission.
  • Subject : la ligne d’objet. Elle fait partie de l’en-tête et s’affiche dans la boîte, comme From et Date. Sa rédaction fait l’objet d’un guide sur l’objet d’email accrocheur. Le texte d’aperçu affiché après l’objet n’en fait pas partie : voir le guide du pre-header.
  • Return-Path : l’adresse qui reçoit les rejets. Le serveur destinataire la recopie depuis l’enveloppe SMTP (la commande MAIL FROM de la RFC 5321). Pour un envoi via un prestataire d’emailing, elle pointe vers un domaine de rebonds différent du From. C’est le fonctionnement normal, détaillé dans l’article sur le return path.
  • Reply-To : l’adresse qui reçoit votre réponse. Sans ce champ, la réponse part vers le From.
  • Message-ID : l’identifiant unique du message, généré à l’envoi. Un support technique le demande pour retrouver le mail dans ses journaux.
  • MIME-Version et Content-Type : le format du contenu (text/html ou multipart/alternative) et son jeu de caractères.
  • Les champs en X- : ajoutés par des filtres. X-Spam-Status, par exemple, porte le score de SpamAssassin, détaillé dans le guide du score SpamAssassin.

La syntaxe de ces champs est fixée par la RFC 5322.

Lire les lignes Received de bas en haut

Chaque serveur SMTP qui relaie le message ajoute sa ligne Received au-dessus des précédentes. La plus basse correspond donc au premier serveur et la plus haute au dernier.

Une ligne contient le nom annoncé par l’émetteur (from), son adresse IP entre crochets, le serveur qui reçoit (by) et un horodatage. Seules les lignes ajoutées par votre propre fournisseur ou par le serveur destinataire méritent confiance : un expéditeur malveillant peut inventer les lignes les plus basses avant l’envoi.

Received décrit le trajet. Il ne contient aucun verdict SPF ni DKIM.

Lire Authentication-Results : SPF, DKIM et DMARC

Le champ Authentication-Results (norme RFC 8601) est écrit par le serveur destinataire à la réception. La ligne ajoutée par votre propre serveur échappe donc à l’expéditeur : c’est la plus fiable de l’en-tête. Méfiez-vous des lignes du même nom placées plus bas, qu’un expéditeur peut avoir inventées.

  • spf=pass (RFC 7208) : l’IP qui a transmis le message figure dans l’enregistrement DNS du domaine de l’enveloppe. Le fonctionnement est expliqué dans l’article sur SPF.
  • dkim=pass (RFC 6376) : la signature cryptographique est valide. La valeur header.d donne le domaine signataire. Voir aussi DKIM.
  • dmarc=pass : SPF ou DKIM réussit avec un domaine aligné sur celui du From (même domaine ou même domaine organisationnel en alignement relaxé, selon la RFC 7489). La mise en place figure dans le guide DMARC.

Pour SPF, les valeurs d’échec sont fail (« -all » dans l’enregistrement DNS) et softfail (« ~all »). Une évaluation SPF s’arrête à 10 requêtes DNS (RFC 7208) : au-delà, le résultat est permerror. Les erreurs temporaires (temperror) et permanentes (permerror) signalent un souci de DNS ou de configuration. Après un transfert, SPF échoue souvent car l’IP du relais n’est pas autorisée. Les lignes ARC (RFC 8617) conservent alors le verdict constaté à son arrivée par chaque intermédiaire qui scelle le message.

Repérer un phishing ou une usurpation dans l’en-tête

Comparez d’abord From, Return-Path et Reply-To. Un Return-Path différent du From est banal en emailing. Un Reply-To vers un domaine sans rapport avec l’expéditeur affiché mérite en revanche une vérification.

Passez ensuite à Authentication-Results. Un dmarc=fail sur un message qui prétend venir d’une banque ou d’un transporteur signale une usurpation (spoofing en anglais). L’absence de la ligne montre que le serveur destinataire n’a pas consigné de verdict : n’en tirez aucune conclusion favorable. Regardez enfin la ligne Received la plus basse, celle du premier serveur : l’IP d’origine d’un « service client » situé chez un hébergeur sans lien avec l’entreprise confirme le soupçon.

Diagnostiquer un retard ou un classement en spam

Vous lancez une campagne, l’outil d’emailing affiche « envoyé » et le destinataire reçoit le message 60 minutes plus tard ou dans le dossier spam. Demandez-lui l’en-tête complet.

Pour un retard, soustrayez les horodatages de deux lignes Received consécutives. Si les horloges sont synchronisées, le saut qui concentre l’écart désigne le serveur fautif : file d’attente saturée ou limitation de débit chez le destinataire. Pour un problème de délivrabilité (message classé en spam), relisez Authentication-Results : un fail sur l’un de ces trois contrôles est la première piste. Cherchez aussi un champ X-Spam-Status avec un score élevé. Depuis 2024, les consignes pour les expéditeurs de Google demandent une authentification SPF ou DKIM pour tout envoi vers un compte Gmail personnel. Au-delà de 5 000 messages par jour, SPF et DKIM sont tous deux requis, avec en plus un enregistrement DMARC. Un échec sur l’un de ces contrôles pèse lourd dans la réputation d’une campagne.

Erreurs courantes

  • Chercher SPF et DKIM dans Received. Ces verdicts se trouvent dans Authentication-Results.
  • Lire les Received de haut en bas et prendre le dernier serveur pour l’origine du message.
  • Se fier au From affiché sans contrôler dmarc.
  • Transférer le message en texte au support technique : le transfert réécrit l’en-tête. Joignez-le au format .eml.

Utiliser un analyseur d’en-têtes

Un analyseur d’en-têtes, comme celui de Google Admin Toolbox ou de MxToolbox, reçoit l’en-tête collé en texte brut. Il reconstruit le trajet saut par saut et calcule le délai de chaque relais.

Un analyseur mâche le travail sans dire si le serveur qui a écrit une ligne Received est fiable. C’est à vous de le juger.

Ajouter Captain Verify à vos sources préférées sur Google
Nicolas Forni
Author

Fondateur de Captain Verify, je travaille sur la vérification d'emails et de numéros mobiles depuis 2015. Sur ce blog, j'écris sur la délivrabilité, l'hygiène des bases de contacts, les règles des messageries et le SMS marketing. Des articles concrets, pensés pour les équipes marketing qui envoient chaque semaine.