Defaults.Exposed › Corrections › Guides

SPF PermError : comment corriger « trop de lookups DNS » sans casser votre e-mail (2026)

Publié 2026-07-08

Chiffres au 2026-06-29 · méthodologie v7. Données de recensement agrégées sur 261 millions de domaines évalués. Voir comment nous notons.

Au moins 797 263 domaines dépassent la limite de 10 lookups DNS de SPF, selon le recensement Defaults.Exposed portant sur 261 086 232 domaines — sur 139 millions d’éditeurs SPF. Au-delà de dix lookups, un destinataire s’arrête et retourne PermError : votre SPF est nul, et DMARC compte un PermError comme un échec.

Le correctif a un ordre strict, et la plupart des guides l’inversent. Comptez vos vrais lookups résolus ; supprimez les includes morts et inutilisés — cela seul corrige la plupart des enregistrements ; déplacez les expéditeurs en masse vers des sous-domaines avec leur propre budget SPF ; aplatissez seulement en dernier recours, et seulement avec un re-aplatissement automatisé, parce que l’aplatissement statique se dégrade et casse silencieusement la livraison.

Que signifie « SPF PermError : too many DNS lookups » ?

Le RFC 7208 §4.6.4 plafonne chaque vérification SPF à 10 lookups DNS. Au-delà de dix, le destinataire s’arrête et retourne PermError — l’enregistrement entier est traité comme cassé, pas seulement la partie hors budget. La même section ajoute un second plafond moins connu : au maximum 2 « void lookups » (requêtes ne retournant aucune réponse ou NXDOMAIN), donc quelques entrées include: mortes pour des services annulés peuvent annuler votre SPF à elles seules.

La conséquence est pire que « pas de SPF » : DMARC traite un PermError comme un échec SPF, donc un domaine qui casse son propre SPF est non authentifié sur la branche SPF de chaque évaluation DMARC. Si DKIM n’est pas configuré ou casse en transit, ce courrier échoue désormais DMARC purement et simplement.

Un chiffre du recensement montre à quel point ce mode d’échec est cruel : 112 215 domaines publient un enregistrement strict -all qui est nul à cause d’un dépassement de lookups — sur les 54 655 923 domaines qui publient -all tout court. Leurs propriétaires ont fait la partie difficile — choisi la terminaison stricte — et un include de trop a coupé tout l’enregistrement. Ils ont l’air stricts ; ils sont cassés. Pour l’image de données complète, voir le rapport SPF PermError.

Pourquoi mon SPF a-t-il cassé alors que je n’ai rien changé ?

Parce que le budget est en grande partie dépensé par les enregistrements d’autres personnes. Chaque include: est évalué de façon récursive, et chaque mécanisme de lookup à l’intérieur compte contre votre dix. Une seule ligne dans votre panneau DNS peut coûter quatre ou cinq lookups une fois résolue. Un prestataire imbrique un include de plus, et votre SPF meurt sans aucun changement dans votre zone.

Les grandes plateformes ne sont pas le problème : Google et Microsoft ont tous deux aplati leur propre SPF — _spf.google.com et spf.protection.outlook.com se développent en simples listes d’IP coûtant zéro lookup interne (vérifié contre le DNS en direct, juillet 2026). Les vraies explosions viennent de chaînes d’includes de panneaux d’hébergement imbriquées sur plusieurs niveaux, et de l’empilement SaaS honnête — boîte aux lettres plus newsletter plus CRM plus centre d’aide, chacun « juste un include ». Personne n’ajoute le onzième lookup exprès ; il arrive comme la somme de décisions raisonnables. C’est pourquoi le bord du gouffre est si peuplé : 2 119 539 domaines sont exactement à 9–10 lookups résolus — environ 1 sur 66 de tous les éditeurs SPF, bien aujourd’hui, nuls le jour où quelqu’un colle un include de plus. L’enregistrement SPF du 99e centile se résout déjà à 9 lookups. Si votre pile est riche en SaaS, le guide SPF échouant pour les outils SaaS couvre la version fournisseur par fournisseur.

Quelles parties d’un enregistrement SPF comptent comme des lookups DNS ?

Comptez le total résolu, pas les lignes visibles. Quatre includes peuvent être quatre lookups ou quatorze.

Comment corriger « too many DNS lookups » sans casser l’e-mail ?

1. Lancez le scan gratuit avant de toucher au DNS. Il résout votre chaîne d’includes complète et montre votre vrai décompte de lookups, pour que vous corrigiez le vrai problème — pas l’enregistrement tel qu’il apparaît dans votre panneau. (S’il indique que vous n’avez aucun SPF du tout, c’est un échec différent — voir « SPF record not found ».)
2. Supprimez d’abord les includes morts et inutilisés. L’outil que vous avez abandonné en 2023, l’include de l’ancien hébergeur qui a survécu à une migration, les doublons, tout mécanisme ptr. Les includes morts sont doublement toxiques : ils brûlent du budget de lookups et sont la source habituelle des void lookups. La plupart des enregistrements hors budget repassent sous 10 avec cette seule étape. Si votre enregistrement porte encore les mécanismes d’un prestataire précédent, suivez le guide de nettoyage de migration.
3. Vérifiez que chaque include restant fait quelque chose. Les destinataires évaluent SPF contre le domaine du Return-Path (RFC5321.MailFrom), pas l’en-tête From — et de nombreux outils SaaS mettent leur propre domaine de rebond sur le Return-Path, donc leur include dans votre enregistrement ne fait rien d’autre que dépenser du budget. Gardez les includes seulement pour les services qui utilisent votre domaine comme Return-Path ; pour les autres, activez plutôt le DKIM en domaine personnalisé du fournisseur.
4. Déplacez les expéditeurs en masse vers des sous-domaines. Newsletters depuis news.votredomaine.com, courrier transactionnel depuis mail.votredomaine.com. Chaque sous-domaine obtient son propre enregistrement SPF avec un budget de 10 lookups tout neuf, et un problème dans un flux cesse de contaminer les autres.
5. Ensuite seulement, envisagez l’aplatissement — et seulement l’aplatissement automatisé. Voir ci-dessous.
6. Relancez le scan pour confirmer que vous êtes confortablement sous 10 — visez de la marge, pas exactement 10, ou vous venez de rejoindre les 2,1 millions de domaines au bord du gouffre. Puis parcourez tout ce que le scan signale d’autre sur la page corriger SPF.

Devrais-je aplatir mon enregistrement SPF ?

L’aplatissement remplace les includes par leurs blocs ip4:/ip6: sous-jacents, qui coûtent zéro lookup. Cela fonctionne — et fait à la main, c’est une panne de livraison à retardement.

Les prestataires font tourner leurs IP d’envoi régulièrement et ne l’annoncent à personne. Une liste d’IP statique est correcte le jour où vous la collez et discrètement fausse en quelques mois — et comme l’échec se manifeste par d’autres personnes qui ne reçoivent pas votre courrier, vous le découvrez tard. Si l’élagage et les sous-domaines vous ramènent sous la limite, arrêtez-vous là ; ne recopiez jamais à la main les blocs d’IP d’un tiers comme correctif permanent.

Questions fréquentes

Un PermError SPF signifie-t-il que mon e-mail cesse d’être livré ? Pas instantanément — c’est ce qui le rend dangereux. DMARC compte un PermError comme un échec SPF, donc la livraison repose entièrement sur DKIM ; si DKIM est absent ou casse en transit, vous échouez DMARC. Sur 139 millions d’éditeurs SPF dans notre recensement (au 2026-06-29), au moins 797 263 sont dans cet état — la plupart sans le savoir.

Mon enregistrement n’a que quatre includes — comment peut-il dépasser 10 lookups ? Les includes sont comptés de façon récursive : tout ce qui se trouve à l’intérieur de chaque include (et à l’intérieur de ses includes) est facturé à votre budget, donc quatre lignes visibles peuvent se résoudre en quatorze lookups. Comptez avec un outil de résolution, pas à l’œil — résoudre les chaînes est comment notre rapport PermError a trouvé environ 100× plus de domaines cassés que ne le montrent les décomptes de surface.

Je termine mon enregistrement par -all — je suis sûrement protégé ? Seulement si l’enregistrement s’évalue. Notre recensement (au 2026-06-29) a trouvé 112 215 domaines dont l’enregistrement strict -all est nul à cause d’un dépassement de lookups. Un qualificateur strict sur un enregistrement PermError ne protège rien.

La limite est-elle de 10 lookups par include ou pour tout l’enregistrement ? Toute l’évaluation : le RFC 7208 §4.6.4 plafonne la vérification complète à 10, plus au maximum 2 void lookups. Chaque sous-domaine a son propre enregistrement et son propre budget — c’est pourquoi l’étape 4 fonctionne.

Les entrées ip4 et ip6 comptent-elles dans la limite ? Non — les mécanismes IP ne coûtent rien, ce qui explique exactement pourquoi l’aplatissement réduit le décompte.

Envoyez le rapport au propriétaire

Si vous corrigez cela pour un client ou votre employeur, terminez le travail avec des preuves. Relancez le scan gratuit après vos modifications et transmettez le rapport noté au chef d’entreprise : langage clair, daté, PermError disparu. C’est l’artefact dont il aura besoin pour le renouvellement de cyberassurance et le prochain questionnaire de sécurité client — la différence entre « j’ai modifié quelques enregistrements DNS » et un avant-après documenté.

Vérifiez votre domaine gratuitement

Voyez votre vrai décompte de lookups résolus — et tout le reste sur SPF, DKIM et DMARC — en privé et réservé au propriétaire.

Vérifiez votre domaine → · Corriger SPF → · SPF échouant pour les outils SaaS → · Configurer SPF sur GoDaddy → · Comment nous notons → · Données agrégées uniquement. Données stockées et traitées dans l’UE.