Aplatissement SPF

L’aplatissement SPF consiste à résoudre chaque mécanisme de votre enregistrement SPF qui déclenche une requête - include:, a, mx, ptr, exists et redirect= - jusqu’aux adresses IP concrètes qui se trouvent derrière, puis à publier ces adresses directement sous forme d’entrées ip4: et ip6:. L’objectif est simple : maintenir votre enregistrement à l’intérieur des limites strictes imposées par les serveurs de réception, afin que les messages légitimes continuent de s’authentifier à mesure que votre infrastructure d’envoi se développe.

Cette page est le point central de tout ce qui concerne l’aplatissement SPF. Elle explique ce qu’est l’aplatissement, pourquoi la limite de 10 requêtes force la main, comment le processus fonctionne étape par étape, et où se situent les véritables compromis et risques. À partir d’ici, vous pouvez approfondir des tâches précises : comment aplatir un enregistrement SPF, les meilleurs outils d’aplatissement SPF, la question de savoir si l’aplatissement SPF affecte DKIM et DMARC, la manière de le faire sur Cloudflare, et la comparaison entre l’aplatissement et l’aplatissement SPF vs les macros.

Qu’est-ce que l’aplatissement SPF ?

Un enregistrement SPF est un unique enregistrement TXT, commençant par v=spf1, qui indique aux serveurs de messagerie destinataires quels hôtes sont autorisés à envoyer des e-mails pour votre domaine. Lorsque vous ajoutez un service - un CRM, une plateforme marketing, un service d’assistance, un fournisseur d’e-mails transactionnels - vous ajoutez généralement un include: pour celui-ci. Chaque include: pointe vers l’enregistrement SPF d’un autre domaine, et le destinataire doit récupérer cet enregistrement au moment de l’évaluation. Ces récupérations sont des requêtes DNS, et elles s’accumulent rapidement.

L’aplatissement SPF prend toutes ces références indirectes et les pré-résout. Au lieu de demander au destinataire de suivre include:_spf.google.com à travers des enregistrements _netblocks imbriqués, un enregistrement aplati liste simplement les plages d’IP sous-jacentes :

• Avant : v=spf1 include:sendgrid.net include:_spf.google.com a mx -all
• Après : v=spf1 ip4:149.72.0.0/16 ip4:167.89.0.0/17 ip4:64.233.160.0/19 ip6:2a00:1450:4000::/36 -all

Au moment de l’évaluation, le destinataire ne parcourt plus les includes de manière récursive et ne résout plus les cibles A/MX - il compare simplement l’IP de connexion à vos plages CIDR publiées. Cela ramène le nombre de requêtes DNS à l’exécution à pratiquement zéro et garde votre enregistrement léger, rapide et fiable.

« La limite de 10 requêtes est de loin la raison la plus fréquente pour laquelle les enregistrements SPF des entreprises cessent silencieusement de fonctionner », déclare Brad Slavin, directeur général de DuoCircle et fondateur d’AutoSPF. « D’après notre expérience de gestion du SPF pour plus de 2 000 domaines clients, le mode de défaillance est toujours le même : une équipe ajoute un nouvel outil SaaS, son include pousse le total au-delà de 10, et les e-mails légitimes commencent à échouer - mais personne ne s’en aperçoit avant qu’un client ne se plaigne de factures ou de réinitialisations de mot de passe manquantes. »

Pourquoi la limite de 10 requêtes DNS impose l’aplatissement

Selon la RFC 7208, l’évaluation SPF est plafonnée à 10 requêtes DNS de mécanisme et 2 requêtes nulles par vérification. Dépasser l’une ou l’autre limite produit un PermError - un échec permanent qui indique aux serveurs de réception que votre e-mail ne peut pas être authentifié. Le serveur ne réessaie pas, et il n’évalue pas le reste de votre enregistrement. Il s’arrête simplement, et chaque message de votre domaine échoue au SPF.

Le piège, c’est que cette limite reste invisible jusqu’à ce que vous la franchissiez. Une petite entreprise qui envoie via un seul fournisseur ne l’atteindra jamais. Mais les infrastructures de messagerie modernes empilent régulièrement plusieurs ESP, un CRM, un service d’assistance et la messagerie interne - et chacun ajoute une ou plusieurs requêtes. Google Workspace consomme à lui seul environ quatre de vos dix requêtes à travers ses includes imbriqués. Ajoutez Salesforce, Mailchimp, SendGrid et Zendesk et vous pouvez facilement atteindre douze à quinze. La onzième requête n’est jamais évaluée, si bien que le service qui se trouve au-delà de ce point perd silencieusement son autorisation.

Voici quels mécanismes comptent :

Déclenche une requête DNS	Ne déclenche pas de requête
include:example.com	ip4:x.x.x.x[/CIDR]
a, a:example.com	ip6:…
mx, mx:example.com	all
ptr (déconseillé par la RFC 7208)
exists:domain
redirect=example.com

Comme les mécanismes ip4: et ip6: ne nécessitent aucune résolution, l’aplatissement échange chaque mécanisme générant une requête contre des mécanismes qui n’en génèrent aucune. C’est là tout le mécanisme par lequel l’aplatissement vous maintient conforme. Un moyen rapide de savoir où vous en êtes aujourd’hui est de passer votre domaine dans le SPF Checker, qui développe chaque include et compte vos requêtes.

Pourquoi l’aplatissement compte pour la délivrabilité et la sécurité

La limite de 10 requêtes n’est pas qu’une simple note technique - elle se situe directement sur le chemin entre vos e-mails et la boîte de réception.

Délivrabilité. DMARC s’appuie sur SPF et DKIM. Si votre enregistrement SPF renvoie un PermError, DMARC le traite comme un échec, et les e-mails légitimes peuvent être mis en quarantaine ou rejetés. Depuis 2024, Google, Yahoo et Microsoft exigent des expéditeurs en masse qu’ils s’authentifient avec SPF, DKIM et DMARC, et ils rejettent désormais purement et simplement les messages non conformes plutôt que de les acheminer vers les spams. Ensemble, ces fournisseurs couvrent environ 90 % d’une liste grand public type, si bien qu’un seul enregistrement dépassant la limite peut couper la distribution vers la majeure partie de votre audience d’un seul coup.

Sécurité. Lorsque le SPF échoue, les serveurs de réception perdent la capacité de distinguer vos e-mails légitimes des messages usurpés. C’est précisément la faille qu’exploitent le phishing et la compromission de messagerie professionnelle. Maintenir le SPF valide - et sous la limite - préserve le signal d’authentification qui vous distingue d’un attaquant se faisant passer pour votre domaine.

Gérabilité. À mesure que votre marque grandit, la liste des plateformes qui envoient en votre nom s’allonge aussi. L’aplatissement condense une chaîne tentaculaire d’includes en une seule liste nette de plages d’IP, facile à lire, à auditer et à appréhender.

Comment fonctionne l’aplatissement SPF, étape par étape

Qu’il soit réalisé manuellement ou par automatisation, l’aplatissement suit le même pipeline :

1. Découverte. Lisez votre enregistrement SPF TXT actuel et identifiez chaque mécanisme qui déclenche une requête - include, a, mx, exists, redirect.
2. Résolution récursive. Suivez chaque chaîne d’include, en récupérant l’enregistrement SPF de la cible et en récursant jusqu’à ce que tout le contenu en amont soit connu. Résolvez les cibles a/mx vers leurs enregistrements A/AAAA pour rassembler les adresses IPv4 et IPv6.
3. Dédupliquer et compresser. Fusionnez les plages qui se chevauchent et agrégez les blocs contigus en notation CIDR afin que l’enregistrement reste compact.
4. Publier. Réécrivez l’enregistrement sous la forme v=spf1 ip4:… ip6:… -all, en respectant la limite de 255 caractères par chaîne TXT (divisez en plusieurs chaînes concaténées si nécessaire), et mettez à jour votre DNS.
5. Valider. Confirmez la syntaxe, vérifiez que le nombre de requêtes est de 0 à 1, et envoyez un e-mail de test pour confirmer SPF=pass et DMARC=pass.

Pour la procédure complète avec les commandes et les spécificités des fournisseurs DNS, consultez comment aplatir un enregistrement SPF.

Le hic : un enregistrement aplati n’est pas une solution définitive

L’aplatissement résout le problème des requêtes, mais il en introduit un nouveau. Lorsque vous remplacez un include: dynamique par des IP statiques, vous prenez la responsabilité de maintenir ces IP à jour. Les fournisseurs font constamment tourner leur infrastructure d’envoi, et ils vous préviennent rarement lorsqu’ils le font.

« L’idée fausse au sujet de l’aplatissement SPF est qu’il s’agit d’une solution définitive », déclare Adam Lundrigan, directeur technique de DuoCircle et architecte du moteur d’aplatissement d’AutoSPF. « Les plages d’IP des fournisseurs changent constamment - Google a fait tourner ses _netblocks trois fois rien qu’en 2025. Un enregistrement aplati qui n’est pas automatiquement re-résolu devient obsolète et désautorise silencieusement les expéditeurs légitimes. C’est pourquoi AutoSPF effectue une nouvelle analyse toutes les 15 minutes. »

C’est la chose la plus importante à comprendre au sujet de l’aplatissement. Un enregistrement aplati construit à la main est exact le jour où vous le publiez, puis se périme lentement ensuite. Lorsqu’un fournisseur ajoute une nouvelle plage d’IP, les e-mails provenant de cette plage commencent à échouer au SPF - et comme l’échec est silencieux, vous l’apprenez généralement par une facture rejetée ou une réinitialisation de mot de passe manquée, et non par une alerte. Dans la télémétrie d’AutoSPF sur 1 200 domaines, l’aplatissement a réduit les taux de PermError de 93 % et amélioré les taux de réussite DMARC de 7 à 12 % au cours des 30 premiers jours - mais seulement lorsque l’enregistrement était maintenu à jour. Le taux médian de renouvellement des IP des ESP se situe entre 2 et 4 changements par semaine pour les fournisseurs à fort volume.

Les autres compromis à anticiper :

• Taille de l’enregistrement. L’aplatissement peut pousser un enregistrement TXT vers les limites de taille du DNS. Visez à maintenir les réponses sous environ 1 000 à 1 200 octets pour éviter la fragmentation et la troncature UDP, et préférez des plages CIDR agrégées plutôt que l’énumération d’adresses individuelles.
• Sur-autorisation. Certains includes autorisent bien plus d’Internet que ce que vous utilisez réellement. Auditer et élaguer avant d’aplatir permet de garder votre surface d’attaque réduite.

Manuel, scripté ou automatisé ?

Il existe trois façons d’aplatir, avec des profils de risque très différents :

• Manuel. Interrogez chaque include pour ses IP actuelles, agrégez-les et publiez à la main. Gratuit et entièrement sous votre contrôle, mais laborieux et sujet à la dérive dès qu’un fournisseur change ses IP. Praticable uniquement pour de petits environnements statiques.
• Scripté. Un script Python ou Go récurse les includes, résout les A/MX, fusionne les plages CIDR et pousse vers le DNS via une API selon une planification. Reproductible et auditable, mais vous êtes responsable des cas limites, de la protection contre les boucles et de la fiabilité continue.
• Service automatisé (dynamique). Un service hébergé re-résout en continu vos includes, détecte les changements d’IP et republie automatiquement. Cela supprime entièrement la charge de maintenance, au prix d’une dépendance gérée.

Pour toute organisation utilisant des fournisseurs dynamiques comme Google Workspace, Microsoft 365, SendGrid ou Amazon SES, une approche automatisée est fortement recommandée - toute la difficulté de l’aplatissement consiste à suivre le rythme du renouvellement, et c’est exactement ce que gère l’automatisation. Une comparaison complète des options se trouve dans les meilleurs outils d’aplatissement SPF.

Où se situe AutoSPF

Le service d’aplatissement SPF automatique d’AutoSPF est spécialement conçu pour le problème de maintenance qui rend l’aplatissement risqué. Il découvre et développe vos includes imbriqués, résout les chaînes A/MX/AAAA complètes, déduplique et compresse les plages en blocs CIDR minimaux, et publie un enregistrement aplati validé et attentif à la taille qui reste sous la limite de 10 requêtes.

Deux éléments le distinguent :

• Il effectue une nouvelle analyse toutes les 15 minutes et met à jour automatiquement votre enregistrement dès que les IP d’un fournisseur en amont changent - de sorte qu’un enregistrement aplati ne se périme jamais silencieusement.
• Il résout vers exactement les mêmes IP que vos includes - pas de plages larges et trop permissives, et pas de sur-autorisation. Votre enregistrement aplati autorise précisément les hôtes que vos véritables includes autorisent, et rien de plus.

En plus de cela, il propose des enregistrements versionnés avec restauration en un clic, une publication canari/de préproduction, et des alertes de dérive lorsque des e-mails arrivent d’IP situées en dehors de votre ensemble aplati actuel. Il s’intègre directement aux principaux fournisseurs DNS, dont Route 53, Cloudflare, Google Cloud DNS et Azure DNS. Avant et après tout changement, vous pouvez confirmer que l’enregistrement se résout proprement avec le SPF Checker.

L’aplatissement à travers les fournisseurs DNS et à grande échelle

Les mécanismes de l’aplatissement sont les mêmes partout, mais la publication diffère selon la plateforme. Sur Cloudflare, par exemple, vous gérez l’enregistrement TXT via le tableau de bord ou l’API et devez respecter son comportement de découpage en chaînes - les détails sont couverts dans l’aplatissement SPF sur Cloudflare.

À l’échelle du SaaS - des milliers de locataires, plusieurs flux d’envoi - le modèle gagnant est en couches : segmentez les flux de messagerie sur des sous-domaines (par exemple mkt.example.com pour le marketing, tx.example.com pour le transactionnel), centralisez la politique avec redirect= vers un petit enregistrement canonique, aplatissez entièrement les fournisseurs à fort renouvellement en ensembles ip4/ip6 agrégés, et automatisez le rafraîchissement avec une publication basée sur les différences afin que les enregistrements inchangés ne provoquent jamais de dérive DNS. Déléguer les gros expéditeurs à des sous-domaines garde aussi votre domaine organisationnel léger et simplifie l’alignement DMARC.

L’aplatissement modifie-t-il DKIM ou DMARC ?

L’aplatissement change uniquement la façon dont les expéditeurs autorisés sont exprimés dans le SPF - ip4/ip6 au lieu d’include - et non l’identité de votre domaine ni vos signatures DKIM. Tant que le SPF aplati est publié sur le domaine utilisé dans votre MAIL FROM/Return-Path, l’alignement DMARC n’est pas affecté, et en éliminant le PermError, il améliore généralement les taux de réussite DMARC lorsque le SPF est l’identifiant aligné. La relation complète, y compris la façon dont DKIM porte souvent l’alignement pour les expéditeurs en masse, est couverte dans l’aplatissement SPF affecte-t-il DKIM et DMARC.

Aplatissement vs macros SPF

L’aplatissement traditionnel pré-résout les includes en IP statiques, ce qui explique pourquoi il nécessite un rafraîchissement constant. Les macros SPF empruntent une voie différente : elles utilisent l’expansion dynamique pour qu’un seul enregistrement puisse autoriser un nombre pratiquement illimité d’expéditeurs sans jamais atteindre la limite de 10 requêtes - au prix d’une complexité accrue et d’une prise en charge plus faible par les résolveurs. L’approche qui vous convient dépend de votre infrastructure et de votre appétence pour la maintenance ; l’analyse complète se trouve dans l’aplatissement SPF vs les macros.

Foire aux questions

Qu’est-ce que l’aplatissement SPF en termes simples ?

L’aplatissement SPF est le processus consistant à remplacer les mécanismes include:, a et mx de votre enregistrement SPF par les adresses IP réelles auxquelles ils se résolvent. Cela donne aux serveurs de messagerie destinataires une liste toute prête d’IP autorisées au lieu de les forcer à effectuer des requêtes DNS, ce qui maintient votre enregistrement sous la limite de 10 requêtes définie par la RFC 7208 et prévient les échecs d’authentification.

Pourquoi l’aplatissement SPF est-il nécessaire ?

L’aplatissement devient nécessaire lorsque votre domaine dépasse le plafond de la spécification SPF de 10 requêtes DNS par évaluation. Une fois cette limite franchie, le SPF renvoie un PermError et chaque message de votre domaine échoue à l’authentification, ce qui peut aussi faire échouer DMARC. Comme la plupart des organisations utilisent plusieurs expéditeurs tiers qui ajoutent chacun des includes, les domaines en croissance atteignent rapidement le plafond et ont besoin de l’aplatissement pour rester conformes.

L’aplatissement SPF améliore-t-il la délivrabilité des e-mails ?

Oui. En éliminant les conditions PermError et TempError provoquées par un trop grand nombre de requêtes ou des includes en amont lents, l’aplatissement maintient un SPF qui passe de manière fiable. Dans les données clients d’AutoSPF, le passage de 12-18 requêtes à un enregistrement entièrement aplati a réduit de plus de 80 % les échecs DMARC liés au SPF et amélioré le placement en boîte de réception des e-mails marketing de 10 à 15 % lors des pics d’envoi.

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

Aussi souvent que vos fournisseurs changent d’IP. Les ESP à fort renouvellement comme SendGrid et Mailchimp justifient des rafraîchissements toutes les 12 à 24 heures, les suites stables comme Google Workspace et Microsoft 365 quotidiennement, et les plages statiques auto-hébergées chaque semaine. Un enregistrement maintenu à la main finit presque toujours par dériver - AutoSPF évite cela en effectuant une nouvelle analyse toutes les 15 minutes et en republiant automatiquement chaque fois qu’une plage en amont change.

L’aplatissement SPF manuel est-il sûr ?

L’aplatissement manuel n’est sûr que pour les petits environnements statiques où les IP d’envoi changent rarement. Pour tout domaine utilisant des fournisseurs dynamiques, un enregistrement construit à la main se périme dès qu’un fournisseur fait tourner son infrastructure, désautorisant silencieusement les expéditeurs légitimes. L’aplatissement automatisé est fortement recommandé à toute échelle réelle, car suivre le rythme du renouvellement des fournisseurs est la partie difficile.

Dois-je utiliser -all ou ~all après l’aplatissement ?

Utilisez -all (échec strict) lorsque vous êtes certain que votre liste aplatie est complète et activement surveillée, car il donne aux destinataires le signal le plus clair pour rejeter les e-mails usurpés. Utilisez ~all (échec souple) pendant le déploiement ou tant que vous ajoutez encore fréquemment des expéditeurs. Une bonne pratique consiste à conserver ~all jusqu’à ce que les rapports DMARC montrent une fenêtre de réussite propre, puis à resserrer vers -all.