SPF et DMARC sur les 10 000 premiers domaines : les données 2026

Nous avons passé les 10 000 domaines les plus populaires de la liste Tranco au crible des vérificateurs SPF et DMARC d'InfraNest. Sur les 7 204 qui reçoivent des e-mails, seuls 55,7 % associent un enregistrement SPF valide à une politique DMARC réellement appliquée. La plupart des autres publient quelque chose qui ressemble à de l'authentification des e-mails, mais qui est soit à une modification de la panne, soit configuré pour ne rien bloquer.

Ceci est le premier rapport de données d'InfraNest. La méthode et les chiffres agrégés sont publics, et chacun peut relancer les mêmes vérifications sur son propre domaine.

Comment nous avons mesuré SPF et DMARC

• La liste : les 10 000 premiers domaines de la liste Tranco K9PXW, un classement de sites populaires conçu pour la recherche et difficile à manipuler. Analyse réalisée le 25 septembre 2026.
• Les vérifications : exactement le code de nos outils gratuits vérificateur SPF et vérificateur DMARC. Chaque chiffre de ce rapport correspond à ce que ces outils indiqueraient au propriétaire du domaine.
• DNS : le résolveur de Cloudflare via HTTPS, avec celui de Google en secours. 23 domaines n'ont pu être lus par aucun des deux et sont exclus.
• Qui est pris en compte : uniquement les domaines qui reçoivent des e-mails, c'est-à-dire qui ont un véritable enregistrement MX. Il en reste 7 204. Les 2 773 autres sont surtout des noms d'hôte de CDN, d'API et de tracking qui n'envoient jamais d'e-mails (75 d'entre eux le déclarent explicitement avec un null MX).

Deux définitions portent l'essentiel des chiffres :

Ce que nous n'avons pas mesuré : DKIM, car ses sélecteurs ne peuvent pas être listés depuis le DNS ; le fait que les e-mails réels passent ou non l'alignement ; et les sous-domaines. Le jeu de données agrégé est librement réutilisable avec attribution.

Un second avis. Nous avons revérifié un échantillon aléatoire de 100 domaines avec checkdmarc, un outil open source indépendant. Le verdict SPF concordait pour 98 d'entre eux, le nombre de lookups pour les 76 enregistrements jugés valides par les deux outils, et la politique DMARC pour 99 ; chaque différence restante concernait un enregistrement que checkdmarc ne parvenait pas à lire ou auquel il reprochait une question de style, ce que nous avons confirmé à la main. Ce contrôle croisé a aussi révélé un bug dans notre propre vérificateur : les enregistrements qui incluent le même fournisseur via deux expéditeurs étaient pris à tort pour des boucles d'include. Le problème est également corrigé dans notre vérificateur SPF, et tous les chiffres présentés ici proviennent de l'analyse corrigée.

Enregistrement SPF : presque tout le monde en a un, et un sur six frôle la panne

92,9 % des domaines qui reçoivent des e-mails publient un enregistrement SPF. Le point faible n'est pas l'existence d'un enregistrement SPF, mais le nombre de lookups DNS qu'il coûte.

La RFC 7208 accorde au serveur destinataire 10 lookups DNS pour évaluer une politique SPF, et chaque include, a, mx et exists compte, y compris ceux imbriqués dans l'include d'un fournisseur. À 11, le résultat est une erreur permanente, et les destinataires traitent le domaine comme s'il n'avait aucun SPF.

• 2,7 % des enregistrements SPF (184 domaines) dépassent déjà la limite. Leur enregistrement SPF ne sert à rien.
• 14,3 % supplémentaires utilisent 8 à 10 lookups. Chaque include coûte au moins un lookup, et de nombreux fournisseurs imbriquent d'autres includes derrière le leur. Un nouveau CRM, un outil de helpdesk ou de newsletter suffit donc souvent à faire basculer ces domaines au-delà de la limite, sans que rien n'avertisse la personne qui l'ajoute.
• L'enregistrement médian utilise 4 lookups ; un sur dix en utilise 9 ou plus.
• 52 domaines (0,8 %) publient deux enregistrements SPF. C'est aussi une erreur permanente : avec deux enregistrements, les destinataires n'en évaluent aucun.

La façon dont les enregistrements se terminent est moins inquiétante qu'il n'y paraît. 46,3 % se terminent par -all et 47,4 % par ~all. Avec une politique DMARC appliquée en amont, ~all est un choix tout à fait raisonnable. Seuls 2,1 % se terminent par ?all, qui ne demande rien, et à peine 3 domaines par +all, qui autorise tout Internet à envoyer en leur nom.

TipVérifiez votre propre compteur avec le vérificateur SPF gratuit. Il parcourt chaque include comme le fait un destinataire et montre quel expéditeur coûte le plus.

DMARC : largement publié, beaucoup moins souvent appliqué

82,3 % des domaines qui reçoivent des e-mails publient un enregistrement DMARC, mais seuls 58,3 % l'appliquent. L'écart s'explique par p=none : une politique qui demande aux destinataires de signaler les échecs sans rien faire à leur sujet.

Le mode surveillance est la bonne façon de démarrer avec DMARC. Ce n'est pas un endroit où rester, et les données suggèrent que beaucoup de domaines n'en sortent jamais : 21,8 % de tous les domaines de messagerie s'y trouvent actuellement.

Le volet reporting a ses propres problèmes :

• 11,0 % des domaines de messagerie publient un DMARC sans aucune adresse de rapport (rua). Ils ont une politique, mais aucun moyen de voir ce qu'elle intercepte.
• 5,3 % supplémentaires envoient leurs rapports à une adresse qui ne les recevra jamais. Lorsque l'adresse de rapport se trouve sur un autre domaine, la RFC 7489 exige que ce domaine publie un enregistrement d'autorisation (<your-domain>._report._dmarc.<their-domain>). Sans lui, les destinataires conformes n'envoient rien, et le propriétaire en conclut que personne n'envoie d'e-mails en son nom.
• 2,1 % des enregistrements DMARC n'appliquent leur politique qu'à une partie des e-mails, avec un pct inférieur à 100.

Le top 1 000 fait mieux, mais pas de beaucoup

Parmi les 1 000 domaines les plus populaires, 71,1 % ont un SPF valide et un DMARC appliqué, contre 54,1 % pour les rangs 1 001 à 10 000. Le top 1 000 utilise aussi plus souvent p=reject : 57,2 % de ses enregistrements DMARC, contre 40,8 % en dessous.

Un point se dégrade au sommet : 3,4 % des enregistrements SPF du top 1 000 dépassent la limite de lookups, contre 2,7 % en dessous. Les grandes organisations envoient via davantage de services, et chacun d'eux coûte des lookups.

Ce que j'en retiens

Je m'attendais à trouver de la négligence. Ce n'est pas le cas. Plus de neuf domaines sur dix publient un SPF, et quatre sur cinq un DMARC. Quelqu'un, à un moment donné, a fait le travail. Ce qui coince, c'est tout ce qui vient après cette première configuration.

Personne n'est responsable de l'enregistrement. Le marketing ajoute un outil de newsletter, les commerciaux un CRM, le support un helpdesk, et chacun consomme discrètement un lookup ou deux jusqu'à épuisement du budget. p=none devait durer quelques semaines d'observation et devient le réglage permanent. Et les rapports arrivent dans une boîte que personne ne lit, ou, pour un domaine sur vingt, à une adresse qui ne les recevra jamais.

Je connais ce schéma. J'ai passé douze ans à concevoir des systèmes de caisse et d'automatisation pour des restaurants et des commerces, et c'était toujours la même chose : la mise en place reçoit de l'attention, la maintenance non, parce que rien ne casse le jour où l'on fait la modification. L'authentification des e-mails est ce genre de système. Elle tombe en panne sans bruit, des semaines après la modification qui l'a cassée, et le premier signe est souvent un client qui demande pourquoi votre e-mail a atterri dans ses spams.

C'est aussi pour cela que j'ai conçu les vérificateurs d'InfraNest pour qu'ils montrent le calcul plutôt qu'une coche verte, et pourquoi je dis franchement que notre propre vérificateur SPF se trompait sur un cas jusqu'à cette semaine. C'est la confrontation de ce rapport avec un outil indépendant qui l'a révélé. Quand on mesure des choses pour les autres, on vérifie d'abord ses propres instruments.

Si votre domaine envoie des e-mails, ces trois vérifications valent bien dix minutes cette semaine :

1. Comptez vos lookups SPF. À partir de 8, anticipez avant l'arrivée du prochain outil. Déplacez les envois en masse vers un sous-domaine doté de son propre enregistrement SPF, ou supprimez les includes des services que vous n'utilisez plus.
2. Fixez une date de fin à p=none. Lisez les rapports pendant quelques semaines, corrigez les expéditeurs légitimes en échec, puis passez à quarantine et plus tard à reject.
3. Assurez-vous que vos rapports arrivent. Si rua pointe vers un autre domaine, vérifiez qu'il publie l'enregistrement d'autorisation pour le vôtre. Le vérificateur DMARC le teste pour vous.

Vérifier votre domaine

Passez votre domaine dans le vérificateur SPF et le vérificateur DMARC ; si l'un des deux doit être corrigé, le générateur SPF et le générateur DMARC créent un enregistrement corrigé. Pour détecter les modifications ultérieures de ces enregistrements, la gestion DNS d'InfraNest inclut la détection de dérive sur l'ensemble de vos fournisseurs.

Source : analyse InfraNest des 10 000 premiers domaines de la liste Tranco K9PXW (Le Pochat et al., "Tranco: A Research-Oriented Top Sites Ranking Hardened Against Manipulation", NDSS 2019), 25 septembre 2026. Données agrégées : email-auth-2026-09.json, CC BY 4.0.