Pourquoi Spoofhound existe
L’e-mail a été bâti sur la confiance.
Internet, non.
Le protocole qui transporte vos factures, vos contrats et vos réinitialisations de mot de passe a été conçu en 1982 sans le moindre contrôle de sécurité — parce qu’aucun ne semblait nécessaire. Tout ce qui a suivi n’a été que rustines. Cette page explique les problèmes que cette histoire vous a légués, et exactement comment Spoofhound les résout.
Brève histoire d’un protocole non sécurisé
Personne n’avait imaginé ce que l’e-mail allait devenir.
Spoofhound aide à sécuriser vos e-mails.
SMTP a été écrit pour un petit réseau d’institutions qui se connaissaient entre elles. Aucun de ses concepteurs n’avait imaginé des milliards de messages par jour entre inconnus — ni le spam, l’usurpation et l’hameçonnage devenus des industries pesant des milliards. Chaque protection dont dispose l’e-mail aujourd’hui a été greffée des décennies plus tard, et chacune existe pour combler une faille précise de ce modèle de confiance d’origine.
-
1978
Le premier spam
Un commercial envoie à environ 400 utilisateurs d’ARPANET une annonce de produit non sollicitée. La réaction est furieuse — et ne change rien. Aucun mécanisme n’existe pour empêcher le suivant.
-
1982
SMTP est normalisé (RFC 821)
Le protocole qui transporte encore aujourd’hui l’e-mail mondial est écrit pour un réseau de quelques centaines d’hôtes de confiance, essentiellement universitaires. N’importe quel serveur peut revendiquer n’importe quelle adresse d’expéditeur ; la ligne From n’est que du texte. Aucune authentification, aucun chiffrement, aucune vérification — rien de tout cela jugé nécessaire entre collègues qui se connaissaient.
-
1990s
L’e-mail dépasse ses hypothèses
Internet s’ouvre au public et l’e-mail en devient la première application phare. Le modèle de confiance conçu pour quelques centaines d’hôtes achemine désormais le courrier entre parfaits inconnus, et le spam s’industrialise presque aussitôt — au début des années 2000, il représente déjà la majorité de tous les e-mails envoyés.
-
1996
Le « phishing » reçoit son nom
Les attaquants découvrent le corollaire d’une ligne From non authentifiée : un courrier qui prétend venir de votre banque, de votre fournisseur, de votre patron. Le terme naît parmi les voleurs de comptes AOL ; la technique ne disparaîtra jamais.
-
2002
STARTTLS (RFC 3207) : le chiffrement, de façon opportuniste
Le courrier de serveur à serveur peut désormais être chiffré — mais seulement si les deux parties le proposent, et la livraison se poursuit même si la négociation échoue. Un attaquant sur le chemin peut simplement retirer l’offre et lire le courrier. Personne n’en est averti.
-
2003–2007
SPF et DKIM greffent l’authentification
SPF publie quels serveurs peuvent émettre pour un domaine ; DKIM y ajoute une signature cryptographique. Les deux sont de réels progrès — et tous deux vérifient des identifiants techniques cachés plutôt que l’adresse From qu’un humain lit réellement. Un message peut réussir l’un ou l’autre tout en affichant le domaine de quelqu’un d’autre.
-
2012–2015
DMARC le relie à la ligne From
DMARC exige que SPF ou DKIM s’aligne sur le domaine From visible, permet au propriétaire de publier une politique (surveiller, mettre en quarantaine ou rejeter) et — c’est crucial — oblige les destinataires à signaler qui envoie au nom du domaine. Pour la première fois, un propriétaire de domaine peut voir les abus et les couper.
-
2018
MTA-STS et TLS-RPT (RFC 8461/8460) comblent le manque de chiffrement
MTA-STS permet à un domaine d’exiger un TLS vérifié pour le courrier entrant au lieu de simplement l’espérer ; TLS-RPT en est la boucle de retour — des rapports quotidiens des expéditeurs sur chaque connexion échouée ou dégradée qui, sinon, échouerait en silence.
-
2019–2021
BIMI : une récompense visible pour avoir terminé le travail
Brand Indicators for Message Identification place le logo vérifié d’un domaine à côté de son courrier dans Gmail, Yahoo, Apple Mail et d’autres — mais uniquement pour les domaines qui ont mené DMARC jusqu’à l’application, avec un logo SVG validé et, pour la plupart des fournisseurs, un Verified Mark Certificate prouvant que la marque en est propriétaire. Pour la première fois, bien faire la sécurité des e-mails se voit quelque part où tout le monde peut le constater.
-
2026
DMARCbis (RFC 9989) devient la norme
DMARC accède au rang de norme Internet à part entière, avec des recommandations plus précises : un chemin mesuré et progressif vers l’application, et une politique choisie selon l’usage réel du domaine.
Pourquoi DMARC
La ligne From que voit votre lecteur est celle qui compte.
SPF et DKIM authentifient des choses réelles — le serveur émetteur, la signature du message — mais ni l’un ni l’autre n’a besoin de correspondre à l’adresse From qu’un humain lit réellement. Un hameçonneur peut réussir les deux sur un domaine qui lui appartient tout en affichant le vôtre. DMARC comble cette faille : il exige que ce qui a réussi s’aligne sur le domaine From visible, et vous laisse dire à chaque destinataire de la planète quoi faire lorsque ce n’est pas le cas — le livrer, le mettre au rebut ou le refuser purement et simplement.
Tout aussi important, DMARC produit des rapports. Chaque grand destinataire envoie au propriétaire du domaine un compte rendu quotidien de ce qui prétendait être lui : quelles sources, quels volumes, ce qui a réussi, ce qui a échoué. Ces rapports sont la visibilité sur laquelle tout le reste repose — vous ne pouvez pas appliquer sans risque une politique contre des expéditeurs que vous n’avez pas identifiés, ce qui explique pourquoi la RFC 9989 prescrit un chemin mesuré et progressif : surveiller d’abord, comprendre chaque source, puis resserrer.
Pourquoi TLS-RPT
Un chiffrement que vous ne pouvez pas vérifier est un chiffrement que vous n’avez pas.
Le courrier entre serveurs n’est chiffré que de manière opportuniste : si la poignée de main TLS échoue, ou qu’un attaquant sur le chemin retire discrètement l’offre, le message est envoyé quand même — en clair. L’expéditeur ne le sait pas. Vous ne le savez pas. MTA-STS règle la moitié « politique », en permettant à votre domaine d’exiger un TLS vérifié plutôt que de l’espérer.
TLS-RPT est la moitié dont personne ne se souvient : la boucle de retour. Les expéditeurs vous signalent, chaque jour, toute connexion à votre domaine ayant échoué ou dégradé son chiffrement — ce qui constitue à la fois votre alerte précoce d’une attaque en cours et votre seul moyen de savoir qu’une politique MTA-STS fonctionne au lieu de rejeter silencieusement du courrier légitime. Sans les rapports, vous appliquez à l’aveugle.
Pourquoi BIMI
Votre logo, uniquement là où votre courrier est prouvé authentique.
BIMI est la récompense de tout ce qui précède : une fois DMARC appliqué, les fournisseurs de messagerie participants — Gmail, Yahoo, Apple Mail, Fastmail — affichent votre logo vérifié à côté de vos messages. Ce sont des impressions de marque quotidiennes au seul endroit que vos clients regardent avec constance, et un repère visuel qu’un hameçonneur ne peut reproduire, car le logo n’apparaît que sur le courrier ayant réussi l’authentification pour votre domaine en application.
Y parvenir a des arêtes vives : le logo doit être un fichier SVG Tiny P/S valide, la plupart des fournisseurs exigent un Verified Mark Certificate prouvant que la marque en est propriétaire, et tout — l’enregistrement, le logo, l’expiration du certificat — doit rester correct sous peine de voir le logo disparaître en silence. Spoofhound surveille les trois pour chaque domaine, et peut héberger pour vous le logo validé et le certificat, afin que BIMI reste une récompense plutôt qu’une chose de plus à surveiller.
Les problèmes que Spoofhound résout
Cinq problèmes que rencontre chaque propriétaire de domaine.
Qu’il le sache ou non.
Des criminels envoient des e-mails au nom de votre domaine
Le problème : La fraude à la facture, le détournement de paie et l’hameçonnage visant vos clients et vos employés utilisent couramment votre domaine exact dans la ligne From — parce que tant que DMARC n’est pas appliqué, les destinataires le livreront. La fraude au président (BEC) figure invariablement en tête des pertes de cybercriminalité signalées au FBI, année après année.
Comment Spoofhound le résout : Spoofhound établit une référence pour chaque source d’envoi légitime dans vos rapports DMARC, de sorte qu’une source toute nouvelle échouant à l’alignement — la signature classique de l’usurpation — déclenche une alerte le jour même, avec une ligne de runbook vous indiquant ce que cela signifie et ce qu’il faut faire. Ce que DMARC arrête et n’arrête pas →
Votre courrier légitime finit dans les spams — ou nulle part
Le problème : Google, Yahoo et Microsoft exigent désormais l’authentification (dont DMARC pour les expéditeurs en masse) comme condition de livraison. Une plateforme marketing oubliée ou un enregistrement SPF mal configuré vous coûte silencieusement votre placement en boîte de réception, et personne ne vous dit quel message a échoué ni pourquoi.
Comment Spoofhound le résout : Chaque identité d’envoi vue dans vos rapports est inventoriée et classée — légitime, redirecteur, mal configurée ou malveillante — afin que vous puissiez corriger celles qui sont mal configurées et faire passer et aligner chaque expéditeur réel avant de resserrer la politique.
La preuve existe, mais personne ne peut la lire
Le problème : Les rapports DMARC et TLS arrivent sous forme de pièces jointes XML et JSON compressées, par destinataire et par jour, dans une boîte aux lettres. La visibilité dont vous avez besoin vous est techniquement déjà envoyée — sous une forme qu’aucun être humain ne lira jamais.
Comment Spoofhound le résout : Spoofhound les ingère et les lit tous, chaque jour, et s’ouvre sur une file de tri des éléments qui nécessitent vraiment une décision — pas un mur de graphiques. Un résumé du lundi récapitule la semaine en phrases.
L’application semble trop risquée pour être menée à terme
Le problème : Passer à la quarantaine ou au rejet, c’est là que se trouve la protection — mais un faux pas jette vos propres factures ou votre paie. Aussi la plupart des domaines restent bloqués à p=none pour toujours, surveillés mais non protégés.
Comment Spoofhound le résout : L’assistant d’application codifie le chemin sûr : un seuil de 98 % de réussite alignée sur une fenêtre glissante plus une vérification « toutes sources expliquées », avec une recommandation par étapes à chaque palier — la progression mesurée que prescrit la RFC 9989 elle-même.
Le chiffrement du courrier échoue en silence
Le problème : STARTTLS est opportuniste : si la négociation TLS échoue — ou qu’un attaquant la retire — le courrier est livré quand même, en clair, et personne n’est prévenu. Sans MTA-STS et TLS-RPT, vous ne pouvez pas savoir que cela se produit.
Comment Spoofhound le résout : Spoofhound note chaque domaine de A à F sur la sécurité du transport à partir de ses rapports TLS, héberge votre fichier de politique MTA-STS (certificat émis et renouvelé pour vous), et alerte sur les schémas d’échec avec des niveaux de gravité.
Voyez-le sur votre propre domaine
La vérification de domaine gratuite évalue votre configuration SPF, DKIM, DMARC, MTA-STS, TLS-RPT et BIMI en quelques secondes — sans inscription, sans agent, rien à installer.
Comment Spoofhound est conçu
Pensé pour le cloud, de fond en comble.
La plupart des outils de surveillance sont des applications classiques qui se trouvent tourner dans un centre de données — des machines virtuelles et des conteneurs qu’il faut dimensionner, corriger et payer, que quelqu’un les utilise ou non. Spoofhound, non. Il a été conçu pour le cloud de fond en comble : pas de machines virtuelles, pas de conteneurs, pas de baies de serveurs. Il s’exécute sous forme de code serverless sur un réseau edge mondial, au plus près de l’endroit où arrivent vos rapports.
Ce choix se ressent à trois endroits bien concrets. Il évolue avec la demande — une journée qui apporte dix fois le volume de rapports habituel est traitée comme n’importe quelle autre, sans capacité à provisionner. Il est séparé par conception — chaque juridiction est un déploiement autonome avec sa propre base de données et sa région, ce qui permet à vos données de rester dans le pays que vous choisissez plutôt que dans un système partagé unique avec une colonne « pays ». Et parce qu’il ne coûte presque rien au repos, c’est la raison pour laquelle notre tarification est ce qu’elle est : un prix par domaine bas avec toutes les fonctionnalités incluses, plutôt que des paliers de fonctionnalités conçus pour amortir le coût de serveurs qui tournent à vide.