Outils populaires

Thème

Analyseur d'en-têtes e-mail

Collez les en-têtes d'un e-mail pour tracer un mail de bout en bout : cette analyse d'en-tête mail montre le chemin parcouru, la durée de chaque saut et ce que disent les contrôles SPF, DKIM et DMARC de votre fournisseur.

Lecture dans votre navigateur · seules les IP publiques des serveurs sont consultées, et le domaine de l'expéditeur si vous le demandez · rien n'est conservé

Vos en-têtes ne quittent jamais votre appareil. Seules les adresses IP et les domaines listés sous le résultat sont consultés.

Ce que vous verrez

  • Qui l'a vraiment envoyé, jugé uniquement d'après les contrôles de votre fournisseur
  • Chaque serveur du chemin, le délai à chaque saut et s'il a utilisé TLS
  • SPF, DKIM, DMARC et ARC, et s'ils correspondent à l'adresse From
  • Domaines sosies, résultats falsifiés et autres indices, chacun avec sa preuve
  • En-têtes anti-spam de Microsoft 365, Gmail et SpamAssassin, décodés
  • Règles des expéditeurs en masse de Gmail et Yahoo, désabonnement en un clic compris

Qu'est-ce qu'un en-tête d'e-mail ?

Un en-tête d'e-mail est le bloc de lignes situé au-dessus du texte du message : qui l'a envoyé et à qui, quand, et la trace de chaque serveur qui l'a traité. Les applications de messagerie en cachent la plus grande partie ;  « Afficher l'original »  ou  « Afficher la source »  montre tout.

Chaque ligne est un nom, deux-points et une valeur ; une longue valeur continue sur des lignes qui commencent par une espace (RFC 5322). Les en-têtes s'arrêtent à la première ligne vide. Tout ce qui suit est le corps, que cet outil ne lit jamais.

Trois sortes d'auteurs les écrivent : l'application de l'expéditeur (From, To, Subject, Date), chaque serveur en chemin (une ligne Received chacun) et votre fournisseur (Authentication-Results, verdicts anti-spam). Seuls ces derniers sont vérifiés par quelqu'un en qui vous avez confiance.

L'exemple de la newsletter30 champs · 4,6 Ko

Ajouté par votre fournisseur (Google)11 champs

  1. 1Delivered-To: reader@example.com
  2. 2Received: by 2002:a05:6214:5a0b:… with SMTP id kq11csp1342871qvb; Wed, 21 Oct 2026 07:02:48 -0700
  3. 3–7 X-Google-Smtp-Source, X-Received, ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results
  4. 8Return-Path: <bounces+48213-9f1c-reader=example.com@sendgrid.net>
  5. 9Received: from o1.ptr1234.example.org ([167.89.118.37]) by mx.google.com with ESMTPS id …; Wed, 21 Oct 2026 07:02:47 -0700
  6. 10Received-SPF: pass (google.com: domain of …@sendgrid.net designates 167.89.118.37 as permitted sender) client-ip=167.89.118.37;
  7. 11Authentication-Results: mx.google.com; dkim=pass …; dkim=pass …; spf=pass …; dmarc=pass …

Ajouté par les serveurs en chemin (SendGrid et example.org)5 champs

  1. 12DKIM-Signature: v=1; a=rsa-sha256; d=example.org; s=s1; h=content-type:from:…
  2. 13DKIM-Signature: v=1; a=rsa-sha256; d=sendgrid.info; s=smtpapi; h=content-type:from:…
  3. 14Received: by filterdrecv-7d9c8b5f6-2kqzr with SMTP id … 2026-10-21 14:02:13.517 +0000 UTC
  4. 15Received: from app-01.example.org ([198.51.100.24]) by geopod-ismtpd-3 (SG) with ESMTPSA id …; Wed, 21 Oct 2026 14:02:12.902 +0000
  5. 16Received: from localhost ([127.0.0.1]) by app-01.example.org (Postfix) with ESMTP id 4Xc9Fq2Lb1z9vKs; Wed, 21 Oct 2026 14:02:10 +0000

Écrit par l'application de l'expéditeur14 champs

  1. 17Content-Type: multipart/alternative; boundary=8a1f4c2e9b7d3a6c5e0f
  2. 18Date: Wed, 21 Oct 2026 14:02:04 +0000 (UTC)
  3. 19From: Example Weekly <news@example.org>
  4. 20Mime-Version: 1.0
  5. 21Message-ID: <3qX0b1wZTcO2pN9sKd4ZfA@geopod-ismtpd-3>
  6. 22Subject: This week at Example: five things worth reading
  7. 23List-Unsubscribe: <https://u48213.ct.sendgrid.net/lu/unsubscribe?…>, <mailto:unsubscribe@example.org?…>
  8. 24List-Unsubscribe-Post: List-Unsubscribe=One-Click
  9. 25–29 List-Id, Feedback-ID, X-SG-EID, X-SG-ID, X-Entity-ID
  10. 30To: reader@example.com

ligne vide : le corps commence ici, et cet outil ne le lit jamais

Abrégé : une ligne par champ, numérotée comme dans les en-têtes. Couleurs comme dans le résultat : votre fournisseur, les serveurs en chemin, l'expéditeur.
Analyseur d'en-têtes e-mail sur un faux message PayPal : verdict, constats et chemin de remise avec un écart de 41 minutesAnalyseur d'en-têtes e-mail sur un faux message PayPal : verdict, constats et chemin de remise avec un écart de 41 minutesLe verdictQui l'a envoyé, jugé uniquement d'après les Authentication-Results écrits par votre fournisseur, avec le serveur qui a fait la vérification.Ce qui ressortChaque constat avec sa gravité, la raison et la ligne d'en-tête exacte dont il provient.Le chemin de remiseChaque serveur, de l'en-tête Date jusqu'à la boîte de réception, les écarts à l'échelle et la limite de confiance qui les traverse.Les faitsLe temps de remise, le nombre de sauts, si chaque saut externe a utilisé TLS et quel dossier Microsoft a choisi.
L'exemple suspect : les contrôles de Microsoft 365 ne confirment pas l'expéditeur, les constats citent leurs preuves et le chemin montre où le message a attendu. Sélectionnez un numéro pour voir ce que montre chaque partie.

Analyse d'en-tête mail : comment le lire, de bas en haut

Pour analyser un en-tête mail, lisez les lignes Received de bas en haut. Chaque serveur ajoute sa ligne au-dessus de celles déjà présentes : la plus basse est donc le premier saut, et celle du haut est votre fournisseur qui remet le message à la boîte aux lettres (RFC 5321 §4.4).

Une ligne indique qui a reçu le message (by), depuis quel serveur et quelle adresse (from, l'adresse vue sur la connexion), comment (with : ESMTPS signifie STARTTLS, ESMTPSA STARTTLS plus une authentification) et quand. Les serveurs marquent leur heure locale : convertissez chacune en UTC avant de soustraire : 07:02:47 -0700 donne 14:02:47 UTC.

Seules les lignes écrites par votre fournisseur sont certaines. Tout ce qui se trouve sous sa première ligne vient de serveurs que vous ne pouvez pas vérifier, et un expéditeur peut ajouter ses propres lignes.

Dans l'en-tête · le haut est le plus récent

Le trajet · saut 1 en premier

#2 by 2002:a05:6214:5a0b:…with SMTP id kq11csp…07:02:48 -0700
5interne à Google14:02:48 UTC+1 s
#9 from o1.ptr1234.example.org [167.89.118.37]by mx.google.com with ESMTPS07:02:47 -0700
4mx.google.com14:02:47 UTC+33 s

Limite de confiance

#14 by filterdrecv-7d9c8b5f6-2kqzrwith SMTP id filterd…2026-10-21 14:02:13.517 +0000 UTC
3filtre de SendGrid14:02:13 UTC+0,6 s
#15 from app-01.example.org [198.51.100.24]by geopod-ismtpd-3 (SG) with ESMTPSA14:02:12.902 +0000
2SendGrid14:02:12 UTC+2,9 s
#16 from localhost [127.0.0.1]by app-01.example.org (Postfix) with ESMTP14:02:10 +0000
1app-01.example.org14:02:10 UTCpremier

Lisez vers le haut : chaque serveur ajoute sa ligne au-dessus

Les cinq lignes Received de la newsletter. Le saut 1 est l'application de newsletter ; les 33 s entre SendGrid et Google sont le plus grand écart.

SPF, DKIM et DMARC dans les en-têtes e-mail

SPF demande si le serveur d'envoi a le droit d'envoyer pour le domaine d'enveloppe (le Return-Path). DKIM demande si un domaine a signé le message et si la signature correspond toujours. DMARC demande si un domaine SPF ou DKIM qui a réussi correspond à l'adresse From que vous voyez.

Votre fournisseur écrit les réponses dans Authentication-Results. Fiez-vous au bloc écrit par votre fournisseur à côté de sa propre ligne Received. Les autres copies, les copies ARC et celles qui se trouvent parmi les lignes de l'expéditeur peuvent avoir été ajoutées par n'importe qui (RFC 8601).

Une réussite prouve le domaine, pas ses intentions : examp1e.com peut réussir les trois contrôles pour lui-même.

Authentication-Results, disséquénewsletter · puis l'exemple suspect
Authentication-Results: mx.google.com;1

Qui a vérifiél'authserv-id : le propre serveur de votre fournisseur

dkim=pass header.i=@example.org header.s=s1 header.b=Xk3Pq9aZ;2

DKIM : example.org l'a signésa clé se trouve à s1._domainkey.example.org

dkim=pass header.i=@sendgrid.info header.s=smtpapi …;3

Une deuxième signaturecelle du service d'envoi ; elle ne peut pas s'aligner sur example.org

spf=pass (google.com: … designates 167.89.118.37 as permitted sender) smtp.mailfrom=…@sendgrid.net;4

SPF : autorisé à envoyer pour sendgrid.netle domaine d'enveloppe (Return-Path), pas celui de From

dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.org5

DMARC : le domaine de From correspond à ②p=quarantine est ce que example.org demande aux récepteurs de faire des échecs

#3 Authentication-Results: spf=softfail (sender IP is 198.51.100.77) … dkim=none … dmarc=none action=none … compauth=fail reason=001RetenuMicrosoft 365 l'a écrit, au-dessus de la première ligne Received qu'il a ajoutée.

Limite de confiance

#7 Authentication-Results: protection.outlook.com; spf=pass … dkim=pass … dmarc=pass action=none … compauth=pass reason=100IgnoréIl nomme Microsoft mais se trouve sous toutes les lignes Received : il est venu dans le message. Un récepteur n'écrit jamais à cet endroit.
Sous la ligne : les deux Authentication-Results de l'exemple suspect. La position décide lequel compte.

Cet e-mail est-il authentique ou usurpé ?

Les en-têtes ne peuvent pas dire si une offre est honnête, mais ils montrent si le domaine de From a vraiment envoyé le message et s'il en imite un autre. Commencez par le verdict écrit par votre fournisseur, puis cherchez ces indices.

Aucun ne prouve un hameçonnage à lui seul, et plusieurs différences courantes sont normales. Microsoft note qu'un domaine sosie peut réussir SPF, DKIM et DMARC si son propriétaire les a configurés (Microsoft).

  • Un domaine From sosieÉlevée

    paypa1-billing.examplecontrepaypal.com

    Un chiffre ou une lettre voisine a été substitué. Il peut réussir SPF, DKIM et DMARC pour lui-même.

  • Des lettres d'un autre alphabetÉlevée

    xn--pypal-4ve.examples'affiche commepаypal.example

    Le а est cyrillique. Les en-têtes gardent la forme xn-- (punycode), qui le trahit.

  • Votre fournisseur indique failÉlevée

    compauth=fail reason=001 · spf=softfail

    Le récepteur n'a pas pu relier le domaine de From au serveur qui l'a envoyé.

  • Un nom qui porte une autre adresseMoyenne

    "accounts@example.com" <notice@mailer.example>

    Les applications affichent le nom, pas l'adresse. Le vrai expéditeur est entre les chevrons.

  • Le verdict du filtre lui-mêmeMoyenne

    CAT:PHSH · dest:J · SFTY:9.25

    Microsoft l'a classé comme hameçonnage et rangé dans les indésirables ; 9.25 est l'astuce de premier contact.

  • Des réussites sous la ligneMoyenne

    #7 Authentication-Results: protection.outlook.com; spf=pass dmarc=pass

    Écrites sous toutes les lignes Received : c'est donc l'expéditeur qui les a écrites. Seules celles de votre fournisseur comptent.

Normal, pas un signal d'alerte en soi

  • Le Return-Path diffère de From

    sendgrid.netcontreexample.org

    Les services d'e-mail envoient pour vous ; DKIM porte la correspondance.

  • Le Reply-To diffère de From

    Reply-To: support@example.org

    Les réponses vont à un service d'assistance. Ne mérite un coup d'œil que si ce domaine en imite un autre.

  • Une heure qui recule

    09:47:12 → 09:47:11 (−1 s)

    Chaque serveur marque sa propre horloge, et les horloges peuvent différer d'une seconde ou plus.

  • Un serveur dans un autre pays

    CTRY:US · 209.85.208.54

    C'est là où se trouve le serveur, pas la personne. Les grands fournisseurs envoient de partout.

Des indices tirés de l'exemple suspect et de variantes inventées. Aucun ne prouve un hameçonnage à lui seul.

Pourquoi mon e-mail a-t-il été retardé ?

Soustrayez chaque heure Received de celle qui est au-dessus, en UTC. Le plus grand écart montre où le message a attendu. Un écart de 30 minutes ou plus est compatible avec une nouvelle tentative (la RFC 5321 suggère d'attendre au moins 30 minutes).

L'en-tête Date vient de l'appareil de l'expéditeur : le temps entre Date et le premier serveur inclut donc une horloge en retard ou un brouillon écrit longtemps avant l'envoi. Les heures peuvent aussi reculer d'une seconde quand les horloges de deux serveurs diffèrent.

Aucune norme ne dit à partir de quand c'est trop long.

L'exemple suspectheures en UTC
En-tête Date09:05:44 UTC
+7 s
mail.paypa1-billing.example09:05:51 · premier serveur
41 min 21 s≥ 30 min : une nouvelle tentative

Microsoft 365

  • 09:47:12périphérie, première ligne
  • 09:47:11interne · −1 s
  • 09:47:13serveur de boîtes aux lettres
  1. 09:05:44En-tête Datel'horloge de l'expéditeur
  2. +7 s
  3. 09:05:51mail.paypa1-billing.examplepremier serveur
  4. 41 min 21 s≥ 30 min : compatible avec une nouvelle tentative
  5. 09:47:12périphérie de Microsoft 365première ligne écrite par Microsoft
  6. −1 shorloges différentes
  7. 09:47:11interne à Microsoft
  8. +2 s
  9. 09:47:13serveur de boîtes aux lettres de Microsoft
d'après l'en-tête Date
41 min 29 s
d'après le premier serveur
41 min 22 s
L'exemple de la newsletter · 44 soù le temps est passé
  • Date → premier serveur 6 s
  • vers SendGrid 2,9 s
  • filtre SendGrid 0,6 s
  • SendGrid → Google, le plus grand écart 33 s
  • à l'intérieur de Google 1 s

En-têtes anti-spam de Microsoft 365 et Gmail, décodés

Microsoft 365 écrit le verdict de son filtre dans X-Forefront-Antispam-Report : CAT est le verdict, SFV la décision du filtrage anti-spam, et X-Microsoft-Antispam-Mailbox-Delivery indique le dossier où il est allé.

SCL est toujours écrit, mais Microsoft dit qu'il ne décide plus rien dans Microsoft 365 : lisez plutôt CAT (Microsoft). BCL note le courrier en masse d'après les plaintes, de 0 à 9, et le seuil de votre politique (7 par défaut) tranche.

Gmail n'écrit aucun verdict anti-spam documenté. Les serveurs qui exécutent SpamAssassin ajoutent X-Spam-Status avec le score, le seuil et les règles déclenchées.

X-Forefront-Antispam-Reportl'exemple suspect
CIP:198.51.100.77CTRY:LANG:en3SCL:5SRV:5IPV:NLI2SFV:SPMH:mail.paypa1-billing.examplePTR:mail.paypa1-billing.example1CAT:PHSH4SFTY:9.25SFS:(13230040)(376014)(1800799024)(8096899003)6DIR:INB
  1. 1CAT:PHSH le verdict : hameçonnage (SPM spam, SPOOF, BULK, HPHSH…)
  2. 2SFV:SPM le filtrage anti-spam l'a marqué comme spam (NSPM : pas du spam)
  3. 3SCL:5 une entrée du filtrage, pas la décision dans Microsoft 365
  4. 4SFTY:9.25 l'astuce de sécurité de premier contact a été affichée
  5. 5IPV:NLI l'IP ne figure dans aucune liste de réputation
  6. 6DIR:INB entrant ; SFS et ARA sont des diagnostics internes de Microsoft

Niveau de plaintes pour courrier en masseBCL:0

01–3 peu4–7 variées8–9 beaucoup

Seuils 5 strict, 6 standard, 7 par défaut : à partir du seuil, c'est du courrier en masse.

Où il est allédest:J

Courrier indésirableX-Microsoft-Antispam-Mailbox-Delivery

dest:I est la boîte de réception. ucf, jmr et ENG sont internes.

Gmail et SpamAssassin

Gmail n'écrit aucun verdict anti-spam documenté : X-Received, X-Google-Smtp-Source et X-Gm-* sont internes.

X-Spam-Status: No, score=2.307 required=6.31

SpamAssassin : du spam seulement à partir du score requis.

Chaque valeur de l'exemple suspect, lue avec les tableaux d'en-têtes anti-spam de Microsoft.

Où trouver l'en-tête d'un mail Gmail, Outlook, Apple Mail et ailleurs

Copiez les en-têtes complets, ou le message d'origine en entier, depuis un ordinateur ou un navigateur web. Collez-les ensuite plus haut, ou enregistrez le message en fichier .eml et importez-le.

Chaque application les cache dans un menu différent. Choisissez la vôtre : les étapes suivent la page d'aide de chaque fournisseur.

  1. 1Ouvrez le message
  2. 2Plus ⋮
  3. 3Afficher l'original
  4. 4Copier dans le presse-papiers

Source : support.google.com/mail/answer/29436

Sur un téléphone ? Les applications Gmail, Outlook et Apple Mail n'affichent pas les en-têtes complets. Ouvrez le message dans un navigateur (Gmail, Outlook sur le web) ou une application de bureau, ou transférez-le en pièce jointe et importez ici le .eml.

Comment tracer l'origine d'un mail, et ce qu'une IP peut ou non révéler

Pour tracer un mail, prenez l'adresse from de la première ligne Received écrite par votre fournisseur : le serveur qui lui a remis le message. Cherchez à qui il appartient et vous saurez de quel serveur il s'agit, ce qui peut être un relais plutôt que l'expéditeur d'origine. C'est ainsi que l'on peut tracer l'origine d'un mail.

Les en-têtes montrent des serveurs de messagerie, et seulement parfois le propre réseau de l'expéditeur, dans X-Originating-IP.

Même cette adresse désigne un réseau et à peu près un pays, jamais une personne ni une rue.

L'exemple Gmail → Outlookconsulté depuis votre navigateur
L'ordinateur d'Anaabsent des en-têtes
209.85.208.54mail-ed1-f54.google.com
Microsoft 365première ligne Received qu'il a écrite

Ce que 209.85.208.54 vous apprend

Propriétaire
Google LLC · 209.85.128.0/17 (ARIN)
Pays
États-Unis, là où se trouve le serveur
Rôle
un serveur d'envoi de Gmail, celui que SPF a vérifié

Ce qu'elle ne peut pas vous apprendre

Qui
Ana, ou n'importe qui d'autre chez example.net
Où
sa ville ou sa rue
Appareil
son ordinateur ou son téléphone
L'analyseur ne consulte que les adresses publiques des serveurs, auprès de leur registre, et montre exactement ce qu'il a demandé.

En-têtes e-mail : questions et réponses

Comment analyser l'en-tête d'un mail (Gmail, Outlook…) avec cet email header analyzer ?

Copiez les en-têtes complets depuis votre application de messagerie, collez-les plus haut et sélectionnez Analyser les en-têtes. L'analyse de l'en-tête mail les lit de bas en haut : le verdict écrit par votre fournisseur, le chemin serveur par serveur avec le délai à chaque étape, et les constats avec leurs preuves.

Peut-on coller des en-têtes d'e-mail ici sans risque ?

Les en-têtes sont lus dans votre navigateur et ne nous sont jamais envoyés. Seules les IP publiques des serveurs sont consultées : leur propriétaire auprès des registres (RDAP, demandé par votre navigateur) et leur pays d'après des fichiers DB-IP récupérés sur notre propre site, notre serveur voit donc quelle plage d'adresses a été demandée. Le domaine de l'expéditeur n'est consulté sur dns.google que si vous le demandez. Les en-têtes contiennent bien des adresses et des noms de serveurs : partagez-les avec précaution.

Les en-têtes d'un e-mail peuvent-ils être falsifiés ?

Oui : tout ce qui a été écrit avant que votre fournisseur ne prenne le message. Chaque serveur ajoute sa ligne au-dessus, donc un expéditeur peut placer de fausses lignes Received en dessous et même un faux Authentication-Results qui indique pass. Les lignes de votre fournisseur, en haut, et les résultats qu'il a écrits à côté sont la partie à laquelle vous pouvez vous fier ; l'analyseur présente le reste comme des affirmations.

Comment savoir si un e-mail est faux ?

Commencez par les Authentication-Results de votre fournisseur : un DMARC fail, ou un compauth fail dans Microsoft 365, signifie que le domaine de From n'a pas été confirmé. Lisez ensuite le domaine lui-même : un sosie comme paypa1-billing.example peut réussir tous les contrôles pour lui-même. Enfin, regardez où vont les réponses et quel serveur a remis le message ; l'analyseur liste chaque constat avec sa preuve.

Comment tracer l'origine d'un mail et retrouver l'adresse IP de l'expéditeur ?

Vous pouvez retrouver le serveur qui a remis le message à votre fournisseur : l'adresse from de la première ligne Received de votre fournisseur, celle que SPF a vérifiée. C'est en général un serveur de messagerie, pas l'ordinateur de la personne. Certains fournisseurs ajoutent aussi X-Originating-IP, en général l'appareil ou le réseau de l'expéditeur, et même cela renvoie à un réseau et à peu près à un pays, jamais à une personne.

Pourquoi Gmail n'affiche-t-il pas l'adresse IP de l'expéditeur ?

Les messages envoyés depuis le web et les applications de Gmail ne portent en général que les serveurs de Google : la première ligne Received n'a pas de partie from, l'adresse de l'expéditeur n'est donc pas dans les en-têtes. L'adresse que vous pouvez voir appartient au serveur Google qui a transmis le message, celui que SPF a vérifié ; une recherche montre donc Google comme propriétaire, pas le réseau de l'expéditeur.

SPF a réussi, alors pourquoi DMARC a-t-il échoué ?

SPF vérifie le domaine d'enveloppe (Return-Path), qui peut différer du From que vous voyez. DMARC exige que SPF ou DKIM réussisse pour un domaine qui correspond à From, exactement ou au sein de la même organisation ; si le domaine qui a réussi appartient à quelqu'un d'autre, comme le domaine de rebond d'un service d'e-mail, DMARC échoue. Une signature DKIM du domaine de From réussit DMARC à elle seule.

Que signifie un délai négatif entre deux sauts ?

Un serveur plus tardif a marqué une heure antérieure à celle du précédent. Chaque serveur écrit l'heure de sa propre horloge, et ces horloges peuvent différer, donc l'analyseur montre un écart d'horloge plutôt qu'un délai. Les heures des lignes situées sous celles écrites par votre fournisseur peuvent aussi être falsifiées ; considérez donc leur ordre et leurs écarts comme des affirmations.

Que signifient SCL et BCL ?

Ce sont deux scores de Microsoft 365 dans ses en-têtes anti-spam. BCL note le courrier en masse d'après son niveau de plaintes, de 0 (pas un expéditeur en masse) à 9. SCL est toujours écrit, mais dans Microsoft 365 il est une entrée du filtrage, pas la décision : c'est CAT qui porte le verdict, et SFV indique comment le filtrage anti-spam a traité le message.

Les en-têtes d'un e-mail montrent-ils les destinataires en Cci ?

Non. Les copies cachées ne sont jamais écrites dans les en-têtes : le serveur d'envoi les livre à partir de l'enveloppe, et les lignes To et Cc ne montrent que les destinataires visibles. Une clause for dans une ligne Received peut nommer un destinataire, c'est pourquoi on demande aux serveurs de l'utiliser avec prudence. Delivered-To peut aussi montrer la boîte que le message a atteinte.

Est-ce la même chose que le Message Header Analyzer de Microsoft ?

Non. Le Message Header Analyzer de Microsoft est un complément Outlook et une page web qui décode les en-têtes d'un message. Celui-ci lit les mêmes en-têtes Microsoft, mais aussi ceux de Gmail, ceux de SpamAssassin et la trace de chaque saut, décide quels résultats croire d'après leur position, et s'exécute entièrement dans votre navigateur.

Pourquoi y a-t-il plusieurs en-têtes Authentication-Results ?

Chaque serveur qui vérifie un message peut en ajouter un, et les expéditeurs peuvent en ajouter de faux, donc un message en porte souvent plusieurs. Seul celui écrit par votre fournisseur compte : en haut, à côté de sa propre ligne Received, avec le nom de son propre serveur. Les ARC-Authentication-Results sont des résultats scellés par un relais de transfert, afin que le serveur suivant voie ce qui avait réussi avant que le transfert ne modifie le message.

Il vous manque quelque chose ?Suggérez une fonction ou un nouvel outil

Plus d'outils e-mail