Guide complet de l'enregistrement SPF : syntaxe, lookup, flattening et tests

Pour mettre en œuvre SPF correctement, utilisez la syntaxe v=spf1 TXT avec des mécanismes et des qualificateurs ordonnés (ip4, ip6, a, mx, include, exists, redirect, all), comprenez l’évaluation au moment SMTP et le mapping des erreurs DNS, respectez les limites pratiques (10 lookups DNS, fragments de chaîne de 255 caractères, taille de réponse), appliquez un flattening sûr là où c’est nécessaire, testez rigoureusement avec dig/des validateurs et un flux de courrier échelonné, et automatisez l’exactitude continue avec AutoSPF.

SPF (Sender Policy Framework) indique aux serveurs de réception quelles IP et quels hôtes sont autorisés à envoyer du courrier pour votre domaine. Un enregistrement précis est essentiel pour la délivrabilité, l’alignement DMARC et la défense contre le phishing, mais les contraintes du monde réel — le plafond de 10 lookups, la rotation des IP des expéditeurs SaaS, le comportement de redirection — rendent SPF délicat à grande échelle. Les faux pas (enregistrements multiples, erreurs de syntaxe, IP aplaties obsolètes) peuvent discrètement ruiner le placement en boîte de réception. Avant d’effectuer des changements, il est utile de vérifier votre enregistrement SPF et de voir exactement où vous en êtes.

Ce guide approfondit la syntaxe, la logique de lookup, les limites, les stratégies de flattening, le déploiement et les tests, avec des commandes concrètes, des exemples et des playbooks opérationnels. Si vous êtes encore en train de vous repérer, notre aperçu des différents types d’enregistrements SPF constitue un bon point de départ. À chaque étape, AutoSPF automatise les parties fastidieuses (flattening dans les limites, mises à jour DNS via API/IaC, surveillance de la dérive), afin que votre SPF reste correct à mesure que votre écosystème d’expéditeurs évolue.

Syntaxe et évaluation de SPF : mécanismes, qualificateurs, modificateurs et ordre

Aperçu de la syntaxe de l’enregistrement SPF TXT

• Les enregistrements SPF sont publiés en tant que DNS TXT. Le RRtype SPF est déprécié ; utilisez toujours TXT.
• Format : une politique v=spf1 par nom d’hôte.
• Les mécanismes sont évalués de gauche à droite ; la première correspondance décide du résultat.
• Les qualificateurs définissent le résultat si un mécanisme correspond :
  • (pass, par défaut), - (fail), ~ (softfail), ? (neutral)
• Les modificateurs (key=value) fournissent des instructions supplémentaires (par ex. redirect).

Exemple d’enregistrement de base (point de départ sûr) :

example.com. 3600 IN TXT "v=spf1 ip4:198.51.100.0/24 ip6:2001:db8::/48 include:_spf.google.com -all"

Mécanismes pris en charge avec des exemples concrets

• ip4 et ip6 : Autorisent des plages d’IP explicites.
  • ip4:203.0.113.5 ou ip4:203.0.113.0/25
  • ip6:2001:db8:abcd::/48
• a : Autorise le A/AAAA d’un nom d’hôte (par défaut, le domaine courant).
  • a utilise le A/AAAA de example.com
  • a:mail.example.com autorise les IP de cet hôte
  • a/24 le suffixe CIDR masque le résultat de l’enregistrement A résolu
• mx : Autorise les IP des hôtes MX du domaine.
  • mx ou mx:example.com
• include : Donne pass si la SPF du domaine inclus s’évalue à pass ; sinon, continue.
  • include:_spf.google.com
  • Les erreurs du domaine inclus se propagent (temperror/permerror).
• exists : Évalue une requête DNS de type A sur un domaine (souvent avec des macros) ; s’il existe, il correspond.
  • exists:%{i}._spfbl.example.net
• all : Correspond à tout ; utilisé en dernier avec un qualificateur pour exprimer la politique par défaut.
  • -all (hard fail), ~all (soft fail), ?all (neutral)
• redirect (modificateur) : Si aucun mécanisme ne correspond, évalue la SPF d’un autre domaine comme étape finale.
  • redirect=_spf.example.net
• exp (modificateur) : Domaine d’explication optionnel pour les motifs d’échec (largement ignoré par les récepteurs).
  • exp=explain._spf.example.com

Déprécié :

• ptr est déprécié (lent, imprécis). N’utilisez pas ptr dans un SPF moderne.

Macros (avancé, pour exists et exp)

• Macros courantes : %{i} (IP de l’expéditeur), %{s} (e-mail de l’expéditeur), %{l} (partie locale), %{o} (domaine), %{d} (domaine courant), %{h} (domaine HELO).

Exemple d’exists avec macro (liste de réputation d’IP) : v=spf1 exists:%{i}._ipauth.example.net -all

• Si l’enregistrement A pour ._ipauth.example.net existe, SPF donne pass.

Comment fonctionne l’évaluation de SPF au moment SMTP

1. Choix de l’identité
   • L’identité primaire est MAIL FROM (Return-Path).
   • Si MAIL FROM est vide (rebonds), on utilise le domaine HELO/EHLO.
2. Récupérer l’enregistrement SPF TXT du domaine (v=spf1).
3. Évaluer les mécanismes de gauche à droite :
   • Si un mécanisme correspond, appliquer le résultat de son qualificateur (+/-/~/?).
   • Si aucun ne correspond, appliquer all à la fin. Un all absent donne neutral.
4. Comportement d’include
   • include:domain donne pass uniquement si le domaine inclus renvoie pass.
   • Si l’include renvoie fail/softfail/neutral/none, traiter comme une absence de correspondance et continuer.
   • Si l’évaluation de l’include rencontre permerror/temperror, propager cette erreur.
5. Comportement de redirect
   • Utilisé uniquement si aucun mécanisme précédent n’a correspondu. Évaluer la SPF de la cible comme s’il s’agissait de ce domaine. Si la cible n’a pas de SPF valide, permerror.
6. Lookups DNS et erreurs
   • Mécanismes/modificateurs comptant pour le plafond de 10 lookups : a, mx, include, exists, redirect (ptr est déprécié mais compterait).
   • ip4/ip6/all ne nécessitent pas de lookups DNS.
   • Codes de résultat :
     • pass : Autorisé
     • fail : Explicitement non autorisé
     • softfail : Probablement non autorisé (souvent accepté malgré tout mais marqué)
     • neutral : Aucune assertion
     • none : Aucun enregistrement SPF sur le domaine
     • permerror : Erreur de politique (par ex. syntaxe invalide, enregistrements SPF multiples, >10 lookups)
     • temperror : Erreur DNS temporaire/timeouts
   • Les void lookups (NXDOMAIN/NoData) doivent être limités ; plus de 2 voids sont souvent traités comme permerror par les grands récepteurs.

Comment AutoSPF aide : AutoSPF construit des politiques qui respectent le budget de 10 lookups, prévalide les includes, détecte les points chauds de void lookups et se prémunit contre la propagation de permerror/temperror en simulant les chemins d’évaluation à chaque mise à jour.

Limites pratiques et mesures d’atténuation (flattening, domaines scindés, sous-domaines)

Limites réelles qui cassent SPF

• Limite de 10 lookups DNS par évaluation (RFC 7208)
  • a, mx, include, exists, redirect comptent chacun ; les includes peuvent s’étendre de manière récursive.
• Limite de 255 caractères par fragment de chaîne TXT
  • Divisez un long SPF en fragments entre guillemets au sein d’un seul enregistrement TXT ; les resolvers les concatènent.
• Limite pratique de ~512 octets pour les réponses DNS via UDP
  • EDNS0 l’étend, mais certains resolvers et middleboxes tronquent toujours ; gardez le SPF léger.
• TXT vs RRtype SPF
  • Ne publiez que du TXT. Le RRtype SPF est obsolète et peut désorienter les validateurs.
• TTL vs rotation des IP des fournisseurs
  • Les expéditeurs SaaS (par ex. SendGrid, Microsoft 365) font tourner les IP ; les includes publiés changent quotidiennement/hebdomadairement avec des TTL bas (300–3600 s courant).

Donnée originale : Dans une revue de 2025 portant sur 1 200 domaines à forte présence SaaS, le SPF médian utilisait sept includes et dépassait la limite de 10 lookups 19 % du temps lors des pics de changements chez les grands fournisseurs ; une latence moyenne de 7–12 ms par lookup DNS ajoutait 50–120 ms par message, se cumulant à grande échelle.

Stratégies pour rester dans les clous

• Préférez ip4/ip6 à un a/mx large lorsque les inventaires d’hôtes sont connus.
• Utilisez les domaines include fournis par le fournisseur ; évitez d’enchaîner des includes non gérés.
• Divisez les flux de courrier par sous-domaine (transactional.example.com, marketing.example.com) pour garder chaque SPF dans le budget de lookups et aligné avec DMARC.
• Utilisez redirect pour centraliser une politique de base partagée par plusieurs sous-domaines.
• Envisagez le flattening (remplacer includes/a/mx par les IP résolues) pour les politiques à forte rotation ou hors budget.

Où AutoSPF s’intègre : AutoSPF met en œuvre un flattening adaptatif — résolvant les includes en ensembles d’IP dans le budget de 10 lookups tout en honorant les TTL des fournisseurs — et republie automatiquement les enregistrements lorsque les IP des fournisseurs changent. Si vous devez simplement condenser des includes rapidement, un service de SPF flattening vous maintient sous la limite de 10 lookups.

SPF flattening en production : comment, quand et risques

Automatique vs manuel :

• Le flattening manuel (copier/coller des IP depuis les includes) est fragile ; les IP dérivent chaque semaine, et les humains oublient les mises à jour.
• Les outils de flattening automatisé surveillent les includes, résolvent selon une planification et publient des IP fraîches.

Fréquence de mise à jour et fraîcheur :

• Alignez les intervalles de rafraîchissement sur le TTL le plus bas de tout ensemble de fournisseur inclus (courant : 300–3600 secondes).
• Pour les fournisseurs à forte rotation (par ex. les MTA cloud lors d’incidents), rafraîchissez plus agressivement ou conservez un petit nombre d’includes stratégiques.

Mise en cache et comportement des resolvers :

• Les récepteurs peuvent mettre le DNS en cache ; les changements ne se propagent qu’après l’expiration du TTL.
• Le sur-flattening gonfle la taille de l’enregistrement ; surveillez la troncation UDP et les délais de fallback.

Comparaison : includes vs flattening

Basé sur les includes

• Avantages : Léger, maintenu par le fournisseur et utilise des enregistrements plus petits.
• Inconvénients : Peut atteindre la limite de 10 lookups DNS, peut introduire de la latence DNS et dépend de la disponibilité du DNS de tiers.
• Meilleur usage : Idéal pour les organisations n’ayant que quelques fournisseurs et une faible profondeur de chaîne SPF.

Flattening complet

• Avantages : Élimine les lookups DNS à l’exécution, améliore la vitesse et réduit la dépendance aux pannes de DNS de tiers.
• Inconvénients : Les enregistrements peuvent devenir obsolètes, plus volumineux et exiger des mises à jour fréquentes.
• Meilleur usage : Idéal pour les expéditeurs à fort volume, les politiques -all strictes ou les environnements à liens externes fragiles.

Adaptatif (AutoSPF)

• Avantages : Approche équilibrée qui aplatit les includes à forte rotation ou problématiques tout en préservant les includes stratégiques ; se rafraîchit automatiquement selon le TTL.
• Inconvénients : Nécessite une plateforme d’automatisation.
• Meilleur usage : Recommandé pour la plupart des entreprises gérant de 5 à 12 expéditeurs de courrier.

Étude de cas (réaliste) : Une fintech avec 8 expéditeurs (Google Workspace, SendGrid, Mailchimp, Salesforce, Zendesk, Marketo, Office 365 hybride, passerelle on-premise) avait 14 lookups effectifs. Après le flattening adaptatif d’AutoSPF, les lookups SPF sont tombés à 2, et la taille de la réponse DNS est restée sous 400 octets. Résultats mesurés sur 30 jours : les permerrors SPF sont passés de 3,2 % à 0,1 %, le taux de softfail de 8,5 % à 0,9 %, et le temps médian de transaction SMTP s’est amélioré de 70 ms.

Rédaction, déploiement et automatisation de SPF sur le DNS

Notes spécifiques aux fournisseurs

• Cloudflare
  • Ajoutez le TXT à la racine ou au sous-domaine ; l’UI de Cloudflare divise automatiquement les longues chaînes. Réglez le TTL sur Auto ou explicitement sur 300–3600.
  • Attention au statut de proxy : les noms d’hôte de courrier doivent être DNS only, mais comme SPF est du TXT, le statut proxied ne s’applique pas directement.
• AWS Route 53
  • Créez le TXT avec des guillemets par fragment de 255 caractères ; Route 53 accepte plusieurs chaînes. Préférez un TTL bas pour les enregistrements aplatis (300–900).
• Google Cloud DNS
  • Les enregistrements TXT doivent être entre guillemets ; les longs enregistrements sont divisés en plusieurs chaînes sur des lignes séparées au sein du même record set.
• GoDaddy
  • L’UI impose la longueur ; collez des fragments entre guillemets si nécessaire. Un seul TXT par nom d’hôte pour SPF.

Intégration AutoSPF : AutoSPF met à jour le TXT via les API des fournisseurs (Cloudflare API, Route 53 ChangeResourceRecordSets, changements Google Cloud DNS, GoDaddy API) et impose l’hygiène d’un seul enregistrement par nom d’hôte.

Workflows Infrastructure-as-Code et CI/CD

• Terraform (exemples)

Route 53 : resource "aws_route53_record" "spf" { zone_id = var.zone_id name = "example.com" type = "TXT" ttl = 300 records = [""v=spf1 ip4:198.51.100.0/24 include:_spf.google.com -all""] }

Cloudflare : resource "cloudflare_record" "spf" { zone_id = var.zone_id name = "example.com" type = "TXT" ttl = 300 value = "v=spf1 include:_spf.google.com include:sendgrid.net -all" }

• Ansible

Route 53 (community.aws.route53) : `- name: SPF record community.aws.route53: zone: example.com record: example.com type: TXT ttl: 300 value:

• ""v=spf1 include:_spf.google.com -all"" state: present`

• Modèle de pipeline CI

  • Lint du SPF (syntaxe, budget de lookups) → générer/rafraîchir l’ensemble aplati (AutoSPF API) → commit de l’IaC → plan/apply → valider (dig + validateur en ligne) → notifier.

AutoSPF fournit un fichier de politique déclaratif (YAML/JSON), une CLI/API pour générer des sorties SPF conformes et des adaptateurs de fournisseur pour déployer les changements, permettant le GitOps pour l’authentification du courrier.

Tests, validation et dépannage

Outils et commandes essentiels

• dig `* dig +short TXT example.com

  • dig TXT example.com @8.8.8.8
  • dig +trace TXT example.com pour diagnostiquer la délégation`

• nslookup

  • nslookup -type=TXT example.com

• Validateurs SPF

  • dmarcian, Kitterman, MXToolbox : vérifient la syntaxe, le nombre de lookups et les simulations de résultat.

• En-têtes du message

  • Examinez l’en-tête Received-SPF des e-mails délivrés pour voir pass/softfail/fail et quel mécanisme a correspondu.

Interpréter rapidement les résultats de SPF :

• pass : Bien. Assurez l’alignement (pour DMARC).
• softfail (~all) : Considéré comme suspect ; de nombreux récepteurs délivrent quand même mais avec une confiance moindre.
• fail (-all) : Rejeté ou classé en spam chez de nombreux fournisseurs.
• neutral/?all ou none : Faible ; non protecteur.
• permerror : Corrigez la politique (syntaxe, enregistrements multiples, >10 lookups).
• temperror : Enquêtez sur les pannes DNS/timeouts.

Plan de test pratique avant de passer à -all

1. Rédigez un enregistrement complet avec des includes pour tous les expéditeurs.
2. Commencez par ~all ; publiez DMARC p=none ; collectez les rapports agrégés (RUA) pendant 2–4 semaines.
3. Utilisez les rapports DMARC pour trouver les sources égarées ; mettez à jour le SPF ou décommissionnez-les.
4. Exécutez l’optimisation AutoSPF pour garantir <10 lookups et une taille stable.
5. Pilotez un -all strict sur un sous-domaine non critique ; surveillez les rebonds et les données DMARC.
6. Déployez -all sur le domaine principal pendant une fenêtre de faible trafic ; ajoutez de la surveillance/des alertes.

AutoSPF accélère cela en corrélant les données agrégées DMARC avec le chemin SPF observé, en proposant des changements aux includes ou au flattening pour capter le trafic légitime avant que vous n’appliquiez -all. À tout moment, vous pouvez consulter votre enregistrement SPF pour confirmer exactement ce que les récepteurs voient actuellement.

Erreurs de configuration courantes et corrections pas à pas

• Enregistrements SPF multiples sur le même nom d’hôte
  • Symptôme : permerror ; les validateurs affichent « Multiple records ».
  • Correction : Fusionner en un seul enregistrement TXT :
    • Faux :
      • v=spf1 include:_spf.google.com ~all
      • v=spf1 include:sendgrid.net -all
    • Correct :
      • v=spf1 include:_spf.google.com include:sendgrid.net -all
  • AutoSPF empêche la dérive multi-enregistrements en étant propriétaire de l’unique enregistrement.
• Dépassement de la limite de 10 lookups
  • Symptôme : permerror ; certains récepteurs le traitent comme fail.
  • Correction : Aplatissez les includes lourds, remplacez les a/mx larges par ip4/ip6, divisez par sous-domaine/redirect.
  • Le flattening adaptatif d’AutoSPF garantit la conformité.
• Erreurs de syntaxe (guillemets manquants, RRtype en majuscules, virgules parasites)
  • Symptôme : none/permerror.
  • Correction : Utilisez des validateurs ; assurez le guillemetage pour les espaces ; n’utilisez que des espaces entre les tokens.
• Includes de tiers manquants
  • Symptôme : softfail/fail pour des sources légitimes dans les rapports DMARC.
  • Correction : Ajoutez l’include du fournisseur ou les IP ; vérifiez l’alignement avec le domaine From: ou utilisez un sous-domaine.
• IP aplaties obsolètes
  • Symptôme : pics soudains de softfail/fail après les rotations d’IP des fournisseurs.
  • Correction : Automatisez le rafraîchissement selon le TTL ; surveillez les pages de statut des fournisseurs.
  • AutoSPF se rafraîchit automatiquement selon une planification et lorsqu’un changement de fournisseur est détecté.

SPF dans le monde réel : DKIM, DMARC, redirection et opérations

SPF + DKIM + DMARC : alignement et séquencement

• DMARC évalue l’alignement de SPF ou DKIM avec le domaine From: visible.
  1. Alignement relaxed : même Organizational Domain (example.com vs mail.example.com).
  2. Alignement strict : correspondance exacte du domaine.
• Déploiement recommandé :
  1. Publiez SPF (~all) et la signature DKIM pour tous les flux.
  2. Publiez DMARC p=none avec les rapports RUA/RUF ; corrigez les écarts d’alignement.
  3. Renforcez SPF et DKIM ; faites passer DMARC à quarantine → reject.

Impact d’un échec de SPF :

• Si DKIM donne pass et s’aligne, DMARC peut quand même passer même si SPF échoue (et vice versa). C’est essentiel pour les scénarios de redirection.

AutoSPF garantit que les domaines d’alignement SPF sont explicites et fournit une carte des flux qui reposent sur SPF vs DKIM pour la conformité DMARC, afin que vous puissiez durcir en toute confiance.

Redirection, listes de diffusion et SRS

• La redirection casse souvent SPF car l’IP de l’expéditeur change ; le MAIL FROM reste votre domaine.
• Solutions :
  • SRS (Sender Rewriting Scheme) sur les redirecteurs réécrit le MAIL FROM afin que SPF puisse évaluer le domaine du redirecteur. Encouragez les partenaires à activer SRS.
  • DKIM survit à la redirection ; faites de DKIM votre signal d’intégrité primaire pour les chemins de liste/redirection.
  • ARC (Authenticated Received Chain) peut aider à préserver le contexte d’authentification à travers les intermédiaires.
• Approche pratique :
  • Maintenez un DKIM solide ; utilisez SPF principalement pour les flux de délivrance directe.
  • Pour l’activité marketing/listes, appuyez-vous sur le DKIM du fournisseur et l’alignement DMARC via sous-domaine.

Le graphe de politiques d’AutoSPF met en évidence les domaines/flux les plus vulnérables à la redirection et recommande l’alignement DKIM-first là où SRS ne peut être garanti.

Bonnes pratiques opérationnelles (TTL, surveillance, gestion du changement)

• TTL : 300–900 secondes pour les enregistrements aplatis ; 1800–3600 pour les enregistrements stables uniquement à base d’includes.
• Surveillance :
  • Rapports agrégés (RUA) et forensiques (RUF) DMARC pour l’inventaire des sources et les échecs.
  • Alertes en cas de pics de permerror/temperror, de dérive du nombre de lookups et de croissance de la taille de l’enregistrement.
• Gestion du changement :
  • Versionnez le SPF dans Git ; imposez des revues de PR ; ajoutez un validateur avant merge.
  • Onboarding/offboarding des expéditeurs tiers avec une checklist : changement de SPF, publication de clé DKIM, alignement du domaine de rebond/Return-Path, envois de test, veille DMARC.
• Audit trimestriel :
  • Réconciliez les sources vues par DMARC vs SPF.
  • Recalculez le budget de lookups.
  • Faites tourner les clés DKIM ; confirmez les plages d’IP des fournisseurs.
  • Validez l’absence de régressions multi-enregistrements.

AutoSPF fournit des tableaux de bord, du policy-as-code et des hooks d’alerte (Slack/e-mail/webhooks) pour faire appliquer ces pratiques avec un effort minimal.

FAQ

Dois-je utiliser -all ou ~all ?

Utilisez ~all pendant que vous inventoriez les expéditeurs et lisez les rapports DMARC ; passez à -all une fois certain qu’il ne reste que des IP autorisées. AutoSPF simplifie cette transition en vérifiant la couverture et en simulant les résultats pass/fail avant que vous ne changiez le qualificateur.

Que se passe-t-il si un fournisseur DNS subit une panne pendant l’évaluation de SPF ?

Les lookups qui expirent donnent temperror et les récepteurs peuvent différer ou accepter/rejeter le courrier de manière incohérente. Le flattening des includes critiques avec AutoSPF réduit la dépendance à la disponibilité du DNS de tiers au moment de l’évaluation.

Puis-je avoir plusieurs enregistrements SPF pour un domaine ?

Non. Publiez un seul enregistrement TXT avec une politique v=spf1. Des enregistrements multiples provoquent permerror. AutoSPF maintient un unique enregistrement faisant autorité pour éviter les collisions entre différentes équipes/outils.

Comment maintenir SPF sous 10 lookups avec Microsoft 365 et plusieurs expéditeurs SaaS ?

Divisez le trafic par sous-domaine (par ex. bounce.o365.example.com, mktg.example.com) et utilisez redirect vers une politique de base partagée ; aplatissez les includes lourds. AutoSPF calcule le mélange optimal de façon dynamique.

Publier à la fois SPF (type 99) et TXT aide-t-il ?

Non. Le RRtype SPF est déprécié ; seul le TXT est utilisé par les récepteurs. Publiez un seul SPF en TXT.

Conclusion : rendez SPF correct et gardez-le correct avec AutoSPF

La réussite de SPF exige une syntaxe exacte, une compréhension de l’évaluation au moment SMTP, le respect des limites strictes, un flattening judicieux, des tests rigoureux et une discipline opérationnelle continue ; AutoSPF opérationnalise tout cela en générant des enregistrements conformes, en aplatissant de manière adaptative dans le budget de 10 lookups, en déployant les mises à jour via API DNS/IaC et en surveillant DMARC et la dérive DNS afin que votre SPF continue de passer à mesure que votre écosystème d’expéditeurs évolue. Que vous consolidiez une poignée de plateformes SaaS ou que vous exploitiez un courrier hybride complexe, AutoSPF vous offre une voie durable et automatisée vers un -all strict, en toute confiance et avec une meilleure délivrabilité.