SPF expliqué : syntaxe, limite des 10 requêtes DNS et flattening

SPF fait partie des bases de l’authentification email.

Il indique aux serveurs qui reçoivent vos messages quelles plateformes ont le droit d’envoyer des emails pour votre domaine.

Sur le papier, le principe est simple : publier une ligne TXT dans le DNS. Dans la pratique, beaucoup de problèmes viennent d’une syntaxe trop chargée, d’anciens outils jamais retirés, ou de la limite des 10 recherches DNS.

À quoi sert SPF ?

SPF signifie Sender Policy Framework.

Quand un serveur reçoit un email, il regarde le domaine utilisé dans l’expéditeur d’enveloppe, aussi appelé MAIL FROM ou Return-Path. Il récupère ensuite l’enregistrement SPF publié dans le DNS de ce domaine.

Si l’adresse IP du serveur qui envoie le message est autorisée par SPF, le test peut passer. Si elle ne l’est pas, le résultat peut être fail, softfail, neutral ou une erreur selon la configuration.

SPF répond donc à une question précise :

Ce serveur a-t-il le droit d’envoyer pour ce domaine d’enveloppe ?

Ce point est important : SPF ne vérifie pas directement l’adresse visible par l’utilisateur dans le champ “De”. C’est DMARC qui relie ensuite SPF au domaine visible, grâce à la notion d’alignement.

La syntaxe d’un enregistrement SPF

Un SPF est publié sous forme d’enregistrement DNS TXT.

Il commence toujours par v=spf1, puis liste des mécanismes qui décrivent les sources autorisées.

Exemple classique :

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

Dans cette ligne :

• v=spf1 annonce qu’il s’agit d’un enregistrement SPF ;
• include:_spf.google.com autorise les serveurs décrits par le SPF de Google ;
• include:sendgrid.net autorise les serveurs décrits par SendGrid ;
• ip4:203.0.113.10 autorise directement une adresse IPv4 ;
• -all indique que tout le reste doit échouer.

On rencontre aussi ip6, a, mx, exists ou redirect.

Le piège est de voir SPF comme une simple liste. En réalité, certains mécanismes déclenchent d’autres requêtes DNS, parfois en cascade.

Les qualifiers : +, -, ~ et ?

Chaque mécanisme SPF peut être précédé d’un qualifier.

Quand il n’y en a pas, + est implicite. Cela signifie “pass”.

Les qualifiers les plus courants :

• + : la source est autorisée ;
• - : la source n’est pas autorisée, résultat strict fail ;
• ~ : la source n’est probablement pas autorisée, résultat softfail ;
• ? : SPF ne se prononce pas, résultat neutral.

La fin de ligne la plus fréquente est -all ou ~all.

Pour un domaine de production bien maîtrisé, -all est généralement l’objectif. Pour une phase d’audit ou de transition, ~all peut être utilisé temporairement, le temps de vérifier les flux.

La limite des 10 requêtes DNS

SPF impose une limite : pendant l’évaluation d’un enregistrement, le serveur destinataire ne doit pas dépasser 10 recherches DNS liées à certains mécanismes.

Cette limite évite qu’un SPF trop complexe ralentisse ou surcharge les résolutions DNS.

Les mécanismes qui consomment des recherches DNS sont notamment :

• include ;
• a ;
• mx ;
• ptr ;
• exists ;
• redirect.

À l’inverse, ip4, ip6 et all ne consomment pas de recherche DNS supplémentaire.

Le point le plus souvent oublié : les include peuvent eux-mêmes contenir d’autres include. Le compteur ne regarde pas seulement votre ligne visible. Il additionne aussi ce que les fournisseurs déclarent derrière leurs propres enregistrements.

Exemple :

v=spf1 include:_spf.google.com include:sendgrid.net include:spf.protection.outlook.com include:mail.service.example -all

Cette ligne paraît courte. Pourtant, elle peut déjà provoquer beaucoup de recherches si chaque fournisseur délègue à d’autres domaines.

Quand la limite est dépassée, le résultat peut devenir permerror. Dans ce cas, SPF n’est plus fiable pour le domaine concerné.

Pourquoi les SPF deviennent trop longs

Un SPF propre au départ se dégrade souvent avec le temps.

On ajoute Microsoft 365, puis une plateforme newsletter, puis un CRM, puis un outil de facturation, puis le site web, puis un ancien routeur SMTP qui reste là “au cas où”.

Chaque ajout semble logique isolément. Mais l’ensemble finit par devenir fragile.

Les causes fréquentes :

• anciens fournisseurs jamais retirés ;
• plusieurs outils qui envoient depuis le domaine principal ;
• include ajoutés sans mesurer leur coût DNS ;
• SPF dupliqué sur plusieurs enregistrements TXT ;
• usage de mx ou a alors que des IP explicites suffiraient ;
• manque de sous-domaines dédiés pour les flux marketing, transactionnels ou applicatifs.

Un domaine ne doit publier qu’un seul enregistrement SPF. Plusieurs TXT commençant par v=spf1 sur le même nom provoquent une erreur.

Le flattening SPF

Le flattening consiste à remplacer certains include par les adresses IP qu’ils résolvent.

Au lieu de demander au destinataire de suivre plusieurs délégations DNS, on publie directement une liste d’IP ou de plages IP.

Exemple simplifié avant flattening :

v=spf1 include:spf.crm.example include:spf.newsletter.example -all

Exemple simplifié après flattening :

v=spf1 ip4:198.51.100.0/24 ip4:203.0.113.12 ip6:2001:db8::/48 -all

Le bénéfice est clair : moins de recherches DNS pendant l’évaluation SPF.

Mais le flattening a un coût : les fournisseurs peuvent changer leurs plages IP. Si la ligne aplatie n’est pas mise à jour, des emails légitimes peuvent échouer SPF.

Le flattening n’est donc pas une opération à faire une fois puis à oublier. Il doit être surveillé, documenté et idéalement automatisé.

Quand utiliser le flattening ?

Le flattening peut être utile quand le domaine approche ou dépasse la limite des 10 recherches DNS, et qu’il n’est pas possible de simplifier autrement.

Mais ce n’est pas toujours la première solution.

Avant de flatten un SPF, il vaut mieux :

1. retirer les anciens fournisseurs ;
2. vérifier si chaque outil envoie encore vraiment ;
3. déplacer certains flux vers des sous-domaines ;
4. remplacer a ou mx par des IP explicites si c’est pertinent ;
5. activer DKIM sur les plateformes modernes ;
6. vérifier l’alignement DMARC.

Le flattening est une réponse technique à une contrainte DNS. Il ne doit pas masquer un problème d’architecture email trop concentrée sur le domaine principal.

SPF, sous-domaines et architecture d’envoi

Une bonne configuration SPF commence souvent par une meilleure séparation des flux.

Par exemple, une entreprise peut garder exemple.com pour les échanges collaborateurs, puis utiliser :

• news.exemple.com pour les newsletters ;
• factures.exemple.com pour les notifications de facturation ;
• app.exemple.com pour les emails transactionnels ;
• support.exemple.com pour l’outil de ticketing.

Chaque sous-domaine peut avoir son propre SPF, son DKIM et sa politique DMARC adaptée.

Cette approche réduit la complexité du SPF principal et limite l’impact d’un problème sur un seul flux.

Elle améliore aussi la lecture des rapports DMARC, car les sources d’envoi deviennent plus faciles à distinguer.

Bonnes pratiques SPF

Un SPF solide doit rester lisible.

Voici les règles à garder en tête :

• publier un seul enregistrement SPF par domaine ;
• éviter les include inutiles ;
• compter les recherches DNS réelles, y compris celles des fournisseurs ;
• documenter chaque source autorisée ;
• préférer ip4 et ip6 quand les IP sont stables ;
• éviter ptr, rarement utile et coûteux ;
• ne pas utiliser +all, qui autorise tout ;
• viser -all quand les flux sont maîtrisés ;
• surveiller après chaque changement de fournisseur ou d’outil.

SPF doit être maintenu comme un inventaire vivant des plateformes autorisées à envoyer.

Conclusion

SPF est simple à expliquer, mais facile à rendre fragile.

Sa syntaxe repose sur quelques mécanismes, mais les include, a, mx, exists et redirect peuvent rapidement consommer la limite des 10 recherches DNS.

Le flattening peut aider, à condition d’être maintenu. Sinon, il transforme un problème de limite DNS en risque de panne silencieuse quand un fournisseur change ses IP.

La bonne approche consiste à garder un SPF court, documenté, mesuré et cohérent avec l’architecture d’envoi : un domaine principal propre, des sous-domaines quand les flux se multiplient, DKIM activé partout où c’est possible, et DMARC pour contrôler l’alignement.