SPF permerror : corriger la limite des recherches DNS

Un résultat SPF permerror indique que l’évaluation a rencontré un problème permanent de politique ou de traitement. Ce n’est pas le même résultat que fail, qui peut correspondre à une politique valide n’autorisant pas l’IP émettrice. Avant d’ajouter un nouvel include, identifiez donc la cause précise : syntaxe, enregistrements concurrents, dépendance invalide ou dépassement du budget DNS.

Le cas étudié ici est celui d’une entreprise qui cumule messagerie, facturation, support et campagnes. Son enregistrement semble court, pourtant certains envois échouent. L’objectif est de retirer la dépendance responsable sans casser un flux rarement utilisé, comme les relances mensuelles.

Partir d’un envoi qui échoue réellement

Récupérez l’IP de sortie, l’heure et le domaine évalué par le destinataire. Utilisez les traces de réception d’un message de test ou celles du prestataire qui l’a refusé. Le domaine de l’adresse visible dans From n’est pas automatiquement celui dont le SPF a été évalué.

Demandez aussi un exemple réussi issu d’un autre service. Les deux observations doivent rester distinctes : application, domaine d’enveloppe, IP, destinataire et résultat. Si vous ne connaissez pas ces paramètres, un validateur générique peut décrire le DNS actuel sans reproduire l’incident.

Le guide d’authentification e-mail permet de remettre SPF dans son contexte. Pour ce dépannage, gardez une question plus étroite : quel parcours d’évaluation mène au permerror observé ?

Compter les termes évalués, pas les paquets réseau

La RFC 7208, section 4.6.4 impose une limite de dix termes DNS évalués : include, a, mx, ptr, exists et redirect. Les dépendances imbriquées comptent aussi. ip4, ip6 et all n’entrent pas dans ce budget. Un cache DNS rapide ne supprime pas cette limite logique.

La même section prévoit d’autres bornes, notamment pour les recherches sans réponse exploitable, dites void lookups. Elle recommande de les limiter à deux. Un compteur inférieur à dix ne suffit donc pas à garantir une politique valide. Conservez le motif détaillé retourné par votre outil.

Voici une politique fictive, utilisée uniquement pour expliquer le diagnostic :

example.com TXT "v=spf1 include:mail.example include:crm.example include:factures.example -all"

Les noms .example ne sont pas des prestataires réels. Supposons que le parcours complet de mail.example consomme quatre termes, celui de crm.example quatre autres, et celui de factures.example trois. Ces nombres incluent, dans cet exemple, chaque include parent et ses dépendances.

Une IP reconnue rapidement dans le premier groupe peut réussir. Un parcours qui doit examiner les trois groupes dépasse dix. La documentation Microsoft sur SPF rappelle qu’une même politique peut ainsi réussir pour certains expéditeurs et échouer pour d’autres, selon les termes atteints pendant l’évaluation.

Produire un inventaire avec des responsables

Exportez le TXT publié et les réponses de chaque dépendance consultée. Notez l’heure et le résolveur utilisés. Travaillez avec un outil capable d’afficher le détail du parcours ; une simple valeur « 11 » ne dit pas quel service supprimer ni quelle IP échouait.

Associez chaque branche à un propriétaire interne. Le contrat avec un fournisseur ne suffit pas : une ancienne intégration peut encore envoyer les factures d’un petit segment de clients. Demandez au responsable un exemple récent d’envoi et la configuration réellement utilisée.

Ajoutez les flux de secours, les tâches programmées et les domaines de retour personnalisés. Ce travail d’inventaire explique pourquoi un service est autorisé ; il rend les futures suppressions vérifiables.

Choisir une correction durable

La première option est de retirer une autorisation devenue inutile, après confirmation de son propriétaire. Conservez l’ancienne valeur dans le ticket de changement et indiquez le flux qui a été décommissionné. Ne retirez pas une branche seulement parce qu’elle n’apparaît pas dans une journée de journaux.

Une deuxième option consiste à supprimer une redondance démontrée. Deux instructions copiées de procédures différentes peuvent couvrir la même intégration, mais vérifiez la documentation actuelle du prestataire avant de les fusionner. Une ressemblance de noms n’établit pas que leurs périmètres sont identiques.

Une troisième option est d’isoler un service sur un domaine d’enveloppe dédié, lorsque sa plateforme le permet. Planifiez alors aussi l’alignement DMARC et les tests de réception. Changer le seul texte SPF du domaine principal ne crée pas ce nouveau trajet d’envoi.

La documentation Google de dépannage SPF conseille notamment d’examiner les inclusions imbriquées et de retirer les références aux services inutilisés. Utilisez ce contrôle comme une revue régulière de dépendances, avec un propriétaire pour chaque branche.

Évaluer le coût du flattening

Le flattening remplace des références DNS par des adresses IP calculées à un instant donné. Il peut réduire le nombre de termes interrogés, mais transfère la maintenance des changements d’IP vers le système qui publie cette liste.

Avant de retenir cette solution, demandez qui détecte une modification chez le prestataire, combien de temps elle met à être publiée et comment revenir en arrière après une erreur. Si personne ne porte cette responsabilité, la politique sera plus courte aujourd’hui et moins fiable au prochain changement d’infrastructure.

Évitez aussi de recopier une grande plage réseau pour faire disparaître une erreur. L’objectif est de représenter les expéditeurs autorisés. Une autorisation plus large que nécessaire peut résoudre le symptôme tout en changeant la politique de confiance.

Valider tous les parcours utiles

Préparez une matrice d’essais avant la publication : service, propriétaire, IP ou pool utilisé, domaine d’enveloppe et destinataire de test. Ajoutez un cas non autorisé dans un validateur SPF local ou hors envoi, afin de vérifier que la correction n’a pas élargi la politique par accident.

Après le changement, observez les réponses DNS et tenez compte du TTL des anciennes valeurs. Refaites les essais avec chaque application, puis contrôlez les résultats reçus. Un succès depuis la messagerie principale ne valide pas la plateforme de facturation.

Gardez enfin un contrôle séparé de la réputation. Réparer SPF ne supprime pas un signal lié à une activité malveillante ni une règle privée du destinataire. La surveillance des changements de réputation peut accompagner ce suivi. Si un domaine ou une IP apparaît dans un refus, consultez son rapport IsMalicious et conservez ce contexte avec le résultat technique de vos essais.