Votre enregistrement SPF tient sur une ligne. Il déclare qui a le droit d’envoyer du courrier en votre nom, et il ressemble à ceci :
v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net include:_spf.salesforce.com ~all
Quatre prestataires, quatre inclusions, une ligne parfaitement lisible. Et il y a de bonnes chances que cet enregistrement soit invalide.
Dix, et pas onze
La norme SPF, RFC 7208 publiée en avril 2014, consacre sa section 4.6.4 aux limites de requêtes DNS. Le texte n’est pas une recommandation :
« SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return « permerror ». »
Dix termes au total. Sont comptés les mécanismes include, a, mx, ptr, exists et le modificateur redirect.
Le compte est récursif. Un include vers un prestataire ne coûte pas une requête : il coûte une requête plus toutes celles que contient l’enregistrement du prestataire. Un hébergeur de messagerie sérieux en consomme trois ou quatre à lui seul.
Quatre prestataires suffisent donc souvent à dépasser dix. C’est pour cela que Microsoft prend la peine de rappeler cette limite dans son annonce d’exigences aux expéditeurs de volume : c’est la panne la plus répandue du métier.
Une sous-limite passe encore plus inaperçue : l’évaluation du mécanisme mx ne doit pas entraîner plus de dix requêtes A ou AAAA supplémentaires, sous la même sanction.
Permerror n’est pas un avertissement
Le mot fait penser à un détail de journalisation. Il désigne un échec d’authentification pur et simple.
Un SPF en permerror ne passe pas. Il ne s’aligne donc pas au sens de DMARC. Si votre signature DKIM ne rattrape pas la situation, votre message échoue à DMARC, et la politique que vous avez vous-même publiée s’applique contre vous.
Le piège tient au moment où la panne apparaît. Vous n’avez rien changé : c’est votre prestataire qui a ajouté une inclusion dans son propre enregistrement, un mardi, sans vous prévenir, parce qu’il a ouvert un centre de données. Votre ligne SPF est identique à celle d’hier, et elle est devenue invalide pendant la nuit.
Le mécanisme que la norme déconseille dans son titre
La section 5.5 de la RFC 7208 s’intitule littéralement : « ptr » (do not use).
Le texte est à l’avenant : « This mechanism SHOULD NOT be published. » Ce n’est pas une interdiction absolue, c’est un déconseil formel, motivé par la lenteur du mécanisme, son manque de fiabilité et la charge indue qu’il impose aux serveurs de la zone .arpa.
Un ptr dans un enregistrement SPF est donc un marqueur d’âge : il signale une configuration écrite avant 2014 et jamais relue depuis. Il consomme en plus l’une de vos dix requêtes.
Le type d’enregistrement DNS qui n’existe plus
SPF a eu, pendant sa phase expérimentale, son propre type d’enregistrement DNS, le type 99. La RFC 7208 a mis fin à cette double publication, section 3.1 :
« SPF records MUST be published as a DNS TXT (type 16) Resource Record (RR) only. »
Le groupe de travail a constaté qu’une migration significative vers le type dédié était improbable, et a abandonné son support. Si votre zone contient encore un enregistrement de type SPF, il ne sert plus à rien depuis douze ans, et il peut entretenir l’illusion d’une redondance qui n’existe pas.
L’aplatissement, et ce qu’il coûte
Face à la limite des dix requêtes, une pratique s’est répandue : remplacer les include par les adresses IP qu’ils désignent, résolues une fois pour toutes. L’enregistrement ne coûte alors plus aucune requête récursive.
Le procédé fonctionne, et il déplace le risque plutôt qu’il ne le supprime.
Vous prenez à votre charge le suivi des adresses IP de vos prestataires. Le jour où l’un d’eux ajoute une plage, vos messages partis de cette plage échouent à SPF, sans que rien ne vous prévienne. Vous avez échangé une panne bruyante et immédiate contre une panne silencieuse et différée.
Ce choix se défend, à une condition : que la resynchronisation soit automatisée et surveillée. Aplatir à la main, une fois, en 2023, est la pire des options.
La solution structurelle est ailleurs, et elle est moins technique : réduire le nombre d’outils qui envoient du courrier en votre nom. Chaque service marketing qui souscrit un nouvel outil consomme une part d’un budget de dix, et personne dans l’entreprise ne tient ce compte.
Ce que vous faites demain matin
Comptez vos requêtes, en résolvant récursivement chaque inclusion, pas en comptant les lignes de votre enregistrement. Le résultat surprend presque toujours.
Cherchez ensuite le mot ptr et le mécanisme a utilisé par réflexe : ce sont deux requêtes souvent inutiles, faciles à rendre.
Enfin, faites la liste des expéditeurs légitimes de votre domaine. Pas la liste théorique : celle qui apparaît dans vos rapports DMARC agrégés. Il y a presque toujours un outil oublié, souscrit par un service qui a changé de responsable, et qui occupe une place dans un budget de dix.
Sources
- Kitterman, S. (avril 2014). Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1, RFC 7208, Proposed Standard
- Herr, T. & Levine, J., éd. (mai 2026). Domain-Based Message Authentication, Reporting, and Conformance (DMARC), RFC 9989, Proposed Standard
- Microsoft Defender for Office 365 Blog (2 avril 2025, mis à jour le 30 avril 2025). Strengthening Email Ecosystem: Outlook’s New Requirements for High-Volume Senders
- Google Workspace Admin Help. Consignes pour les expéditeurs d’e-mails
LaFactory travaille l’emailing sur pièces : en-têtes, enregistrements DNS, journaux de rejet. Aucune promesse de taux d’ouverture, jamais. Contactez-nous pour un audit de délivrabilité.