L'authentification des e-mails dans les plus grandes entreprises mondiales spécialisées dans l'IA

Le secteur de l'intelligence artificielle a passé deux ans à rendre l'usurpation d'identité numérique convaincante à la portée de tous. Nous avons décidé d'évaluer dans quelle mesure les plus grandes entreprises mondiales spécialisées dans l'IA protègent leurs propres domaines d'entreprise contre ces mêmes risques d'usurpation d'identité. Le 6 août 2026, nous avons mené des tests en temps réel de requêtes DNS récursives sur huit protocoles clés de sécurité des e-mails pour 30 grandes entreprises du secteur de l'IA.

La conclusion principale est simple. Toutes les entreprises sans exception ont mis en place les fondements de l’authentification des e-mails. Les 30 publient des enregistrements « SPF » et DMARC, et au moins 28 confirment l’utilisation de DKIM. Mais dès que l’on va au-delà de ces bases, le niveau de sécurité chute de manière spectaculaire. Seules deux entreprises sur trente publient des enregistrements MTA-STS. Seules six signent leurs enregistrements DNS avec DNSSEC, et 19 laissent encore leurs enregistrements « SPF » configurés en « softfail ».

Aucune des entreprises spécialisées dans l'IA figurant dans notre étude comparative ne publie de MTA-STS. Les deux seuls acteurs de l'analyse qui le font sont Google et Microsoft.

De ce fait, toutes les start-ups spécialisées dans l'IA de cette cohorte sont exposées aux attaques par dégradation de qualité et à l'interception du trafic en transit, même si leurs enregistrements DMARC passent la vérification.

Évaluez la sécurité de votre domaine

Vous souhaitez connaître l'état de votre propre domaine ? Vérifiez la configuration de votre domaine en temps réel à l'aide de l'outil PowerDMARC Domain Analyzer tout en explorant l'ensemble complet des données de référence.

Ce que nous avons mesuré et comment

Notre échantillon de recherche couvre 30 grandes organisations spécialisées dans l’IA : OpenAI, Anthropic, Google, DeepMind, Microsoft, Meta AI, NVIDIA, Amazon, Apple, IBM, xAI, Mistral, Cohere, Perplexity, Hugging Face, Stability AI, Midjourney, Character.AI, ElevenLabs, Runway, Databricks, Scale AI, DeepSeek, Cursor, Replit, Groq, Together AI, Cerebras, Writer et Glean. Nous avons évalué le domaine de premier niveau de chaque entité le 6 août 2026 – Google et DeepMind sont considérés comme des domaines de premier niveau distincts tout au long de ce rapport.

Nous avons évalué huit protocoles et paramètres spécifiques : configuration des enregistrements « SPF », présence d’un sélecteur DKIM, déploiement de la politique DMARC, validation DNSSEC, MTA-STS, TLS-RPT, BIMI (Brand Indicators for Message Identification) et fournisseurs de services MX. Nous avons interrogé des résolveurs récursifs publics (1.1.1.1, 8.8.8.8, 9.9.9.9, 8.8.4.4) avec EDNS0 activé et avons effectué trois à quatre tentatives par enregistrement. SPF Les enregistrements TXT de niveau supérieur ont été récupérés via DNS-over-HTTPS afin d’éviter les problèmes de repli vers le port TCP/53 sur des ensembles d’enregistrements TXT trop volumineux. SPF Le nombre de requêtes récursives a été calculé strictement conformément à la section 4.6.4 de la RFC 7208.

Afin de garantir une transparence totale de cette étude, nous tenons à souligner six limites analytiques bien précises :

• Limites de l'analyse DKIM : les sélecteurs DKIM ne peuvent pas être répertoriés à l'aide de requêtes DNS standard. Notre décompte de 28 sur 30 correspond à une limite inférieure. Par exemple, meta.com n'a renvoyé aucun résultat sur plus de 100 sélecteurs analysés, ce qui indique la présence d'un sélecteur personnalisé plutôt qu'une absence de DKIM.
• Caractères génériques : databricks.com utilise un caractère générique DNS sous _domainkey. Toute requête de sélecteur aboutit, ce qui rend inutile le comptage précis des sélecteurs. Nous avons répertorié cette configuration comme un cas de caractère générique.
• Portée de l'étude : nous avons testé uniquement les domaines « apex » principaux des entreprises. Les sous-domaines dédiés au marketing ou aux transactions n'ont pas été pris en compte.
• Échecs DNS lors de l'inclusion de sous-pages : amazon.com s'appuie sur spf3.amazon.com, dont la résolution a échoué en raison de sa taille. Le nombre total de quatre requêtes enregistrées par Amazon constitue un seuil minimal.
• Période de référence : les configurations DNS évoluent. Ces données correspondent à un instantané en temps réel daté du 6 août 2026.
• Approche vs faille : une politique d'authentification plus souple traduit une position moins stricte en matière de lutte contre l'usurpation d'identité. Cela n'implique pas pour autant une faille de sécurité ni une négligence opérationnelle.

Chaque donnée figurant dans ce rapport peut être vérifiée de manière indépendante à l'aide de commandes « dig » standard sur des résolveurs publics.

Tout le monde maîtrise les bases de l'authentification des e-mails

Les protocoles de référence sont intégralement adoptés dans l'ensemble du secteur de l'IA. Les 30 entreprises publient toutes un enregistrement « SPF », les 30 publient toutes un enregistrement DMARC, et 29 publient une adresse de rapport agrégée (rua) valide. 90 % de l'échantillon applique le protocole DMARC avec soit p=quarantine (12 entreprises), soit p=reject (15 entreprises).

Toutefois, le contexte a son importance. Exactement 50,0 % de ces grandes entreprises spécialisées dans l’IA appliquent une politique stricte de « p=reject ». À titre de comparaison, notre récent rapport sur l’adoption des protocoles DMARC et MTA-STS aux États-Unis fait état d’un taux d’application de « p=reject » de 49,0 % à l’échelle nationale. Les entreprises d’IA les plus valorisées au monde se situent donc exactement dans la moyenne nationale en matière d’application des règles de base du protocole DMARC.

Si vous souhaitez comprendre le fonctionnement exact de « p=reject », sachez qu’il s’agit du dernier rempart permettant de bloquer les messages non autorisés avant qu’ils n’atteignent la boîte de réception. Trois entreprises participant au test comparatif, Hugging Face, Stability AI et Cerebras, restent sur le paramètre « p=none », qui surveille le trafic sans bloquer les e-mails usurpés.

Tableau récapitulatif de l'adoption des protocoles (échantillon de 30 grandes entreprises du secteur de l'IA)

Source : Étude PowerDMARC sur le DNS en temps réel (6 août 2026)

Seuls deux sur trente publient des articles sur la MTA-STS

Alors que la vérification de domaine de base est omniprésente, la sécurité au niveau de la couche de transport présente une réalité bien différente. Sur les 30 leaders du marché, seuls Google et Microsoft publient des enregistrements RFC 8461 MTA-STS (Mail Transfer Agent Strict Transport Security) et TLS-RPT (SMTP TLS Reporting). Aucune start-up spécialisée dans l’IA ni aucun fournisseur de matériel spécialisé ne publie ces enregistrements. Notre guide explicatif sur le protocole MTA-STS détaille précisément son fonctionnement.

DMARC et MTA-STS répondent à des problèmes totalement différents au sein de la pile de sécurité. DMARC authentifie l'identité de l'expéditeur afin d'empêcher l'usurpation d'en-tête. MTA-STS impose l'utilisation de connexions TLS chiffrées entre les serveurs de messagerie afin d'empêcher les attaques de type « homme au milieu » et les attaques par rétrogradation. Aucun de ces protocoles ne remplace l'autre.

Pour être honnête, un taux d’adoption de 6,7 % au sein de cet échantillon reste supérieur au taux de référence national de 1,7 % relevé dans notre étude menée aux États-Unis. Le véritable enseignement à en tirer est d’ordre structurel : les seules entreprises de l’écosystème de l’IA qui assurent la sécurité des transmissions sont les deux géants technologiques qui exploitent des plateformes mondiales de messagerie dans le cloud. Vous pouvez vérifier l’état du chiffrement de vos transmissions à l’aide de l’outil MTA-STS Checker de PowerDMARC.

Le fossé du DNSSEC – En incluant tous les grands acteurs de l'IA dans le secteur des technologies

Le protocole DNSSEC (Domain Name System Security Extensions) fournit une preuve cryptographique que les réponses DNS n'ont pas été falsifiées. Seules six des trente entreprises étudiées dans le cadre de notre enquête signent leur zone d'entreprise à l'aide du protocole DNSSEC : Hugging Face, ElevenLabs, Databricks, Scale AI, Writer et Glean. Cela représente un taux d'adoption de 20,0 %, légèrement supérieur à la moyenne nationale américaine de 18,0 %.

Ce qui ressort le plus, c'est l'absence de certains acteurs. Aucun des géants de la technologie figurant dans notre échantillon ne signe son domaine d'entreprise principal avec le protocole DNSSEC. Google, Microsoft, Meta, NVIDIA, Amazon, Apple et IBM laissent tous leur domaine de premier niveau non signé.

Taux d'adoption des protocoles : les 30 principales entreprises du secteur de l'IA par rapport aux valeurs de référence (2026)

Source : Étude originale de PowerDMARC (août 2026) | Rapport sectoriel Valimail 2026

Déploiement incomplet de Stability AI

Nos analyses ont mis en évidence une lacune classique dans le déploiement chez Stability AI. Le domaine publie un enregistrement DNSKEY valide au sein de sa zone, mais ne dispose pas d’un enregistrement DS (Delegation Signer) correspondant chez le registraire parent. La chaîne de confiance étant rompue au niveau supérieur, les résolveurs de validation traitent la zone comme si elle n’était pas signée du tout. Cela ressemble à une protection sur le papier, mais n’offre aucune sécurité aux utilisateurs finaux.

Le protocole DNSSEC a une incidence directe sur la sécurité des e-mails, car les enregistrements « SPF », DKIM et DMARC sont tous transmis via le DNS en clair. En l'absence de signature cryptographique des zones, les attaquants peuvent manipuler les réponses DNS en cours de transmission afin de contourner complètement les contrôles de messagerie.

Sur trente, dix-neuf présentent encore un « softfail » SPF

Nos recherches montrent que 19 entreprises sur 30 terminent leur enregistrement « SPF » par un qualificatif « ~all » (softfail) au lieu de « -all » (hardfail). Seules neuf d'entre elles utilisent le « hardfail », tandis que deux entreprises (Meta et Writer) ont recours à un mécanisme « redirect= ».

Il est intéressant de noter que 10 des 15 entreprises appliquant la règle « p=reject » utilisent toujours « ~all » dans leurs enregistrements « SPF ». Cette liste comprend Anthropic, Google, DeepMind, NVIDIA, Perplexity, Character.AI, Databricks, Replit, Groq et Glean. Vous pouvez vérifier la syntaxe de l’enregistrement « SPF » de votre domaine à l’aide de l’outil de recherche « SPF » de PowerDMARC.

Dans ce contexte, il est essentiel de bien comprendre la syntaxe « softfail » et « hardfail » de SPF . Lorsqu’un domaine applique DMARC avec p=reject, c’est la politique DMARC globale qui détermine la distribution des messages. Un « softfail » dans SPF ne crée pas de faille de sécurité lorsque DMARC est actif. En revanche, l’utilisation de l’option -all envoie un signal explicite et sans ambiguïté aux destinataires qui évaluent SPF de manière indépendante. Passer du « softfail » au « hardfail » reste un moyen simple de renforcer votre posture de sécurité.

SPF Répartition des critères de sélection pour p = rejet (15 entreprises)

Personne n'a encore atteint la limite de recherche d'SPF – pour l'instant

La RFC 7208 fixe une limite stricte de 10 requêtes DNS pour l'évaluation de l'SPF . Le dépassement de cette limite entraîne une erreur « PermError », qui invalide complètement la vérification de l'SPF . Aucune des 30 entreprises ne dépasse le plafond de 10 requêtes. Writer est celle qui s'en approche le plus, avec 9 requêtes, suivie par Perplexity avec 8. OpenAI, Microsoft et Cohere en enregistrent 7.

Le record « SPF » d’OpenAI illustre parfaitement les infrastructures de messagerie d’entreprise modernes. Leur chaîne d’inclusion comprend Google Workspace, Microsoft 365, HubSpot, Marketo et Oracle Cloud. Cette configuration utilise sept recherches, ce qui laisse une marge de trois recherches. L’ajout d’un seul outil marketing externe supplémentaire pourrait entraîner l’échec opérationnel de leur record.

SPF Marge de recherche DNS (entreprises sélectionnées proches de la limite de 10 recherches)

Cinq entreprises ont déjà externalisé la gestion d'SPF

La gestion manuelle des recherches devient difficile à mesure que l'échelle augmente. Cinq entreprises de notre étude comparative ont recours à des services tiers spécialisés pour gérer leur infrastructure d'SPF :

Quatre de ces cinq organisations utilisent des macros « SPF » plutôt que des listes d'adresses IP statiques. Les macros « SPF » évaluent dynamiquement les connexions entrantes au moment de la requête, ce qui en fait une norme éprouvée pour les réseaux d'entreprise complexes.

Les organisations qui souhaitent contourner les limites de recherche sans avoir à effectuer de suivi manuel peuvent se tourner vers les solutions d'SPF hébergées PowerSPF de PowerDMARC.

La configuration décrite par l'auteur met en évidence l'importance d'une mise en œuvre correcte. Son mécanisme de redirection tiers consomme neuf des dix requêtes autorisées en une seule étape. L'utilisation d'un service hébergé et géré de type « SPF » devrait simplifier votre enregistrement, et non épuiser la quasi-totalité de votre budget de requêtes.

Trois grandes universités se limitent encore à la surveillance

Hugging Face, Stability AI et Cerebras appliquent une politique DMARC avec le paramètre p=none. Ce paramètre permet de collecter les rapports de livraison sans protéger le domaine contre les abus. Les pirates peuvent envoyer des messages non autorisés en utilisant ces noms de domaine, et les serveurs de messagerie destinataires les distribueront tout de même normalement.

Ce choix stratégique est particulièrement remarquable dans le cas de Hugging Face, qui sert de plateforme centrale pour le téléchargement de poids de modèles d'IA ouverts. Un faux e-mail convaincant provenant de Hugging Face pourrait facilement inciter les développeurs à télécharger du code ou des fichiers de modèles compromis. D'un autre côté, il faut reconnaître à Hugging Face le mérite d'être l'une des six seules entreprises de notre échantillon à avoir signé son domaine avec DNSSEC.

Ce que cela signifie – et comment y remédier

Ces recommandations de sécurité concrètes fournissent une feuille de route ciblée aux entreprises spécialisées dans l'IA analysées, afin qu'elles puissent éliminer les vulnérabilités liées à l'usurpation d'identité et protéger la réputation de leur domaine. La mise en œuvre de ces contrôles d'authentification des e-mails et du DNS permet d'imposer une vérification rigoureuse de l'expéditeur, de sécuriser le chiffrement en transit et d'instaurer une surveillance opérationnelle continue.

1. Mise en œuvre de DMARC : faites passer votre politique de « p=none » à « p=quarantine », puis fixez une date butoir claire pour passer à « p=reject ».
2. Critères de qualification « Harden SPF » : remplacez la fin de votre enregistrement « SPF » par « -all » au lieu de « ~all » dès que vos rapports agrégés DMARC confirment que tous les expéditeurs légitimes sont conformes.
3. Déployez MTA-STS et TLS-RPT : sécurisez vos e-mails pendant leur transit. DMARC vérifie l'identité de l'expéditeur, tandis que MTA-STS assure le chiffrement du transport entre les serveurs.
4. Activez correctement le protocole DNSSEC : signez votre zone DNS et assurez-vous que votre registraire publie l'enregistrement DS correspondant afin de compléter la chaîne de confiance.
5. Gérer les limites de requêtes « SPF » : surveillez de près le nombre total de vos requêtes DNS. Utilisez des outils hébergés de type « SPF » basés sur des macros pour éviter d’atteindre le plafond de 10 requêtes.
6. Définir explicitement les sous-domaines : définissez explicitement une politique « sp= » dans votre enregistrement DMARC afin d'empêcher les attaquants d'usurper l'identité de sous-domaines non protégés.
7. Désigner un responsable opérationnel : les contrôles techniques doivent faire l'objet d'un suivi régulier. Désignez un membre de l'équipe chargé d'examiner les rapports DMARC chaque semaine.

Combler les lacunes en matière d'authentification des e-mails

Notre étude d'août 2026 montre que les 30 principales entreprises du secteur de l'IA ont toutes mis en place les éléments fondamentaux de l'authentification des e-mails : l'SPF, le DKIM et le DMARC sont systématiquement présents. Cependant, l'adoption s'arrête dès que l'on va au-delà de ces premières étapes. Seules deux d'entre elles publient un MTA-STS, seules six utilisent la signature DNSSEC et dix-neuf continuent de s'appuyer sur des enregistrements « softfail » SPF .

Le secteur de l'IA a mené à bien la phase initiale de mise en place. La prochaine étape consiste à adopter des mesures de contrôle avancées, telles que le chiffrement du transport et la signature de zone, afin de combler les lacunes restantes. Ces améliorations ne nécessitent pas de changer de fournisseur ; elles requièrent simplement une attention particulière au niveau opérationnel.

Vous souhaitez connaître l'état de sécurité de votre domaine ? Vous pouvez vérifier votre propre domaine à l'aide de l'outil gratuit de vérification des enregistrements de domaine de PowerDMARC ou découvrir la suite d'outils de sécurité gratuits de PowerDMARC pour renforcer la sécurité de votre messagerie. Le hameçonnage par e-mail ne cesse de progresser chaque année, et les entreprises présentées ici correspondent exactement au type de marques que les pirates aiment usurper. Si vous préférez discuter de ce que ces failles impliquent pour votre propre domaine, vous pouvez contacter directement notre équipe.

Foire aux questions

Les grandes entreprises spécialisées dans l'IA utilisent-elles le protocole DMARC ?

Oui, 100 % des 30 principales entreprises spécialisées dans l'IA évaluées dans le cadre de notre étude publient un enregistrement DMARC valide. Cependant, seules 90 % d'entre elles appliquent une politique active (quarantine ou reject), tandis que 10 % restent en mode « surveillance uniquement » (p = none).

Combien d'entreprises spécialisées dans l'IA appliquent le protocole DMARC avec le paramètre p=reject ?

Exactement 15 entreprises sur 30 (50,0 %) appliquent le protocole DMARC avec un paramètre p=reject. Ce chiffre correspond à la moyenne nationale actuelle aux États-Unis, qui s'élève à 49,0 % selon les analyses comparatives menées à l'échelle du secteur.

Qu'est-ce que le MTA-STS et pourquoi le DMARC ne le remplace-t-il pas ?

Le protocole MTA-STS impose l'utilisation de connexions TLS chiffrées pour les e-mails transitant entre les serveurs. Le protocole DMARC authentifie l'identité de l'expéditeur afin d'empêcher l'usurpation d'adresse. Ces protocoles protègent différentes étapes du processus de traitement des e-mails ; par conséquent, aucun des deux ne peut se substituer à l'autre.

Le protocole DNSSEC joue-t-il un rôle dans l'authentification des e-mails ?

Oui, le protocole DNSSEC protège votre domaine contre l'usurpation DNS et l'empoisonnement du cache. Étant donné que les enregistrements SPF, DKIM et DMARC reposent sur des requêtes DNS, le protocole DNSSEC garantit que ces enregistrements de politique ne peuvent pas être altérés pendant leur transit.

La commande « SPF ~all » (softfail) pose-t-elle un problème de sécurité ?

Ce n'est pas le cas si votre domaine applique DMARC avec p=quarantine ou p=reject. Lorsque l'application de DMARC est active, elle prend le pas sur le softfail. Cependant, le passage à -all (hardfail) offre un signal de sécurité plus fort pour les destinataires qui vérifient SPF de manière indépendante.

En quoi consiste la limite de 10 recherches de l'« SPF » et qui est sur le point de l'atteindre ?

La RFC 7208 limite les évaluations d'SPF s à 10 requêtes DNS récursives afin d'éviter toute utilisation abusive du serveur. Le dépassement de cette limite de 10 requêtes déclenche une erreur « PermError ». Dans notre étude, Writer arrive en tête avec 9 requêtes, suivi de Perplexity avec 8.

Comment cette étude a-t-elle été menée ?

Les données ont été collectées le 6 août 2026 à l'aide de requêtes DNS en temps réel auprès de résolveurs récursifs publics. Nous avons évalué les domaines de premier niveau de 30 grandes entreprises spécialisées dans l'IA selon huit protocoles clés de sécurité des e-mails, conformément aux normes RFC.

• À propos de
• Derniers messages

Milena Baghdasaryan

Spécialiste du contenu chez PowerDMARC

Milena est une rédactrice et créatrice de contenu qualifiée qui possède plus de 7 ans d'expérience dans la création de contenu attrayant sur les technologies de l'information, la cybersécurité, les événements virtuels, etc. Elle est diplômée d'institutions prestigieuses telles que la New York University Abu Dhabi, l'UWC China et le Collège d'Europe.

Derniers messages de Milena Baghdasaryan (voir tous)

• L'authentification par e-mail dans les plus grandes entreprises d'IA au monde - 10 août 2026
• Les 5 meilleurs outils de lutte contre les attaques par usurpation d'e-mails professionnels (BEC) en 2026 - 31 juillet 2026
• Outils DMARC gratuits : vérificateurs, générateurs et outils de surveillance (2026) - 30 juillet 2026