Le rapport PermError SPF : 100× plus de domaines dépassent la limite des 10 requêtes que ne le montrent les décomptes de surface (2026)

Publié 2026-07-03

Chiffres arrêtés au 2026-06-29 · méthodologie v7, plus une passe de tarification des chaînes exécutée le 2026-07-03. À partir du recensement de 261 millions de domaines notés, nous avons résolu chaque cible SPF include: référencée 100 fois ou plus — 10 842 cibles couvrant 95,2 % de toutes les références include — et tarifé la chaîne retenue de chaque domaine par rapport à cette carte. Les cibles de queue non résolues ont été comptées comme zéro et le contenu des chaînes reflète le jour de résolution, si bien que le chiffre-titre est une approximation prudente, biaisée vers le bas : nous disons « au moins ». Données agrégées uniquement ; jamais l’enregistrement d’une entreprise individuelle. Voir comment nous notons.

Combien de domaines dépassent la limite des 10 requêtes SPF ?

Au moins 797 263 — parce que le SPF comporte une autodestruction intégrée à la norme, et le déclencheur se cache là où les propriétaires ne peuvent pas le voir. La RFC 7208 §4.6.4 plafonne une vérification SPF à 10 requêtes DNS ; au-delà de dix, le destinataire s’arrête et renvoie un PermError, et un enregistrement en PermError ne protège rien. Ne comptez que les requêtes visibles dans l’enregistrement lui-même — comme le fait la plupart des outils, et comme le faisait notre propre recensement jusqu’à ce rapport — et vous trouvez environ 8 000 contrevenants (7 958, précisément). Tarifez les chaînes include: que ces enregistrements tirent réellement à eux, et le décompte atteint 797 263 : environ 100 fois plus élevé.

Pourquoi les propriétaires ne le voient-ils pas venir ?

Parce que le budget est consommé par les enregistrements des autres. include:onetool.example.com se lit comme une seule ligne dans votre panneau DNS — mais le destinataire doit récupérer cet enregistrement aussi, et compter chaque mécanisme de requête qu’il contient, récursivement. Un enregistrement avec trois includes peut coûter onze. Rien n’a changé dans votre propre zone le jour où vous avez dépassé ; un fournisseur a imbriqué un include de plus, et votre SPF est mort sans avertissement.

Pire, DMARC traite un PermError comme un échec sur le volet SPF — de sorte qu’un domaine qui a cassé son SPF de cette façon échoue désormais à la moitié de sa propre authentification.

Ce que la tarification des chaînes a révélé

Constat	Domaines
Au-delà de la limite des 10 requêtes, chaînes tarifées	797 263
Au-delà de la limite en ne comptant que les mécanismes visibles	7 958
Au-delà de la limite tout en se terminant par un `-all` strict	112 215
À exactement 9–10 requêtes — le bord du précipice	2 119 539

Deux histoires dans ce tableau — la troisième, le bord du précipice, a droit à sa propre section ci-dessous :

Les décomptes de surface passent à côté d’environ 99 % de la casse. Le décompte des mécanismes visibles trouve 7 958 ; la tarification des chaînes trouve 797 263. La quasi-totalité des dégâts est héritée de ce que les includes incluent.
112 215 des enregistrements cassés se terminent par -all. Leurs propriétaires ont tout fait correctement — escaladé le mur, choisi la terminaison stricte — et un include de trop a annulé le tout. Avoir l’air strict tout en étant cassé est le mode de défaillance le plus impitoyable en sécurité des e-mails.

2,1 millions de domaines sont à un outil du précipice

Le chiffre qui devrait inquiéter les lecteurs actuellement en règle : 2 119 539 domaines se résolvent à exactement 9 ou 10 requêtes — sous la limite aujourd’hui, morts le jour où quelqu’un connecte une plateforme de plus. C’est environ 1 sur 66 de tous les publieurs SPF, et cela correspond à la forme de la distribution : l’enregistrement SPF au 99e centile se situe déjà à 9 requêtes. Souscrivez à un outil marketing de plus, collez sa ligne « il suffit d’ajouter cet include », et un enregistrement qui était sous la limite au petit-déjeuner est nul au déjeuner.

À qui la faute ? De plus en plus, à la pile technique

Les plus grands fournisseurs ont discrètement aplati leur SPF — le _spf.google.com de Google et le spf.protection.outlook.com de Microsoft se déploient désormais en simples listes d’IP ne coûtant aucune requête interne (nous avons vérifié les deux contre le DNS en direct lors de cette analyse). Les explosions viennent d’ailleurs : des chaînes de panneaux d’hébergement imbriquées sur trois niveaux, des fournisseurs régionaux dont l’include coûte à lui seul 7 à 10 requêtes, et l’accumulation honnête de SaaS — messagerie plus newsletter plus CRM plus service d’assistance, chacun « juste un include ». Presque personne n’ajoute la onzième requête exprès. Elle arrive comme la somme de décisions raisonnables.

Comment vérifier et corriger le vôtre — gratuitement

Comptez votre total réel — notre vérification gratuite résout votre chaîne, ou utilisez n’importe quel compteur de requêtes SPF.
Élaguez le poids mort : les outils que vous n’utilisez plus, les includes en double et le mécanisme ptr déprécié.
N’aplatissez que ce que vous contrôlez. Remplacer un include profond par ses blocs d’IP fonctionne pour votre propre infrastructure ; les IP de tiers changent sans préavis.
Donnez un sous-domaine aux expéditeurs de masse. Les newsletters envoyées depuis news.yourdomain.com obtiennent leur propre enregistrement et leur propre budget de 10 requêtes.

Foire aux questions

Qu’est-ce que la limite des 10 requêtes DNS du SPF ? La RFC 7208 §4.6.4 autorise au maximum 10 requêtes DNS pour évaluer un enregistrement SPF — en comptant les requêtes à l’intérieur de chaque include: récursivement. Le dépasser renvoie un PermError : l’enregistrement est traité comme invalide et n’offre aucune protection.

Que signifie un PermError SPF ? Une erreur d’évaluation permanente — le destinataire n’a pas pu traiter votre enregistrement (trop de requêtes, plusieurs enregistrements, ou une syntaxe cassée) et considère que votre domaine n’a aucun SPF utilisable. DMARC le compte comme un échec sur le volet SPF.

Combien de domaines dépassent la limite de requêtes SPF ? Au moins 797 263 sur 139 millions de publieurs SPF, selon notre passe de tarification des chaînes — soit environ 100× les 7 958 visibles sans résoudre les chaînes. Un autre lot de 2 119 539 se situe à 9–10 requêtes, à un include de la limite.

Un PermError empêche-t-il mon e-mail d’être livré ? Généralement non — les destinataires poursuivent sans SPF, et votre courrier repose sur DKIM et la réputation. Ce qui cesse de fonctionner, c’est la protection : les faussaires ne sont plus rejetés, et chaque vérification DMARC de votre courrier perd son volet SPF. C’est invisible jusqu’à ce que ce soit coûteux.

Comment réduire mon nombre de requêtes SPF ? Supprimez les includes inutilisés et ptr, aplatissez votre propre infrastructure en ip4:/ip6:, déplacez les expéditeurs de masse vers des sous-domaines, et recomptez après chaque nouvel outil. Le guide de correction vous accompagne pas à pas.

Découvrez votre vrai chiffre

Les mécanismes que vous voyez ne sont pas votre nombre de requêtes — le chiffre résolu est celui que calculent les destinataires, et c’est une vérification de 30 secondes.

Vérifiez votre domaine → · Corrigez le SPF → · Le modèle de maturité SPF → · Deux enregistrements SPF = aucun → · Le piège du ptr → · Données agrégées uniquement. Données stockées et traitées dans l’UE.