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

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

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 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 à jour.

Aplatir rompt ce lien. L'opération fige un instantané des IP du prestataire à la date de l'aplatissement. Le jour où il bascule sur une nouvelle plage non recopiée, le courrier émis depuis cette plage échoue à SPF — et rien ne le signale sur le moment. C'est l'ironie cruelle du flattening : un PermError corrigé aujourd'hui contre des échecs silencieux demain.

L'autre coût caché : la taille de l'enregistrement

La maintenance n'est pas le seul revers du flattening — il y en a un purement mécanique. Remplacer une poignée d'include par toutes les plages d'adresses qu'ils contiennent peut transformer un enregistrement d'une ligne en un enregistrement énorme. Or le DNS impose de vraies contraintes : une chaîne TXT est plafonnée à 255 caractères, un enregistrement long doit donc être découpé en plusieurs chaînes, et une réponse très volumineuse peut dépasser ce que certains résolveurs gèrent confortablement en UDP, provoquant troncature et nouvelles tentatives. Rien d'insurmontable, mais c'est de la fragilité ajoutée exactement là où l'on cherchait de la robustesse — et chaque ré-aplatissement fait de nouveau bouger l'enregistrement. Avant de tout aplatir, la question mérite d'être posée : le remède ne produit-il pas un enregistrement si massif qu'il devient un risque opérationnel à lui seul ?

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, l'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 l'enregistrement (souvent via une délégation DNS ou un include vers un enregistrement géré). La dette de maintenance s'échange alors contre une dépendance à ce service — et, en pratique, un include (vers le service) réapparaît dans le SPF. Ce n'est pas un mal, mais la mécanique d'include n'a pas vraiment disparu : elle a seulement changé de place.

Quand le flattening est une bonne idée…

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

• le décompte est réellement bloqué au-dessus de dix résolutions et que les autres leviers ne suffisent pas ;
• les prestataires ont des plages d'IP stables (certaines infrastructures changent rarement) ;
• une surveillance est en place pour signaler l'évolution d'une IP de prestataire, ou un service automatisé fiable prend le relais.

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, mieux vaut épuiser les options plus saines :

1. Faire 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éparer les flux par sous-domaine. Marketing sur news.exemple.fr, transactionnel sur notif.exemple.fr : chaque sous-domaine a son propre budget de dix résolutions, et les include maintenus par les prestataires restent en place. C'est l'approche la plus durable, et celle qu'on recommande en premier.
3. Ne remplacer que 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 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.

La qualification terminale n'est pas à sacrifier

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 d'un SPF — -all (hardfail) reste la bonne qualification terminale pour un domaine maîtrisé. Aplatir et affaiblir sont deux décisions distinctes, à ne surtout pas confondre. La nuance est expliquée dans les mécanismes -all et ~all.

Vérifier après aplatissement

Une fois l'enregistrement aplati, deux contrôles s'imposent :

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 un enregistrement SPF.
2. Les sources passent toujours, dans la durée. Les rapports agrégés des semaines suivantes méritent d'être surveillés : une source qui se met soudain à échouer à SPF est le signal qu'une plage d'IP a changé et que l'aplatissement a vieilli.

Questions fréquentes

Le flattening améliore-t-il la délivrabilité ? Pas directement. Il corrige un PermError qui, lui, plombait la 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é des prestataires. Certains ne bougent presque jamais, d'autres changent leurs plages plusieurs fois par an. Sans service automatisé, une revue régulière s'impose — 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 l'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 la responsabilité de chaque IP de chaque prestataire devient alors interne, à vie. C'est rarement raisonnable, sauf pour une infrastructure d'envoi entièrement maîtrisée par l'organisation.

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.

Thomas choisit la bonne approche

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

Analyser un domaine gratuitement ou créer un compte pour garder un SPF propre et sous la barre.