255 caractères : c’est la longueur maximale d’une chaîne unique dans un enregistrement TXT au format DNS. Un enregistrement SPF qui liste Google Workspace, un prestataire d’emailing transactionnel, un outil de newsletter et le serveur SMTP historique du client dépasse cette limite bien plus vite qu’on ne l’imagine, surtout sur un parc de domaines gérés pour plusieurs clients.
Le protocole DNS gère cette contrainte en autorisant la concaténation de plusieurs chaînes au sein d’un même enregistrement TXT, mais tous les résolveurs ne le font pas correctement, et certains outils de vérification SPF s’arrêtent à la première chaîne. La solution la plus robuste reste de fractionner l’enregistrement en sous-inclusions, via le mécanisme include du protocole SPF.
Pourquoi un enregistrement SPF s’allonge vite sur un parc de domaines
Chaque service tiers autorisé à envoyer des emails au nom d’un domaine ajoute son propre bloc à l’enregistrement SPF : un include:_spf.google.com pour Google Workspace, un include:sendgrid.net pour un envoi transactionnel, un ip4: pour le serveur SMTP historique encore utilisé par une application interne. Sur un domaine qui accumule ces intégrations au fil des années sans jamais faire de ménage, la chaîne finit par dépasser la limite technique.
Un enregistrement SPF typique commence simplement :
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all
Mais chaque nouvel expéditeur ajouté rapproche l’enregistrement de la limite des 255 caractères par chaîne, sans qu’aucune alerte ne prévienne l’administrateur au moment où la limite est franchie.
Structurer l’enregistrement en sous-inclusions
La solution consiste à créer un sous-domaine dédié, par exemple _spf1.exemple.fr, qui porte lui-même un enregistrement SPF complet, puis à l’inclure depuis l’enregistrement principal du domaine. Cette imbrication permet de répartir la liste des expéditeurs autorisés sur plusieurs enregistrements, chacun restant sous la limite de longueur :
exemple.fr. TXT "v=spf1 include:_spf1.exemple.fr include:_spf2.exemple.fr -all"
_spf1.exemple.fr. TXT "v=spf1 include:_spf.google.com include:sendgrid.net ~all"
_spf2.exemple.fr. TXT "v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 ~all"
Cette structuration en cascade répartit la charge sur plusieurs enregistrements DNS distincts, chacun restant lisible et modifiable indépendamment. Ajouter un nouvel expéditeur au parc se fait ensuite en modifiant uniquement le sous-enregistrement concerné, sans toucher à l’enregistrement racine du domaine.
La limite des dix recherches DNS, un piège distinct
Le fractionnement en sous-inclusions résout le problème de longueur de chaîne, mais il n’élimine pas une autre limite du protocole SPF, celle des dix recherches DNS maximum autorisées lors de l’évaluation d’un enregistrement, mécanismes include, a, mx, ptr et exists confondus. Multiplier les niveaux d’inclusion rapproche mécaniquement de cette limite, indépendamment du nombre de caractères.
Un outil de vérification SPF permet de contrôler ce point avant de publier la structure définitive, en simulant l’évaluation complète de la chaîne d’inclusions telle qu’un serveur receveur la traiterait réellement.
- Regrouper les expéditeurs par domaine ou service tiers plutôt qu’un par un
- Limiter la profondeur d’imbrication des sous-inclusions
- Vérifier régulièrement le nombre total de recherches DNS déclenchées
- Documenter à quoi correspond chaque sous-enregistrement dans le parc
Maintenir la structure dans la durée
Sur un parc de domaines gérés pour plusieurs clients, cette structure en sous-inclusions ne vaut que si elle reste documentée et maintenue. Un tableau de correspondance, tenu à part, entre chaque sous-enregistrement et les services tiers qu’il autorise évite de recréer un enregistrement fourre-tout au fil des demandes ponctuelles.
Sur les parcs que nous suivons, le passage à des sous-inclusions nommées par usage plutôt que par ordre chronologique a rendu la maintenance bien plus lisible : un coup d’œil suffit pour savoir ce que chaque bloc autorise.
Ce sujet ne couvre volontairement pas DKIM ni DMARC, qui complètent SPF dans une stratégie d’authentification email complète mais répondent à des mécanismes de vérification différents, l’un basé sur une signature cryptographique, l’autre sur une politique appliquée en cas d’échec des deux premiers.
En résumé
Fractionner un enregistrement SPF trop long en sous-inclusions nommées permet de rester sous la limite des 255 caractères par chaîne tout en gardant une structure lisible sur un parc de domaines. La vigilance doit ensuite se porter sur la limite distincte des dix recherches DNS, qui peut être atteinte même après ce découpage si l’imbrication devient trop profonde.
