Comment bloquer l'usurpation d'e-mail sur les domaines inutilisés ?

Pourquoi les domaines inutilisés ont-ils besoin d'enregistrements e-mail ?

Parce que n'importe qui peut mettre votre domaine dans la ligne « De » d'un e-mail, et qu'un domaine sans enregistrements ne donne rien à vérifier aux destinataires. Un domaine défensif, comme une faute de frappe de votre marque, est attrayant pour cette raison. Les hameçonneurs envoient des messages qui semblent venir de la variante, ou d'un nom qui ressemble à votre adresse de support, et un système de réception qui ne trouve aucune politique n'a aucune raison de les rejeter.

Deux enregistrements comblent l'essentiel de cette lacune. SPF liste les serveurs autorisés à envoyer pour un domaine, et un enregistrement SPF sans serveur avec un échec strict rejette tous les expéditeurs. DMARC indique aux destinataires quoi faire du courrier qui échoue aux vérifications SPF et DKIM, et p=reject leur demande de le refuser. Le troisième enregistrement, un MX nul, indique aux expéditeurs que le domaine n'a pas de serveur de messagerie, si bien qu'un message qui lui est adressé échoue immédiatement au lieu d'être retenté pendant des jours.

La liste des extensions défensives de Wardmint se trouve dans quels domaines un projet crypto devrait enregistrer. Une fois que vous les possédez, ces trois enregistrements sont la première chose à ajouter.

Que fait un enregistrement MX nul (RFC 7505) ?

Un MX nul est un unique enregistrement MX de préférence 0 avec un point racine pour cible, et il signifie que le domaine n'accepte aucun e-mail. La RFC 7505 le définit. L'échangeur est une étiquette de longueur nulle, écrite dans les fichiers de zone sous la forme d'un point, et comme un point n'est pas un nom d'hôte valide, l'enregistrement ne peut pas être pris pour un vrai serveur de messagerie.

Deux règles s'appliquent. Un domaine qui publie un MX nul ne doit publier aucun autre enregistrement MX. Et l'enregistrement n'est un MX nul que sous cette forme exacte : préférence 0, cible point. Les expéditeurs qui le voient échouent immédiatement avec une erreur permanente, ce qui évite les boucles de courrier et épargne les files de nouvelles tentatives des expéditeurs honnêtes qui ont mal saisi votre domaine.

Sans lui, un expéditeur qui ne trouve aucun MX se rabat sur l'enregistrement A du domaine et tente d'y livrer, ce qui est plus lent et moins clair. Un MX nul supprime cette incertitude.

Que signifie SPF v=spf1 -all ?

C'est un enregistrement TXT qui n'autorise aucun expéditeur, et le signe moins fait échouer toutes les vérifications. La RFC 7208 le définit : v=spf1 est la balise de version, et -all est une directive unique dans laquelle le mécanisme all correspond toujours et le qualificatif moins renvoie un échec. Ensemble, ils indiquent qu'aucun hôte ne peut envoyer de courrier pour ce nom.

La RFC 7208 suggère cette approche pour les noms qui ne sont ni utilisés dans des adresses ni censés envoyer du courrier. Publiez-le à la racine de chaque domaine défensif. SPF est vérifié pour le domaine de l'expéditeur d'enveloppe ou du nom HELO ; un usurpateur peut donc aussi essayer un sous-domaine que vous n'avez jamais configuré. Un enregistrement TXT générique (wildcard), qui s'applique aux noms situés sous le domaine qui n'ont pas d'enregistrements propres, peut les couvrir.

example.com.          3600  IN  MX   0 .
example.com.          3600  IN  TXT  "v=spf1 -all"
_dmarc.example.com.   3600  IN  TXT  "v=DMARC1; p=reject; adkim=s; aspf=s"

Qu'apporte DMARC p=reject ?

DMARC apporte la politique et le reporting : il demande aux destinataires de rejeter le courrier qui échoue et vous permet de voir qui essaie. La RFC 7489 place la politique dans un enregistrement TXT au nom _dmarc du domaine. La balise v doit venir en premier et valoir DMARC1, et p fixe la politique à none, quarantine ou reject. La balise sp fixe la politique pour les sous-domaines et, en son absence, p s'y applique. Les balises adkim et aspf fixent l'alignement strict ou relaxé, et rua indique les adresses des rapports agrégés.

La RFC est prudente quant à la force de p=reject : le titulaire demande aux destinataires de rejeter, et ceux-ci sont censés faire de leur mieux mais n'y sont pas strictement obligés. Les grands fournisseurs de messagerie l'appliquent en pratique, ce qui justifie de publier l'enregistrement.

Pour voir les tentatives, ajoutez une adresse de reporting, par exemple rua=mailto:[email protected], sur une boîte que vous lisez. Pour un projet qui possède plusieurs domaines défensifs, une seule boîte de reporting pour tous suffit. Gardez un domaine qui envoie réellement du courrier, comme votre domaine principal, à une politique adaptée à ses vrais expéditeurs, et lisez les rapports agrégés avant de le passer à reject.

Combien coûte la protection d'un ensemble défensif ?

Les trois enregistrements ne coûtent rien de plus chez Wardmint ; ce sont les domaines qui coûtent. Wardmint fournit un modèle DNS « sans e-mail » (MX nul, SPF -all, DMARC p=reject) pour qu'un domaine défensif ne serve pas à usurper votre messagerie, la redirection d'URL gratuite pour envoyer chaque variante vers votre site principal, et le renouvellement automatique depuis votre solde pour qu'aucune variante n'expire.

Selon l'enquête de Wardmint du 12 novembre 2026, les neuf terminaisons de l'ensemble prisé des hameçonneurs (.xyz, .pro, .info, .shop, .online, .icu, .click, .live et .support) coûtent $212.41 par an au total, soit $637.23 sur trois ans, et chacune peut porter le modèle sans e-mail. L'ensemble de base de .com, .net, .org, .io, .xyz, .app coûte $128.94 par an. Les ensembles sont des suggestions, pas des lots : les noms s'ajoutent au panier via la recherche en masse, jusqu'à 50 à la fois.

Appliquez le modèle à chaque domaine défensif qui ne redirige pas le trafic web, et combinez-le avec la redirection d'URL pour ceux qui le font. La méthode de choix des noms est dans comment construire une liste de domaines défensifs pour votre marque.