SPF et la limite des 255 caractères : chaînes et découpage

exemple.fr.  IN  TXT  ( "v=spf1 ip4:192.0.2.0/28 ip4:198.51.100.0/26 include:_spf.google.com "
                        "include:spf.protection.outlook.com include:sendgrid.net ~all" )

Là où ça casse : les interfaces DNS et le copier-coller

Face à une valeur de plus de 255 caractères, les interfaces des hébergeurs DNS se répartissent en trois familles. La première refuse net : message d'erreur explicite, la valeur n'est pas enregistrée. C'est agaçant mais sain — l'échec est visible et se corrige dans la minute, en découpant soi-même. La deuxième famille découpe automatiquement : l'interface accepte la valeur longue et la segmente en chaînes conformes au moment de générer la zone. Cloudflare procède ainsi, et c'est le comportement idéal : la valeur se colle d'un bloc, le résolveur reçoit un enregistrement correct.

La troisième famille est la dangereuse : celle qui tronque ou corrompt en silence. Un champ de formulaire doté d'un maxlength invisible ampute la valeur collée au 255ᵉ caractère, souvent en plein milieu d'un mécanisme — l'enregistrement publié se termine alors par include:_spf.exemple- suivi de rien. Résultat : SPF syntaxiquement invalide, permerror systématique. Sous DMARC, un permerror SPF équivaut à une absence de SPF : toute l'authentification repose dès lors sur DKIM, et les flux qui n'ont que SPF — certains outils métier, de vieux serveurs applicatifs — échouent purement et simplement.

Le copier-coller ajoute sa propre couche de pièges : un retour à la ligne inséré par un client mail ou un traitement de texte, des guillemets typographiques substitués aux guillemets droits par un correcteur automatique, une interface qui attend la valeur nue et stocke les guillemets comme des caractères littéraux. Aucune de ces corruptions ne déclenche d'alerte à la saisie ; elles ne se révèlent qu'à la vérification extérieure, une fois l'enregistrement propagé — d'où l'importance du réflexe dig détaillé plus bas.

La taille des réponses : UDP, EDNS et la robustesse

La limite par chaîne n'est pas la seule raison de surveiller l'embonpoint d'un SPF. Le DNS transporte historiquement ses réponses en UDP, avec un plafond de 512 octets par message hérité de la RFC 1035. L'extension EDNS0 a relevé ce plafond — la plupart des résolveurs annoncent aujourd'hui 1 232 octets, valeur recommandée depuis le DNS Flag Day de 2020 — mais le mécanisme de secours n'a pas changé : une réponse trop grosse est marquée tronquée (bit TC), et le client doit retenter en TCP. Or de vieux pare-feux bloquent encore le port 53 en TCP, et certains équipements maltraitent les paquets UDP volumineux. Une réponse obèse devient alors une réponse perdue : le vérificateur rend temperror, et le message légitime est différé, voire évalué sans authentification.

Un détail aggrave le calcul : une requête TXT renvoie tous les enregistrements TXT du nom, pas seulement le SPF. Les jetons de vérification accumulés au fil des ans — google-site-verification=…, MS=…, validations d'outils SaaS oubliés — partagent la même réponse et en gonflent la taille. Un SPF de 300 octets dans une réponse qui en compte déjà 600 de jetons franchit le seuil bien plus vite que prévu. La RFC 7208 recommande explicitement de garder la réponse dans des dimensions modestes : la robustesse plaide pour la concision, même quand le découpage multi-chaînes rend la longueur parfaitement « légale ».

Dégraisser un enregistrement SPF obèse

Avant de découper, mieux vaut raccourcir. Un SPF obèse est presque toujours un SPF sédimenté : des années d'ajouts, jamais un retrait. Le nettoyage suit un ordre logique.

• Les mécanismes morts. L'ESP quittée il y a deux ans, le serveur décommissionné, l'agence dont le contrat est clos : leurs include: et ip4: restent dans l'enregistrement. Les rapports DMARC tranchent — une source absente des rapports depuis des mois peut sortir.
• Les redondances. Un ip4: désignant une adresse déjà couverte par un include:, deux include: du même prestataire sous des noms différents, un mx alors que les serveurs entrants n'émettent jamais : autant d'octets gratuits.
• L'agrégation CIDR. Quatre adresses contiguës listées une à une (ip4:192.0.2.16 ip4:192.0.2.17 ip4:192.0.2.18 ip4:192.0.2.19) se compriment en un bloc unique ip4:192.0.2.16/30. Sur des plages plus larges, le gain se compte en dizaines d'octets.
• Le mécanisme ptr. Déconseillé par la RFC 7208 elle-même, coûteux et peu fiable : sa place est dans les archives, pas dans l'enregistrement.
• La délégation par sous-domaine. Le levier le plus puissant : la newsletter part de news.exemple.fr, la facturation de billing.exemple.fr, chacun avec son propre SPF court. Le domaine principal ne porte plus que ses flux propres, et chaque enregistrement respire.

Deux techniques voisines méritent un renvoi plutôt qu'un traitement ici. L'aplatissement — remplacer les include: par leurs adresses IP résolues — réduit les requêtes DNS mais allonge l'enregistrement, soit exactement l'inverse de l'objectif de cette page ; ses promesses et ses pièges sont examinés dans l'aplatissement SPF, fausse bonne idée. Quant aux macros de la RFC 7208, capables de compacter radicalement certains cas d'usage, elles ont leur propre article : les macros SPF et le mécanisme exists.

255 caractères et 10 lookups : deux limites que tout oppose

La limite des 255 caractères est régulièrement confondue avec l'autre plafond célèbre de SPF : les dix mécanismes déclenchant une requête DNS (include, a, mx, ptr, exists, plus le modificateur redirect). Les deux n'ont pourtant rien en commun. La première est une contrainte d'encodage du DNS : elle se mesure en octets et se contourne proprement par le découpage en chaînes. La seconde est une règle de SPF lui-même : elle se compte en résolutions DNS et se solde par un permerror normatif dès la onzième requête.

La confusion vient de ce que les deux frappent les mêmes victimes — les enregistrements qui ont grossi sans surveillance — mais les remèdes divergent, et parfois s'opposent frontalement. L'aplatissement guérit les lookups en aggravant la taille ; le découpage multi-chaînes guérit la taille sans retirer une seule requête. Un enregistrement très court peut exploser le plafond de requêtes (trois include: imbriqués y suffisent), tandis qu'un enregistrement de 350 octets composé uniquement d'ip4: ne consomme aucun lookup. Identifier lequel des deux plafonds pose réellement problème est donc le préalable à toute correction — le plafond des dix requêtes DNS a son propre mode d'emploi, et il se lit avant de toucher quoi que ce soit.

Vérifier : dig, guillemets et comptage

La vérification ne demande que dig, présent sur toute machine Unix (ou nslookup -type=TXT sous Windows) :

$ dig +short TXT exemple.fr
"v=spf1 ip4:192.0.2.0/28 include:_spf.google.com " "include:sendgrid.net ~all"
"google-site-verification=kX3v…"

La sortie dit tout. Chaque paire de guillemets matérialise une chaîne : deux paires sur la ligne SPF signifient que l'enregistrement est découpé et que le découpage a survécu à l'interface de l'hébergeur. L'espace de jonction se contrôle à l'œil nu — ici, en fin de première chaîne. Le comptage global tient en une commande :

$ dig +short TXT exemple.fr | grep spf1 | wc -c

L'essentiel n'est pas le total, mais la répartition : chaque chaîne individuelle doit rester sous les 255 octets, ce que la présence de guillemets multiples démontre d'un coup d'œil. Trois réflexes complètent l'outillage : vérifier après propagation (le TTL de l'ancien enregistrement peut masquer la modification pendant des heures), interroger un résolveur public (@1.1.1.1, @9.9.9.9) plutôt que le cache local, et surveiller les rapports DMARC dans les jours qui suivent — un permerror de troncature s'y lit noir sur blanc, là où l'interface DNS n'affichera jamais rien.

En résumé

La « limite des 255 caractères » de SPF est en réalité une règle du DNS : 255 octets par chaîne de caractères d'un enregistrement TXT, jamais par enregistrement. Un SPF long reste conforme s'il est découpé en plusieurs chaînes que le vérificateur concatène sans ajouter d'espace ; les vraies casses viennent des interfaces qui tronquent en silence, des copier-coller corrompus et des réponses DNS devenues trop grosses pour l'UDP. Le bon ordre des opérations : dégraisser d'abord (mécanismes morts, redondances, agrégation CIDR, sous-domaines dédiés), découper ensuite si nécessaire, vérifier toujours avec dig — et ne pas confondre cette limite d'octets avec le plafond des dix requêtes DNS, qui obéit à d'autres lois et appelle d'autres remèdes.

Pour savoir en quelques secondes si l'enregistrement d'un domaine frôle la limite, est proprement découpé ou traîne des octets morts, une analyse DMARC gratuite montre l'état de SPF aux côtés de DKIM et de la politique DMARC, découpage compris. Et pour suivre dans la durée ce que les rapports disent des sources réelles du domaine, la création d'un compte ouvre la surveillance continue — la limite des 255 octets, elle, ne bougera pas.