Analyseur d'en-têtes d'e-mail

Par La rédaction de Mon-Adresse-IP.net·Publié le 21 août 2026·

Collez les en-têtes bruts d'un message : l'outil les déplie, remet la chaîne Received dans l'ordre chronologique, situe les adresses IP traversées et détaille les verdicts SPF, DKIM et DMARC. Rien n'est enregistré.

L'analyseur

En-têtes bruts du message Return-Path: <lettre@example.com> Received: from mx-in-03.mail.example.org (mx-in-03.mail.example.org [198.51.100.42]) by stockage-07.mail.example.org (Postfix) with ESMTPS id 4Zk8Qv2m1Nz3Hb for <marie.durand@example.org>; Tue, 03 Feb 2026 18:41:27 +0100 (CET) Received: from smtp-out-12.example.com (smtp-out-12.example.com [203.0.113.77]) by mx-in-03.mail.example.org (Postfix) with ESMTPS id 4Zk8Qt5r0Kz2Gd for <marie.durand@example.org>; Tue, 03 Feb 2026 18:41:24 +0100 (CET) Received: from relais-interne.example.com (unknown [192.0.2.19]) by smtp-out-12.example.com (Postfix) with ESMTP id 6C41E1A0B7; Tue, 03 Feb 2026 18:41:09 +0100 (CET) Authentication-Results: mx-in-03.mail.example.org; dkim=pass header.i=@example.com header.s=selecteur1; spf=pass smtp.mailfrom=lettre@example.com; dmarc=pass (p=QUARANTINE sp=NONE) header.from=example.com Received-SPF: pass (mx-in-03.mail.example.org: domain of lettre@example.com designates 203.0.113.77 as permitted sender) client-ip=203.0.113.77; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selecteur1; t=1770140469; h=From:To:Subject:Date:Message-ID; b=Qk9zR1pPdEhuTmxXcmVFeEFtcGxlU2lnbmF0dXJlRmljdGl2ZQ== From: "Lettre Example" <lettre@example.com> To: Marie Durand <marie.durand@example.org> Reply-To: contact@example.com Subject: =?UTF-8?Q?Votre_r=C3=A9capitulatif_mensuel?= Date: Tue, 03 Feb 2026 18:41:05 +0100 Message-ID: <20260203174105.6C41E1A0B7@smtp-out-12.example.com> X-Mailer: ExampleMailer 4.2 List-Unsubscribe: <https://example.com/desabonnement?id=abc123>, <mailto:stop@example.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2841_1927364"

Analyser les en-têtes Analyser un exemple Effacer

64 Ko traités au maximum. Aucune inscription, aucun cookie, aucun envoi de fichier.

En-têtes principaux

17 en-têtes ont été lus et dépliés, puis l'analyse s'est arrêtée à la première ligne vide : le corps du message a été ignoré.

From	"Lettre Example" <lettre@example.com> , Expéditeur affiché
To	Marie Durand <marie.durand@example.org> , Destinataire
Reply-To	contact@example.com , Adresse de réponse
Return-Path	<lettre@example.com> , Chemin de retour (enveloppe)
Subject	Votre récapitulatif mensuel Encodage MIME d'origine : =?UTF-8?Q?Votre_r=C3=A9capitulatif_mensuel?= , Objet
Date	Tue, 03 Feb 2026 18:41:05 +0100 , Date déclarée par l'expéditeur
Message-ID	<20260203174105.6C41E1A0B7@smtp-out-12.example.com> , Identifiant du message
X-Mailer	ExampleMailer 4.2 , Logiciel expéditeur
Content-Type	multipart/alternative; boundary="----=_Part_2841_1927364" , Type de contenu
List-Unsubscribe	<https://example.com/desabonnement?id=abc123>, <mailto:stop@example.com> , Lien de désabonnement

Chaîne de transmission (Received)

Les serveurs empilent leurs en-têtes Received du plus récent au plus ancien. Ils sont ici remis dans l'ordre chronologique : l'étape 1 est la plus ancienne trace disponible, la dernière correspond au serveur qui a déposé le message dans la boîte du destinataire.

1. relais-interne.example.com → smtp-out-12.example.com

   Serveur émetteur

   relais-interne.example.com

   Serveur récepteur

   smtp-out-12.example.com

   Protocole

   ESMTP

   Identifiant de file

   6C41E1A0B7

   Horodatage

   Tue, 03 Feb 2026 18:41:09 +0100 (CET)
   soit 03/02/2026 17:41:09 UTC

   Adresses IP

   192.0.2.19 (documentation)

2. smtp-out-12.example.com → mx-in-03.mail.example.org

   Serveur émetteur

   smtp-out-12.example.com

   Serveur récepteur

   mx-in-03.mail.example.org

   Protocole

   ESMTPS

   Identifiant de file

   4Zk8Qt5r0Kz2Gd

   Horodatage

   Tue, 03 Feb 2026 18:41:24 +0100 (CET)
   soit 03/02/2026 17:41:24 UTC

   Adresses IP

   203.0.113.77 (documentation)

   Délai

   + 15 s depuis l'étape précédente

3. mx-in-03.mail.example.org → stockage-07.mail.example.org

   Serveur émetteur

   mx-in-03.mail.example.org

   Serveur récepteur

   stockage-07.mail.example.org

   Protocole

   ESMTPS

   Identifiant de file

   4Zk8Qv2m1Nz3Hb

   Horodatage

   Tue, 03 Feb 2026 18:41:27 +0100 (CET)
   soit 03/02/2026 17:41:27 UTC

   Adresses IP

   198.51.100.42 (documentation)

   Délai

   + 3 s depuis l'étape précédente

Un délai de plusieurs minutes entre deux étapes signale une mise en file d'attente : gestion antispam, réessai après un rejet temporaire (4xx), ou saturation du serveur. Un délai « en arrière » n'a rien d'anormal : il traduit simplement deux horloges mal synchronisées, ou deux fuseaux horaires mal déclarés.

Adresses IP rencontrées

Authentification du message

SPF	pass d'après Authentication-Results Le serveur qui a remis le message est bien autorisé par l'enregistrement SPF du domaine utilisé dans l'enveloppe SMTP (MAIL FROM). Ce domaine n'est pas forcément celui affiché dans le champ From.
DKIM	pass d'après Authentication-Results Une signature cryptographique a été vérifiée avec succès : les champs signés et le corps du message n'ont pas été modifiés entre la signature et la réception, et la clé publique publiée dans le DNS du domaine signataire correspond.
DMARC	pass d'après Authentication-Results La politique DMARC du domaine affiché dans le champ From est satisfaite : SPF ou DKIM a réussi et le domaine concerné est aligné avec celui du From. C'est le seul des trois résultats qui porte sur l'adresse que voit le destinataire.

Où trouver les en-têtes d'un e-mail

Aucun client de messagerie n'affiche les en-têtes par défaut : il faut demander la source brute du message. La manipulation prend quelques secondes et diffère selon le logiciel.

1. Ouvrez le message concerné Ne le transférez pas : un transfert reconstruit un nouveau message et détruit la chaîne d'origine. Si vous devez le transmettre à un service de sécurité, utilisez la fonction « transférer en pièce jointe ».
2. Affichez la source Suivez le chemin indiqué ci-dessus pour votre client.
3. Sélectionnez le bloc d'en-têtes Il commence par la première ligne du type Nom: valeur et se termine à la première ligne totalement vide. Tout ce qui suit est le corps du message : inutile de le copier.
4. Conservez les retours à la ligne Les lignes indentées prolongent la ligne précédente. Un copier-coller qui les écrase rend la chaîne Received illisible.

Comment lire une chaîne Received

Chaque serveur qui accepte un message y ajoute un en-tête Received en tête de pile, avant tous les autres. La conséquence est contre-intuitive : dans le fichier, le premier Received que vous lisez est le dernier ajouté, celui du serveur qui vient de vous livrer le message. Pour suivre le trajet dans le sens du voyage, il faut lire du bas vers le haut : ce que l'outil fait pour vous.

Un en-tête Received bien formé suit toujours la même grammaire, définie par la RFC 5321 :

Received: from nom annoncé par l'expéditeur (nom inverse résolu [IP réelle])
        by serveur récepteur with protocole id identifiant de file
        for <destinataire>; date

La distinction la plus importante se joue dans la clause from. Le nom qui suit immédiatement from est déclaré par la machine qui se connecte lors de la commande HELO ou EHLO : n'importe qui peut y écrire ce qu'il veut. Ce qui figure entre parenthèses, en revanche, a été constaté par le serveur récepteur : le nom obtenu par résolution inverse et, entre crochets, l'adresse IP de la connexion TCP. Cette adresse-là ne se falsifie pas au niveau applicatif. Quand les deux ne concordent pas, beaucoup de serveurs notent unknown entre parenthèses.

La frontière de confiance

Un expéditeur malveillant peut parfaitement inclure de faux en-têtes Received dans le message qu'il envoie : ils apparaîtront tout en bas de la pile et raconteront une histoire inventée, avec des serveurs et des dates qui n'ont jamais existé. C'est une technique classique pour faire croire qu'un message provient d'une banque ou d'une administration.

La règle de lecture est donc la suivante : partez du haut. Les en-têtes ajoutés par votre propre fournisseur de messagerie sont fiables, puisque c'est lui qui les a écrits. Descendez tant que vous reconnaissez des serveurs appartenant à votre fournisseur, puis à des opérateurs légitimes. La première ligne qui échappe à ce périmètre marque la frontière : tout ce qui se trouve en dessous n'est qu'une déclaration de l'expéditeur, à traiter comme telle. En pratique, sur un message reçu chez un grand webmail, seuls les deux ou trois Received du haut ont une valeur probante.

Les incohérences de dates constituent un second indice. Des horodatages qui reculent de quelques secondes traduisent une simple dérive d'horloge entre serveurs. Un écart de plusieurs heures, ou une date antérieure à celle du champ Date déclaré, mérite en revanche l'attention. Pour comprendre pourquoi les serveurs se reconnaissent par leur nom plutôt que par leur adresse, notre guide du DNS détaille le rôle des résolutions directe et inverse.

SPF, DKIM et DMARC en trois minutes

Ces trois mécanismes sont souvent présentés comme un tout ; ils répondent en réalité à trois questions distinctes, et c'est leur combinaison qui fait la protection.

SPF	Le serveur qui présente ce message est-il autorisé à envoyer pour le domaine déclaré dans l'enveloppe SMTP (MAIL FROM) ? La réponse est publiée dans un enregistrement DNS de type TXT du domaine.
DKIM	Le contenu signé a-t-il été modifié depuis l'envoi ? Le serveur expéditeur signe certains en-têtes et le corps avec une clé privée ; le destinataire vérifie avec la clé publique publiée sous sélecteur._domainkey.domaine.
DMARC	Le domaine affiché dans le champ From, le seul que voit l'utilisateur, est-il couvert par un SPF ou un DKIM réussi portant sur ce même domaine ? Et que faire si ce n'est pas le cas ?

Le point que tout le monde manque tient en une phrase : SPF ne regarde jamais l'adresse affichée dans votre client de messagerie. Il vérifie l'adresse de l'enveloppe, invisible pour l'utilisateur, celle qui apparaît dans Return-Path. Rien n'interdit à un attaquant d'envoyer depuis un domaine qu'il contrôle, avec un SPF impeccable pour ce domaine, tout en affichant service-client@votre-banque.fr dans le champ From. Résultat : SPF « pass », et pourtant usurpation.

C'est exactement le trou que comble DMARC avec la notion d'alignement. Pour qu'un message passe DMARC, il faut qu'au moins un des deux mécanismes réussisse et que le domaine qu'il a validé corresponde à celui du champ From (identique, ou sous-domaine du même domaine organisationnel selon le mode d'alignement choisi). Le propriétaire du domaine publie en plus une politique : p=none (surveiller seulement), p=quarantine (classer en indésirables) ou p=reject (refuser à la porte). La syntaxe précise de ces enregistrements figure dans notre référence des types d'enregistrements DNS, et notre guide adresse IP et e-mails replace ces mécanismes dans le fonctionnement général de la messagerie.

Deux limites à garder en tête. D'abord, ces mécanismes authentifient un domaine, pas une intention : un domaine d'escroquerie enregistré le jour même peut publier SPF, DKIM et DMARC en règle. Ensuite, ils cassent facilement de façon légitime : une liste de diffusion qui ajoute un pied de page invalide la signature DKIM, une redirection automatique de boîte fait échouer SPF. Le mécanisme ARC a précisément été conçu pour que ces intermédiaires puissent attester les vérifications faites en amont. Enfin, si vos propres messages partent en indésirables, la cause se trouve souvent du côté de la réputation de votre adresse d'émission : notre page mon IP est bloquée explique le fonctionnement des listes de blocage.

Ce que l'adresse IP d'origine permet

Retrouver l'adresse IP la plus ancienne de la chaîne est le réflexe de tous ceux qui découvrent les en-têtes. Il faut immédiatement en désamorcer l'attente : cette adresse désigne un réseau, pas une personne.

Dans l'immense majorité des cas, elle appartient au serveur d'envoi du fournisseur de messagerie de l'expéditeur, pas à sa machine. Les grands webmails ont cessé d'inscrire l'adresse IP de leurs utilisateurs dans les en-têtes des messages envoyés depuis leur interface web : vous obtiendrez donc un centre de données, souvent situé dans un pays qui n'a aucun rapport avec la localisation réelle de l'expéditeur. Une adresse IP repérée dans les en-têtes d'un message parti de Lyon peut parfaitement pointer vers l'Irlande ou les Pays-Bas.

Même lorsque l'adresse correspond bien à une connexion grand public, elle n'identifie qu'un point de raccordement : une box, partagée par tout un foyer, et parfois par plusieurs abonnés lorsque l'opérateur utilise le CGNAT. Sa localisation est approximative par construction : notre guide de la géolocalisation par IP détaille pourquoi la ville affichée est souvent celle du point de sortie de l'opérateur. Seul le fournisseur d'accès peut relier une adresse à un abonné, à une date et une heure précises, et il ne le fait que sur réquisition d'une autorité judiciaire : c'est ce qu'expliquent nos pages sur l'adresse IP et le RGPD et sur ce que votre FAI conserve.

Concrètement, l'adresse d'origine sert donc à corroborer ou infirmer une histoire : un message qui se présente comme émanant d'une administration française mais dont le premier serveur appartient à un hébergeur de VPS bon marché à l'autre bout du monde vous renseigne utilement. Elle ne sert pas à désigner un coupable. Si vous êtes victime, le bon réflexe est de signaler le message et de transmettre les en-têtes complets aux services compétents, pas de mener l'enquête vous-même.

Reconnaître une tentative d’hameçonnage

Les en-têtes ne remplacent pas le bon sens, mais ils objectivent une intuition. Voici les signaux qui, cumulés, doivent déclencher la méfiance : l'objectif étant toujours de vous protéger, jamais d'apprendre à fabriquer un tel message.

• Reply-To différent du From : le message affiche une adresse connue, mais votre réponse partirait ailleurs. Légitime pour une lettre d'information, très suspect sur un courrier qui vous demande de répondre avec des informations.
• Return-Path incohérent : l'enveloppe désigne un domaine sans rapport avec la marque affichée. C'est le domaine que SPF a réellement validé.
• Domaine proche mais distinct : substitution de caractères, tiret ajouté, extension changée, ou nom de marque placé en sous-domaine d'un autre domaine. Le domaine qui compte est toujours celui qui précède immédiatement l'extension.
• Aucune authentification : une grande organisation qui envoie des millions de messages publie forcément SPF, DKIM et DMARC. Trois résultats none sur un courrier prétendument bancaire sont anormaux.
• Serveur d'origine sans rapport : le premier serveur de la chaîne appartient à un hébergeur mutualisé ou à un réseau résidentiel étranger, alors que le message se réclame d'une institution.
• Date déclarée incohérente : le champ Date précède de plusieurs jours le premier Received, signe d'un message forgé ou rejoué.
• En-têtes techniques absents : ni Message-ID, ni MIME-Version, ni List-Unsubscribe sur une prétendue lettre d'information commerciale.

Aucun de ces signaux ne constitue une preuve à lui seul, et un message parfaitement authentifié peut être malveillant. Inversement, une réexpédition automatique ou une passerelle d'entreprise déclenchent régulièrement plusieurs de ces alertes sur des courriers légitimes. La bonne pratique reste invariable : ne cliquez pas sur le lien, tapez vous-même l'adresse du site concerné, et vérifiez directement dans votre espace client. En France, un message frauduleux peut être signalé sur la plateforme Signal Spam ou via le service Phishing Initiative ; les SMS frauduleux se signalent au 33700. Le vocabulaire employé dans cette page est repris et défini dans notre glossaire du réseau, et les en-têtes que votre navigateur envoie de son côté sont détaillés par l'outil mes en-têtes HTTP.

Questions fréquentes