2026-07-20 · RESEARCH · L'équipe Offensive Technology

À quel point les domaines les plus fréquentés au monde sont-ils exposés à l'usurpation d'email ?

Réponse courte : Nous avons pris les 1 000 domaines les plus fréquentés d'Internet, résolu 994 d'entre eux et lu leurs enregistrements DNS publics d'authentification d'email. 41.5% ne publient aucune politique DMARC restrictive, ce qui signifie que les emails usurpant leur domaine dans la ligne From ne sont ni rejetés ni mis en quarantaine sur cette base et peuvent atteindre les boîtes de réception. Un peu moins de 30% (29.6%) ne publient aucun enregistrement DMARC, et 11.9% de plus en publient un configuré en surveillance seule (p=none), qui observe l'usurpation sans la bloquer. Les contrôles plus avancés sont encore plus rares : 13.6% utilisent DNSSEC et 3.2% annoncent MTA-STS. Chaque chiffre provient de requêtes DNS publiques et passives que nous avons exécutées nous-mêmes sur une liste publiée de sites majeurs. Aucun hôte n'a été contacté, rien n'a été scanné. Voici exactement comment nous l'avons mesuré, et ce que cela prouve ou ne prouve pas.

Le résultat en un graphique

Pour chaque domaine, nous avons posé quatre questions publiques. Publie-t-il un enregistrement SPF ? Publie-t-il un enregistrement DMARC, et la politique est-elle réellement restrictive ? La zone est-elle signée avec DNSSEC ? Annonce-t-il MTA-STS ? Les réponses se raréfient rapidement à mesure que les contrôles se renforcent :

Le seul chiffre qui compte : DMARC restrictif

L'email dispose de trois enregistrements d'authentification bien connus, et il est facile de croire à tort qu'en posséder certains suffit à être protégé. SPF (RFC 7208) liste les serveurs autorisés à envoyer des emails pour un domaine. DKIM (RFC 6376) signe un message pour qu'un destinataire puisse vérifier qu'il n'a pas été altéré. Aucun des deux, pris isolément, ne protège l'adresse qu'un humain lit réellement.

Voici la faille qu'utilise un attaquant. SPF valide l'expéditeur de l'enveloppe, le Return-Path masqué utilisé lors de la distribution, et non l'adresse From affichée dans le client de messagerie. Un message peut valider SPF pour un domaine jetable contrôlé par l'attaquant tout en affichant votre domaine dans la ligne From. DKIM n'aide que si un mécanisme vérifie que la signature s'aligne avec le domaine visible et rejette le message dans le cas contraire. L'enregistrement qui lie l'authentification à l'adresse From visible, et indique aux destinataires quoi faire en cas d'échec, est DMARC (RFC 7489).

DMARC propose trois politiques, et toute la différence réside là :

• p=reject indique aux destinataires de refuser les emails qui échouent. C'est le paramètre qui bloque réellement l'usurpation de domaine.
• p=quarantine indique aux destinataires de traiter les emails en échec comme suspects, généralement en les redirigeant vers le dossier spam. C'est une politique restrictive, bien que plus faible que reject.
• p=none indique aux destinataires de ne rien faire d'autre que d'envoyer des rapports au propriétaire du domaine. Les emails usurpés arrivent toujours. Il s'agit de surveillance, pas de défense.

La vraie question n'est donc pas "ce domaine a-t-il DMARC", mais "son DMARC est-il réellement restrictif". Si l'on ne compte que quarantine et reject comme politiques applicatives, 58.5% des domaines résolus répondent à ce critère. Les 41.5% restants constituent la population exposée : aucun enregistrement, ou un enregistrement en simple observation.

Lisez les trois dernières lignes ensemble. Elles représentent ces 41.5% : les emails usurpés portant leur domaine ne sont pas bloqués par DMARC. Il convient de souligner que l'adoption de SPF est plus élevée, à 73.7%, précisément parce que SPF est l'enregistrement configuré en premier et considéré à tort comme suffisant. Ce n'est pourtant pas l'enregistrement qui empêche quelqu'un d'usurper une identité auprès d'un client ou d'une équipe financière, une attaque que nous avons décrite dans notre guide sur ce que les attaquants peuvent voir de votre entreprise.

Les couches plus profondes sont presque absentes

Deux autres contrôles renforcent la messagerie et le DNS au-delà du trio SPF-DKIM-DMARC, et tous deux restent rares, même parmi les domaines les plus fréquentés.

DNSSEC (RFC 4033 et ses standards associés) signe cryptographiquement les réponses DNS pour qu'un résolveur puisse détecter une réponse falsifiée. Nous avons considéré un domaine comme signé lorsque sa zone parente publiait un enregistrement DS. Seuls 13.6% le faisaient. DNSSEC sous-tend des mécanismes de messagerie plus robustes comme DANE, donc sa rareté limite la maturité de la sécurité email pour la plupart de ces domaines.

MTA-STS (RFC 8461) permet à un domaine d'indiquer aux serveurs expéditeurs d'exiger TLS lors de la distribution d'emails, ce qui protège contre la dégradation du chiffrement et l'interception entre serveurs de messagerie. Seuls 3.2% l'annonçaient. Nous avons vérifié uniquement l'annonce DNS (l'enregistrement _mta-sts TXT) et nous n'avons volontairement pas récupéré le fichier de politique sur HTTPS, car cela impliquerait de se connecter à l'hôte du domaine, une limite que nous ne franchissons pas dans le cadre de nos recherches.

Comment nous avons mesuré cela

Toute personne sceptique doit pouvoir reproduire cette étude de zéro, voici donc la méthode complète sans rien cacher.

• La population. Nous avons utilisé la liste Tranco (liste 64YYX, générée le 19 juillet 2026), un classement de sites majeurs orienté recherche qui fait la moyenne de plusieurs fournisseurs sur 30 jours afin de résister aux manipulations quotidiennes. Il est publié, versionné et citable de manière permanente, ce qui importe plus pour la reproductibilité que la liste d'un seul éditeur. Voir tranco-list.eu et le papier NDSS 2019 associé.
• L'échantillon. Les 1 000 premiers domaines de cette liste. 994 ont résolu vers des serveurs de noms actifs ; 6 n'ont pas répondu et ont été écartés, le dénominateur est donc de 994.
• Les requêtes. Pour chaque domaine, quatre requêtes DNS passives via dig auprès de résolveurs récursifs publics : TXT sur le domaine pour SPF, TXT sur _dmarc.<domain> pour DMARC (analyse du tag p=), DS sur le domaine pour DNSSEC, et TXT sur _mta-sts.<domain> pour l'annonce MTA-STS.
• Ce que nous n'avons pas fait. Nous n'avons jamais envoyé d'email, ouvert de connexion vers un serveur de messagerie, récupéré de fichier de politique ni scanné quoi que ce soit. Lire un enregistrement DNS public est une simple consultation, pas un balayage. C'est cette même frontière entre contrôle et infraction qui régit chacune de nos missions.
• Ce que nous avons conservé. Uniquement des totaux agrégés et des pourcentages. Les résultats par domaine sont restés en mémoire pendant l'exécution et n'ont jamais été écrits sur disque. Aucun domaine n'est nommé. Aucune donnée personnelle n'a été collectée ; les domaines et leurs enregistrements DNS ne sont pas des données personnelles, et nous n'avons recueilli aucune adresse email.

Ce que cela ne prouve pas

Des limites honnêtes, car un chiffre sans ses nuances relève du marketing.

• Il s'agit d'une photographie à un instant T. Le DNS évolue chaque jour. Ces chiffres décrivent la situation au 20 juillet 2026, pas une tendance. Un domaine à p=none aujourd'hui peut être en cours de déploiement et passer en politique restrictive le mois prochain.
• Cela concerne uniquement le DNS. Nous lisons des politiques publiées, pas des emails distribués. Un grand opérateur de messagerie peut superposer des défenses que le DNS ne révèle pas. DMARC est simplement le signal public standardisé sur lequel les destinataires agissent réellement, c'est pourquoi c'est l'indicateur adéquat à mesurer à grande échelle.
• Le haut de la liste ne contient pas que des domaines de messagerie. Une partie des domaines les plus fréquentés est constituée de CDN, de points de terminaison d'API et d'infrastructures qui n'envoient jamais d'emails interactifs. Pour eux, l'absence de DMARC représente un risque réel plus faible, car personne n'attend de message de leur part. Cela reste une lacune : la posture recommandée pour un domaine n'envoyant aucun email est un MX nul combiné à un DMARC reject, et un attaquant peut toujours usurper un domaine s'il n'est pas configuré de façon restrictive.
• p=none est fréquent pour une bonne raison. Le déploiement de DMARC commence par de la surveillance afin qu'une organisation identifie ses expéditeurs légitimes avant de rejeter. Nous considérons p=none comme non restrictif car, sur le plan opérationnel, les emails usurpés ne sont pas bloqués tant qu'un domaine reste dans cet état. C'est un constat factuel, non un jugement sur le propriétaire.
• DMARC au niveau du domaine organisationnel. La liste Tranco est filtrée sur les domaines enregistrés (domaine principal), nous avons donc vérifié la politique là où elle doit l'être, au niveau du domaine organisationnel. Les sous-domaines individuels peuvent différer.

Pourquoi un attaquant s'y intéresse, et pourquoi vous devriez aussi

L'usurpation de domaine n'a rien d'exotique. Un email semblant provenir de l'adresse de facturation d'une entreprise, envoyé à son propre service financier ou à un client pour demander un changement de coordonnées bancaires, est l'un des vecteurs d'intrusion les plus fiables qui soient. Aucun système n'est compromis ; une identité est empruntée parce qu'un enregistrement DNS n'a jamais été configuré sur reject. Lorsque 41.5% des domaines les plus fréquentés d'Internet laissent cet enregistrement non restrictif, la technique continue de fonctionner car la défense est optionnelle et souvent négligée.

La solution est peu spectaculaire et essentiellement gratuite. Publiez SPF et DKIM, puis déployez DMARC et faites-le évoluer de p=none vers p=quarantine puis p=reject à mesure que vos rapports confirment vos expéditeurs légitimes. La partie difficile n'est jamais la modification DNS ; c'est de savoir quelles sources d'envoi vous risqueriez d'interrompre en appliquant la politique, et d'être certain d'avoir tout identifié. C'est une affaire de discernement, le même discernement qui permet de savoir lesquelles de vos surfaces exposées comptent réellement et lesquelles ne sont que du bruit.

Exposition à l'usurpation d'email : réponses rapides

Quelle part des domaines majeurs peut faire l'objet d'une usurpation d'email ?

Lors de notre contrôle de juillet 2026 sur les 1 000 domaines les plus fréquentés (994 résolus), 41.5% ne publiaient aucune politique DMARC restrictive, ainsi les emails usurpant leur domaine dans la ligne From visible ne sont ni rejetés ni mis en quarantaine sur cette base. Environ 29.6% n'avaient aucun enregistrement DMARC et 11.9% de plus publiaient une politique p=none en surveillance seule.

Le fait de posséder un enregistrement SPF empêche-t-il l'usurpation d'email ?

Non, pas à lui seul. SPF autorise les serveurs pour l'expéditeur de l'enveloppe, et non pour l'adresse From qu'une personne voit. Seul DMARC configuré sur quarantine ou reject lie l'authentification au domaine From visible et indique aux destinataires d'agir en cas d'échec.

La politique DMARC p=none est-elle suffisante ?

Non, pas pour bloquer l'usurpation. p=none est de la surveillance seule : les destinataires envoient des rapports mais ne prennent aucune mesure, les emails usurpés arrivent donc toujours. C'est une bonne première étape, mais tant que la politique n'évolue pas vers quarantine ou reject, elle ne stoppe pas l'usurpation.

Comment puis-je vérifier l'authentification email de mon propre domaine ?

Consultez votre propre DNS public : dig TXT yourdomain.com pour SPF, dig TXT _dmarc.yourdomain.com pour DMARC et sa politique p=, dig DS yourdomain.com pour DNSSEC, et dig TXT _mta-sts.yourdomain.com pour MTA-STS. Il s'agit de requêtes passives sur des enregistrements que vous publiez, le contrôle est donc sûr et gratuit.

Lectures connexes

• Combien de domaines majeurs restreignent les autorités autorisées à émettre leurs certificats ? La même méthode par DNS passif, appliquée aux enregistrements CAA.
• Que peuvent réellement voir les attaquants sur votre entreprise ?
• Contrôle, scan ou pentest complet ?
• Combien coûte un test d'intrusion ?