SPF : trop de lookups DNS

Cette panne est désagréable précisément parce que rien n'a l'air cassé. Votre enregistrement SPF est syntaxiquement valide. Il liste les bons serveurs. Vous pouvez le lire, et tout ce qu'il contient est correct.

Ce que vous constatez à la place :

• Du courrier légitime d'un prestataire commence à partir en indésirables, souvent d'un seul prestataire, souvent après l'ajout d'un nouvel outil.
• Les rapports agrégés DMARC affichent spf=permerror, ou spf=none, pour des sources dont vous savez qu'elles sont les vôtres.
• Un vérificateur SPF en ligne signale « trop de résolutions DNS » ou « permerror », alors qu'un simple validateur de syntaxe déclare l'enregistrement conforme.

Les deux outils se contredisent parce qu'ils ne répondent pas à la même question. Un validateur de syntaxe demande si l'enregistrement est bien formé. Évaluer la limite de résolutions suppose de le résoudre réellement, récursivement, comme le fait un serveur destinataire.

Une conséquence qu'il vaut mieux énoncer franchement : si vous publiez DMARC, un permerror signifie que la moitié SPF de votre authentification a disparu. Tout repose alors sur DKIM seul, et toute source qui ne signe pas échouera.

SPF est évalué par le serveur destinataire, au moment de la remise, pour chaque message. Chaque include: qu'il rencontre déclenche une requête DNS de plus, et ces include: peuvent s'imbriquer.

Sans plafond, un enregistrement forgé malicieusement pourrait faire exécuter à n'importe quel destinataire des centaines de résolutions par message, transformant chaque serveur de messagerie d'Internet en amplificateur pointé vers le serveur de noms choisi par l'attaquant. La limite est une protection contre le déni de service, pas une contrainte arbitraire : c'est pourquoi aucun destinataire ne la relèvera pour vous.

La RFC 7208 la fixe à dix. C'est un plafond strict, appliqué à l'enregistrement entièrement déplié, et le dépasser produit une erreur permanente plutôt qu'une évaluation partielle.

Une seconde limite, moins connue, l'accompagne : deux résolutions vides au maximum, c'est-à-dire des requêtes qui ne renvoient aucun enregistrement. Un include: pointant vers un prestataire que vous n'utilisez plus, dont l'enregistrement a depuis été supprimé, en consomme une sur les deux.

Seuls certains mécanismes coûtent une résolution. C'est la partie qui surprend, et la connaître change ce qu'on cherche à optimiser.

• Coûtent une résolution chacun : include, a, mx, ptr, exists, et le modificateur redirect=. Les include: imbriqués ajoutent les leurs.
• Ne coûtent rien : ip4, ip6 et all. Ils se résolvent en littéraux, le destinataire n’interroge donc rien.

Toute la partie se joue sur cette asymétrie. Chaque include: que vous parvenez à transformer en ip4: est une résolution récupérée.

Ce que coûtent réellement les prestataires Le chiffre publié par un prestataire est rarement le vrai, parce que son enregistrement en inclut d'autres. Google Workspace en est l'exemple classique : include:_spf.google.com paraît coûter une résolution, mais il se déplie en trois include: de plages supplémentaires, soit environ quatre au total. Microsoft 365 est plus économe, généralement une ou deux.

Ajoutez une plateforme marketing, un expéditeur transactionnel et une billetterie : vous dépassez dix sans avoir rien ajouté d'inhabituel.

Faire le compte Lisez d’abord votre enregistrement :

dig +short TXT exemple.com | grep spf1

Puis résolvez chaque include: à son tour et comptez ce qu'il contient. Faire ce travail à la main une fois vaut ses vingt minutes : il vous montre exactement où part votre budget, au lieu de vous donner un nombre. Ensuite, servez-vous d'un vérificateur qui affiche le compte déplié.

Procédez dans cet ordre. Les premières étapes sont gratuites, et elles suffisent souvent à elles seules.

1. Retirez ce que vous n’utilisez plus C'est presque toujours le plus gros gain, et le moins risqué. Les organisations accumulent les expéditeurs : une plateforme testée il y a deux ans, un outil d'infolettre remplacé au printemps dernier, un CRM migré depuis. Chacun a laissé son include: derrière lui.

Recoupez chaque include: avec vos rapports DMARC. Une source qui n'a rien envoyé depuis des mois est candidate au retrait, et le retrait ne coûte rien si vous aviez raison.

2. Prenez l’include le plus étroit que documente le prestataire Plusieurs prestataires publient à la fois un enregistrement large couvrant toute leur plateforme et un plus étroit pour le service précis que vous utilisez. L'étroit coûte généralement moins de résolutions. Consultez leur documentation plutôt que de recopier la valeur trouvée sur un forum.

3. Remplacez a et mx par des adresses explicites Si vos serveurs de messagerie ont des adresses stables, mx coûte une résolution que ip4: ne coûte pas. Le compromis est réel : il faudra désormais mettre l'enregistrement à jour quand l'adresse change. Faites-le là où l'adresse ne bouge véritablement jamais, pas partout.

4. Supprimez ptr purement et simplement Le mécanisme ptr est déprécié par la RFC, lent et peu fiable. S'il figure dans votre enregistrement, il ne devrait pas y être.

Les étapes précédentes vous achètent de la marge. Celle-ci change la nature du problème, et c'est la réponse pour une organisation qui a réellement beaucoup d'expéditeurs.

La limite de dix résolutions s'applique au domaine évalué. Or un sous-domaine est, de ce point de vue, un domaine différent, avec son propre budget.

Donc au lieu d’un enregistrement unique qui porte tout :

exemple.com          "v=spf1 include:_spf.google.com include:marketing include:crm include:facturation -all"

faites partir chaque famille de courrier de son propre sous-domaine, avec son propre enregistrement :

exemple.com          "v=spf1 include:_spf.google.com -all"
news.exemple.com     "v=spf1 include:prestataire-marketing.net -all"
factures.exemple.com "v=spf1 include:prestataire-facturation.net -all"

Votre messagerie d'entreprise garde le domaine racine et reste très en deçà de la limite. Chaque plateforme dispose de son budget, et aucune ne peut faire déborder les autres.

Trois bénéfices supplémentaires justifient la migration :

• Un problème de délivrabilité sur le courrier marketing cesse de contaminer la réputation de vos factures et de vos échanges quotidiens.
• Vos rapports DMARC deviennent lisibles, chaque sous-domaine remontant séparément.
• Ajouter une plateforme l'an prochain ne signifie plus réauditer tout l'enregistrement.

Le coût est réel : chaque plateforme d'envoi doit être reconfigurée pour utiliser le nouveau domaine d'expédition, et DKIM doit être mis en place pour chaque sous-domaine. Prévoyez une migration, pas un après-midi. Mais c'est le seul correctif qu'il ne faudra pas refaire la prochaine fois que quelqu'un souscrira à un outil.

Aplatir consiste à résoudre soi-même chaque include: et à écrire les plages d'adresses obtenues directement dans son enregistrement. Les résolutions tombent à zéro, puisque ip4: ne coûte rien.

"v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ... -all"

Ça fonctionne, et c'est parfois la seule option restante. Soyez lucide sur ce que vous prenez en charge.

Vous venez de convertir un enregistrement que vos prestataires entretenaient en un enregistrement que vous entretenez. Quand Google, Microsoft ou votre routeur d'e-mails change ses plages — et ils le font — votre enregistrement devient silencieusement faux. Le courrier envoyé depuis une adresse ajoutée la semaine dernière échoue à votre propre SPF. Rien ne vous prévient, et le symptôme ressemble exactement au problème que vous venez de corriger.

Il y a aussi un plafond de longueur à surveiller : un enregistrement DNS TXT est limité à 255 caractères par chaîne, et la limite pratique pour un SPF complet tourne autour de 512 octets avant que les réponses ne se fragmentent. Les enregistrements aplatis s'en approchent vite.

Donc : n'aplatissez que si vous ne pouvez pas déléguer, utilisez un service qui ré-aplatit automatiquement et alerte au changement plutôt qu'un dépliage manuel unique, et inscrivez une revue trimestrielle à votre calendrier. Un enregistrement aplati laissé un an sans surveillance est un incident de délivrabilité qui attend son moment.

Relisez l'enregistrement, confirmez que le compte déplié est à dix ou moins, puis vérifiez face à la réalité plutôt que face à un outil.

dig +short TXT exemple.com | grep spf1

Le contrôle qui compte, ce sont vos rapports agrégés DMARC. Laissez passer une semaine : permerror doit disparaître, et chaque source légitime doit ressortir en spf=pass avec alignement. Un vérificateur vous dit que l'enregistrement est valide ; les rapports vous disent ce que les destinataires ont réellement fait de votre courrier.

Empêchez ensuite le retour du problème. Le mécanisme qui marche est procédural, pas technique : faites de SPF une étape de l'adoption d'une nouvelle plateforme d'envoi. Tout outil qui envoie en votre nom a besoin d'une entrée, et tout outil abandonné a besoin qu'on retire la sienne. La plupart des enregistrements dépassent la limite parce que la première moitié de cette règle est appliquée et pas la seconde.