Comment aplatir un enregistrement SPF

Aplatir un enregistrement SPF consiste à remplacer les mécanismes qui déclenchent des requêtes DNS — include:, a, mx, exists, ptr et redirect — par les plages ip4: et ip6: explicites auxquelles ils se résolvent. Le résultat est un enregistrement qui autorise exactement les mêmes expéditeurs mais force les serveurs de réception à parcourir bien moins (idéalement zéro) de requêtes DNS, vous maintenant en toute sécurité sous la limite de 10 requêtes de la RFC 7208. Ce guide parcourt le processus étape par étape, montre à quoi ressemble un enregistrement aplati, et explique comment le garder exact une fois en ligne.

Cette page fait partie de notre guide plus vaste sur l’aplatissement SPF. Si vous voulez éviter entièrement le travail manuel, le SPF Checker développe chaque include et compte vos requêtes en quelques secondes.

Pourquoi aplatir un enregistrement SPF en premier lieu

L’authentification SPF est plafonnée à 10 requêtes DNS par évaluation selon la RFC 7208. Chaque terme include:, a, mx, exists et redirect compte dans ce budget, et chacun peut déclencher d’autres requêtes récursives à l’intérieur du domaine vers lequel il pointe. Ajoutez une plateforme marketing, un CRM, un service d’assistance et un service de facturation, et un seul enregistrement v=spf1 peut discrètement gonfler jusqu’à 15-40 requêtes.

Lorsque vous franchissez la limite, les destinataires renvoient un PermError. Un PermError ne fait pas qu’échouer un message — il invalide l’enregistrement tout entier, si bien que les e-mails légitimes de chaque source autorisée peuvent commencer à échouer au SPF. Comme rien ne rebondit bruyamment, les équipes ne le remarquent souvent pas avant qu’un client ne signale une facture ou un e-mail de réinitialisation de mot de passe manquant.

L’aplatissement résout cela en résolvant ces mécanismes indirects à l’avance et en publiant les IP brutes. Un destinataire évaluant un enregistrement entièrement aplati effectue une simple correspondance d’IP sans parcours DNS récursif, ce qui signifie aussi une validation plus rapide et aucune exposition à une panne DNS temporaire d’un tiers.

À quoi ressemble un enregistrement SPF aplati

Voici un enregistrement type non aplati qui s’appuie sur trois includes :

v=spf1 include:_spf.google.com include:vendor.com include:vendor2.net -all

Chaque include représente au moins une requête, et l’include de Google en imbrique à lui seul plusieurs autres. Aplatie, la même autorisation devient une liste directe d’IP :

v=spf1 ip4:203.0.113.5 ip4:192.168.1.1 ip4:185.23.45.67 -all

Aucune requête ne se produit au moment de l’évaluation, car chaque adresse autorisée est déjà explicitement indiquée. Le qualificateur -all est conservé afin que la politique reste stricte.

Comment aplatir un enregistrement SPF, étape par étape

Étape 1 : trouver et auditer votre enregistrement actuel

Récupérez votre enregistrement SPF existant avec une requête dig TXT yourdomain.com (ou le tableau de bord de votre fournisseur DNS) et confirmez que vous avez exactement un enregistrement TXT v=spf1. Plusieurs enregistrements SPF sur le même nom constituent en eux-mêmes un PermError. Notez quels mécanismes provoquent des requêtes (include, a, mx, exists, redirect, ptr) par opposition aux entrées ip4/ip6 sans coût que vous pouvez conserver telles quelles.

Étape 2 : compter vos requêtes

Avant de changer quoi que ce soit, mesurez de combien vous dépassez le budget. Passez votre domaine dans le SPF Checker, qui développe récursivement chaque include et vous donne un décompte exact des requêtes. Si vous êtes à 8 ou plus, ou si vous voyez déjà un PermError, l’aplatissement (ou la délégation) est justifié. Si vous êtes à 3 includes stables ou moins, il se peut que vous n’ayez pas besoin d’aplatir du tout.

Étape 3 : résoudre récursivement chaque mécanisme en IP

C’est le cœur de l’aplatissement. Pour chaque terme générant une requête, résolvez-le jusqu’à des adresses explicites :

Mécanisme	Comment le résoudre	Résultat
include:	Récupérer l’enregistrement SPF de la cible et développer ses mécanismes récursivement	ip4:/ip6: pour chaque IP qu’il autorise
a	Résoudre les enregistrements A/AAAA du domaine	Un ip4:/ip6: par adresse
mx	Résoudre les enregistrements MX, puis les A/AAAA de chaque hôte de messagerie	ip4:/ip6: pour l’IP de chaque hôte MX
ptr	Ne pas aplatir — il est déprécié, lent et peu fiable	Le supprimer
exists:	Ne peut généralement pas être aplati (dépend de macros à l’exécution)	Conserver tel quel ou isoler sur un sous-domaine
ip4/ip6	Déjà statique	Conserver inchangé

Parcourez le graphe en profondeur d’abord et gardez la trace des domaines déjà visités afin de détecter les includes circulaires — si un include pointe vers un domaine déjà présent dans votre pile de résolution, arrêtez-vous et conservez-le comme include plutôt que de boucler indéfiniment.

Étape 4 : dédupliquer et agréger les CIDR

L’expansion récursive produit des chevauchements. Deux fournisseurs peuvent partager une IP, ou vous pouvez collecter plusieurs blocs /25 adjacents qui se combinent proprement en un /24. Dédupliquez chaque adresse, puis agrégez les plages adjacentes en super-réseaux uniquement lorsque l’union reste entièrement à l’intérieur de l’espace autorisé d’un seul fournisseur. Sur-agréger entre des fournisseurs non liés autorise des IP que vous ne contrôlez pas — une régression de sécurité, pas une optimisation.

Étape 5 : surveiller la taille de l’enregistrement

Les chaînes DNS TXT sont limitées à 255 caractères par segment entre guillemets ; les enregistrements plus longs doivent être divisés en plusieurs chaînes concaténées au sein du même enregistrement. En règle pratique, maintenez la réponse totale sous environ 450-900 octets pour éviter la fragmentation UDP et les problèmes de middlebox. Si la liste aplatie est trop grande, répartissez les IP dans des étiquettes auxiliaires (par exemple spf-a.example.com, spf-b.example.com) contenant chacune uniquement des entrées ip4/ip6 et incluez-les depuis l’enregistrement principal — chaque auxiliaire coûte une requête, alors gardez le total ≤ 10.

Étape 6 : rattacher le qualificateur all et valider

Ajoutez votre mécanisme de terminaison d’origine — -all pour une application stricte est recommandé pour les expéditeurs en production. Puis repassez l’enregistrement dans un validateur SPF pour confirmer que la syntaxe est propre, qu’il n’y a toujours qu’un seul enregistrement, et que le nombre de requêtes est là où vous l’attendez. Si vous migrez avec prudence, vous pouvez publier avec ~all brièvement, puis passer à -all une fois que la surveillance montre des taux de réussite stables.

Étape 7 : publier avec un TTL faible, puis l’augmenter

Avant de publier, abaissez le TTL de l’enregistrement à 60-300 secondes afin que toute erreur puisse être corrigée rapidement. Publiez le nouvel enregistrement aplati, vérifiez qu’il se résout correctement depuis plusieurs résolveurs publics (Google, Cloudflare, Quad9), et surveillez vos rapports agrégés DMARC pour tout recul des taux de réussite SPF. Une fois les choses stabilisées, remontez le TTL à 1-4 heures.

Le hic : les enregistrements aplatis se périment

Voici le problème qui piège la plupart des gens qui aplatissent à la main. Dès l’instant où vous aplatissez, votre enregistrement est un instantané. Lorsque Google, Mailchimp, Amazon SES ou tout autre fournisseur fait tourner ses IP d’envoi — et les grands ESP le font constamment — votre liste codée en dur ne correspond plus à la réalité. Les e-mails provenant des nouvelles IP échouent silencieusement au SPF, et vous voilà de retour aux factures perdues et aux réinitialisations de mot de passe échouées, sauf que cette fois la cause est invisible parce que l’enregistrement semble correct.

Les expéditeurs adossés à un CDN et les expéditeurs marketing sont les pires : les données internes d’AutoSPF sur plus de 1 200 domaines montrent que les expéditeurs adossés à un CDN renouvellent 8-15 % de leur ensemble d’IP chaque mois, contre moins de 0,5 % pour les serveurs de messagerie internes. Aplatir aveuglément un fournisseur à fort renouvellement, c’est chercher les ennuis.

Les enseignements pratiques :

• Aplatissez les sources stables (relais sur site, IP cloud statiques) agressivement.
• Laissez les ESP volatils en includes, ou isolez-les derrière un sous-domaine délégué comme mail-out.example.com que la racine inclut avec une seule requête.
• Ne considérez jamais l’aplatissement comme définitif — il nécessite une re-résolution continue.

Automatiser le ré-aplatissement avec AutoSPF

Refaire les étapes 1 à 7 à la main chaque fois qu’un fournisseur change d’IP n’est pas réaliste. C’est exactement ce pour quoi le service d’aplatissement SPF automatisé d’AutoSPF est conçu. Il exécute en continu l’algorithme d’aplatissement déterministe ci-dessus : il ré-analyse vos includes toutes les 15 minutes, et lorsque les IP d’un fournisseur en amont changent, il met à jour automatiquement votre enregistrement publié via l’API de votre fournisseur DNS — avec des permutations atomiques, des TTL échelonnés et une restauration en un clic si une vérification canari échoue.

De façon cruciale, AutoSPF résout vers les mêmes IP exactement que vos includes — il n’élargit jamais l’autorisation avec des fusions de CIDR trop larges, si bien que vous n’autorisez pas accidentellement des expéditeurs que vous n’aviez pas prévus. Vous gardez un enregistrement petit et stable à la racine ; AutoSPF le maintient correct en arrière-plan.

Pour décider lesquelles de vos sources aplatir ou déléguer, consultez notre guide sur les meilleurs outils d’aplatissement SPF. Si vous préférez éviter complètement de coder les IP en dur, comparez les approches dans l’aplatissement SPF vs les macros. Et avant d’aplatir, il vaut la peine de confirmer que le changement ne perturbera pas vos autres enregistrements d’authentification — consultez l’aplatissement SPF affecte-t-il DKIM et DMARC.

Foire aux questions

L’aplatissement d’un enregistrement SPF casse-t-il DKIM ou DMARC ?

Non, lorsqu’il est fait correctement. L’aplatissement change seulement quelles IP le SPF autorise — il ne touche pas aux signatures DKIM ni à l’alignement DMARC. Le risque est indirect : si un enregistrement aplati obsolète commence à échouer au SPF pour des e-mails légitimes, cela peut faire baisser les taux de réussite DMARC. Maintenez l’enregistrement re-résolu et les deux restent sains.

Combien de requêtes DNS un enregistrement SPF aplati utilise-t-il ?

Un enregistrement entièrement aplati utilise zéro requête DNS au moment de l’évaluation, car chaque IP autorisée est listée explicitement en ip4:/ip6:. Si vous conservez quelques includes volatils ou répartissez les IP dans des étiquettes auxiliaires, chacune d’elles ajoute une requête — gardez simplement le total à la limite de 10 de la RFC 7208 ou en dessous.

Puis-je aplatir les mécanismes ptr et exists ?

En général non. ptr est déprécié, lent et devrait simplement être supprimé. exists: s’appuie généralement sur des macros à l’exécution (évaluant MAIL FROM ou HELO au moment de la vérification), il ne peut donc pas être réduit à une liste d’IP statiques. Conservez exists tel quel, ou isolez-le sur un sous-domaine délégué pour limiter son impact en requêtes.

À quelle fréquence un enregistrement SPF aplati doit-il être mis à jour ?

Aussi souvent que vos expéditeurs changent d’IP. Les serveurs de messagerie internes peuvent être stables pendant des semaines, mais les grands ESP et CDN peuvent changer d’adresses quotidiennement. C’est pourquoi l’aplatissement manuel est fragile et pourquoi AutoSPF ré-analyse toutes les 15 minutes, publiant automatiquement un enregistrement mis à jour dès qu’un ensemble d’IP en amont change.

Que se passe-t-il si mon enregistrement aplati devient trop grand ?

Les enregistrements DNS TXT sont limités à 255 caractères par chaîne, et les enregistrements surdimensionnés risquent la fragmentation UDP. Si la liste d’IP aplatie est trop grande, répartissez-la dans des étiquettes auxiliaires (contenant chacune uniquement des entrées ip4/ip6) et incluez-les depuis l’enregistrement principal, ou déléguez les fournisseurs volatils à un sous-domaine. Visez à maintenir la réponse totale sous ~900 octets et les requêtes ≤ 10.

Dois-je aplatir mon enregistrement SPF manuellement ou utiliser un outil ?

L’aplatissement manuel fonctionne pour une correction ponctuelle, mais il ne peut pas suivre le rythme des fournisseurs qui font tourner leurs IP — un enregistrement aplati à la main désautorise silencieusement les expéditeurs dès qu’une plage en amont change. Un outil géré comme AutoSPF prend en charge pour vous la résolution récursive, la déduplication, la gestion de la taille et le ré-aplatissement continu, ce qui en fait l’approche recommandée pour tout ce qui va au-delà d’un unique expéditeur statique.