Aller au contenu
DMARC
Diagnostic d’un message reçu

Analyseur d’en-têtes d’e-mail gratuit

Ce qu’un message dit vraiment de son expéditeur.

Un message affiche un expéditeur ; ses en-têtes disent qui l’a réellement remis. Cet analyseur lit les verdicts SPF, DKIM et DMARC du serveur de réception, recalcule l’alignement et reconstitue le trajet saut par saut.

  • Gratuit
  • Sans compte
  • Résultat immédiat
  • Analyse dans le navigateur

Analyser un message

L’analyse a lieu dans le navigateur : les en-têtes ne sont envoyés à aucun serveur.

Gmail : « Afficher l’original ». Outlook : « Propriétés » puis « En-têtes Internet ».

Comment ça marche

  1. 1

    Copiez le message d’origine

    Dans Gmail, « Afficher l’original » ; dans Outlook, « Propriétés » puis « En-têtes Internet ». Le bloc d’en-têtes suffit.

  2. 2

    Collez-le dans le champ

    L’analyse a lieu dans le navigateur : les en-têtes ne sont envoyés à aucun serveur, et le corps du message n’est jamais lu.

  3. 3

    Verdict immédiat

    Les verdicts SPF, DKIM et DMARC s’affichent avec leur alignement, la chaîne ARC et le trajet des serveurs traversés.

Pourquoi c’est important

Un message d’hameçonnage affiche un expéditeur crédible ; seuls les en-têtes ajoutés par le serveur de réception disent d’où il vient vraiment. À l’inverse, un message légitime parti en indésirable laisse la trace de sa cause dans ces mêmes en-têtes : signature absente, alignement rompu par un routeur tiers, ou relais qui casse SPF.

Usurpation invisible

Un champ « From: » se falsifie en une ligne. Sans lecture des verdicts d’authentification, rien ne distingue le vrai du faux à l’écran.

Alignement rompu

SPF peut être valide pour l’enveloppe d’un routeur tiers sans couvrir le domaine affiché — DMARC échoue alors malgré un « pass ».

Cause du classement en indésirable

Sans ses en-têtes, un message filtré ne livre pas sa cause : signature manquante, relais intermédiaire ou retard de remise.

Ce que contiennent les en-têtes

Un message transporte des dizaines de champs techniques que les logiciels de messagerie masquent. « Authentication-Results » (RFC 8601) porte les verdicts SPF, DKIM et DMARC rendus par le serveur qui a accepté le message. « DKIM-Signature » nomme le domaine signataire et son sélecteur. Les champs « Received: », ajoutés en tête par chaque relais, retracent le trajet à l’envers. « ARC-Seal » (RFC 8617) atteste des verdicts d’origine quand un relais a modifié le message en route.

À retenir — Un « Authentication-Results » s’écrit librement par l’expéditeur : seul celui apposé par le serveur de réception fait foi. L’analyseur affiche son authserv-id pour que la question reste posée.

Comment fonctionne l’analyseur

L’analyse est un calcul de texte exécuté dans le navigateur : découpage des champs, dépliage des lignes de continuation, lecture des verdicts, puis recalcul de l’alignement entre le domaine signataire, le domaine de l’enveloppe et celui du champ « From: ». Aucune requête réseau, aucune conservation. En contrepartie, aucune signature n’est recalculée : le corps du message n’étant pas fourni, l’analyseur lit les verdicts existants au lieu de les refaire.

Questions fréquentes

Les en-têtes collés sont-ils envoyés quelque part ?
Non. L’analyse est réalisée par le navigateur, sur la page elle-même. Rien n’est transmis à un serveur, rien n’est conservé, et fermer l’onglet efface tout.
L’analyseur vérifie-t-il vraiment la signature DKIM ?
Non, et c’est une limite volontaire : vérifier une signature exige le corps complet du message. L’analyseur lit le verdict rendu par le serveur de réception, qui, lui, disposait du message entier.
Pourquoi DMARC échoue-t-il alors que SPF passe ?
Parce que SPF valide le domaine de l’enveloppe, pas celui affiché dans le champ « From: ». Quand un routeur tiers expédie avec sa propre enveloppe, SPF passe sans être aligné — DMARC exige alors une signature DKIM du domaine affiché.

Lire ce qu’un message ne montre pas

Analyser un message

Gratuit et immédiat — l’analyse reste dans le navigateur, aucun compte requis.