Analyseur d'en-têtes d'email

Chaque en-tête Received enregistre un saut, le passage d'un serveur de messagerie au suivant. Lisez-les de bas en haut : le plus bas est le premier serveur qui a touché le message, celui du haut est le serveur qui vous l'a remis. La ligne indique quel hôte l'a envoyé (from), quel hôte l'a reçu (by), le protocole utilisé (with) et un horodatage. Un écart important entre deux horodatages signale un délai de file d'attente à ce saut.

Le serveur de réception écrit cet en-tête pour enregistrer ce que ses propres contrôles ont trouvé. Il commence par un authserv-id (le nom du serveur, comme mx.google.com), puis liste chaque méthode et son résultat : spf=pass, dkim=pass, dmarc=pass. Chaque résultat nomme l'identité jugée, écrite sous la forme ptype.property : smtp.mailfrom pour SPF, header.d pour le domaine signataire DKIM, header.from pour DMARC. C'est le seul endroit où vit réellement le verdict SPF, DKIM et DMARC. L'analyseur le cite. Il ne refait pas les contrôles.

L'expéditeur ajoute cet en-tête et signe une partie du message avec une clé privée. Le destinataire la vérifie avec une clé publique publiée dans le DNS. Les balises qui comptent : d= est le domaine signataire, s= est le sélecteur (la clé publique se trouve donc à s._domainkey.d), h= liste les en-têtes couverts par la signature, bh= est le hachage du corps et b= est la signature elle-même. L'analyseur vous montre les balises. Vérifier la signature nécessite une requête DNS, qu'il ne fait pas.

Une note lisible que certains serveurs de réception ajoutent à côté du résultat SPF, indiquant l'IP de connexion (client-ip=) et l'expéditeur d'enveloppe contre lequel il a été contrôlé. Considérez la valeur spf= dans Authentication-Results comme le résultat faisant autorité. Received-SPF n'est qu'une copie de commodité.

La chaîne ARC (Authenticated Received Chain) permet à un transitaire d'enregistrer le résultat d'authentification qu'il a vu, afin qu'un serveur de réception ultérieur puisse encore faire confiance à un courrier dont le SPF ou le DKIM a été cassé en transit. Chaque maillon porte un numéro d'instance i= (1 pour le premier saut, en incrémentant). L'ARC-Seal rapporte une valeur de validité de chaîne cv= : none signifie que c'est le premier maillon, pass que la chaîne a validé jusqu'ici, fail qu'elle n'a pas validé. L'analyseur rapporte le cv= que chaque sceau déclare. Il ne valide pas les sceaux lui-même. En savoir plus sur l'alignement DMARC.

Quatre adresses qui concordent en général. From est l'expéditeur que le message annonce, et l'identité que DMARC juge. Return-Path est l'expéditeur d'enveloppe, là où vont les rebonds, et l'identité que SPF juge. Reply-To est l'adresse à laquelle part une réponse. Sender nomme qui a réellement soumis le message lorsque cela diffère de From. Quand ces adresses pointent vers des domaines sans rapport, cela peut être un signe d'usurpation. La carte de triage anti-phishing ci-dessus les compare pour vous. En savoir plus sur l'alignement DMARC.

Un identifiant unique au niveau mondial que le serveur d'envoi appose sur le message. Sa partie domaine correspond généralement au système d'envoi, ce qui est un contrôle rapide, et c'est la valeur que les équipes de support demandent pour tracer un message précis dans les journaux.

L'heure à laquelle le message a été composé, telle que rapportée par le système de l'expéditeur. Comparez-la aux horodatages des en-têtes Received. Une Date éloignée de l'heure du premier saut peut signaler une horloge mal réglée ou un message rejoué.

Microsoft 365 appose ces en-têtes sur le courrier entrant pour enregistrer ce que son filtre a observé : l'IP et le pays de connexion, les niveaux de confiance spam et bulk, le verdict du filtre et les éventuels conseils de sécurité. C'est la première chose à lire quand un courrier légitime atterrit dans les indésirables sur Microsoft 365. Les codes sont décodés dans la section suivante et dans la carte Microsoft 365 ci-dessus.

Cet outil téléverse-t-il mes en-têtes ?

Non. L'analyseur ne téléverse pas vos en-têtes. L'analyse s'exécute entièrement dans votre navigateur. Vous pouvez ouvrir les outils de développement et surveiller l'onglet Réseau pendant que vous cliquez sur Analyser ; aucune requête ne transporte le texte de vos en-têtes. La page elle-même charge les scripts standards du site (analytics, chat) avant que vous ne colliez quoi que ce soit ; ces scripts ne voient jamais le contenu de vos en-têtes.

Vérifie-t-il indépendamment SPF, DKIM, DMARC et ARC ?

Non. L'outil rapporte ce que l'en-tête Authentication-Results indique que le serveur de réception a vérifié. Pour revérifier une signature DKIM ou consulter une politique DMARC publiée, il faudrait des requêtes DNS, ce qui briserait la garantie de confidentialité. Les verdicts sont étiquetés avec leur provenance : d'après Authentication-Results, signature présente (non vérifiée) ou inconnu.

Comment afficher les en-têtes dans Gmail ?

Ouvrez le message, cliquez sur le menu à trois points en haut à droite du message et choisissez Afficher l'original. Gmail ouvre un nouvel onglet avec la source complète. Copiez tout ce qui se trouve au-dessus de la première ligne vide, ou cliquez sur Télécharger l'original pour enregistrer le fichier .eml.

Comment afficher les en-têtes dans Outlook ?

Outlook sur le web : ouvrez le message, cliquez sur le menu à trois points, choisissez Afficher, puis Afficher la source du message. Outlook classique pour Windows : ouvrez le message dans sa propre fenêtre, choisissez Fichier > Propriétés et copiez la zone En-têtes Internet. Nouveau Outlook et Outlook pour Mac : ouvrez le message, cliquez sur le menu à trois points et choisissez Afficher la source.

Comment afficher les en-têtes dans Apple Mail ?

Ouvrez le message, puis dans la barre de menu choisissez Affichage > Message > Tous les en-têtes (ou appuyez sur Maj+Cmd+H). Les en-têtes complets apparaissent au-dessus du corps du message.

Comment afficher les en-têtes dans Thunderbird ?

Ouvrez le message, puis dans la barre de menu choisissez Affichage > En-têtes > Tous. Vous pouvez aussi enregistrer le message en .eml depuis Fichier > Enregistrer sous et déposer le .eml sur l'analyseur.

Que signifie X-Forefront-Antispam-Report ?

C'est un en-tête Microsoft 365 qui enregistre ce que le filtre du flux de messagerie entrant a observé. L'analyseur décode les codes qu'il contient : CIP (l'IP de connexion), CTRY (son pays), SCL (niveau de confiance spam, -1 à 9), BCL (niveau de confiance bulk 0-9), SFV (verdict du filtre antispam), SFTY (conseil de sécurité phishing), IPV (statut de la liste d'autorisation d'IP) et les drapeaux d'override SOR / SOT / SOI. Chaque ligne de la section M365 affiche la valeur brute et une explication en clair.

Est-il sûr de coller un en-tête de production sensible ?

L'analyse se fait localement, donc le texte des en-têtes lui-même n'est envoyé nulle part par l'analyseur. Si votre organisation interdit de coller des données de production dans une page tierce, suivez cette règle : c'est la plus sûre, et vous pouvez toujours vérifier la garantie de confidentialité en surveillant les outils de développement pendant que vous cliquez sur Analyser.

Peut-on détecter une usurpation depuis l'en-tête ?

Souvent, mais pas toujours avec certitude. L'en-tête montre des indices, pas une preuve. Le signal le plus fort est un échec DMARC dans l'en-tête Authentication-Results, qui signifie que le domaine From ne s'est pas authentifié. La carte de triage anti-phishing en ajoute d'autres : un nom d'affichage From qui cite une marque que son adresse ne correspond pas, ou un Reply-To et un Return-Path sur des domaines sans rapport. Chacun de ces signes mérite un second regard. Aucun ne prouve à lui seul que le message est malveillant, et un message de phishing bien construit peut quand même passer les contrôles de base ; traitez donc l'en-tête comme un indice, pas comme un verdict final. DMARC réussit mais l'usurpation continue.

Pourquoi mon email légitime affiche-t-il DMARC=fail ?

Presque toujours à cause de l'alignement, pas parce que le message est faux. DMARC ne réussit que lorsque SPF ou DKIM authentifie un domaine qui correspond au domaine From. Lorsque vous envoyez via un service tiers (une plateforme marketing, un service d'assistance, un outil de paie) sans y avoir configuré votre propre domaine, SPF réussit pour le domaine du fournisseur et DKIM signe avec le domaine du fournisseur, donc aucun ne s'aligne avec votre From. Un transitaire casse l'alignement de la même manière. Lisez l'en-tête Authentication-Results et la carte de triage anti-phishing ici pour voir quelle identité n'a pas réussi à s'aligner, puis corrigez-la dans le service d'envoi. Le courrier de l'ESP échoue à DMARC : correctifs par fournisseur.

Un succès DMARC signifie-t-il que l'email est sûr ?

Non. Un succès DMARC vous dit une seule chose : le message provient réellement du domaine indiqué dans l'adresse From et n'a pas été usurpé. Il ne dit rien sur la fiabilité de ce domaine ni sur la sûreté du contenu. Un attaquant qui contrôle un domaine, ou qui a enregistré un domaine ressemblant, peut envoyer du courrier qui réussit DMARC pour ce domaine. L'authentification répond à « ce message vient-il vraiment de ce domaine ? », pas à « dois-je faire confiance à ce domaine ? ». Servez-vous du succès comme point de départ, puis jugez l'expéditeur et le contenu par eux-mêmes.