SPF PermError : ce que ça signifie et comment le corriger

Parmi tous les résultats que peut renvoyer une évaluation SPF, le PermError est le plus traître. Ce n'est ni un pass ni un fail : c'est une erreur permanente qui signifie que ton enregistrement est impossible à évaluer correctement. Pour le serveur destinataire, c'est presque comme si ton SPF n'existait pas — avec, en prime, un signal négatif pour DMARC. Le piège, c'est que ton courrier est parfaitement légitime ; seul ton enregistrement est cassé. Ce guide explique ce qu'est vraiment un PermError, ses causes principales, et comment diagnostiquer puis corriger chacune.

Les résultats possibles d'une évaluation SPF

Pour situer le PermError, il faut connaître les sept résultats que SPF peut produire :

• pass — l'IP est autorisée.
• fail (hardfail) — l'IP n'est pas autorisée, signal franc (-all).
• softfail — probablement non autorisée, signal mou (~all).
• neutral — aucune position (?all).
• none — pas d'enregistrement SPF du tout.
• temperror — erreur temporaire (souvent un souci DNS passager) ; à réessayer.
• permerror — erreur permanente : l'enregistrement est invalide ou inévaluable.

PermError et TempError se confondent souvent. La distinction est cruciale : un TempError se résout généralement tout seul (réseau, DNS momentané), alors qu'un PermError ne disparaîtra jamais sans que tu corriges ton enregistrement.

Pourquoi un PermError est dangereux

Un PermError ne « bloque » pas directement ton courrier, mais il prive ton domaine de toute protection SPF et, surtout, il pèse sur DMARC. Pour DMARC, un SPF en PermError ne s'aligne pas et ne passe pas. Si DKIM ne rattrape pas le message, celui-ci échoue à DMARC — et selon ta politique (quarantine, reject), il part en indésirable ou il est refusé. Autrement dit : un enregistrement cassé peut envoyer ton propre courrier légitime dans le mur. C'est pourquoi un PermError se corrige vite.

Cause n°1 : trop de résolutions DNS

C'est de loin la cause la plus fréquente. La RFC 7208 limite l'évaluation à dix résolutions DNS. Chaque include, a, mx, ptr, exists et redirect en consomme, et les include de prestataires se déplient en cascade. Dépasse dix, et c'est PermError. C'est si courant qu'on lui consacre un guide entier : la limite de 10 lookups DNS. La correction passe par le ménage des include inutiles, la séparation par sous-domaine, ou un aplatissement maîtrisé.

Cause n°2 : trop de « void lookups »

Plus discrète, mais bien réelle. Un void lookup est une résolution DNS qui ne renvoie rien (domaine inexistant ou enregistrement vide). La RFC limite le nombre de ces résolutions vides à deux. Au-delà, c'est aussi un PermError. La cause typique : un include qui pointe vers un domaine de prestataire supprimé, ou une faute de frappe dans un nom de domaine. Le symptôme est sournois car l'enregistrement « a l'air » correct — il faut dérouler chaque mécanisme pour repérer ceux qui ne résolvent vers rien.

Cause n°3 : une syntaxe invalide

Une simple faute de frappe peut casser tout l'enregistrement : un ip4: mal formé, un include sans deux-points, un caractère parasite, deux mécanismes collés sans espace. SPF est strict : si l'analyseur du destinataire ne peut pas interpréter un mécanisme, il renvoie PermError plutôt que de deviner. Relis attentivement, ou — plus sûr — fais valider la syntaxe par un outil.

Cause n°4 : un double enregistrement SPF

Un domaine ne doit avoir qu'un seul enregistrement v=spf1. S'il en existe deux (un posé par l'IT, un autre par le marketing, par exemple), la situation est ambiguë et de nombreux destinataires renvoient PermError — ou ignorent les deux. La correction : fusionner les deux en un unique enregistrement, en combinant leurs mécanismes et en vérifiant qu'on ne dépasse pas dix résolutions au passage.

Cause n°5 : des mécanismes obsolètes ou interdits

Certains mécanismes posent problème. Le ptr, par exemple, est déconseillé par la RFC : lent, peu fiable, il peut contribuer à un PermError et devrait être retiré. De même, des macros SPF exotiques ou des modificateurs mal placés peuvent rendre l'enregistrement inévaluable. En règle générale, un SPF sain se limite à include, ip4, ip6, a, mx (avec parcimonie) et la qualification terminale.

Comment diagnostiquer ton PermError

La bonne nouvelle, c'est qu'un PermError est déterministe : il a une cause précise, et il suffit de la trouver. La méthode :

1. Récupère ton enregistrement (dig +short TXT ton-domaine.fr) et confirme qu'il n'y en a qu'un.
2. Déplie l'arbre des include pour compter les résolutions réelles et repérer les void lookups.
3. Valide la syntaxe mécanisme par mécanisme.
4. Identifie la cause parmi les cinq ci-dessus.

Tu peux tout faire à la main, mais un analyseur va beaucoup plus vite. Notre analyseur gratuit déplie ton SPF, compte les résolutions, repère les void lookups et les fautes de syntaxe, et te dit précisément pourquoi tu es en PermError. La démarche complète de vérification est dans comment vérifier ton enregistrement.

PermError vs SoftFail vs Fail : ne pas confondre dans les rapports

Quand tu lis tes rapports agrégés, distingue bien ce que tu vois. Un fail SPF (qui peut venir d'un PermError ou d'une IP non autorisée) n'a pas la même cause qu'un softfail. Et surtout, rappelle-toi que le champ SPF des rapports reflète l'alignement, pas seulement le résultat brut. Une source en PermError apparaîtra en échec ; une fois ton enregistrement réparé, elle devrait repasser au vert. C'est la preuve définitive que la correction a porté.

Un PermError décortiqué : cas réel

Prenons un domaine qui vient de basculer en PermError sans prévenir. L'équipe jure n'avoir « rien changé ». On déroule. L'enregistrement :

v=spf1 include:_spf.google.com include:_spf.ancien-routeur.com
  include:mail.partenaire.fr include:_spf.salesforce.com include:servers.mcsv.net -all

Premier passage dans l'analyseur : deux problèmes coexistent. D'abord, include:_spf.ancien-routeur.com ne résout vers rien — le prestataire a fermé son service il y a six mois. C'est un void lookup, et il y en a un second, plus loin, sur un sous-domaine mort. Deux void lookups, c'est la limite ; le moindre autre fait basculer. Ensuite, en dépliant les include restants, on compte onze résolutions : la limite des dix est aussi dépassée. Deux causes de PermError empilées, ce qui explique pourquoi le diagnostic « à l'œil » avait échoué.

La correction est en deux temps. On retire d'abord les deux include morts (ancien-routeur et le sous-domaine défunt) : le courrier ne part plus de ces sources de toute façon. Ce simple ménage supprime les void lookups et fait retomber le décompte à huit ou neuf résolutions. Puis, comme la marge reste faible, on déplace Mailchimp (servers.mcsv.net) sur un sous-domaine news. avec son propre SPF. Le domaine racine repasse largement sous la barre, sans void lookup. PermError résolu — et la vraie leçon, c'est que « on n'a rien changé » est presque toujours faux : un prestataire a fermé, et c'est l'enregistrement qui a vieilli sous l'équipe.

Questions fréquentes

PermError veut-il dire que mon courrier est rejeté ? Pas directement par SPF, mais via DMARC : si SPF est en PermError et que DKIM ne s'aligne pas, le message échoue à DMARC et subit ta politique. En pratique, un PermError non corrigé finit par coûter des emails.

Quelle est la différence entre PermError et TempError ? Le TempError est temporaire (souci DNS passager) et se résout souvent seul ou au réessai. Le PermError est permanent : il vient de ton enregistrement et ne disparaîtra qu'après correction.

Pourquoi mon SPF est-il soudain en PermError alors qu'il marchait ? Presque toujours parce que tu as franchi la limite des dix résolutions en ajoutant un prestataire, ou parce qu'un include pointe désormais vers un domaine supprimé (void lookup). C'est un seuil franchi, pas une dégradation continue.

Combien de void lookups sont autorisés ? Deux. Au-delà de deux résolutions DNS qui ne renvoient rien, c'est PermError. Traque les include morts et les fautes de frappe dans les noms de domaine.

Un analyseur peut-il corriger automatiquement mon PermError ? Il le diagnostique précisément, mais la correction dépend de la cause (ménage, fusion, syntaxe). Un copilote comme Thomas va plus loin : il propose l'enregistrement corrigé adapté à ton cas.

Prévenir les futurs PermError

Un PermError n'arrive jamais sans raison, et les mêmes causes reviennent. Trois habitudes les évitent durablement :

• Retire l'include d'un prestataire le jour où tu cesses de l'utiliser. C'est précisément ce qui crée un void lookup quand le service ferme plus tard, des mois après que tout le monde l'a oublié.
• Surveille ton décompte de résolutions à chaque ajout de source : garde une marge avant la limite des dix, ne la frôle pas. Un enregistrement à neuf résolutions est une bombe à retardement.
• Centralise la gestion du SPF. Le double enregistrement vient presque toujours de deux équipes qui modifient le DNS chacune de leur côté. Une seule main sur l'enregistrement supprime l'ambiguïté à la racine.

Un contrôle trimestriel suffit à détecter un include devenu mort ou un décompte qui grimpe — bien avant que le PermError ne frappe en production et n'expédie tes factures en indésirable.

Laisse Thomas diagnostiquer et corriger

Un PermError a toujours une cause précise — encore faut-il la trouver vite, avant que ton courrier n'en pâtisse. Thomas, ton RSSI virtuel, déplie ton enregistrement, identifie la cause exacte (dépassement, void lookup, syntaxe, double enregistrement), et te génère l'enregistrement SPF corrigé, propre et sous la barre des dix.

Analyse ton domaine gratuitement → ou crée un compte pour sortir du PermError et y rester.