Analyse des en-têtes d'e-mail

Ce que fait l'outil

Chaque serveur de messagerie qui traite un message ajoute des lignes en tête de ses en-têtes, et le serveur qui l'accepte en dernier consigne si l'expéditeur a passé ses vérifications. Le résultat est un long bloc de texte replié, pénible à lire à l'œil nu. Cet outil analyse les en-têtes bruts d'un e-mail et les répartit en cinq parties :

• Résumé : From, To, Subject, Date, Message-ID, Return-Path et Reply-To.
• Authentification : les verdicts SPF, DKIM et DMARC (pass, fail, none, etc.) tirés des en-têtes Authentication-Results et Received-SPF, ainsi que le domaine (d=) et le sélecteur (s=) de chaque en-tête DKIM-Signature.
• Alignement : le domaine du From correspond-il au domaine d= de DKIM et au domaine du Return-Path ?
• Chaîne Received : chaque relais, numéroté du plus ancien au plus récent, avec les hôtes from et by, le protocole (par exemple ESMTPS), l'horodatage et le délai écoulé depuis le relais précédent, plus la durée totale de livraison.
• Avertissements : un Reply-To différent du From, des relais aux horodatages dans le désordre ou aux horloges décalées, et l'absence de résultats d'authentification.

L'analyse est faite par du JavaScript dans votre navigateur. Rien n'est téléversé ni envoyé nulle part, et une fois chargée, la page continue de fonctionner sans connexion au réseau. L'outil ne vérifie pas cryptographiquement les signatures DKIM et n'interroge pas le DNS ; il rapporte ce que les serveurs destinataires ont écrit dans les en-têtes.

Mode d'emploi

1. Ouvrez la source brute du message. Dans Gmail, cliquez sur l'icône Plus (les trois points) à côté de Répondre et choisissez Afficher l'original. Dans l'Outlook classique pour Windows, ouvrez le message dans sa propre fenêtre, choisissez Fichier, puis Propriétés, et copiez le contenu de la zone En-têtes Internet. Dans Outlook sur le web et le nouvel Outlook, ouvrez le menu Plus d'actions (les trois points), puis Afficher, puis « Afficher les détails du message ». Dans Apple Mail, choisissez Présentation, puis Message, puis « Source brute ».
2. Copiez le bloc d'en-têtes : tout ce qui se trouve avant la première ligne vide. Le corps du message, en dessous, n'est pas nécessaire.
3. Collez-le dans le champ de cette page.
4. Lisez le résumé et les résultats d'authentification, puis les avertissements, puis la liste des relais.

Transférer un message lui fait perdre ses en-têtes d'origine : travaillez donc sur l'exemplaire présent dans la boîte qui l'a reçu, ou demandez au destinataire de vous le transférer en pièce jointe.

Cas d'usage

• Examiner un message suspect. Une demande de paiement d'un fournisseur affiche dmarc=fail, un domaine DKIM d= sans rapport avec le domaine du From et un Reply-To différent. C'est assez pour la signaler au lieu d'y répondre.
• Trouver où un retard s'est produit. Un e-mail de réinitialisation de mot de passe arrive avec 40 minutes de retard. La plupart des relais ont mis une ou deux secondes, mais l'un d'eux l'a retenu 38 minutes : vous savez à qui poser la question de sa file d'attente.
• Tester votre propre domaine. Après avoir branché un service d'envoi de newsletters, envoyez-vous un test et vérifiez que SPF et DKIM réussissent et que d= est bien votre domaine, et non le domaine partagé du service.
• Retrouver un message dans les journaux. Donnez à votre administrateur de messagerie le Message-ID et l'heure à laquelle votre fournisseur l'a accepté ; on peut rechercher l'un et l'autre dans les journaux de livraison.
• Confirmer le chiffrement en transit. ESMTPS sur un relais signifie que cette liaison utilisait TLS ; ESMTP ou SMTP tout court, qu'elle ne l'utilisait pas.

Lire la chaîne Received, et ce qui peut être falsifié

Chaque serveur ajoute sa ligne Received au-dessus des précédentes : le relais le plus récent se trouve donc en haut. En lisant de bas en haut, on suit le message dans l'ordre chronologique ; l'outil inverse l'ordre pour vous.

Received: from mx-out.shop.example (mx-out.shop.example [198.51.100.25])
        by mx1.recipient.example with ESMTPS id 4f2ac81e
        for <you@recipient.example>; Tue, 6 Oct 2026 14:02:11 +0000
Received: from app01.internal (app01.internal [10.0.4.7])
        by mx-out.shop.example with ESMTP id 91c0d3;
        Tue, 6 Oct 2026 14:02:09 +0000

La confiance dépend de qui a écrit chaque ligne. Repérez le premier relais ajouté par votre propre fournisseur, ici celui que mx1.recipient.example a horodaté. Cette ligne et toutes celles qui suivent sont fiables, et l'adresse IP entre crochets qu'elle contient est celle de la machine qui a réellement remis le message. Tout ce qui a été enregistré avant, c'est-à-dire en dessous dans le texte brut, vient du côté de l'expéditeur et peut être inventé, y compris de fausses lignes Received qui suggèrent une autre origine. From, Reply-To, Subject, Date et Message-ID sont eux aussi définis par l'expéditeur.

Chaque horodatage vient de l'horloge du serveur concerné. Un délai de quelques secondes sous zéro signifie en général qu'une horloge est légèrement décalée. De longs écarts trahissent une file d'attente, une nouvelle tentative après un refus temporaire ou un message retenu pour analyse.

Ce que prouvent SPF, DKIM et DMARC

SPF compare l'adresse IP qui se connecte avec les serveurs qu'un domaine déclare dans le DNS. Le domaine vérifié est celui de l'expéditeur d'enveloppe, qui devient le Return-Path, et non le From visible. Un succès prouve seulement que ce serveur a le droit d'envoyer pour le domaine du Return-Path. Le transfert casse souvent SPF, parce que le serveur qui transfère ne figure pas dans la liste.

DKIM est une signature qui couvre le corps et une sélection d'en-têtes. d= nomme le domaine signataire et s= le sélecteur qui permet de trouver sa clé publique. Un succès signifie que les parties signées n'ont pas été modifiées et que le domaine d= s'en porte garant. Il ne dit rien du From, sauf si les domaines correspondent.

DMARC rattache ces deux vérifications à l'adresse que voit le lecteur : il réussit quand SPF ou DKIM réussit et que le domaine qui a réussi est aligné sur le domaine du From. Un message peut réussir SPF et DKIM pour les propres domaines d'un service d'envoi en masse alors que sa ligne From affiche le nom d'une banque : DMARC ne réussira toujours pas.

Authentication-Results: mx1.recipient.example;
       dkim=pass header.d=shop.example header.s=s2026;
       spf=pass smtp.mailfrom=bounce.shop.example;
       dmarc=pass header.from=shop.example

Avec le mode d'alignement souple, celui que DMARC applique par défaut, bounce.shop.example est aligné avec shop.example, car ils partagent le même domaine organisationnel. Vérifiez que le premier nom de cet en-tête est bien le serveur de votre fournisseur ; un expéditeur peut insérer une fausse ligne Authentication-Results, et les destinataires consciencieux suppriment ces lignes.

Enfin, ne vous arrêtez pas au nom affiché. Dans PayDesk Billing <billing@paydesk-help.example>, la plupart des logiciels de messagerie n'affichent que le nom convivial, alors que les vérifications ci-dessus portent sur l'adresse.

Questions fréquentes

L'analyse reprend ce que les serveurs destinataires ont écrit dans les en-têtes et applique des heuristiques simples. Elle ne peut pas prouver qui a envoyé un message ; quand de l'argent ou des identifiants sont en jeu, vérifiez par un canal auquel vous faites déjà confiance.