Analyser les en-têtes d’un e-mail suspect

Pour analyser les en-têtes d’un e-mail suspect, commencez par déterminer qui a ajouté chaque information. Un nom de dirigeant dans From, une mention spf=pass ou une longue chaîne de relais ne valent rien sans cette attribution. La question utile est précise : quelle passerelle fiable a observé quelle identité, depuis quelle connexion ?

Cette méthode sert au triage d’un message reçu. Elle complète le guide d’authentification SPF, DKIM et DMARC en se concentrant sur les preuves à conserver et sur les décisions possibles lorsque les résultats semblent contradictoires.

Conserver le message original

Exportez le message au format proposé par votre messagerie, avec ses en-têtes complets. Un transfert ordinaire peut remplacer les informations de transport par celles du nouvel envoi. Une capture d’écran conserve le leurre visible, mais elle ne suffit pas pour reconstruire sa réception.

Gardez une copie intacte et une copie de travail. Notez la boîte concernée, l’heure de réception, le fuseau horaire et l’identifiant de votre dossier. Si une passerelle a déjà classé le message, conservez son identifiant de trace. Vous pourrez ainsi retrouver la décision appliquée sans dépendre d’un copier-coller partiel.

Ne collez pas l’ensemble du message dans un service public d’analyse. Les en-têtes peuvent contenir des adresses personnelles et des détails d’infrastructure ; le corps peut inclure des documents ou des liens individualisés. Pour un contrôle de réputation externe, commencez par l’indicateur nécessaire, par exemple le domaine d’un lien.

Trouver le point d’entrée fiable

Les relais SMTP ajoutent leurs lignes Received en tête du message : la partie haute décrit donc les étapes les plus récentes. Ce mécanisme de trace est défini dans la RFC 5321, section 4.4. Il ne garantit pas que toutes les lignes reçues étaient authentiques avant leur arrivée dans votre infrastructure.

Repérez d’abord les relais de votre organisation et ceux de son prestataire de messagerie. Descendez jusqu’à la ligne qui décrit la réception depuis Internet. Comparez son adresse IP et son heure aux journaux de la passerelle. À partir de cette frontière, les déclarations des relais précédents exigent une corroboration.

Cette lecture évite une erreur fréquente : considérer la ligne la plus ancienne comme l’origine certaine du message. Un expéditeur peut préparer de faux champs avant l’envoi. Même une chaîne cohérente en apparence ne permet pas de remonter jusqu’au poste d’un auteur sans traces supplémentaires.

Lire un exemple avec trois identités différentes

Voici un extrait fictif et simplifié. Les domaines .example et l’IP de documentation ne représentent aucun expéditeur réel.

From: Direction achats <achats@entreprise.example>
Reply-To: factures@paiement.example
Return-Path: <rebond@routeur.example>
Authentication-Results: mx.destinataire.example;
    spf=pass smtp.mailfrom=routeur.example;
    dkim=pass header.d=routeur.example;
    dmarc=fail header.from=entreprise.example
Received: from sortie.routeur.example (192.0.2.40)
    by mx.destinataire.example with ESMTPS;
    Tue, 29 Sep 2026 08:15:00 +0000

Supposons que mx.destinataire.example soit votre passerelle reconnue et que ses journaux confirment la réception. Trois questions restent séparées : l’adresse à laquelle le lecteur pense répondre, l’identité contrôlée lors du transport et celle présentée dans le champ visible.

Le champ Reply-To propose une autre destination de réponse. Cette différence mérite une explication métier, mais les outils de support et certaines plateformes l’utilisent aussi. Dans le dossier, écrivez « réponse dirigée vers un autre domaine », puis vérifiez si cette configuration était attendue. Écrire directement « adresse de l’attaquant » dépasserait les preuves.

Les résultats SPF et DKIM concernent ici routeur.example. Le résultat DMARC échoue pour entreprise.example. Ce contraste n’est pas une contradiction : les contrôles n’évaluent pas tous la même identité. La définition actuelle de DMARC relie le domaine visible à une authentification alignée, comme l’explique la RFC 9989.

Dans notre scénario, demandez au propriétaire du service d’envoi si ce routeur est autorisé et correctement configuré. Une erreur d’intégration et une usurpation peuvent produire des traces voisines. Le contenu du message, les journaux et la confirmation métier permettent de les départager.

Ne retenir que les résultats de la bonne passerelle

Un message peut comporter plusieurs champs Authentication-Results. Identifiez le service qui les a écrits, puis vérifiez que votre architecture lui accorde confiance. La RFC 8601 encadre précisément cette frontière et le traitement des champs ajoutés en dehors d’elle.

La présence du nom de votre serveur dans un champ n’est pas, seule, une preuve. Consultez la trace du message et la configuration d’assainissement des en-têtes si vous avez un doute. Un résultat copié dans le corps, placé dans un message joint ou conservé depuis un autre trajet ne décrit pas nécessairement la réception étudiée.

Comparez ensuite les contrôles au chemin réellement emprunté. Un transfert ou une liste de diffusion peut modifier la situation observée à l’arrivée. Si ce parcours existe, demandez les traces intermédiaires avant de conclure à une falsification. Consignez les pièces manquantes au lieu de transformer un résultat incomplet en certitude.

Examiner la demande après l’authentification

Une fois les identités clarifiées, revenez au geste demandé : transmettre un document, saisir un mot de passe, approuver une connexion ou modifier un compte bancaire. Un message correctement authentifié peut être frauduleux si un compte légitime est compromis ou si le domaine appartient à l’expéditeur malveillant.

Relevez les domaines des liens sans les ouvrir dans une session de travail. Distinguez le texte affiché de la destination, puis gardez le chemin utile dans le dossier. Le guide de vérification d’un domaine de phishing aide à examiner cette seconde partie de l’enquête. Une demande inhabituelle doit aussi être confirmée par un canal déjà connu, indépendamment des coordonnées du message.

Si l’utilisateur a cliqué, changez le périmètre de l’analyse. Les en-têtes expliquent la réception, pas ce que le navigateur a fait ensuite. Recherchez les connexions, téléchargements ou authentifications correspondants. La corrélation entre IOC, DNS et processus décrit cette étape.

Écrire une conclusion qui permet d’agir

Une conclusion utile distingue l’observation, l’interprétation et l’action. Par exemple : « passerelle confirmée ; authentification alignée en échec ; routeur non reconnu ; demande de paiement non validée ; message maintenu en quarantaine et propriétaire métier sollicité ». Ce texte dit ce qui manque et évite une clôture fondée sur un seul voyant.

Si le message est légitime, documentez le service responsable et la correction nécessaire avant toute exception. S’il est frauduleux, conservez les identifiants permettant de rechercher les autres destinataires. Pour enrichir les domaines et IP extraits, consultez un rapport IsMalicious, puis joignez le résultat daté aux preuves de réception. La réputation complète l’enquête ; elle ne remplace pas les traces du message.