Ce qu’est vraiment le bloc d’en-tête
Tout message est constitué de deux parties séparées par une ligne vide : un bloc de lignes Name: value, et le texte que vous lisez. La RFC 5322 appelle la première partie l’en-tête, et chaque ligne qui la compose un champ, sans fixer de limite à leur nombre. Votre application de messagerie vous en montre quatre ou cinq. Un message qui a traversé trois serveurs en porte généralement entre trente et soixante.
Return-Path: <bounces+2841@mail.example.com>
Delivered-To: signup-2026@example.org
Received: by mx.example.org (Postfix) with LMTP id 4c8f21
for <signup-2026@example.org>; Fri, 5 Sep 2026 09:14:22 +0000 (UTC)
Received: from out-17.mail.example.com (out-17.mail.example.com [198.51.100.17])
by mx.example.org (Postfix) with ESMTPS id 9a31b0
for <signup-2026@example.org>; Fri, 5 Sep 2026 09:14:21 +0000 (UTC)
Authentication-Results: mx.example.org;
spf=pass smtp.mailfrom=mail.example.com;
dkim=pass header.d=example.com;
dmarc=pass header.from=example.com
From: "Example Support" <support@example.com>
To: signup-2026@example.org
Subject: Confirm your email address
Date: Fri, 5 Sep 2026 09:14:19 +0000
Message-ID: <20260905091419.9a31b0@mail.example.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_4c8f21"Lu de haut en bas, cela ressemble à du bruit de machine, et c’est en grande partie le cas. Quatre champs portent presque toute l’information, et ce sont les quatre dont traite ce guide : Received, From, Return-Path et Authentication-Results.
Où se cache l’en-tête complet
Rien de ce qui suit ne demande un outil, une extension ou un compte. Chaque client de messagerie garde le message brut derrière un élément de menu, et le mot à chercher est toujours une variante de source, original ou brut.
| Où vous lisez votre courrier | Quoi ouvrir | Ce que vous obtenez |
|---|---|---|
| Gmail, dans un navigateur | Le menu à trois points sur un message ouvert → Afficher l’original | Le bloc en entier, au-dessus d’un panneau récapitulatif qui a déjà noté le SPF, le DKIM et le DMARC à votre place |
| Outlook.com, dans un navigateur | Le menu à trois points → Affichage → Afficher la source du message | Le message complet tel qu’il est arrivé, en texte brut |
| L’application de bureau Outlook | Ouvrez le message dans sa propre fenêtre → Fichier → Propriétés | Le bloc d’en-tête seul, dans la zone en bas de la boîte de dialogue |
| Apple Mail, sur un Mac | Présentation → Message → Contenu brut | En-tête et corps ensemble, dans une fenêtre qui leur est propre |
| Thunderbird, sur n’importe quel système | Affichage → Code source du message | Le message entier, avec le bloc d’en-tête en haut |
| Proton Mail, dans un navigateur | Le menu à trois points sur un message → View headers | Le bloc d’en-tête seul, sans le corps du message |
| Yahoo Mail, dans un navigateur | Plus → View raw message | Le message entier, exactement tel qu’il a été distribué |
| Un fichier que quelqu’un vous a envoyé, ou que vous avez exporté vous-même | Ouvrez le fichier .eml dans n’importe quel éditeur de texte | Tout, parce qu’un bloc d’en-tête et un corps de message, c’est exactement ce qu’est un fichier .eml |
Ces chemins de menu sont ceux qui étaient valables au 5 septembre 2026, et ils bougent environ une fois par an, ce qui explique pourquoi la phrase ci-dessus compte plus que le tableau : quel que soit le nom de l’élément cette saison, il contiendra source, original ou brut.
La chaîne Received, lue depuis le bas
Chaque serveur qui accepte le message écrit une ligne Received: et la place tout en haut du bloc, au-dessus de tout ce qui s’y trouve déjà. Cette seule habitude produit le fait le plus utile qui soit à propos des en-têtes : le dernier saut est la première ligne que vous voyez, et le trajet du message est écrit à l’envers.
Received: by mx.example.org (Postfix) with LMTP id 4c8f21
for <signup-2026@example.org>; Fri, 5 Sep 2026 09:14:22 +0000 (UTC)
Received: from out-17.mail.example.com (out-17.mail.example.com [198.51.100.17])
by mx.example.org (Postfix) with ESMTPS id 9a31b0
for <signup-2026@example.org>; Fri, 5 Sep 2026 09:14:21 +0000 (UTC)
Received: from app-3.internal (app-3.internal [192.0.2.53])
by out-17.mail.example.com (Postfix) with ESMTP id 771c4e
for <signup-2026@example.org>; Fri, 5 Sep 2026 09:11:58 +0000 (UTC)Chaque ligne est construite à partir de la même poignée de mots, et une fois que vous savez les nommer, la chaîne cesse d’être du papier peint.
from- Le nom sous lequel la machine qui se connectait s’est présentée, suivi entre crochets de ce qu’elle était réellement — le nom obtenu par résolution DNS inverse et l’adresse IP que le serveur destinataire a vues sur la connexion. Le nom avant les crochets est une prétention. L’adresse à l’intérieur, elle, a été observée.
by- Le serveur qui a écrit cette ligne. C’est la seule partie de la ligne dont vous puissiez tenir quelqu’un pour responsable.
with- Comment le saut a été effectué :
ESMTP,ESMTPSquand la connexion était chiffrée,LMTPpour la remise finale dans une boîte. Un saut qui indiqueESMTPsansSa transporté le message en clair. for- Le destinataire de l’enveloppe à ce saut — laquelle de vos adresses a réellement reçu le message, avant qu’une règle de transfert ne réécrive quoi que ce soit. Sur un domaine catch-all ou avec une étiquette plus, c’est le champ qui nomme l’adresse qui a fuité.
- l’horodatage à la fin
- Le moment où ce serveur a fini d’accepter le message. Soustrayez l’heure d’une ligne à celle de la ligne juste au-dessus, et vous obtenez le délai à ce saut — c’est ainsi que l’on découvre où un message lent a réellement stagné, plutôt que de le deviner.
Dans l’exemple ci-dessus, le message a quitté l’application à 09:11:58 et a atteint le serveur sortant du fournisseur expéditeur deux minutes et vingt-trois secondes plus tard ; les deux sauts suivants n’ont pris qu’une seconde à eux deux. Un message qui arrive avec une heure de retard a presque toujours une ligne où se cache cette heure perdue, et ce n’est presque jamais la dernière.
Quatre champs qui prétendent tous être l’expéditeur
« Qui a envoyé ceci » a quatre réponses possibles dans un en-tête, et elles ont le droit de ne pas concorder. La plupart du temps, si elles ne concordent pas, c’est pour des raisons banales — une liste de diffusion, une plateforme marketing, une règle de transfert que vous avez configurée vous-même. Un désaccord ne prouve rien en soi. Ce qui compte, c’est de savoir lequel des quatre vous avez sous les yeux.
From:- L’adresse que l’expéditeur veut afficher, plus un nom d’affichage qui est du texte libre. Rien ne vérifie ni l’un ni l’autre. C’est le champ que votre application de messagerie place dans la liste des messages, et sur un téléphone, l’adresse est généralement entièrement cachée derrière le nom.
Return-Path:- L’expéditeur de l’enveloppe, inscrit dans l’en-tête par le serveur qui a accepté le message, d’après ce qui a réellement été dit pendant la conversation SMTP. C’est là que repart un message non distribué, et c’est l’adresse contre laquelle le SPF est vérifié — ce qui explique exactement pourquoi un message peut réussir le SPF tout en portant un
From:qui n’a rien à voir avec elle. Reply-To:- L’adresse à laquelle votre réponse sera envoyée, qui n’a pas à être celle d’où venait le message. Les expéditeurs ordinaires s’en servent pour des services d’assistance et des adresses sans réponse. C’est aussi la plus vieille ruse du métier, parce qu’un lecteur prudent vérifie l’expéditeur, juge que tout va bien, puis appuie sur Répondre.
Delivered-To:etX-Original-To:- Laquelle de vos adresses a été utilisée. Sur un domaine catch-all ou avec une étiquette plus, c’est le champ qui nomme l’adresse que vous avez réellement communiquée — celle qui identifie qui l’a laissée filer.
From: "Example Support <support@example.com>" <billing@example.net>
^-- the display name, which is free text and is all a phone shows
^-- the address, which is notLe nom d’affichage est un texte arbitraire, si bien qu’il peut contenir une adresse complète appartenant à quelqu’un d’autre. Tous les clients de messagerie du monde afficheront la partie entre guillemets et masqueront la partie entre chevrons — c’est là toute l’attaque : elle ne coûte rien à écrire, et elle fonctionne sur le seul champ qu’un lecteur est garanti de regarder.
SPF, DKIM et DMARC, en une seule ligne
Un champ ne ressemble à aucun autre dans le bloc. Authentication-Results: est écrit par le serveur qui a accepté le message — le vôtre — et tout ce qui arrive déjà sous ce même nom est supprimé ou renommé avant que vous ne le voyiez. C’est la seule ligne d’un en-tête qu’un imposteur ne peut pas écrire.
Authentication-Results: mx.example.org;
spf=pass (sender IP is 198.51.100.17) smtp.mailfrom=mail.example.com;
dkim=pass header.d=example.com header.s=s1 header.b=Qk3vR2mA;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.comTrois contrôles se trouvent dans cette ligne, et ils répondent à trois questions différentes. La quatrième colonne est celle qui mérite d’être lue deux fois.
| Contrôle | Ce que signifie un succès | Ce que signifie généralement un échec | Ce qu’aucun des deux ne prouve |
|---|---|---|---|
spf= | La machine qui a remis le message figure sur la liste que le domaine de l’expéditeur de l’enveloppe publie dans le DNS. | Soit un imposteur, soit un simple transfert : le SPF casse dès qu’un tiers relaie un message, ce qui n’est pas un défaut et arrive constamment. | Quoi que ce soit sur l’adresse dans From:. Le SPF ne la regarde jamais. |
dkim= | Une signature cryptographique du message correspond à une clé publique publiée par le domaine signataire. | Soit le message a été modifié en chemin — il suffit qu’une liste de diffusion ajoute un pied de page — soit il n’a pas été signé par le domaine dont il se réclame. | Que le domaine signataire soit celui indiqué dans From:. N’importe qui peut parfaitement signer son propre courrier. |
dmarc= | Le SPF ou le DKIM a réussi, et le domaine pour lequel il a réussi correspond au domaine indiqué dans From:. | Le domaine indiqué dans From: n’a pas autorisé ce message — ce qui est, pour un en-tête, ce qui se rapproche le plus de dire que l’expéditeur n’est pas qui il prétend être. | Que le message soit sûr, honnête ou sollicité. Un domaine enregistré ce matin peut publier un DMARC irréprochable avant midi. |
Cette dernière colonne est tout l’enjeu, et c’est là que la plupart des lectures d’en-têtes déraillent. dmarc=pass prouve que le domaine imprimé dans From: a autorisé le message. Cela ne dit absolument rien sur le fait que ce domaine mérite quoi que ce soit de votre part — et publier vous-même les enregistrements prend environ dix minutes, pour n’importe qui.
Cinq choses qu’un en-tête ne peut pas vous dire
- Où se trouve l’expéditeur. L’adresse de la machine sur laquelle quelqu’un a rédigé le message ne figure généralement pas du tout dans le bloc. Les grands fournisseurs de webmail ont cessé de la publier il y a des années, et ce qui reste, c’est leur propre serveur sortant, qui vit dans un centre de données et ne vous donne que le nom d’un hébergeur.
- Qui est l’expéditeur. Un domaine n’est pas une personne.
dmarc=passpour un domaine acheté il y a quarante minutes est un succès parfaitement authentique. - Si quoi que ce soit de tout cela est vrai. L’authentification concerne l’enveloppe, jamais l’affirmation qu’elle contient. Une facture peut être correctement signée, correctement alignée, et entièrement inventée.
- Si quelqu’un l’a lu. Rien dans un en-tête ne l’enregistre. Ce qui essaie de le faire, c’est un pixel de suivi dans le corps du message, un mécanisme différent avec des parades différentes.
- Quand il a été écrit.
Date:provient de la machine de l’expéditeur et de son horloge à lui. Un message daté de trois heures dans le futur est bien plus souvent un ordinateur mal configuré qu’autre chose d’intéressant ; les horodatages auxquels vous pouvez vous fier sont ceux des lignesReceivedqu’a écrites votre fournisseur.
Et toute une famille de champs ne prouve rien par construction. Tout ce qui commence par X- est une extension privée inventée par celui qui l’a écrite, et un expéditeur peut y écrire ce qu’il veut : X-Spam-Status: No dans un message signifie que le message affirme ne pas être un spam.
Quand le message a atterri sur une adresse jetable
Soyons clairs sur ce que ce service restitue et ce qu’il ne restitue pas. Un message lu ici arrive analysé plutôt que brut : l’expéditeur, l’objet, la date, le texte, le HTML et la liste des pièces jointes — les champs qu’un script est venu chercher — et non le bloc d’en-tête. La lecture décrite plus haut, c’est quelque chose que vous faites dans la boîte qui conserve votre vrai courrier.
{
"id": "m_7Kq2fV3xTn",
"from": "support@example.com",
"from_name": "Example Support",
"to": "signup-2026@grabmail.io",
"subject": "Confirm your email address",
"date": "2026-09-05T09:14:22+00:00",
"expires_at": "2026-09-10T09:14:22+00:00",
"text": "Confirm your address: <https://example.com/confirm/9a31b0>",
"text_derived": true,
"html": "<!doctype html><html>…",
"attachments": []
}Ce qu’une adresse jetable vous donne à la place, c’est un signal qu’aucun champ d’en-tête ne peut égaler, et il fonctionne avant même que vous ayez lu une seule ligne : vous avez donné cette adresse à un seul tiers. Un message qui y arrive en prétendant venir de quelqu’un d’autre a soit été transféré par ce tiers, soit envoyé par celui à qui il l’a transmis. Il n’y a pas de troisième explication, et il n’y a rien à vérifier.
C’est le même argument que fait valoir une étiquette plus, moins la partie où l’étiquette peut être coupée en une ligne de code — ici, l’adresse elle-même est différente, donc il n’y a rien à retirer. C’est aussi pourquoi un catch-all sur un domaine qui vous appartient en est la version la plus forte : une adresse par inscription, conservée aussi longtemps que vous gardez le domaine, et Delivered-To: dans votre propre boîte nomme celle qui a fuité.
Le contrôle qu’il vous reste à faire
Regardez où mène le lien, pas ce qu’il affiche. Le champ text est soit la partie texte brut de l’expéditeur lui-même, soit un rendu du HTML — text_derived indique lequel des deux — et ce rendu conserve chaque cible de lien entre chevrons. L’adresse vers laquelle un bouton vous aurait mené se trouve donc dans la réponse, bien en vue, sans charger la page, les images ou le pixel.
Confirm your address: <https://example.com/confirm/9a31b0>
Not you? Ignore this message. <https://example.com/help>La version en soixante secondes
- Ouvrez la source. Afficher l’original, Afficher la source du message ou Contenu brut, selon le client dans lequel vous êtes.
- Trouvez d’abord
Authentication-Results. Une seule ligne, écrite par votre propre fournisseur, et la seule que personne d’autre n’aurait pu forger.dmarc=pass, et le domaine dansFrom:a vraiment autorisé le message ;dmarc=fail, et il ne l’a pas fait. - Comparez
From:avecReturn-Path:etReply-To:. Ils ne concordent pas pour des raisons banales toute la journée. Ils ne concordent pas non plus, parfois, pour la raison intéressante. - Lisez les lignes
Receiveddu bas vers le haut, et cessez d’y croire dès la première machine qui n’est pas celle de votre fournisseur. - Regardez ensuite où pointent les liens, car c’est cette partie qui décide de ce qui vous arrive réellement.
Tout ce qui précède répond à une seule question, étroite : le domaine dans From: a-t-il autorisé ce message ? C’est une question plus modeste que « est-ce sûr », mais elle vaut la peine d’être posée quand même — c’est la seule à laquelle un en-tête puisse jamais répondre.
Questions
Comment voir l’en-tête complet dans Gmail ?
Ouvrez le message, puis le menu à trois points en haut à droite, puis Afficher l’original. Gmail ouvre un nouvel onglet avec le message brut et, au-dessus, un petit panneau qui a déjà noté le SPF, le DKIM et le DMARC — le verdict le plus rapide qui soit, et il est gratuit.
Un en-tête d’e-mail peut-il être falsifié ?
La majeure partie, oui. From:, Reply-To:, Date:, l’objet et un nombre quelconque de lignes Received: inventées sont tous tapés par l’expéditeur. Ce qui ne peut pas être falsifié, c’est ce que votre propre fournisseur a écrit à l’arrivée du message : la ligne Received du haut et Authentication-Results. Lisez ces deux-là et traitez le reste comme un témoignage.
Puis-je trouver l’adresse IP de l’expéditeur dans un en-tête ?
Généralement pas celle que vous imaginez. Le courrier envoyé via un grand service de webmail porte l’adresse du serveur sortant de ce service, pas celle de la machine sur laquelle il a été rédigé ; les fournisseurs ont cessé de publier cette dernière il y a des années, pour la raison évidente. Le courrier envoyé par une application ou un petit serveur la montre souvent encore, entre crochets, dans la ligne Received du bas — qui est aussi la ligne la plus facile à forger dans tout le bloc.
Quelle est la différence entre <code>From:</code> et <code>Return-Path:</code> ?
From: est ce que l’expéditeur veut afficher, et rien ne le vérifie. Return-Path: est l’expéditeur d’enveloppe réellement utilisé par les serveurs, inscrit dans l’en-tête par la machine qui a accepté le message, et c’est là que repartent les messages non distribués. Le SPF est vérifié contre Return-Path:, jamais contre From:, ce qui explique pourquoi spf=pass à lui seul dit moins qu’il n’y paraît. Aligner les deux est tout le travail du DMARC.
L’en-tête indique <code>dmarc=fail</code>. Le message est-il un faux ?
Pas nécessairement. Le transfert casse le SPF par conception, et une liste de diffusion qui ajoute un pied de page casse aussi le DKIM, si bien qu’un courrier relayé par une liste, une université ou une règle « tout renvoyer vers mon autre adresse » échoue couramment tout en étant parfaitement authentique. Ce que l’échec signifie réellement, c’est que rien dans le message ne prouve que le domaine dans From: s’en porte garant — donc tout ce que le message vous demande de faire mérite d’être vérifié par une seconde voie.
À quoi sert <code>Message-ID</code> ?
C’est le nom du message — unique, attribué par le serveur expéditeur, et la chaîne vers laquelle pointent In-Reply-To et References pour construire un fil de discussion. Son utilité pratique, c’est qu’un service d’assistance ou un postmaster peut le retrouver dans ses journaux : citer le Message-ID fait toute la différence entre « un e-mail n’est pas arrivé hier » et une question à laquelle quelqu’un peut réellement répondre.
Puis-je lire les en-têtes d’un courrier envoyé ici à une adresse temporaire ?
Non — un message lu ici revient analysé, sous forme d’expéditeur, d’objet, de date, de texte, de HTML et de liste de pièces jointes, et le bloc d’en-tête brut ne fait pas partie de ces champs. En contrepartie, une adresse à usage unique est sa propre preuve : elle n’a été donnée qu’à un seul tiers, donc un courrier qui en arrive prétendant venir de quelqu’un d’autre désigne le tiers qui l’a laissé sortir, sans aucune signature à vérifier. Les messages sont de toute façon supprimés après 5 jours.
