SPF : la limite des dix résolutions DNS

La raison de cette limite est défensive : sans elle, un enregistrement SPF malicieusement construit pourrait faire exécuter des centaines de requêtes DNS à tout serveur qui l’évalue, ce qui en ferait un amplificateur d’attaque par déni de service.

La conséquence pour vous est franche : au-delà de dix, l’évaluation ne renvoie pas « échec », elle renvoie permerror. Et un permerror n’est pas un fail : la plupart des serveurs destinataires traitent alors le message comme si SPF n’existait pas.

La récursivité est ce qui fait déborder les enregistrements : un include coûte une résolution pour lui-même, plus tout ce que l’enregistrement inclus consomme à son tour. Un fournisseur qui en imbrique trois en consomme quatre.

v=spf1 include:_spf.google.com include:sendgrid.net
       include:_spf.brevo.com include:servers.mcsv.net
       include:spf.protection.outlook.com mx a -all

Cinq services à une résolution chacun, plus a et mx qui en coûte une de plus par serveur listé : on arrive à neuf ou dix. L’enregistrement est syntaxiquement parfait et il tient encore. Le prochain outil ajouté le fait basculer, et personne ne le verra.

Le même RFC plafonne à deux le nombre de void lookups : les requêtes qui reviennent vides, avec NXDOMAIN ou zéro réponse. Au-delà de deux, c’est également un permerror.

C’est la panne des enregistrements qui vieillissent : un include vers un prestataire dont on s’est séparé, et dont le domaine SPF n’existe plus, consomme un void lookup. Trois anciens prestataires suffisent à casser un enregistrement par ailleurs correct.

1. Supprimer ce qui ne sert plus. Le premier passage est presque toujours suffisant : les anciens prestataires, l’outil testé six mois, le ptr hérité d’un modèle de configuration. C’est gratuit et sans risque.
2. Retirer mx et a s’ils sont inutiles. Ils sont dans presque tous les enregistrements par habitude. Votre serveur de réception n’est pas forcément votre serveur d’envoi ; s’il ne l’est pas, mx ne sert qu’à consommer des résolutions.
3. Déléguer par sous-domaine. Faire envoyer chaque famille de services depuis un sous-domaine dédié, envois.exemple.fr pour la newsletter, factures.exemple.fr pour la facturation, donne à chacun son propre budget de dix résolutions. C’est la solution propre, et elle améliore aussi la lecture des rapports.
4. En dernier recours, remplacer un include par ses ip4. Cela fonctionne, et cela crée une dette : voir ci-dessous.

dig +short TXT exemple.fr | grep spf1

L’aplatissement (flattening) consiste à remplacer un include par la liste des adresses IP qu’il désigne au moment où on regarde. Le compte de résolutions tombe, l’enregistrement redevient valide, et le problème semble réglé.

Il ne l’est pas : il est déplacé dans le temps. Ces adresses appartiennent à votre prestataire, qui les change quand il veut et sans vous prévenir, c’est précisément la raison pour laquelle il publie un include plutôt qu’une liste. Le jour où il ajoute un bloc, vos messages échouent à SPF sans que rien n’ait changé chez vous.

SPF vérifie l’Envelope-From, une adresse que votre destinataire ne voit jamais. Un enregistrement parfait n’empêche donc personne d’afficher votre domaine dans le champ que l’humain lit : seul DMARC, en exigeant l’alignement des deux, referme cette porte.

SPF ne survit pas non plus aux transferts, puisque l’adresse IP change en route. C’est la raison pour laquelle DKIM n’est pas optionnel : dans un monde où les messages sont transférés, il est le seul des deux contrôles qui tienne.