La ligne « De » visible d'un e-mail est saisie par celui qui l'envoie. Les en-têtes situés en dessous sont écrits par les serveurs qui l'ont acheminé, et ils sont bien plus difficiles à falsifier. Collez-les ici pour voir les résultats SPF, DKIM et DMARC, la chaîne de relais complète avec ses délais, les astuces de nom affiché et de Reply-To derrière la plupart des fraudes au paiement, et une lecture passive du risque de chaque lien du corps.
Vous avez utilisé vos vérifications gratuites du jour. Créez un compte gratuit pour continuer — cela prend une trentaine de secondes.
Le résultat réel de chaque mécanisme, issu de l'en-tête Authentication-Results du serveur destinataire lui-même, avec le segment brut pour que vous voyiez ce qui a été évalué plutôt que de vous fier à une coche verte.
Chaque étape parcourue par le message, la plus récente en premier, avec le délai ajouté par chacune. Chronologie non monotone, géographie impossible et premières étapes inattendues ressortent toutes ici.
Nom affiché contre adresse réelle, Reply-To pointant ailleurs que le From, Return-Path en désaccord avec les deux, et domaines expéditeurs sosies — la mécanique du détournement de facture.
Chaque URL portée par le message, avec une lecture de réputation effectuée hors ligne — aucune requête sortante n'est émise, donc rien n'indique à l'expéditeur que vous avez regardé.
Commencez ici, pas par SPF. SPF casse dès qu'un message est transféré et DKIM casse dès qu'une liste de diffusion réécrit le corps — les deux échouent constamment sur du courrier légitime. DMARC est la politique du propriétaire du domaine sur ce qui doit se passer quand le domaine authentifié ne correspond pas à celui que vous voyez. Un échec DMARC signifie que l'organisation dont le nom figure sur le message déclare que ce message n'est pas le sien.
Une authentification parfaite sur un domaine sosie est la forme la plus courante de fraude à la facture. exarnple.com passe SPF, DKIM et DMARC à merveille — pour exarnple.com. Lisez le domaine expéditeur caractère par caractère, et méfiez-vous particulièrement de rn/m, l/I, et de tout domaine comportant un trait d'union supplémentaire.
Un Reply-To différent du From n'est pas automatiquement suspect — les systèmes de tickets et les listes de diffusion en définissent constamment. Mais quand le From est le vrai domaine d'un fournisseur et que le Reply-To est une adresse de messagerie gratuite ou un domaine enregistré le mois dernier, vous avez sous les yeux le mécanisme, pas une coïncidence.
Lisez les étapes de bas en haut : le message doit partir d'un endroit plausible et progresser dans le temps. Des délais de plusieurs heures entre deux étapes voisines, une chaîne qui remonte le temps, une première étape sur une connexion résidentielle, ou un message qui revendique une origine professionnelle mais est entré par un relais grand public — chacun mérite une explication avant que vous n'agissiez sur le contenu.
Les en-têtes décrivent l'acheminement, pas l'intention. Un message qui passe toutes les vérifications peut tout de même être une fraude envoyée depuis une vraie boîte compromise — et la compromission de compte est désormais assez courante pour que « les en-têtes étaient propres » ne soit plus une défense. À l'inverse, un message qui échoue à SPF a peut-être simplement été transféré par un collègue.
Les en-têtes ne peuvent pas non plus vérifier la pièce jointe. Si la demande porte sur un changement de coordonnées bancaires, une facture ou un document signé, c'est dans le fichier lui-même que se trouve la réponse — et c'est à cela que sert une analyse documentaire.
Rien n'est enregistré. Les outils gratuits conservent votre saisie le temps de la requête et l'effacent avec la réponse — aucun rapport stocké, aucun fichier archivé, aucune trace de l'URL, du message ou du nom de fichier. La seule chose que nous conservons est un décompte anonyme, pour que l'allocation quotidienne ait un sens ; c'est un nombre, pas une identité.
Tout ce que vous voyez provient d'une analyse déterministe : registres publics d'enregistrement, négociations DNS et TLS en direct, analyse d'en-têtes et structure PDF. Les mêmes moteurs répondent de la même façon, que vous ayez un compte ou non.
Collez un lien. Obtenez l'ancienneté de l'enregistrement, les enregistrements DNS et messagerie, le certificat en direct, les en-têtes de sécurité et un verdict de sécurité corroboré.
Vérifier un lienTéléversez un PDF. Voyez les révisions enregistrées, les valeurs portées par une version antérieure, les calques masqués et les traces structurelles que laisse une modification.
Radiographier un PDFLiées, mais pas identiques — et la différence détermine quel contrôle les arrête.
Que faire lorsqu'un fournisseur vous écrit pour mettre à jour son compte.
Ce qu'une équipe comptable doit vérifier avant le cycle de paiement.
Dans Gmail, ouvrez le message, utilisez le menu à trois points et choisissez « Afficher l'original ». Dans Outlook sur le web, ouvrez le message, puis Autres actions et « Afficher la source du message ». Dans Apple Mail, Présentation puis Message puis Source brute. Collez ce que vous obtenez — les en-têtes seuls suffisent, et le message entier fonctionne aussi.
SPF indique que le serveur expéditeur était autorisé à envoyer pour ce domaine. DKIM indique que le message porte une signature cryptographique valide du domaine. DMARC est la politique du propriétaire du domaine sur la conduite à tenir quand les deux premiers ne concordent pas avec l'adresse From visible. DMARC fait autorité : SPF et DKIM cassent régulièrement sur le courrier transféré et les listes de diffusion, mais un échec DMARC signifie que la politique du propriétaire du domaine désavoue le message.
Ceux qu'écrit l'expéditeur, oui — From, Reply-To, nom affiché et Date sont tous sous son contrôle. Ceux qu'ajoutent les serveurs destinataires en chemin ne peuvent pas être réécrits après coup, et c'est pourquoi la chaîne de relais est la partie qui mérite d'être lue. Une chaîne qui saute de fuseau horaire, remonte le temps ou démarre sur une connexion résidentielle vous dit quelque chose que la ligne From ne dira pas.
Non. L'authentification prouve que le message vient bien du domaine qu'il revendique — et un attaquant qui enregistre un domaine sosie passera toutes ces vérifications pour son propre domaine. C'est exactement ainsi que fonctionne la majorité des détournements de facture : du courrier parfaitement authentifié, depuis un domaine à un caractère près du véritable.
Non. Il est analysé en mémoire pendant la requête et effacé avec la réponse. Rien n'est écrit dans un rapport ni dans un journal de ce qui a été analysé. Caviardez de toute façon ce que vous préférez ne pas transmettre — l'analyse fonctionne avec les seuls en-têtes.
Un compte gratuit ajoute l'analyse forensique complète de la facture, du contrat ou du relevé que l'e-mail transportait.