SPF : trop de requêtes DNS, comment corriger la limite de 10 et le permerror

Ce que signifie « trop de requêtes DNS »

Quand un serveur destinataire vérifie SPF, il lit l’enregistrement TXT commençant par v=spf1 sur le domaine de l’expéditeur d’enveloppe (l’adresse MAIL FROM, visible ensuite dans Return-Path) et évalue ses termes de gauche à droite. Certains termes obligent le destinataire à lancer une nouvelle requête DNS. La section 4.6.4 de la RFC 7208 limite ces termes à 10 par vérification, y compris ceux de chaque enregistrement inclus. Si l’évaluation en demande un onzième, le destinataire doit s’arrêter et renvoyer permerror, le résultat réservé aux enregistrements publiés qui n’ont pas pu être interprétés correctement.

On le remarque en général à l’un de ces trois endroits : l’en-tête Authentication-Results d’un message reçu (RFC 8601), par exemple spf=permerror smtp.mailfrom=example.com ; un message de non-remise qui évoque un trop grand nombre de requêtes ; ou des erreurs SPF dans vos rapports agrégés DMARC.

Deux détails rendent l’erreur déroutante. Les destinataires comptent les requêtes pendant l’évaluation, et l’évaluation s’arrête au premier terme qui correspond. Le courrier d’un service placé tôt dans l’enregistrement peut donc continuer de passer, tandis que celui d’un service dont l’include arrive après la dixième requête reçoit permerror : le problème peut sembler intermittent. Ensuite, permerror n’est pas un fail : SPF cesse simplement d’aider. DMARC réussit quand SPF ou DKIM réussit pour un domaine aligné sur l’adresse From (RFC 9989) ; un message doté d’une signature DKIM alignée passe donc toujours, alors qu’un message qui comptait sur SPF seul échoue. Au-delà, la façon de traiter un permerror relève de chaque destinataire.

Quels termes SPF comptent dans la limite, et lesquels non

Le budget vaut pour toute l’évaluation, pas pour un seul enregistrement. Un include coûte une requête pour lui-même, puis tout ce que coûte l’enregistrement derrière lui, jusqu’au dernier niveau d’imbrication. Les fournisseurs modifient leurs propres enregistrements, par exemple en répartissant leurs plages d’adresses sur davantage d’include imbriqués : votre total peut donc changer sans que vous ayez touché à quoi que ce soit.

La limite existe parce qu’un enregistrement SPF fait envoyer des requêtes DNS aux destinataires pour le compte de celui qui le publie ; la section 11.1 de la RFC 7208 décrit comment un attaquant pourrait sinon s’en servir pour submerger le DNS d’un tiers. La RFC suggère aussi une durée maximale pour toute la vérification, d’au moins 20 secondes. La dépasser donne temperror, une erreur temporaire, et non permerror.

La seconde limite : pas plus de deux requêtes vides

La RFC 7208 ajoute une limite distincte pour les requêtes qui reviennent vides : une réponse sans enregistrement (NOERROR avec zéro réponse) ou une erreur de nom (NXDOMAIN, le nom n’existe pas). On les appelle requêtes vides (void lookups). Les implémentations DEVRAIENT en accepter deux au plus, et dépasser ce seuil donne aussi permerror, même si le total reste sous 10. Cela empêche un enregistrement SPF d’envoyer les destinataires à la recherche de longues listes de noms inexistants.

Les requêtes vides viennent le plus souvent de vestiges :

• a:old-web.example.com après la suppression du nom DNS de l’ancien serveur.
• mx ou mx:example.org sur un nom sans enregistrement MX. Le mécanisme ne doit pas se rabattre sur l’enregistrement A du nom : il ne trouve donc rien.
• a sur le domaine nu après le déménagement du site vers un hébergeur qui ne répond que sur www.

Avec include:, la règle est plus stricte. Si le nom inclus n’existe pas ou ne publie pas d’enregistrement SPF, l’include ne compte pas seulement comme requête vide : il rend tout le résultat permerror immédiatement (section 5.2). C’est ce qui arrive quand un fournisseur que vous n’utilisez plus abandonne le domaine que votre enregistrement inclut encore. Interrogez chaque nom vers lequel pointe votre enregistrement ; un nom qui ne renvoie rien doit être corrigé ou retiré.

Comment compter vos requêtes SPF à la main

Partez du domaine de l’expéditeur d’enveloppe, que vous lisez dans l’en-tête Return-Path d’un message que vous avez envoyé, et parcourez l’enregistrement de façon récursive :

1. Lisez l’enregistrement : dig +short TXT example.com, ou nslookup -type=TXT example.com sous Windows.
2. Comptez 1 pour chaque include, a, mx, ptr, exists et redirect, et 0 pour ip4, ip6 et all.
3. Pour chaque include et chaque redirect, lisez l’enregistrement cible et comptez-le de la même manière, jusqu’au niveau le plus profond.
4. Additionnez le tout et notez chaque nom qui n’a renvoyé aucun enregistrement.

Voici un enregistrement fictif qui ne montre que cinq termes à requête :

example.com.  TXT  "v=spf1 mx include:_spf.mail.example.net include:spf.crm.example.org include:news.example.net a -all"

Ce total est le pire cas. Un expéditeur reconnu par le premier include demande au plus cinq requêtes et passe. Un expéditeur qui ne correspond à rien avant atteint le a final, onzième requête : le courrier usurpé reçoit donc permerror au lieu du fail que -all devait produire. Refaites le compte à chaque nouveau service d’envoi, et de temps en temps de toute façon, car les enregistrements inclus changent sans préavis.

Repasser sous dix sans perdre de courrier

• Retirez les include inutilisés. Un ancien fournisseur de messagerie, un outil de newsletter résilié, un CRM essayé quelques semaines. Les rapports agrégés DMARC montrent quelles sources envoient réellement au nom de votre domaine, ce qui aide à repérer les include dont personne n’a besoin. Voyez avec le responsable de chaque service avant de le retirer.
• Vérifiez si un include est seulement évalué. SPF est vérifié sur le domaine de l’expéditeur d’enveloppe. Si les messages d’un service affichent son propre domaine dans Return-Path, les destinataires consultent l’enregistrement SPF de ce domaine, pas le vôtre, et votre include ne sert à rien pour ce courrier. Confirmez-le dans la documentation du fournisseur avant de le supprimer.
• Remplacez a et mx par ip4 et ip6 pour les serveurs que vous gérez. Si votre propre serveur envoie depuis 192.0.2.10, ip4:192.0.2.10 ne coûte rien, alors que a coûte une requête. Demandez-vous si mx a sa place : les serveurs qui reçoivent votre courrier n’en envoient pas forcément, et s’ils appartiennent à votre fournisseur de messagerie, son include couvre peut-être déjà ses serveurs d’envoi. Mettez l’adresse à jour quand le serveur change.
• Donnez à chaque expéditeur à fort volume son propre sous-domaine. Faites utiliser à un service de newsletter ou de tickets un domaine de rebond comme news.example.com en expéditeur d’enveloppe, avec son propre enregistrement SPF et sa propre limite de 10. SPF ne s’hérite pas : le sous-domaine a besoin de cet enregistrement. Avec l’alignement relâché qu’applique DMARC par défaut, news.example.com reste aligné sur une adresse From en example.com. Beaucoup de services parlent de domaine de rebond ou de return-path personnalisé.
• Supprimez ptr. La RFC 7208 indique qu’il NE DEVRAIT PAS être publié : il est lent, dépend du DNS inverse contrôlé par le détenteur de l’adresse IP qui se connecte, et consomme des requêtes. Remplacez-le par ip4/ip6 ou par l’include du fournisseur.
• Réordonner n’est pas une correction. Placer l’expéditeur le plus actif en tête réduit le nombre de messages qui atteignent la onzième requête, mais l’enregistrement reste cassé pour tout ce qui suit, y compris le courrier usurpé qui devrait tomber sur -all.

DKIM allège aussi la pression. DMARC n’a besoin que d’un seul résultat aligné réussi, et DKIM résiste en général au transfert, contrairement à SPF. Assurez-vous que chaque service signe avec votre domaine, puis allégez l’enregistrement SPF.

L’aplatissement SPF (flattening) : moins de requêtes, plus d’entretien

L’aplatissement remplace un include par les plages ip4 et ip6 vers lesquelles il se résout aujourd’hui. Le nombre de requêtes baisse, mais votre enregistrement contient désormais une copie de la liste de quelqu’un d’autre, et cette copie ne se met pas à jour toute seule.

Les services d’aplatissement automatique résolvent les include à intervalles réguliers et réécrivent votre enregistrement. Cela règle le problème des plages périmées, mais donne à un tiers un rôle dans votre DNS, et une mise à jour ratée casse votre SPF. Essayez d’abord les autres solutions. Si vous aplatissez malgré tout, notez quel include vous avez remplacé et quand, comparez régulièrement avec les plages publiées par le fournisseur et testez SPF après chaque modification (Microsoft Learn donne le même conseil à ses clients).

Un seul enregistrement SPF par nom, correctement découpé

Un nom doit porter exactement un enregistrement TXT commençant par v=spf1. S’il y en a deux, le destinataire ne peut pas choisir et renvoie permerror (section 4.5 de la RFC 7208). Cela arrive souvent quand le guide de configuration d’un nouveau service dit « ajoutez cet enregistrement TXT » et que quelqu’un crée un second enregistrement SPF au lieu de modifier le premier. Un second enregistrement ne double donc pas le budget ; fusionnez les deux :

# Incorrect : deux enregistrements SPF sur le même nom
example.com.  TXT  "v=spf1 include:_spf.mail.example.net -all"
example.com.  TXT  "v=spf1 include:spf.crm.example.org ~all"

# Correct : un seul enregistrement
example.com.  TXT  "v=spf1 include:_spf.mail.example.net include:spf.crm.example.org -all"

Les autres enregistrements TXT du même nom, comme les jetons de vérification de services, ne posent pas de problème ; seuls comptent ceux qui commencent par v=spf1. Une chaîne dans un enregistrement TXT contient au plus 255 caractères. Un enregistrement SPF plus long reste un unique enregistrement TXT composé de plusieurs chaînes entre guillemets, que les destinataires concatènent sans ajouter d’espace (section 3.3). Terminez donc une chaîne par une espace là où un terme se termine :

example.com.  TXT  "v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::/32 include:_spf.mail.example.net " "include:spf.crm.example.org -all"

D’autres erreurs produisent le même permerror : une erreur de syntaxe n’importe où dans l’enregistrement, comme include= au lieu de include: (section 4.6), ou un include vers un domaine sans enregistrement SPF. Les enregistrements SPF ne s’héritent pas non plus : chaque nom utilisé comme expéditeur d’enveloppe a besoin de son propre enregistrement, et chacun dispose de sa propre limite de 10.

Ce que compte le vérificateur SPF et DMARC gratuit

Le snapshot gratuit de Sitelemetry exécute huit contrôles passifs sur un domaine public, sans inscription ; l’un d’eux lit les enregistrements DNS de messagerie. Ce n’est pas un test d’intrusion, ni l’audit des six domaines, et il n’envoie aucun e-mail.

• Nom d’hôte exact. Il lit l’enregistrement SPF du nom saisi, sans repli sur le domaine parent. Saisissez le domaine de l’expéditeur d’enveloppe lui-même, par exemple example.com plutôt que www.example.com.
• Compte au premier niveau. Il compte les termes à requête DNS de cet enregistrement (include, a, mx, ptr, exists et redirect) et signale plus de dix comme risque moyen.
• Ce qu’il ne suit pas. Il ne suit ni include: ni redirect=, ne compte pas les requêtes vides et ne signale pas un second enregistrement SPF sur le même nom. L’exemple à cinq termes ci-dessus passe ce compte alors que les destinataires ont besoin de onze requêtes : faites donc aussi le compte récursif vous-même.
• Autres signaux SPF. +all est signalé comme risque élevé et ?all comme faible ; l’absence d’enregistrement SPF ou DMARC est signalée quand l’hôte a des enregistrements MX.

Pour ouvrir d’abord le contrôle du DNS de messagerie, utilisez le vérificateur SPF et DMARC gratuit : il lance le même snapshot et affiche ce contrôle au-dessus des sept autres. Pour le reste de l’enregistrement, du choix entre ~all et -all au passage de DMARC de none à reject, consultez le guide SPF et DMARC.