Comment lire les en-têtes d'un e-mail

Authentication-Results : le verdict, et son piège

C'est l'en-tête décisif, normalisé par la RFC 8601. Le serveur qui accepte le message y consigne le résultat des vérifications qu'il vient d'effectuer :

Authentication-Results: mx.exemple.fr;
       dkim=pass header.d=exemple.fr header.s=s2026;
       spf=pass smtp.mailfrom=bounces.routeur.example;
       dmarc=pass header.from=exemple.fr

Trois méthodes, trois résultats, et des propriétés attachées à chacune. header.d= nomme le domaine qui a signé en DKIM ; header.s= donne le sélecteur qui désigne la clé publique ; smtp.mailfrom= donne le domaine d'enveloppe validé par SPF.

Et voici le piège, celui que la plupart des lectures manquent : cet en-tête s'écrit librement. Rien n'empêche un attaquant d'insérer dans le message qu'il envoie une ligne Authentication-Results proclamant dkim=pass pour la banque qu'il imite. Seul l'en-tête apposé par le serveur de réception du destinataire fait foi — les autres sont du texte fourni par l'expéditeur.

Deux repères permettent de trancher. D'abord le premier segment, l'authserv-id : il nomme le serveur qui prétend avoir fait la vérification, et il doit correspondre au domaine de réception réel. Ensuite l'ordre : chaque relais ajoute son en-tête en tête de liste, donc le plus haut dans le message est le plus récent, celui du bord final. Un message qui porte trois Authentication-Results a franchi trois frontières — ou en transporte deux qui ont été écrits ailleurs.

L'alignement, l'étape que le verdict ne montre pas

Un spf=pass isolé ne dit presque rien. SPF valide le domaine de l'enveloppe, pas celui que le destinataire voit. Quand une lettre d'information part par un routeur tiers, l'enveloppe appartient au routeur et SPF passe légitimement — sans couvrir le domaine affiché dans From:. DMARC exige davantage : que la méthode qui passe soit alignée avec le domaine du From:.

La lecture consiste donc à comparer deux chaînes. Le domaine de header.d= couvre-t-il celui de From: ? Le domaine de smtp.mailfrom= le couvre-t-il ? Il suffit qu'une des deux réponde oui pour que DMARC soit satisfait. Dans l'exemple ci-dessus, SPF passe sans être aligné, DKIM passe en étant aligné, et le message est donc conforme. Ce cas — un SPF valide qui n'empêche pas DMARC d'échouer — est la source d'incompréhension la plus fréquente du protocole, et il se lit en trois secondes dans les en-têtes.

DKIM-Signature : ce que la signature couvre

L'en-tête de signature est présent dans le message d'origine, indépendamment de tout verdict :

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=exemple.fr; s=s2026; h=from:to:subject:date;
        bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=Xk9dQ2mF...

d= et s= désignent la clé publique à interroger en DNS. h= énumère les champs couverts par la signature — et cette liste mérite l'attention, car ce qui n'y figure pas peut être modifié sans invalider la signature. bh= est l'empreinte du corps, b= la signature elle-même.

Un point pratique en découle : la présence d'un DKIM-Signature ne prouve rien à elle seule. Vérifier une signature exige de recalculer ces empreintes, donc de disposer du corps complet du message et d'interroger le DNS. C'est le travail du serveur de réception, et la marche à suivre pour contrôler soi-même une signature DKIM le détaille. Une lecture d'en-têtes se contente d'observer que la signature existe, quel domaine elle revendique, et ce que le serveur en a conclu.

Received: : le trajet, à lire à l'envers

Chaque serveur qui prend en charge le message ajoute un champ Received: en tête de la pile. La conséquence est contre-intuitive : le premier Received: du message est le dernier saut chronologique, et le trajet se lit du bas vers le haut.

Received: from relais.exemple.fr (relais.exemple.fr [198.51.100.24])
        by mx.destinataire.example with ESMTPS id 4Wx1Yz;
        Wed, 5 Aug 2026 09:14:50 -0700 (PDT)

Chaque ligne donne l'hôte annoncé (from), l'hôte qui reçoit (by), le protocole (with), souvent l'adresse IP entre crochets, et l'horodatage. Trois lectures en découlent.

La première est l'origine réelle : l'adresse IP du saut le plus ancien, celle du serveur qui a réellement émis. Elle résiste à la falsification du From:, et c'est elle qu'une plainte auprès d'un hébergeur doit citer.

La deuxième est le délai. Comparer les horodatages de deux sauts consécutifs donne le temps passé à chaque étape. Quelques secondes sont normales. Plusieurs minutes signalent une file d'attente, un greylisting, ou un filtrage intermédiaire — et expliquent souvent qu'un message soit « arrivé en retard » sans que personne ne l'ait bloqué. Cette piste est l'une des premières à suivre quand des messages légitimes finissent en indésirable.

La troisième est le nombre de bords franchis. Un message direct fait deux ou trois sauts. Une dizaine trahit une chaîne de redirections, et donc un contexte où SPF a de fortes chances d'être cassé.

ARC, les listes de diffusion et les redirections

Quand un intermédiaire modifie un message — une liste de diffusion qui ajoute un pied de page, un système qui réécrit l'objet —, la signature DKIM d'origine cesse de vérifier et la redirection casse l'autorisation SPF. Le message légitime devient indistinguable d'une usurpation.

ARC répond à ce problème en faisant témoigner l'intermédiaire. Trois en-têtes apparaissent alors, numérotés par instance : ARC-Authentication-Results conserve l'instantané des verdicts constatés avant modification, ARC-Message-Signature signe le message tel qu'il est retransmis, et ARC-Seal scelle l'ensemble. La balise cv= du sceau d'instance la plus haute donne l'état de la chaîne : pass pour une chaîne intacte, none pour un premier maillon, fail pour une chaîne rompue. Le fonctionnement détaillé de la chaîne ARC mérite un article à lui seul ; pour une lecture d'en-têtes, sa seule présence suffit à expliquer une authentification qui s'effondre sans fraude.

Les champs List-Id et List-Unsubscribe racontent la même histoire plus simplement : le message vient d'une liste, et une liste réécrit volontiers l'expéditeur.

Ce que les en-têtes ne diront jamais

Un message est un cas. Il prouve ce qui est arrivé à ce message-là, et rien d'autre. Les en-têtes ne disent pas combien d'autres messages ont été émis sous le même domaine ce jour-là, ni combien ont échoué, ni depuis quelles adresses IP. Un domaine peut afficher un message parfaitement authentifié et laisser passer, ailleurs, un flux entier d'usurpation.

C'est la limite structurelle de l'exercice, et la raison pour laquelle les rapports agrégés existent. Là où l'en-tête montre un cas, la lecture des rapports agrégés DMARC montre la totalité des expéditeurs d'un domaine, jour après jour, et permet de repérer une usurpation dans les rapports que personne n'aurait signalée. Les deux lectures sont complémentaires : l'une répond à « pourquoi ce message », l'autre à « que se passe-t-il sur ce domaine ».

Pour éviter le décorticage manuel, un analyseur d'en-têtes gratuit rend les mêmes constats en une fois : verdicts par méthode, alignement recalculé, chaîne ARC et trajet reconstitué. Et pour la vue d'ensemble d'un domaine, l'analyseur DMARC gratuit part de l'autre bout — la configuration publiée plutôt qu'un message reçu.

Questions fréquentes

Un en-tête peut-il être entièrement falsifié ? Tout ce qu'écrit l'expéditeur peut l'être : From:, Reply-To:, Date:, et même de faux Received: ou de faux Authentication-Results insérés avant l'envoi. Ce qui ne peut pas l'être, ce sont les champs ajoutés après l'envoi par les serveurs traversés — ils s'empilent au-dessus. D'où la règle : la confiance décroît en descendant dans la pile.

Pourquoi le Return-Path: diffère-t-il du From: ? Parce que ce sont deux identités distinctes du protocole. L'enveloppe sert au routage et aux rebonds ; l'adresse affichée sert à l'humain. Un routeur tiers utilise presque toujours sa propre enveloppe, et cet écart n'a rien d'anormal — il devient un problème seulement si aucune signature DKIM alignée ne vient compenser.

Les en-têtes contiennent-ils des données personnelles ? Oui : adresses e-mail, adresses IP, parfois des noms de serveurs internes. Un bloc d'en-têtes collé dans un ticket public ou envoyé à un service tiers expose ces éléments. La précaution vaut d'être prise avant de partager un message en clair.

En résumé

Les en-têtes sont la seule partie d'un e-mail qui garde une trace de son passé. Trois blocs suffisent : les identités pour savoir qui le message prétend être, Authentication-Results pour savoir ce que le serveur de réception en a conclu — en vérifiant toujours quel serveur parle —, et la pile Received: pour reconstituer d'où il vient et combien de temps il a mis. Le reste est du bruit technique. Et le jour où la question passe de « ce message » à « ce domaine », c'est vers les rapports agrégés qu'il faut se tourner.