Lire les en-têtes : d'où venait vraiment ce message ?

Module 1: Comment fonctionne l'e-mail · Temps de lecture : 11 minutes

Objectif pédagogique : Après cette leçon, vous saurez ouvrir les en-têtes d'un message, lire les lignes Received dans le bon ordre et déterminer à partir d'Authentication-Results si SPF, DKIM et DMARC étaient corrects.

Notions clés : en-têtes (headers), RFC 5322, Received, Return-Path, From, Reply-To, Message-ID, DKIM-Signature (d=, s=), Authentication-Results, ARC, en-têtes X, origine ou message original

Ce que vous ne voyez normalement pas

Votre logiciel de messagerie n'affiche que quelques lignes d'un message : expéditeur, objet, date, destinataires. En réalité, chaque message contient des dizaines d'en-têtes (headers) en haut, avant le texte. Ils sont ajoutés par le programme de l'expéditeur et par chaque serveur qui touche le message en cours de route. Ensemble, ils constituent le journal de voyage du message.

Celui qui sait lire les en-têtes peut répondre lui-même à de nombreuses questions : ce message vient-il vraiment de ma banque ? Pourquoi est-il arrivé seulement après deux heures ? Pourquoi est-il dans les spams ? Mon propre DKIM est-il correct ? De nombreux exercices de cette formation vous demandent d'examiner des en-têtes. Dans cette leçon, vous apprendrez comment faire.

Ouvrir les en-têtes

Chaque programme a son propre bouton pour cela :

Sur un téléphone, ce n'est généralement pas possible. Transférez alors le message à vous-même en pièce jointe, ou ouvrez-le dans le webmail.

Un exemple

Jean reçoit un message d'Anne. Voici à quoi ressemblent les principaux en-têtes (abrégés) :

Return-Path: <anna@example.com>
Delivered-To: jan@example.net
Received: from mx1.mailprovider.example (localhost [127.0.0.1])
        by mailbox3.mailprovider.example with LMTP; Sun, 08 Nov 2026 10:15:09 +0100
Received: from out.hosting.example (out.hosting.example [192.0.2.25])
        by mx1.mailprovider.example with ESMTPS id 4F2A1B
        for <jan@example.net>; Sun, 08 Nov 2026 10:15:07 +0100
Received: from [198.51.100.77] (helo=[10.0.0.12])
        by out.hosting.example with ESMTPSA (TLS1.3)
        (authenticated as anna@example.com); Sun, 08 Nov 2026 10:15:04 +0100
Authentication-Results: mx1.mailprovider.example;
        spf=pass smtp.mailfrom=example.com;
        dkim=pass header.d=example.com header.s=x;
        dmarc=pass header.from=example.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=x;
        h=From:To:Subject:Date:Message-ID; bh=...; b=...
From: Anna <anna@example.com>
To: Jan <jan@example.net>
Subject: Offerte
Date: Sun, 8 Nov 2026 10:15:00 +0100
Message-ID: <a1b2c3@example.com>

Lignes Received : du bas vers le haut

Chaque serveur qui transmet le message ajoute une ligne Received: en haut. La plus ancienne se trouve donc en bas, la plus récente en haut. Lisez-les de bas en haut pour suivre le trajet :

1. Ligne du bas : l'ordinateur portable d'Anne (IP 198.51.100.77, sa connexion domestique) remet le message à out.hosting.example, avec ESMTPSA (le A signifie authenticated : elle s'est connectée) et TLS 1.3. À 10:15:04.
2. Ligne du milieu : out.hosting.example (192.0.2.25) remet le message à mx1.mailprovider.example, le MX d'example.net. À 10:15:07.
3. Ligne du haut : le serveur de messagerie dépose le message en interne dans la boîte de Jean (LMTP). À 10:15:09.

Une ligne Received a toujours la forme from <qui a proposé le message> by <qui l'a reçu> with <protocole>; <heure>. Entre parenthèses, après from, figure ce que le serveur récepteur a lui-même constaté : le nom réel (PTR) et l'adresse IP réelle. Cette partie est fiable dans la mesure où vous faites confiance à ce serveur récepteur. Ce que l'expéditeur a lui-même indiqué (helo=) n'est pas vérifiable.

Deux astuces pratiques :

• Rechercher un retard : comparez les horaires. S'il y a deux heures entre deux lignes, le message est resté aussi longtemps dans une file d'attente à cet endroit. Attention aux fuseaux horaires (+0100, +0000).
• Trouver le véritable serveur d'expédition : cherchez la ligne Received la plus haute qui a été écrite par un serveur du destinataire lui-même, et regardez ce qui figure après from à cet endroit. Tout ce qui se trouve en dessous a été écrit par le côté expéditeur et peut en théorie être falsifié. Dans l'exemple, 192.0.2.25 est le serveur qui a livré chez le destinataire ; c'est sur cette base que SPF et la réputation sont évalués.

Les adresses

Une ruse bien connue des escrocs : un From qui ressemble à celui de votre banque, avec un Reply-To vers une tout autre adresse. En cas de doute, regardez toujours le domaine dans From et dans Return-Path, ainsi que les Authentication-Results.

Authentication-Results : le verdict du destinataire

Le serveur récepteur inscrit dans Authentication-Results (RFC 8601) le résultat de ses contrôles :

• spf=pass smtp.mailfrom=example.com : l'IP du serveur qui a livré le message figure dans l'enregistrement SPF du domaine indiqué dans Return-Path.
• dkim=pass header.d=example.com header.s=x : la signature DKIM du domaine example.com, avec la clé (sélecteur) x, est correcte.
• dmarc=pass header.from=example.com : le domaine dans From est aligné avec un SPF ou un DKIM réussi, donc DMARC a réussi.

Autres résultats que vous pouvez rencontrer : fail (incorrect), softfail (SPF se termine par ~all et l'IP n'y figure pas), neutral, none (aucun enregistrement), temperror (erreur DNS temporaire) et permerror (enregistrement défectueux, par exemple deux enregistrements SPF). Leur signification exacte et la manière de les corriger sont expliquées dans le module 4.

Attention : ne faites confiance qu'à l'Authentication-Results du serveur du destinataire lui-même (le nom au début, ici mx1.mailprovider.example). Un message falsifié peut inclure son propre Authentication-Results inventé. Les bons serveurs les suppriment, mais pas tous.

DKIM-Signature : la signature

L'en-tête DKIM-Signature est la signature elle-même. Deux champs vous sont souvent nécessaires :

• d= le domaine qui signe (ici example.com) ;
• s= le sélecteur, le nom de la clé (ici x).

Cela permet de retrouver la clé publique dans le DNS : x._domainkey.example.com. Dans les exercices et en cas de problème, vous devrez souvent rechercher précisément ces deux valeurs. Un message peut avoir plusieurs signatures DKIM, par exemple une de votre domaine et une du service d'envoi. Nous approfondirons ce point dans la leçon 4.3.

Vous verrez parfois aussi ARC-Seal, ARC-Message-Signature et ARC-Authentication-Results. ARC (RFC 8617) est un moyen par lequel des relais intermédiaires, comme une liste de diffusion ou un serveur de redirection, consignent quels étaient les résultats des contrôles avant qu'ils ne modifient le message. Vous n'avez pas besoin de savoir les lire pour l'instant.

En-têtes X

Les en-têtes commençant par X- ne sont pas normalisés. Les filtres antispam y inscrivent leur score, comme X-Spam-Status: No, score=1.2 ou X-Spam-Flag: YES. Cela aide à comprendre pourquoi un message a atterri dans les spams. Ils varient selon le fournisseur.

Résumé

• Les en-têtes constituent le journal de voyage d'un message. Ouvrez-les avec « afficher l'original », « source du message » ou une fonction similaire.
• Lisez les lignes Received de bas en haut. La ligne écrite par le serveur du destinataire indique quelle IP a livré le message.
• Return-Path est l'expéditeur d'enveloppe (SPF), From l'expéditeur visible (DMARC), Reply-To indique où vont les réponses.
• Authentication-Results donne le verdict sur SPF, DKIM et DMARC ; ne faites confiance qu'à celui du serveur récepteur.
• Dans DKIM-Signature figurent d= (domaine) et s= (sélecteur) ; ensemble, ils indiquent l'emplacement de la clé : s._domainkey.d.

Quiz

Exercice

Exercice Z1.5 : Faire analyser des en-têtes. Envoyez-vous un message depuis une autre adresse (par exemple de votre adresse professionnelle vers votre adresse personnelle, ou inversement), ouvrez les en-têtes et collez-les dans le formulaire. Si vous n'avez pas de seconde adresse, utilisez le fichier d'exemple kopregels-1.txt fourni avec l'exercice. Indiquez ensuite vous-même : l'adresse IP du serveur qui a livré le message chez le destinataire, le domaine dans Return-Path, le domaine et le sélecteur de la signature DKIM, et le résultat de SPF, DKIM et DMARC. Le programme analyse les mêmes en-têtes, recherche la clé DKIM en direct et compare son résultat au vôtre. Vos en-têtes ne sont pas conservés.

Pour aller plus loin

Les étapes décrites dans ces articles s'appliquent aux panneaux de WebOké ; chez d'autres fournisseurs, le fonctionnement est comparable.

• Vérifier qu'un e-mail est bien arrivé avec Email Tracking dans DirectAdmin
• Guide DirectAdmin 9.3: Suivi des e-mails : où est passé mon message ?
• Cet e-mail provient-il réellement de WebOké ? Reconnaître le phishing et utiliser le code promotionnel
• Cours DNS gratuit 4.4: DKIM : la signature sous votre mail
• RFC 5322 (structure d'un message), RFC 8601 (Authentication-Results), RFC 6376 (DKIM), RFC 8617 (ARC)