SPF PermError : trop de recherches DNS, et comment corriger

SPF a une limite stricte, fixée par sa norme (RFC 7208, section 4.6.4) : l’évaluation d’un enregistrement peut déclencher au plus dix recherches DNS. Une de plus et le résultat est permerror, que les destinataires traitent comme un échec pour tous les messages, légitimes compris. L’enregistrement a l’air correct, chaque service a demandé d’ajouter son include:, et pourtant SPF est cassé pour tout le monde.

Ce qui compte

Compte comme une recherche	Ne compte pas
`include:` (et chaque recherche dans l’enregistrement inclus)	`ip4:` et `ip6:`
`a`, `mx`	`all`
`exists:`, `ptr`	`exp=`
`redirect=`

Les inclusions s’empilent : include:spf.protection.outlook.com coûte une recherche, plus tout ce que cet enregistrement inclut lui-même. Une petite entreprise type, avec Microsoft 365, un outil de newsletter, un CRM et un outil de support, atteint onze ou douze sans s’en rendre compte. Le vérificateur SPF déplie tout l’arbre et compte.

Il existe une seconde limite, plus petite : deux recherches vides. Un include: qui pointe vers un nom qui n’existe plus compte comme vide ; trois provoquent aussi permerror.

Cinq corrections, de la plus sûre à la plus risquée

1. Retirer ce qui n’envoie plus. Le service quitté il y a deux ans, l’ancien hébergeur, les a et mx ajoutés « au cas où ». Chaque inclusion retirée rend tout son sous-arbre. Vos rapports DMARC montrent quelles sources envoient vraiment.

2. Retirer les inclusions inutiles pour DMARC. Beaucoup d’outils de newsletter et de CRM envoient avec leur propre domaine d’adresse de retour : SPF est alors vérifié sur leur domaine, pas le vôtre. Leur include: dans votre enregistrement ne sert à rien ; ce qui fait passer leurs messages au contrôle DMARC, c’est DKIM signé avec votre domaine. Regardez la page d’authentification de domaine de chaque service : s’il ne vous a jamais demandé de changer l’adresse de retour, son inclusion peut en général partir.

3. Envoyer les newsletters depuis un sous-domaine. Envoyez-les depuis news.votredomaine.fr, avec son propre SPF. Chaque sous-domaine a son propre budget de dix recherches, et le domaine principal garde un enregistrement court et lisible.

4. Remplacer a et mx par ip4:. Si votre propre serveur de messagerie a une adresse fixe, écrivez-la ip4:203.0.113.10. Zéro recherche.

5. Aplatir, avec prudence. L’aplatissement (flattening) remplace les inclusions par les adresses IP qu’elles donnent. Il règle le compte, mais les fournisseurs changent leurs adresses sans prévenir, et un enregistrement aplati refuse alors en silence leurs nouveaux serveurs. N’aplatissez que ce que vous pouvez revérifier automatiquement, et jamais à la main les inclusions des grands fournisseurs (Microsoft, Google).

Après la correction

Revérifiez l’enregistrement : un seul, moins de dix recherches avec un peu de marge, une fin en ~all ou -all. Puis confirmez dans les rapports de la semaine suivante que DMARC passe toujours pour chaque service, avec le lecteur de rapports DMARC. Le générateur SPF écrit un enregistrement propre si vous préférez repartir de zéro.