Le SPF flattening, c'est quoi (et quand l'utiliser vraiment)

Dès qu'un domaine accumule trop de prestataires d'envoi, il bute sur la fameuse limite des dix résolutions DNS de SPF. Parmi les solutions qui reviennent, une porte un nom intrigant : le SPF flattening (ou « aplatissement »). L'idée est séduisante sur le papier — résoudre les include une fois pour toutes et les remplacer par des adresses IP — mais elle cache une dette de maintenance que beaucoup découvrent trop tard. Ce guide explique précisément ce qu'est le flattening, comment il fonctionne, ses vrais risques, et dans quels cas il vaut mieux choisir une autre approche.

Le problème que le flattening prétend résoudre

Rappel express : chaque include:, a, mx ou ptr dans ton enregistrement SPF coûte au moins une résolution DNS, et la RFC 7208 en plafonne le total à dix. Au-delà, c'est le PermError : ton SPF n'est plus évalué du tout, et ton courrier légitime risque la quarantaine ou le rejet. Les include de prestataires (Microsoft 365, Google Workspace, un routeur marketing…) se déplient souvent en plusieurs résolutions chacun, si bien qu'on franchit la limite sans s'en apercevoir.

Le flattening attaque ce problème à la racine : puisque ce sont les include qui coûtent des résolutions, on les supprime — en les remplaçant par les adresses IP qu'ils contiennent.

Comment fonctionne l'aplatissement

Le principe est mécanique. Pour chaque include de ton enregistrement, on résout récursivement tout ce qu'il référence (sous-include, a, mx) jusqu'à obtenir la liste complète des plages d'adresses autorisées. Puis on remplace l'include par les ip4: et ip6: correspondants.

Prenons un exemple. Un enregistrement classique :

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

Après aplatissement, il pourrait ressembler à :

v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20
  ip4:167.89.0.0/17 ip4:168.245.0.0/17 ... -all

Le résultat ne contient plus que des ip4:/ip6: — des littéraux qui ne comptent pas dans la limite des dix. Le décompte de résolutions tombe à zéro (hors le mécanisme terminal). Sur le papier, problème réglé.

Le piège : les IP des prestataires changent

Voilà ce que les guides enthousiastes oublient souvent de dire. Les plages d'IP derrière un include de prestataire ne sont pas figées. Microsoft, Google, SendGrid et les autres ajoutent, retirent ou réorganisent leurs serveurs régulièrement. C'est même tout l'intérêt de l'include : il pointe vers un enregistrement que le prestataire maintient pour toi.

En aplatissant, tu romps ce lien. Tu figes un instantané des IP du prestataire à la date de l'aplatissement. Le jour où il bascule sur une nouvelle plage que tu n'as pas recopiée, le courrier émis depuis cette plage échoue à SPF — et tu ne le verras pas tout de suite. C'est l'ironie cruelle du flattening : tu corriges un PermError aujourd'hui et tu t'exposes à des échecs silencieux demain.

Aplatissement manuel ou automatisé

Pour gérer ce risque, deux écoles :

• L'aplatissement manuel consiste à résoudre et recopier les IP à la main. Simple à comprendre, mais c'est précisément là que la dette mord : sans surveillance, ton enregistrement périme dès que le prestataire bouge. À réserver aux prestataires dont les plages sont stables et documentées.
• L'aplatissement automatisé délègue le suivi à un service qui ré-aplatit périodiquement et met à jour ton enregistrement (souvent via une délégation DNS ou un include vers un enregistrement géré). Tu échanges la dette de maintenance contre une dépendance à ce service — et, en pratique, tu réintroduis un include (vers le service) dans ton SPF. Ce n'est pas un mal, mais sache que tu n'as pas vraiment supprimé la mécanique d'include, tu l'as déplacée.

Quand le flattening est une bonne idée…

Le flattening n'est pas à diaboliser. Il a sa place quand :

• tu es réellement bloqué au-dessus de dix résolutions et que les autres leviers ne suffisent pas ;
• tes prestataires ont des plages d'IP stables (certaines infrastructures changent rarement) ;
• tu mets en place une surveillance qui te prévient si une IP de prestataire évolue, ou tu utilises un service automatisé fiable.

Dans ces conditions, c'est un outil légitime pour tenir un enregistrement complexe sous la barre.

…et quand il vaut mieux l'éviter

Pour beaucoup d'organisations, le flattening est une réponse disproportionnée. Avant d'y recourir, épuise les options plus saines :

1. Fais le ménage des include inutiles. La moitié des dépassements vient d'outils qu'on n'utilise plus. C'est gratuit et sans risque.
2. Sépare tes flux par sous-domaine. Marketing sur news.ton-domaine.fr, transactionnel sur notif.ton-domaine.fr : chaque sous-domaine a son propre budget de dix résolutions, et tu gardes les include maintenus par les prestataires. C'est l'approche la plus durable, et celle qu'on recommande en premier.
3. Remplace seulement les prestataires à IP stables par des ip4:, en laissant en include ceux qui bougent.

Dans la grande majorité des cas, ces trois leviers suffisent à repasser sous dix sans la dette du flattening complet. La séquence détaillée est dans la limite de 10 lookups DNS.

Un cas réel : la PME multi-prestataires

Illustrons avec une situation très courante. Une PME envoie depuis Microsoft 365 (messagerie), un routeur marketing, un outil de facturation et un service de signature électronique. Son SPF empile quatre include, qui se déplient en treize résolutions — PermError garanti. La tentation est de tout aplatir d'un coup. Mauvaise idée : trois de ces quatre prestataires changent leurs plages d'IP plusieurs fois par an.

La bonne lecture du cas commence par trier les prestataires selon la stabilité de leurs IP, pas selon leur volume. Microsoft 365 publie un include riche mais bien maintenu : on le garde en include, car le figer t'obligerait à courir derrière ses mises à jour mensuelles. Le service de signature, lui, n'a qu'une poignée d'IP fixes documentées : on peut les inscrire en ip4: sans risque, économisant une résolution. Le routeur marketing, gros consommateur, part sur un sous-domaine news.pme.fr avec son propre SPF — il quitte donc complètement le décompte du domaine racine.

Résultat : le domaine racine ne porte plus que Microsoft 365 (en include), la facturation (en include) et la signature (en ip4:), soit cinq ou six résolutions — sous la barre, et sans aplatir le prestataire le plus instable. On n'a aplati que ce qui était sûr de l'être. C'est ça, le bon usage du flattening : un scalpel ciblé sur les IP stables, pas une hache sur tout l'enregistrement. La maintenance résiduelle se limite à surveiller la poignée d'ip4: figés, ce qu'un contrôle trimestriel couvre largement.

Ne sacrifie pas la qualification terminale

Un réflexe à éviter, qu'on voit souvent accompagner le flattening : profiter de la refonte pour passer en ~all « par sécurité ». Le flattening ne change rien à la rigueur de ton SPF — -all (hardfail) reste la bonne qualification terminale pour un domaine maîtrisé. Aplatir et affaiblir sont deux décisions distinctes ; ne les confonds pas. La nuance est expliquée dans les mécanismes -all et ~all.

Vérifier après aplatissement

Une fois l'enregistrement aplati, contrôle deux choses :

1. Le décompte de résolutions est bien repassé sous dix, et la syntaxe est valide — un coup d'œil dans notre analyseur gratuit, comme décrit dans comment vérifier ton enregistrement.
2. Tes sources passent toujours, dans la durée. Surveille tes rapports agrégés les semaines suivantes : une source qui se met soudain à échouer à SPF est le signal qu'une plage d'IP a changé et que ton aplatissement a vieilli.

Questions fréquentes

Le flattening améliore-t-il la délivrabilité ? Pas directement. Il corrige un PermError qui, lui, plombait ta délivrabilité — donc l'effet net peut être positif. Mais aplatir un SPF déjà sous la limite n'apporte rien et ajoute de la dette.

Vais-je devoir ré-aplatir souvent ? Cela dépend de la stabilité de tes prestataires. Certains ne bougent presque jamais, d'autres changent leurs plages plusieurs fois par an. Sans service automatisé, prévois une revue régulière — c'est justement la dette à anticiper.

Le flattening contourne-t-il aussi les limites de DKIM ? La question ne se pose pas : DKIM n'a pas de limite de résolutions. Le problème des dix lookups est propre à SPF. C'est d'ailleurs une raison de soigner ton alignement DKIM, plus robuste — voir comment les trois protocoles fonctionnent ensemble.

Puis-je tout mettre en ip4: et n'avoir aucun include ? Techniquement oui, mais tu deviens responsable de chaque IP de chaque prestataire, à vie. C'est rarement raisonnable, sauf pour une infrastructure d'envoi entièrement maîtrisée en interne.

Le flattening résout-il le double enregistrement SPF ? Non, ce sont deux problèmes distincts. Avoir deux enregistrements v=spf1 est une erreur de configuration à corriger en fusionnant en un seul — indépendamment du décompte de résolutions.

Laisse Thomas choisir la bonne approche

Faut-il aplatir, faire le ménage, ou découper en sous-domaines ? La réponse dépend de tes prestataires réels et de la stabilité de leurs IP. Thomas, ton RSSI virtuel, déplie ton SPF, identifie les include gourmands, distingue ceux qu'on peut figer sans risque de ceux qui bougent, et te recommande la correction la plus durable pour ton cas — pas la plus à la mode.

Analyse ton domaine gratuitement → ou crée un compte pour garder un SPF propre et sous la barre.