Erreur SPF PermError : la limite de 10 résolutions DNS

Dernière mise à jour : 4 novembre 2026

C'est la panne la plus sournoise de l'authentification des emails : votre SPF est bien publié, sa syntaxe est correcte, et pourtant il n'authentifie plus rien. Aucune alerte, aucun message d'erreur, aucune trace dans vos outils. Vos messages partent simplement avec une authentification dégradée, et vous le découvrez quand la délivrabilité s'effondre.

La cause tient en une phrase : un enregistrement SPF ne peut déclencher que dix résolutions DNS.

D'où vient cette limite

Elle est inscrite dans la norme qui définit SPF, la RFC 7208, à la section 4.6.4. Sa raison d'être est défensive : sans elle, un attaquant pourrait publier un SPF en cascade qui ferait exécuter des milliers de requêtes DNS à chaque serveur de messagerie évaluant un message. SPF deviendrait un amplificateur d'attaque par déni de service.

La norme impose donc un plafond strict, et surtout une sanction nette : au-delà de dix résolutions, l'évaluation doit échouer avec le statut PermError. Pas « continuer au mieux », pas « ignorer le reste », échouer.

Ce qui compte, et ce qui ne compte pas

Toutes les instructions d'un SPF ne consomment pas de résolution. La distinction est essentielle pour diagnostiquer.

Consomment une résolution : include, redirect, a, mx, ptr, exists.

N'en consomment aucune : ip4, ip6, all.

C'est contre-intuitif mais ip4:192.0.2.0/24 est gratuit, quelle que soit la taille de la plage, alors que include:un-prestataire.example coûte au moins un point, et souvent davantage.

Le piège vient de la récursivité. Un include compte pour un, mais tout ce que l'enregistrement inclus déclenche à son tour s'additionne à votre total. Un seul include peut donc en consommer cinq.

Ce que coûtent réellement les prestataires

J'ai mesuré ces valeurs le 3 novembre 2026, en résolvant récursivement chaque enregistrement. Elles évoluent : les prestataires réorganisent leurs enregistrements sans prévenir.

Deux surprises par rapport à ce qu'on lit encore partout. Google et Microsoft ont aplati leurs enregistrements : ils ne contiennent plus que des plages d'adresses, sans aucun include imbriqué. Les documentations qui annoncent « Google coûte 4 résolutions » sont périmées.

À l'inverse, Mailgun en consomme cinq à lui seul, parce qu'il inclut une zone générale et une zone européenne, dont l'une inclut encore deux sous-enregistrements. Google Workspace plus Mailgun plus SendGrid vous place déjà à huit sur dix.

Reconnaître le problème

Le symptôme principal est l'absence de symptôme : rien ne casse visiblement. Les indices à chercher :

• dans les rapports DMARC agrégés, le résultat SPF remonte en permerror au lieu de pass ou fail ;
• dans les en-têtes d'un message reçu, Received-SPF: permerror ou spf=permerror dans Authentication-Results ;
• une délivrabilité qui se dégrade peu après l'ajout d'un nouvel outil d'emailing.

Ce dernier point est révélateur : la panne apparaît presque toujours le jour où l'on ajoute un prestataire de plus, sans rapport apparent avec les messages qui commencent à poser problème.

Mesurer avant de corriger

Radar DNS affiche le total et le détail. Analysez votre domaine, onglet Email : la carte SPF indique le nombre de résolutions sur dix, et la liste de chaque include avec son coût individuel, trié du plus coûteux au moins coûteux. Vous voyez immédiatement lequel vous ruine.

Un repère utile : sur vingt-quatre grands comptes que j'ai scannés, aucun ne dépassait la limite, mais trois se trouvaient exactement à dix sur dix, saturés, un prestataire de plus et leur SPF cassait. La marge est plus étroite qu'on ne l'imagine.

Les corrections, de la meilleure à la pire

Un sous-domaine dédié par prestataire

C'est la bonne réponse, celle qu'emploient les gros expéditeurs. Plutôt d'empiler tous vos prestataires dans un seul SPF, vous faites partir chaque flux depuis un sous-domaine distinct : info.exemple.fr pour l'infolettre, notifications.exemple.fr pour les messages transactionnels.

Chaque sous-domaine porte alors son propre SPF, avec un seul prestataire et donc un ou deux lookups. La limite ne se pose plus. Bénéfice supplémentaire : la réputation de chaque flux est isolée, et une campagne marketing qui se passe mal ne contamine pas vos factures.

Retirer ce qui ne sert plus

Avant toute optimisation, regardez simplement la liste. Les SPF accumulent les couches : un outil testé il y a trois ans, un prestataire résilié, un mx ou un a hérité d'une configuration disparue. Chaque ligne inutile est une résolution gratuite à récupérer.

Les instructions a et mx sont souvent les premières à sauter : elles servaient à autoriser votre propre serveur, ce qui n'a plus de sens quand tout part de prestataires externes.

Remplacer un include coûteux par des adresses

Si un prestataire publie des plages d'adresses stables, vous pouvez remplacer son include par les ip4: correspondants, qui ne coûtent rien.

C'est efficace, mais c'est une dette : le jour où le prestataire change ses adresses, vos messages cessent d'être authentifiés et personne ne vous préviendra. Ne faites cela que pour un prestataire dont les plages sont contractuellement figées, et notez quelque part qu'il faut les vérifier.

L'aplatissement automatique

Des services proposent de « compresser » votre SPF en résolvant tous les includes et en publiant le résultat à plat, remis à jour automatiquement.

Cela fonctionne, mais vous confiez à un tiers un maillon critique de votre authentification : s'il tombe ou se trompe, votre SPF casse. Et cela ne règle pas la cause, cela la masque. À réserver aux cas où le découpage par sous-domaine est impossible.

Ce qu'il ne faut pas faire

Publier deux enregistrements SPF. C'est une erreur fréquente quand on veut « ajouter » un prestataire. La norme l'interdit : un domaine qui publie deux enregistrements commençant par v=spf1 provoque un PermError, exactement comme le dépassement. Il faut un seul enregistrement, avec plusieurs include.

Croire que le problème disparaît avec DKIM. DKIM authentifie indépendamment, et c'est effectivement lui qui sauve l'alignement DMARC quand SPF échoue. Mais un SPF en PermError reste un SPF cassé, interprété défavorablement par certains filtres, et il vous prive d'un des deux mécanismes.

Un cas où l'absence de SPF est normale

Si votre domaine d'envoi utilise une délégation par CNAME (le montage que proposent SendGrid ou Mailgun) l'enveloppe SMTP de vos messages part d'un sous-domaine du prestataire, qui porte lui-même le SPF. Le SPF n'est alors jamais évalué sur votre nom, et c'est la signature DKIM qui aligne DMARC.

Dans ce cas précis, ajouter un include chez vous ne sert strictement à rien. Radar DNS reconnaît ce montage et affiche « SPF délégué au prestataire » plutôt que de réclamer un enregistrement inutile.