Module 3 · 3.3
Français
Lire l'expéditeur et les en-têtes
Module 3: Reconnaître le phishing · Temps de lecture : 13 minutes
Objectif pédagogique : après cette leçon, vous saurez évaluer l'expéditeur d'un e-mail à partir du nom affiché, de l'adresse From, du Reply-To, du Return-Path, des lignes Received et du résultat de SPF, DKIM et DMARC dans Authentication-Results.
Notions clés : nom affiché, From, Reply-To, Return-Path, Received, Authentication-Results, résultat SPF/DKIM/DMARC, alignement
Ce que vous voyez et ce qui est réellement indiqué
Un logiciel de messagerie ne vous montre généralement qu'une petite partie de l'expéditeur : un nom, parfois une adresse. Derrière se cache un bloc de lignes techniques que vous ne voyez pas, les en-têtes. On y trouve qui l'e-mail prétend être, où il souhaite recevoir les réponses, par quels serveurs il est passé et ce que votre serveur de messagerie a vérifié.
Vous n'avez pas besoin d'être technicien pour les lire. Il vous en faut six :
| En-tête | Ce que c'est | Qui le renseigne |
|---|---|---|
| Nom affiché | Le nom devant l'adresse, par exemple Mabanque | L'expéditeur, librement choisi |
From | L'adresse de l'expéditeur que vous voyez | L'expéditeur |
Reply-To | Où va votre réponse si vous cliquez sur Répondre | L'expéditeur |
Return-Path | L'adresse technique de l'expéditeur pour les messages d'erreur (expéditeur d'enveloppe) | Votre serveur de messagerie, sur la base de ce qu'a indiqué l'envoyeur |
Received | Une ligne par serveur ayant transmis l'e-mail | Chaque serveur sur le trajet |
Authentication-Results | Le résultat de SPF, DKIM et DMARC | Votre serveur de messagerie |
Les trois premiers, un expéditeur peut y écrire ce qu'il veut. Ce n'est qu'à partir des trois derniers qu'une vérification intervient.
Le nom affiché ne prouve rien
Le nom affiché n'est que du texte. N'importe qui peut utiliser comme nom « Service client Mabanque » ou le nom de votre dirigeant. De nombreux logiciels de messagerie, surtout sur téléphone, n'affichent que ce nom. Une astuce courante consiste à placer une adresse dans le nom :
From: "info@mabanque.example" <noreply@attaquant.example>Vous voyez info@mabanque.example, mais l'adresse réelle se trouve entre les chevrons. Touchez ou cliquez donc toujours sur le nom pour voir l'adresse complète.
L'adresse From elle-même peut aussi être falsifiée : dans le protocole de messagerie, un serveur peut indiquer n'importe quelle adresse From. Que cela passe sans finir dans le dossier indésirable dépend de SPF, DKIM et DMARC du domaine usurpé. C'est le sujet du reste de cette leçon.
Reply-To : répondre à quelqu'un d'autre
Avec Reply-To, un e-mail indique : « ne me répondez pas à moi, mais à cette adresse ». Les newsletters et les formulaires web l'utilisent normalement. Les escrocs l'utilisent pour détourner une conversation. L'e-mail provient d'une adresse réelle ou qui y ressemble, mais votre réponse, contenant les informations demandées ou la confirmation du paiement, part vers l'attaquant.
From: Fournisseur Farine <administratie@leverancier.example>
Reply-To: <administratie@leverancier-betalingen.example>En cas de demande d'argent ou d'informations, vérifiez toujours l'adresse dans la fenêtre de réponse avant de cliquer sur Envoyer.
Return-Path, Received et le trajet
Le Return-Path est l'adresse vers laquelle partent les messages d'erreur. On l'appelle aussi expéditeur d'enveloppe : l'adresse sur l'extérieur de l'enveloppe, alors que From figure sur la lettre elle-même. C'est sur ce domaine que porte la vérification SPF. Pour les newsletters et les factures issues d'un logiciel de comptabilité, le Return-Path est souvent un domaine du service d'envoi. C'est normal.
Chaque serveur qui transmet l'e-mail ajoute une ligne Received au-dessus des précédentes. Vous les lisez donc de bas en haut : la ligne du bas est le début du trajet, celle du haut la dernière étape (votre propre serveur de messagerie). Attention : seules les lignes du haut, ajoutées par votre propre fournisseur, sont dignes de confiance. En dessous, un expéditeur peut faire figurer des lignes inventées.
Authentication-Results : le résultat de la vérification
Votre propre serveur de messagerie vérifie trois choses à la réception (plus d'explications dans le module 4 et la formation DNS) :
- SPF : ce serveur était-il autorisé à envoyer des e-mails pour le domaine indiqué dans le Return-Path ?
- DKIM : la signature numérique est-elle correcte, et de quel domaine provient-elle (
d=ouheader.d=) ? - DMARC : l'une au moins de ces deux vérifications réussies appartient-elle au domaine indiqué dans From ? C'est ce qu'on appelle l'alignement. « Appartenir à » signifie : le même domaine enregistrable (leçon 3.2).
mail.mabanque.exampleest aligné avecmabanque.example(même domaine enregistrable).
Le résultat figure dans Authentication-Results. Ne faites confiance qu'à la ligne portant en premier le nom de votre propre serveur de messagerie ; un expéditeur peut lui aussi faire figurer une telle ligne.
| Résultat | Signification |
|---|---|
pass | La vérification a réussi |
fail | La vérification a échoué : non autorisé ou signature incorrecte |
softfail (SPF) | Probablement non autorisé, mais le domaine ne souhaite pas refuser strictement (~all) |
none | Il n'y avait rien à vérifier : pas d'enregistrement ou pas de signature |
La leçon la plus importante : dmarc=pass signifie seulement « cet e-mail provient réellement du domaine indiqué dans From ». Cela ne dit rien sur la question de savoir si ce domaine est digne de confiance. Un attaquant possédant son propre domaine imitant un autre peut avoir tout configuré correctement en pass.
En pratique : à quoi cela ressemble
Trois blocs d'en-têtes simulés, réduits aux lignes qui comptent. Le destinataire est Boulangerie Example ; son propre serveur de messagerie s'appelle mx1.example.com.
Exemple 1 : authentique.
Return-Path: <bounce-7731@mail.mijnbank.example>
Received: from out3.mail.mijnbank.example (out3.mail.mijnbank.example [198.51.100.40])
by mx1.example.com with ESMTPS; Sun, 08 Nov 2026 09:14:06 +0100
Authentication-Results: mx1.example.com;
spf=pass smtp.mailfrom=mail.mijnbank.example;
dkim=pass header.d=mijnbank.example header.s=sel2026;
dmarc=pass (p=reject) header.from=mijnbank.example
From: Mijnbank <info@mijnbank.example>
To: info@example.com
Subject: Je jaaroverzicht 2026 staat klaarLe domaine From est mijnbank.example et DKIM est signé par mijnbank.example, et le Return-Path relève de ce même domaine : les deux sont alignés, DMARC réussit. L'e-mail provient réellement de ce domaine. Pour le récapitulatif annuel, rendez-vous tout de même sur le site de la banque via votre propre favori.
Exemple 2 : expéditeur falsifié.
Return-Path: <x7@mailer.aanvaller.example>
Received: from mailer.aanvaller.example (mailer.aanvaller.example [203.0.113.66])
by mx1.example.com with ESMTP; Sun, 08 Nov 2026 10:02:41 +0100
Authentication-Results: mx1.example.com;
spf=pass smtp.mailfrom=mailer.aanvaller.example;
dkim=none;
dmarc=fail (p=none) header.from=leverancier.example
From: Leverancier Meel <administratie@leverancier.example>
Reply-To: <administratie@leverancier-betalingen.example>
Subject: Nieuw rekeningnummerSPF réussit, mais pour aanvaller.example, pas pour le domaine From. Il n'y a pas de signature. DMARC échoue donc. Comme le fournisseur a configuré p=none, l'e-mail a quand même été distribué. Avec p=reject, il aurait été refusé. S'y ajoute le Reply-To vers un autre domaine. Faux.
Exemple 3 : domaine imitateur avec tout en pass.
Return-Path: <service@mijnbank-veilig.example>
Received: from smtp.mijnbank-veilig.example (smtp.mijnbank-veilig.example [192.0.2.77])
by mx1.example.com with ESMTPS; Sun, 08 Nov 2026 11:20:13 +0100
Authentication-Results: mx1.example.com;
spf=pass smtp.mailfrom=mijnbank-veilig.example;
dkim=pass header.d=mijnbank-veilig.example header.s=k1;
dmarc=pass (p=reject) header.from=mijnbank-veilig.example
From: Mijnbank Klantenservice <service@mijnbank-veilig.example>
Subject: Confirmez vos informations pour la nouvelle carte de paiementTout réussit, car l'attaquant a correctement configuré son propre domaine. Mais mijnbank-veilig.example n'est pas mijnbank.example, la vraie banque. Faux.
Ouvrir vous-même les en-têtes. Dans un webmail basé sur Roundcube (comme chez WebOké), ouvrez le message et choisissez dans le menu Plus (les trois petits points) l'option Afficher la source. D'autres logiciels appellent cela par exemple « Afficher l'original » ou « Source du message ». Recherchez dans le texte Authentication-Results. Sur téléphone, ce n'est souvent pas possible ; consultez alors l'e-mail dans le webmail sur un ordinateur.
Résumé
- Le nom affiché, le From et le Reply-To sont écrits par l'expéditeur lui-même. Vérifiez toujours l'adresse réelle et le Reply-To avant de répondre.
- Le Return-Path est l'adresse d'enveloppe sur laquelle porte la vérification SPF. Les lignes Received se lisent de bas en haut ; ne faites confiance qu'à celles de votre propre fournisseur.
- Authentication-Results indique le résultat de SPF, DKIM et DMARC. DMARC vérifie si SPF ou DKIM est aligné avec le domaine From.
dmarc=failpour un domaine connu est un signal fort de falsification.dmarc=passprouve seulement que l'e-mail provient du domaine From. Vérifiez toujours que ce domaine est bien le vrai.
Quiz
Exercice
Exercice A3.3 : Lire les en-têtes. Vous recevez trois blocs d'en-têtes. Indiquez pour chaque bloc : le domaine dans Return-Path, le domaine de la signature DKIM (d=), le résultat DMARC et si l'e-mail est authentique ou faux. Le programme corrige et, en cas d'erreur, indique la ligne où se trouve la réponse.
Pour aller plus loin
Les étapes des articles WebOké s'appliquent à l'environnement de WebOké ; chez d'autres fournisseurs, le fonctionnement est comparable.
- Qu'est-ce que le DMARC ? Explication en termes simples
- Mon e-mail n'arrive pas ou atterrit dans les spams : comment le vérifier
- Vérification publique des e-mails (SPF, DMARC, MX) d'un domaine : https://www.weboke.lu/verification-e-mail, et le test e-mail d'internet.nl : https://internet.nl
- Formation DNS, leçons 4.3 SPF, 4.4 DKIM et 4.5 DMARC : https://www.weboke.lu/dns-cursus
- RFC 8601, Authentication-Results : https://www.rfc-editor.org/rfc/rfc8601