SPF : la limite des 10 requêtes DNS, mesurée sur mes domaines et corrigée dans l'ordre
Le ticket arrive toujours dans le même ordre. Quelqu’un branche un nouvel outil d’emailing le lundi. Le jeudi, des clients signalent qu’ils ne reçoivent plus rien. On colle le domaine dans un vérificateur en ligne, et la réponse tombe : SPF permerror, too many DNS lookups.
Personne n’a rien cassé. Aucune décision absurde n’a été prise. L’enregistrement SPF est simplement devenu trop cher à évaluer, et un enregistrement trop cher n’est pas dégradé : il est mort.
J’ai relu la RFC à la source le 19 septembre 2026, puis compté les requêtes de mes deux domaines avec un script maison. Voici la règle exacte, les chiffres mesurés, et l’ordre dans lequel corriger.
Ce que dit exactement la RFC 7208
Tout tient dans la section 4.6.4. Trois limites y cohabitent, et on n’en connaît généralement qu’une.
Limite 1 : dix termes qui interrogent le DNS. Les termes concernés sont les mécanismes include, a, mx, ptr, exists, et le modificateur redirect. Le texte est un MUST : « SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation », et au-delà le résultat est permerror. À l’inverse, all, ip4, ip6 et le modificateur exp ne déclenchent aucune requête pendant l’évaluation. Ils ne comptent pas. Cinquante ip4: alignés coûtent zéro.
Limite 2 : dix adresses derrière un mx. Elle se superpose à la première sans la remplacer. Le mécanisme mx consomme une place dans le budget de 10, comme les autres. Mais son évaluation ne doit pas non plus résoudre plus de dix enregistrements A ou AAAA, sous peine de permerror. Un domaine à douze serveurs MX déclenche donc l’erreur alors que son SPF ne contient qu’un seul terme.
Limite 3 : deux « void lookups ». Une requête qui revient vide, ou qui porte sur un domaine inexistant, est un void lookup. Ici la RFC dit SHOULD, avec un défaut recommandé de deux. C’est donc appliqué inégalement selon les serveurs de réception, mais deux includes morts vous placent déjà sur le fil.
Un mot sur ptr, qui traîne encore dans de vieilles zones : sa limite de dix adresses existe aussi, sauf qu’au-delà les enregistrements sont ignorés au lieu de produire une erreur. La RFC le déconseille explicitement. Si vous en croisez un, la bonne action est de le supprimer, pas de l’optimiser.
Le point qui fait basculer tout le reste : le comptage est récursif. Un include compte pour 1, et tout ce que contient l’enregistrement inclus compte en plus. Le budget n’est donc pas seulement le vôtre, il est partagé avec vos prestataires.
Pourquoi on dépasse sans jamais avoir mal fait
Deux mécanismes, et aucun des deux ne ressemble à une faute.
Le premier est l’accumulation. Chaque outil branché au fil des années demande « juste un petit include », et personne ne retire jamais rien. Messagerie, newsletter, CRM qui envoie des relances, helpdesk qui répond aux tickets : quatre includes, ça reste raisonnable sur le papier.
Le second est invisible depuis votre propre zone. L’enregistrement d’un prestataire peut lui-même contenir des includes, et ceux-là se paient dans votre budget. _spf.protonmail.ch contient _spf2.protonmail.ch. sendgrid.net contient ab.sendgrid.net. Dans les deux cas, ce qui ressemble à un include en coûte deux. Rien ne l’indique dans l’enregistrement que vous écrivez, et rien ne vous prévient le jour où un fournisseur en ajoute un.
Un SPF fictif à 11 requêtes, terme par terme
Prenons un enregistrement inventé mais réaliste pour exemple.fr, accumulé sur cinq ans : un mécanisme mx, l’include de Microsoft 365, celui de l’outil d’emailing, celui du CRM, celui du helpdesk, et celui d’une ancienne agence web, le tout terminé par ~all.
Le compte, en suivant chaque include jusqu’au bout (les contenus des zones incluses sont illustratifs) :
| Terme | Requêtes |
|---|---|
mx | 1 |
5 × include de premier niveau | 5 |
spf.emailing-exemple.fr contient 2 includes internes | 2 |
spf.crm-exemple.com contient 1 include et 1 a | 2 |
spf.helpdesk-exemple.net contient 1 include | 1 |
| Total | 11 |
Onze : permerror. Et l’include de l’ancienne agence web, dont le domaine ne publie plus de SPF depuis sa fermeture, ajoute un void lookup au passage. Pris isolément, aucun terme de cet enregistrement n’est absurde. C’est exactement ce qui rend la panne difficile à voir venir.
Compter, pour de vrai
À la main, la méthode est bête et infaillible. Récupérez l’enregistrement TXT de votre domaine avec l’outil de résolution DNS de votre choix, puis suivez chaque include et chaque redirect en comptant tout ce qui interroge le DNS, niveau après niveau. Répétez pour chaque domaine inclus, puis additionnez. C’est fastidieux, et ça force à découvrir qui envoie réellement au nom du domaine, ce qui est souvent l’information la plus utile de la journée.
Comme je devais le faire sur deux domaines, j’ai écrit un petit compteur récursif qui fait exactement ce travail : il lit l’enregistrement, suit les includes, et affiche l’arbre complet avec le total. Un détail m’a coûté du temps, et il vaut pour n’importe quelle méthode : un enregistrement TXT de plus de 255 caractères est découpé en plusieurs chaînes, et un SPF un peu chargé dépasse vite ce seuil. Si l’on ne recolle pas toutes les chaînes d’un même enregistrement avant de le lire, la moitié des includes disparaît du compte, et le total paraît rassurant à tort.
Sur normdrift.com, en vrai, le 19 septembre 2026, l’arbre ressemble à ceci :
| Niveau | Enregistrement interrogé | Ce qu’il contient | Coût |
|---|---|---|---|
| racine | normdrift.com | include:_spf.protonmail.ch, include:spf.brevo.com, ~all | 0 |
| 1 | _spf.protonmail.ch | six plages ip4 et include:_spf2.protonmail.ch | 1 |
| 2 | _spf2.protonmail.ch | cinq adresses ip4 | 1 |
| 1 | spf.brevo.com | dix plages ip4 | 1 |
| Total | 3 |
L’arbre est la partie qui sert le plus. Le total dit s’il y a un problème, l’arbre dit où il est.
Ce que ça donne sur mes domaines
Deux domaines, deux usages différents, mesurés avec le résolveur 1.1.1.1 :
| Domaine | Enregistrement | Requêtes |
|---|---|---|
| normdrift.com | v=spf1 include:_spf.protonmail.ch include:spf.brevo.com ~all | 3 |
| vigiedmarc.fr | v=spf1 include:_spf.mx.cloudflare.net ~all | 1 |
Le détail du premier : l’include Proton compte 1, son include interne _spf2.protonmail.ch compte 1 aussi, et Brevo ajoute la troisième. Sur vigiedmarc.fr, un seul include totalement plat, une requête.
Trois requêtes sur dix, c’est confortable. Ce n’est pas une performance : c’est le résultat normal d’un domaine qui n’a pas encore accumulé cinq ans d’outils. Le chiffre intéressant n’est pas le total, c’est la marge : sept places libres, et je sais exactement ce qui les consommerait.
Combien coûte un include courant
Même méthode, appliquée aux includes qu’on croise le plus souvent. La colonne donne le coût complet, l’include lui-même compris :
| Include | Requêtes | Détail |
|---|---|---|
spf.protection.outlook.com (Microsoft 365) | 1 | uniquement des ip4 et ip6 |
_spf.google.com (Google Workspace) | 1 | uniquement des ip4 et ip6 |
spf.brevo.com | 1 | uniquement des ip4 |
sendgrid.net | 2 | contient include:ab.sendgrid.net |
_spf.protonmail.ch (Proton) | 2 | contient include:_spf2.protonmail.ch |
Bonne nouvelle : les gros fournisseurs sont plats aujourd’hui. Microsoft, Google et Brevo publient des listes d’adresses littérales, sans niveau imbriqué. Avec ces trois-là, vous tenez trois includes pour trois requêtes.
La réserve est dans le mot « aujourd’hui ». Rien n’empêche un prestataire d’ajouter un include interne demain, pour séparer ses régions ou basculer une partie de son infrastructure. Proton et SendGrid l’ont déjà fait. Le jour où ça arrive, le coût monte chez tous ses clients d’un coup, sans notification et sans qu’aucune zone DNS n’ait changé de leur côté. D’où la règle : recomptez après chaque modification, et recomptez de temps en temps sans modification.
Ce qu’un permerror casse vraiment
Un permerror signifie que l’enregistrement ne peut pas être interprété. Il ne produit donc jamais de pass. Ce n’est pas un SPF affaibli, c’est un SPF qui ne sert plus à rien tant que le compte n’est pas redescendu. La RFC prévoit même le cas où le serveur de réception refuse le message en séance SMTP pour cette raison, avec un code 550.
Côté DMARC, la mécanique est simple. Un message passe DMARC si au moins un des deux mécanismes, SPF ou DKIM, produit un pass aligné avec le domaine visible dans le From. Un permerror n’est pas un pass : la jambe SPF est coupée.
Trois conséquences, dans l’ordre où elles se manifestent :
- Si DKIM est correctement configuré et aligné sur tous vos flux, DMARC continue de passer. Le domaine tient sur une seule jambe, ce qui marche jusqu’au premier flux oublié.
- Si un flux n’a pas de DKIM aligné, cas fréquent pour un outil branché à la va-vite, ce flux échoue DMARC. Avec une politique
quarantineoureject, ses messages partent en indésirables ou sont refusés. - Le traitement exact varie d’un serveur de réception à l’autre. Certains sont indulgents avec un
permerror, d’autres non. Ce choix appartient au destinataire, donc il ne se pilote pas.
Le permerror apparaît noir sur blanc dans les rapports DMARC agrégés. Qui les lit le voit avant ses utilisateurs.
Revenir sous la limite, dans l’ordre
Du moins risqué au plus engageant.
1. Le ménage. Gratuit, sans contrepartie, et suffisant dans un bon nombre de cas. Les candidats habituels : l’include d’un prestataire quitté depuis deux ans, un a ou un mx alors que ces machines n’envoient plus rien, un ptr que la RFC déconseille, des doublons. Chaque terme retiré libère au moins une requête, et retirer un include mort supprime en prime un void lookup.
2. Les sous-domaines dédiés. C’est la correction structurelle, celle qui tient dans la durée. La newsletter part de news.exemple.fr, le helpdesk de support.exemple.fr, chacun avec son propre enregistrement SPF. Chaque sous-domaine dispose de son propre budget de dix requêtes, et le domaine principal respire. L’alignement DMARC en mode relaxed, qui est le mode par défaut, considère un sous-domaine du même domaine organisationnel comme aligné. Bénéfice secondaire : un incident de réputation sur la newsletter ne salit plus les mails de facturation.
3. L’aplatissement, en connaissance de cause. Remplacer un include par les ip4 et ip6 qu’il résout ramène son coût à zéro. Le piège est connu et sérieux : les adresses des prestataires changent sans préavis, et le jour où elles changent, les mails légitimes échouent SPF sans le moindre signal. Si vous aplatissez, notez quelle liste correspond à quel prestataire et à quelle date, et surveillez aussi la taille de l’enregistrement, parce qu’un TXT trop long a ses propres ennuis.
4. L’aplatissement géré. Des services surveillent les SPF des prestataires et maintiennent à jour un enregistrement aplati, via un include délégué chez eux. Cela règle la maintenance du point 3, au prix d’une dépendance de plus sur un maillon critique de l’authentification. Compromis défendable, pas une évidence. Je n’en recommande aucun en particulier.
Et s’il vous faut plus de dix
Le cas existe : messagerie, newsletter, CRM, helpdesk, facturation, chacun chez un prestataire différent. La limite ne se négocie pas, mais elle se compte par enregistrement interrogé. La réponse n’est donc pas un contournement, c’est une question d’architecture.
Multiplier les budgets avec les sous-domaines. Quatre flux sur quatre sous-domaines, ce sont quarante requêtes de budget total et des réputations isolées. C’est le levier le plus rentable, et le seul qui ne crée aucune dette.
Faire porter l’alignement par DKIM. DMARC n’exige pas que SPF et DKIM passent tous les deux. La plupart des outils d’envoi sérieux savent signer avec le domaine du client, via des CNAME délégués. Pour ces services, l’alignement repose sur la signature, et leur include n’a plus besoin d’occuper une place dans le SPF du domaine principal. Réserve honnête, et elle compte : sans include, ce flux échouera SPF, et DMARC tiendra uniquement grâce à la signature. À faire seulement pour les services dont le DKIM est en place et vérifié, jamais sur un pari.
En dernier, l’aplatissement géré, pour ce qui reste une fois les deux premiers leviers appliqués.
La règle de synthèse tient en une phrase : votre SPF racine n’est pas l’annuaire de tous vos prestataires, c’est le budget de votre flux principal. Le reste se loge ailleurs, par conception.
Par où commencer
Comptez d’abord, corrigez ensuite. Et comptez en arbre, pas en total : c’est l’arbre qui dit quel prestataire consomme quoi.
Pour un état des lieux immédiat, l’analyse gratuite en haut de la page d’accueil lit les enregistrements SPF et DMARC d’un domaine, sans inscription. C’est l’outil de ce site, autant le dire.
Et quelle que soit la méthode, gardez le réflexe qui manque presque toujours : reposer la question tous les quelques mois. Le compte peut monter alors que personne n’a rien touché.
Questions fréquentes
Est-ce que ip4, ip6 et all comptent dans les 10 requêtes DNS ?
Non, aucun des trois. La limite de la RFC 7208 ne porte que sur les termes qui déclenchent une requête DNS pendant l'évaluation : include, a, mx, ptr, exists et le modificateur redirect. Une adresse littérale écrite en ip4 ou ip6 est déjà résolue, il n'y a rien à interroger. Le modificateur exp est exclu lui aussi, parce qu'il n'est consulté qu'après coup, pour produire un message d'explication.
Mon enregistrement SPF n'a pas bougé depuis deux ans, pourquoi dépasse-t-il aujourd'hui ?
Parce que le budget de 10 se compte récursivement, et qu'une partie du compte appartient à vos prestataires. Quand un fournisseur ajoute un include interne dans son propre enregistrement, le coût se répercute chez tous ses clients, sans annonce et sans que personne n'ait touché à sa zone DNS. Proton et SendGrid ont déjà ce genre d'include imbriqué aujourd'hui. C'est la raison pour laquelle il faut recompter de temps en temps, même quand rien n'a changé de votre côté.
L'aplatissement d'un include en adresses ip4 est-il une bonne solution ?
C'est la solution qui marche tout de suite et qui casse silencieusement plus tard. Remplacer un include par les adresses qu'il résout ramène son coût à zéro requête, mais fige une liste que le prestataire, lui, continue de faire évoluer. Le jour où il change ses adresses d'envoi, vos messages légitimes échouent SPF sans qu'aucune alerte ne se déclenche. À garder pour ce qui reste après le ménage et les sous-domaines, avec une date de revérification notée quelque part.
Combien de requêtes coûte un include Microsoft 365 ou Google Workspace ?
Une seule chacun, mesuré le 19 septembre 2026. Les enregistrements spf.protection.outlook.com et _spf.google.com ne publient que des adresses en ip4 et ip6, sans include imbriqué. Les gros fournisseurs de messagerie sont en général plats, et ce sont plutôt les outils d'envoi transactionnel ou marketing qui empilent des niveaux. Ce coût n'est pas garanti dans le temps : il se recompte.