L'aplatissement SPF expliqué — Comment résoudre la limite de 10 recherches DNS
· DMARC Analyzer Pro
Vous atteignez la limite SPF de 10 recherches DNS ? Découvrez ce qu'est l'aplatissement SPF, pourquoi la limite existe et comment la résoudre sans casser votre authentification e-mail.
Si vous gérez la messagerie d'une organisation de taille moyenne ou grande, vous avez presque certainement rencontré la limite SPF de 10 recherches DNS. Votre enregistrement SPF grandit avec chaque service tiers que vous autorisez à envoyer des e-mails — votre CRM, plateforme marketing, helpdesk, système RH — et avant que vous ne le réalisiez, l'authentification commence à échouer silencieusement. L'aplatissement SPF est la solution, mais il doit être effectué avec précaution.
Pourquoi la limite de 10 recherches existe
La spécification SPF (RFC 7208) impose une limite stricte de 10 recherches DNS par évaluation SPF. C'était une décision de conception délibérée pour empêcher les vérifications SPF de devenir un vecteur de déni de service. Chaque mécanisme `include:`, `a:`, `mx:` et `redirect=` dans votre enregistrement SPF déclenche une recherche DNS. Les includes imbriqués comptent aussi — si l'enregistrement SPF de votre plateforme marketing inclut trois autres domaines, ces trois recherches sont décomptées de votre budget.
Une fois que vous dépassez 10, la vérification SPF renvoie un résultat `permerror`, que la plupart des serveurs récepteurs traitent comme un échec. Le pire ? Cet échec est silencieux. Vous ne recevrez pas de message de rebond, et vos e-mails atterriront silencieusement en spam ou seront rejetés.
Ce que fait l'aplatissement SPF
L'aplatissement SPF remplace les mécanismes gourmands en recherches DNS (comme `include:`) par les adresses IP ou les plages CIDR résolues vers lesquelles ils pointent. Au lieu de `include:spf.protection.outlook.com`, votre enregistrement aplati pourrait contenir `ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/14` — et similairement pour chaque service.
Puisque les mécanismes `ip4:` et `ip6:` ne nécessitent pas de recherches DNS, votre enregistrement aplati peut autoriser des dizaines de services tout en restant bien en dessous du plafond de 10 recherches.
Le piège : les adresses IP changent
C'est là que beaucoup d'organisations se font piéger. Les fournisseurs cloud et les plateformes SaaS font tourner leurs adresses IP d'envoi régulièrement. Microsoft, Google et d'autres mettent à jour leurs plages SPF sans préavis. Si vous aplatissez votre enregistrement une fois et l'oubliez, vous finirez par manquer des plages IP que vos services utilisent activement — entraînant des échecs SPF pour le courrier légitime.
C'est pourquoi l'aplatissement SPF doit être automatisé. Une solution d'aplatissement appropriée surveille en permanence les enregistrements SPF sources, détecte les changements et met à jour votre enregistrement aplati en conséquence. L'aplatissement manuel est une bombe à retardement.
Bonnes pratiques pour l'aplatissement SPF
Premièrement, auditez votre enregistrement SPF actuel. Identifiez chaque `include:` et déterminez si chaque service est encore utilisé. Il est courant de trouver des includes pour des plateformes que vous avez cessé d'utiliser il y a des années. Supprimez-les d'abord — vous n'aurez peut-être même pas besoin d'aplatissement.
Deuxièmement, utilisez un outil d'aplatissement automatisé qui surveille les changements en amont et vous alerte lorsque des mises à jour sont nécessaires. Idéalement, il devrait mettre à jour automatiquement vos enregistrements DNS ou vous fournir des enregistrements prêts à publier.
Troisièmement, gardez toujours un `~all` ou `-all` à la fin de votre enregistrement aplati. Le softfail (`~all`) est un choix plus sûr pendant la transition, mais une fois confiant dans votre configuration, passez au hardfail (`-all`) pour une protection plus forte.
Enfin, surveillez attentivement vos rapports DMARC après avoir effectué des modifications. Vos rapports agrégés DMARC vous montreront exactement quels messages passent ou échouent le SPF — vous donnant un filet de sécurité qui détecte les problèmes avant qu'ils n'impactent vos utilisateurs.