Analyse d’en-têtes

Dans Gmail, ouvrez le message, cliquez sur le menu à trois points, choisissez « Afficher l’original » et copiez tout. Dans Outlook sur le web, ouvrez le message, menu à trois points, puis Afficher > Afficher les détails du message. Dans Outlook classique : Fichier > Propriétés > En-têtes Internet. Dans Apple Mail : Présentation > Message > Tous les en-têtes (ou Source brute). Dans Yahoo Mail : Plus > Afficher le message brut. Collez le texte copié dans l’analyseur ci-dessus.

Chaque serveur qui traite un message ajoute sa ligne Received en haut de l’en-tête : la ligne Received du bas est l’origine, celle du haut votre propre serveur. Lire de bas en haut retrace tout le parcours. L’analyseur remet l’ordre pour vous : le saut 1 est l’origine, et chaque ligne montre le serveur émetteur, le serveur récepteur, le protocole, l’horodatage et le délai depuis le saut précédent.

C’est le relevé, par le serveur destinataire, des résultats du message face à SPF, DKIM et DMARC. Chaque méthode reçoit un verdict (pass, fail, softfail, none, etc.) et le domaine vérifié : smtp.mailfrom pour SPF, header.d pour DKIM, header.from pour DMARC. Écrit par le serveur qui a accepté le message, c’est la preuve d’authentification la plus fiable de l’en-tête.

SPF vérifie le domaine du Return-Path (enveloppe), mais DMARC exige en plus que ce domaine soit aligné sur le domaine From visible. Si un service envoie depuis bounce.someesp.com alors que l’adresse From indique yourbrand.com, SPF peut passer pour someesp.com et DMARC échouer, faute d’alignement. La solution : un domaine Return-Path (rebond) personnalisé sur votre domaine, ou une signature DKIM valide et alignée.

From est l’adresse affichée dans la messagerie ; Return-Path est l’adresse d’enveloppe cachée qui reçoit les rebonds. Les plateformes d’envoi utilisent souvent leur propre domaine Return-Path ou un sous-domaine du vôtre : les deux coïncident rarement. Un même domaine organisationnel (mail.acme.com et acme.com) est normal et suffit à l’alignement souple par défaut de DMARC. Des domaines sans aucun lien méritent un examen : c’est le schéma des e-mails usurpés.

Parfois. Les premières lignes Received contiennent souvent l’IP du serveur, voire de l’appareil qui a soumis le message, et une IP publique se géolocalise à peu près. Mais les grands webmails comme Gmail masquent volontairement l’IP du client, et toute ligne Received ajoutée avant un serveur de confiance peut être falsifiée. Une IP d’en-tête est une piste, pas une preuve.

Cherchez un échec DMARC dans Authentication-Results, un domaine From non aligné sur le Return-Path ou le domaine DKIM, un Reply-To vers un domaine sans rapport et un serveur d’origine étranger à l’expéditeur annoncé. Un signal isolé peut être innocent (le transfert casse SPF, par exemple), mais plusieurs ensemble (surtout dmarc=fail sur un domaine en p=reject) signalent fortement une usurpation.

Causes fréquentes : le greylisting (le destinataire demande exprès un nouvel essai), l’analyse antispam et antivirus, un envoi bridé ou en file d’attente sur un serveur chargé, et des problèmes DNS. Un saut lent montre où la livraison bloque : d’où l’intérêt du délai par saut face aux plaintes « votre e-mail a mis des heures ». Les horloges des serveurs peuvent diverger : un délai faible ou négatif vient souvent d’un décalage d’horloge, pas d’une vraie latence.

Lisez les lignes Received de bas en haut : celle du bas est le serveur d’envoi, celle du haut votre propre serveur, et chaque ligne entre les deux est un relais horodaté. Vérifiez ensuite Authentication-Results, près du haut, pour les verdicts SPF, DKIM et DMARC notés par votre serveur, et comparez l’adresse From au Return-Path pour voir si l’expéditeur visible correspond à celui de l’enveloppe. L’analyseur fait ce tri et cette comparaison : collez les en-têtes, il affiche le tableau saut par saut, les délais de chaque saut et le résumé d’authentification.

Les en-têtes contiennent des métadonnées (adresses, noms de serveurs, IP et objet), pas le corps du message ni les pièces jointes. Ces métadonnées peuvent rester sensibles. Cet analyseur traite tout localement dans votre navigateur et n’envoie, ne journalise ni ne stocke rien de ce que vous collez : rien ne quitte votre machine. Quel que soit l’outil, préférez ceux qui disent précisément ce que deviennent les données.

En partie. L’expéditeur contrôle tout ce qu’il génère : From, Subject, Message-ID, X-Mailer et les lignes Received sous son propre serveur, qui peuvent donc être inventés. Il ne peut pas falsifier les en-têtes ajoutés une fois le message arrivé sur une infrastructure de confiance : la ligne Received de votre serveur et son Authentication-Results. C’est pourquoi l’analyse s’appuie sur le haut de la chaîne et sur les verdicts SPF, DKIM et DMARC, pas sur ce que prétend l’expéditeur.