Collez les en-têtes bruts d'un message suspect ou mal remis : l'outil reconstitue son trajet, lit les résultats SPF, DKIM et DMARC, explique les verdicts de Microsoft 365 et liste les indices de risque. Rien ne quitte votre poste.
Les fichiers .msg d'Outlook (format binaire) ne sont pas pris en charge : copiez plutôt les en-têtes comme indiqué ci-dessus. Transférer le message à quelqu'un remplace ses en-têtes d'origine : analysez toujours le message reçu, pas une copie transférée.
Les exports contiennent les adresses et IP présentes dans les en-têtes : partagez-les avec prudence.
Tout repose sur les normes publiques et sur la documentation des éditeurs de messagerie. L'outil lit ce que les serveurs ont écrit ; il ne refait aucune vérification sur Internet.
Les lignes repliées sont dépliées (RFC 5322, §2.2.3). Les mots encodés =?UTF-8?B?…?= et =?…?Q?…?= sont décodés (RFC 2047), en recollant les mots adjacents. Le corps du message est ignoré ; le tableau de synthèse de Gmail, s'il a été copié, est écarté.
Chaque serveur ajoute un en-tête Received en haut de la pile : l'outil les lit de bas en haut. Il extrait de, par, avec, id, pour et l'horodatage (converti en UTC), calcule le délai entre relais et classe les IP (privées RFC 1918, partagées RFC 6598, documentation RFC 5737 et 3849…). ESMTPS signale TLS, ESMTPA un envoi authentifié (RFC 3848).
Seul l'en-tête Authentication-Results le plus haut est retenu : c'est votre serveur de réception qui l'a écrit, ceux du dessous peuvent être forgés (RFC 8601, §7.1). À défaut : l'ARC-Authentication-Results de rang le plus élevé (RFC 8617), puis Received-SPF. Les signatures DKIM sont lues (d=, s=, a=, h=, l=, x=) mais pas vérifiées : il faudrait le corps intact et une requête DNS.
DMARC exige qu'un SPF ou un DKIM réussi porte sur le même domaine organisationnel que l'adresse From (RFC 7489, §3.1). Le domaine organisationnel est approché par le suffixe public plus un niveau, à l'aide d'une liste embarquée de suffixes courants (extrait simplifié de la Public Suffix List). Le mode relâché, par défaut, est appliqué ; le mode strict est indiqué à titre d'information, car les réglages adkim et aspf du domaine ne sont pas lus (pas de DNS).
Les champs de X-Forefront-Antispam-Report (CAT, SFV, SCL, IPV, SFTY, DIR, SRV, CIP, CTRY, PTR…), le BCL de X-Microsoft-Antispam, X-MS-Exchange-Organization-SCL et les codes compauth sont expliqués d'après la documentation publique de Microsoft, consultée le 3 octobre 2026. Les champs non documentés sont affichés sans interprétation. Les en-têtes X-Gm-* et X-Google-* de Google ne sont pas documentés publiquement : seule leur présence est signalée.
Chaque indice a un poids : élevé 3, moyen 2, faible 1, information 0. Le niveau est « élevé » dès qu'un indice élevé est présent ou que le total atteint 5, « modéré » à partir de 2, « faible » en dessous. Sans aucun résultat d'authentification, l'analyse est dite « limitée ». Ce n'est pas une probabilité : c'est une lecture argumentée des en-têtes.
| Poids | Indices |
|---|---|
| Élevé (3) | DMARC en échec ; compauth=fail ; nom affiché contenant une adresse d'un autre domaine ; catégorie Microsoft de menace (PHSH, HPHSH, SPOOF, MALW, UIMP, DIMP, BIMP, GIMP, INTOS, AMP, FTBP, SAP) ; SFTY 9.19 ou 9.20. |
| Moyen (2) | Aucun alignement DMARC (si aucun résultat DMARC n'est consigné) ; SPF fail ; DKIM invalide sans autre signature valide ; Reply-To d'un autre domaine ; plusieurs From, aucun, ou From sans adresse valide ; domaine From en punycode ; signature DKIM qui ne couvre pas From ; catégorie Microsoft SPM, HSPM ou OSPM ; SFV:SPM, SKB, BLK ou SKS ; SCL de 5 ou plus (hors verdict SFV:NSPM). |
| Faible (1) | SPF softfail, neutral, none ou en erreur ; DMARC none ou en erreur ; message non signé DKIM ; Return-Path d'un autre domaine sans DKIM aligné ; compauth=softpass ; ARC cv=fail ; DKIM rsa-sha1, l= ou expiré ; BCL 8 ou 9 ; catégorie BULK ; PTR vide ou relais d'origine « unknown » ; Message-ID ou Date absent ou illisible ; date postérieure de plus de 15 min à la réception ou antérieure de plus de 24 h au premier relais. |
| Info (0) | Sender différent de From ; Return-Path d'un autre domaine avec DKIM aligné ; premier contact (SFTY 9.25) ; SCL de 5 ou plus alors que le verdict est SFV:NSPM (Microsoft indique que, dans le cloud, le SCL ne détermine ni le classement ni l'action) ; horloges incohérentes entre relais. |
Un hameçonnage envoyé depuis un compte légitime piraté, ou depuis un domaine sosie correctement configuré, peut réussir tous les contrôles. À l'inverse, un message légitime transféré ou passé par une liste de diffusion peut échouer à SPF, DKIM ou DMARC. Les en-têtes ajoutés avant votre serveur de réception sont déclaratifs. En cas de doute, ne cliquez pas, ne répondez pas, et vérifiez auprès de l'expéditeur par un autre canal ; signalez le message à votre équipe sécurité.
Vérifiez que votre propre domaine publie SPF, DMARC et les autres protections qui rendent son usurpation difficile.
Sortez les IP, domaines, URL et empreintes d'un message suspect pour les partager avec votre équipe.
Si l'hameçonnage a fonctionné, qualifiez l'incident et préparez une fiche structurée.
Historique, travail à plusieurs et rapports : l'abonnement cloud hébergé au Maroc est en accès anticipé.
