Guide de syntaxe SPF : composants, règles, exemples et validation

Si vous vous êtes déjà demandé pourquoi certains de vos e-mails légitimes finissaient dans les dossiers de spam ou étaient tout simplement bloqués, le problème pourrait venir de la configuration de l’authentification des e-mails de votre domaine. La syntaxe SPF est ici un élément clé, car elle joue un rôle crucial dans la vérification que vos e-mails sont bien envoyés depuis des serveurs autorisés. Bien que SPF éviter que vos messages ne soient signalés comme suspects, sa syntaxe peut être difficile à comprendre et encore plus compliquée à configurer correctement. 

Dans cet article, nous allons vous expliquer en détail le fonctionnement de la syntaxe SPF et ce à quoi vous devez faire attention lorsque vous les configurez pour votre domaine.

Qu'est-ce que la syntaxe SPF ?

La syntaxe d'un enregistrement SPF est l'ensemble des règles qui définissent comment un enregistrement SPF (Sender Policy Framework) est écrit dans le DNS d'un domaine. En termes simples, il s'agit du "langage" utilisé par votre domaine pour indiquer aux serveurs de messagerie destinataires les sources autorisées à envoyer des courriels en son nom.

La syntaxe SPF comprend généralement des mécanismes (tels que « ip4 », « ip6 » ou « include »), des qualificatifs (tels que « + », « - », « ~ » ou « ? ») et des modificateurs qui, combinés, permettent de déterminer si un e-mail entrant satisfait ou non à la SPF .

Il est essentiel de comprendre cette syntaxe, car même une erreur mineure, telle qu'un espace supplémentaire, un qualificatif incorrect ou un mécanisme manquant, peut faire échouer l'authentification de vos courriels et les faire atterrir dans les spams ou les rejeter.

Remarque concernantl'alignement DMARC: SPF le domaine de l'expéditeur de l'enveloppe, et non pas toujours l'adresse « De » visible par les utilisateurs dans leur boîte de réception. Pour que le DMARC soit validé via SPF, le domaine indiqué dans le champ « Return-Path » doit correspondre au domaine « De » visible. C'est pourquoi SPF être associé aux protocoles DKIM et DMARC.

Structure et composants de la syntaxe SPF

Un SPF se compose de quatre éléments principaux : l'indicateur de version, les mécanismes, les qualificatifs et les modificateurs. Chaque élément joue un rôle spécifique et, ensemble, ils déterminent la manière dont les serveurs de messagerie destinataires traitent les e-mails prétendant provenir de votre domaine.

Balise de version

La balise de version constitue le point de départ d'un SPF . Elle indique que l'enregistrement utilise SPF et garantit que les serveurs de messagerie interprètent correctement le texte qui suit. Sans elle, l'enregistrement ne fonctionnera pas. Une seule balise de version est autorisée, et elle doit figurer au tout début de l'enregistrement. Format valide actuel : v=spf1.

SPF : +, -, ~ et ?

Les qualificatifs sont des symboles placés devant les mécanismes. Ils indiquent au serveur de messagerie destinataire la marche à suivre si le mécanisme correspond. Si aucun qualificatif n'est spécifié, l'action par défaut est « Pass ».

SPF : all, ip4, ip6, a, mx, exists et include

Les mécanismes constituent les règles principales d'un SPF . Ils définissent quels serveurs, adresses IP ou domaines sont autorisés à envoyer des e-mails au nom du domaine. Chaque mécanisme est vérifié dans l'ordre, de gauche à droite, et si une correspondance est trouvée, le qualificatif associé est appliqué.

Le mécanisme « all » : -all vs ~all vs ?all

-all (Rejet catégorique) : Tout expéditeur ne figurant pas dans la liste est explicitement rejeté. Utilisez ce paramètre une fois que votre SPF a été entièrement testé et que tous les expéditeurs légitimes y figurent. Il s'agit du paramètre recommandé pour une application stricte.

~tous (SoftFail) : Les expéditeurs non répertoriés sont acceptés mais signalés. Utilisez cette option lors des tests ou d'un déploiement progressif, lorsque vous n'êtes pas encore certain que tous les expéditeurs légitimes figurent dans la liste.

?all (Neutre) : Aucune politique n'est appliquée aux expéditeurs non répertoriés. Cette option n'offre aucune protection réelle et n'est pas recommandée en environnement de production.

+all (Transmettre tout) : Permet à n'importe quel serveur d'envoyer des messages en votre nom. Cette option est dangereuse et ne doit jamais être utilisée.

SPF : redirect et exp

redirect= (Modificateur) : Délègue l'évaluation complète SPF à un autre domaine. Contrairement à « include », « redirect » remplace entièrement l'enregistrement actuel et ne peut pas être combiné avec un mécanisme « all ». Le mécanisme «SPF » fonctionne différemment. Il ajoute les expéditeurs autorisés issus de SPF d’un domaine référencé sans remplacer le vôtre.

exp= (Modificateur) : Fournit une chaîne d'explication personnalisée pour SPF . Lorsqu'un message échoue SPF, le serveur destinataire peut consulter cet enregistrement TXT pour obtenir une raison compréhensible par l'utilisateur.

« include » vs « redirect » : différence essentielle

Résultats SPF et ce qu'ils signifient

Lorsqu'un serveur de messagerie destinataire analyse un SPF , il renvoie l'un des sept résultats possibles. Comprendre chacun de ces résultats aide les propriétaires de domaines à diagnostiquer les échecs de livraison et à améliorer leur SPF . Pour découvrir des stratégies permettant de résoudre SPF courantes, consultez notre guide intitulé comment optimiser votre SPF .

Exemples de syntaxe d'enregistrement SPF

Enregistrement SPF simple

v=spf1 ip4:203.0.113.5 -all

v=spf1 → balise de version. ip4:203.0.113.5 → autorise une seule adresse IPv4. -all → tous les autres serveurs sont rejetés. Il s'agit d'une configuration courante pour un petit domaine envoyant des e-mails à partir d'un seul serveur.

Enregistrement SPF avancé

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:_spf.mailhost.com ~all exp=explain._spf.example.com

Cet enregistrement autorise une plage IP /24 complète, deux expéditeurs tiers, accepte les expéditeurs non répertoriés avec un indicateur SoftFail et fournit une explication personnalisée en cas d'échec. Chaque mécanisme « include », « a », « mx », « exists » et « redirect » déclenche des requêtes DNS. Si le total dépasse 10, SPF une erreur « PermError ».

Exemple SPF d'entreprise

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net ~all

Cet enregistrement est courant pour les organisations utilisant Google Workspace, Microsoft 365 et une plateforme de diffusion tierce. Chaque ajout entraîne des requêtes DNS ; les équipes doivent donc procéder à une validation minutieuse afin d'éviter les résultats de type « PermError ».

Exemple SPF MSP SPF

Pour les MSP qui gèrent de nombreux domaines clients, l’objectif n’est pas seulement de créer un SPF valide, mais aussi de surveiller les modifications sur l’ensemble des clients. SPF centralisée permet de détecter les enregistrements en double, les risques liés aux limites de requêtes et les inclusions défectueuses avant que les clients ne rencontrent des problèmes de livraison. Le programme de partenariat MSP/MSSP de PowerDMARC de PowerDMARC permet aux prestataires de services de gérer l’authentification sur l’ensemble des domaines de leurs clients à partir d’un tableau de bord unique, sans avoir à changer d’outil ni à analyser manuellement les enregistrements DNS.

Exemples de syntaxe des enregistrements SPF par cas d'utilisation

Comment utiliser plusieurs mécanismes d'inclusion dans la syntaxe SPF

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:_spf.salesforce.com ~all

Chaque mécanisme d’inclusion déclenche au moins une requête DNS, et les inclusions imbriquées en ajoutent d’autres. Le total sur l’ensemble de la chaîne ne doit pas dépasser 10. SPF s’arrête dès la première correspondance ; l’ordre est donc important : placez les expéditeurs les plus fréquemment utilisés en premier. Si le nombre de requêtes approche les 10, utilisez l’ outilSPF pour optimiser automatiquement votre enregistrement. Pour les configurations d'entreprise complexes, SPF offrent une alternative plus évolutive à l’aplatissement traditionnel en se développant dynamiquement au moment de l’évaluation.

Nombre trop élevé de requêtes DNS dans SPF

La RFC 7208 limite à 10 le nombre total de requêtes DNS lors de SPF . Cette limite s'applique à l'ensemble de la chaîne de requêtes, y compris les requêtes imbriquées déclenchées par les mécanismes « include », « a », « mx », « exists » et « redirect ». Si cette limite est dépassée, le serveur destinataire renvoie une erreur « PermError », ce qui entraîne SPF complet SPF . Il existe également une contrainte moins connue : la limite des deux requêtes vides. Si plus de deux requêtes DNS renvoient NXDOMAIN, SPF échoue SPF . Pour savoir en détail comment résoudre ce problème, consultez comment remédier à un nombre trop élevé de requêtes DNS.

Mécanismes pris en compte : include (1 + imbriqué), a (1), mx (1 par requête MX + A), exists (1), redirect (1 + imbriqué), ptr (plusieurs — obsolète).

Mécanismes qui ne sont PAS pris en compte : ip4 et ip6 ne déclenchent pas de requêtes DNS.

Comment réduire les requêtes DNS : Supprimez les mécanismes « include » pour les expéditeurs que vous n'utilisez plus. Remplacez les mécanismes « a » et « mx » par des valeurs IPv4 explicites lorsque cela est possible. Évitez les enregistrements « ptr ». Utilisez PowerSPF ( SPF hébergé) pour regrouper les inclusions et rester dans les limites sans avoir à effectuer de maintenance DNS manuelle. Pour en savoir plus sur le processus d’aplatissement lui-même, consultez «SPF : de la surcharge DNS à SPF rationalisé ».

Comment publier un enregistrement SPF dans le DNS

SPF publié sous forme d'enregistrement TXT dans le DNS de votre domaine, soit au niveau du domaine racine (par exemple, example.com), soit au niveau du sous-domaine concerné. Utilisez notre générateur SPF gratuit pour créer instantanément un enregistrement valide avant de le publier.

Important : Un domaine ne doit comporter qu'un seul enregistrement SPF . La publication de plusieurs enregistrements TXT commençant par v=spf1 entraîne une erreur « PermError ».

Processus de validation SPF

Étape 1 : Répertoriez toutes les sources d'envoi : Microsoft 365, Google Workspace, les CRM, les outils marketing, les systèmes d'assistance, la paie et les expéditeurs régionaux.

Étape 2 : Créez ou mettez à jour SPF — N'ajoutez que les mécanismes et les inclusions autorisés.

Étape 3 : Vérifier le nombre de requêtes DNS — Assurez-vous que l'enregistrement ne dépasse pas la limite de 10 requêtes DNS.

Étape 4 : Vérifier la syntaxe — Utilisez un outilSPF pour détecter les problèmes de mise en forme, les doublons et les mécanismes obsolètes.

Étape 5 : Surveiller les résultats de l'authentification — Consultez les rapports DMARC pour vérifier que les expéditeurs légitimes respectent les règles d'alignement SPF DKIM.

Règles de syntaxe, validation et erreurs courantes SPF

La rédaction d'un enregistrement SPF consiste à placer les mécanismes et les qualificateurs dans le bon ordre et à s'assurer que l'enregistrement fonctionne comme prévu. Même de petites erreurs de syntaxe, telles qu'une balise manquante ou un espace supplémentaire, peuvent faire échouer l'enregistrement, entraînant le rejet des courriels, leur marquage en tant que spam ou rendant votre domaine vulnérable à l'usurpation d'identité.

Cette section couvre trois domaines clés : les meilleures pratiques pour l'écriture de la syntaxe SPF , les erreurs courantes à éviter et la manière de valider votre enregistrement avant de le publier en ligne.

Suivre les meilleures pratiques pour la syntaxe SPF

Pour obtenir un bon SPF , il faut d'abord suivre quelques règles d'or qui rendent votre enregistrement à la fois efficace et fiable :

• Commencez toujours par la balise de version correcte : v=spf1.
• Limite DNS pour éviter de dépasser la limite de limite de 10 consultationsce qui entraînerait la rupture de l'enregistrement.
• Utilisez l'option include pour éviter les boucles ou les références circulaires.
• Rédigez vos consignes de manière aussi concise que possible : les configurations trop complexes sont plus difficiles à maintenir et présentent un risque accru de défaillance.
• Vérifiez régulièrement les enregistrements SPF , en particulier si votre infrastructure de messagerie change ou si vous ajoutez/supprimez des fournisseurs.

Gestion SPF pour les MSP et les MSSP

Pour les MSP et les MSSP qui gèrent SPF de nombreux domaines clients, les bonnes pratiques ne se limitent pas à la création d'un seul enregistrement correct. Parmi les principaux aspects opérationnels à prendre en compte, on peut citer :

• Normaliser SPF pour les configurations client courantes (Google Workspace + Microsoft 365, par exemple) afin d'accélérer la mise en service et de réduire les erreurs de syntaxe.
• Automatiser la surveillance du nombre de requêtes afin de recevoir des alertes avant que SPF d'un client ne dépasse la limite de 10 requêtes DNS, en particulier lorsque les clients ajoutent de nouveaux outils SaaS.
• Utilisez des tableaux de bord centralisés pour détecter simultanément SPF en double, les inclusions défectueuses ou les mécanismes manquants sur l'ensemble des domaines de vos clients.
• Modifications apportées aux documents chaque fois qu'un nouvel expéditeur est ajouté à l'environnement d'un client afin de conserver une piste d'audit précise à des fins de conformité et de dépannage.

Éviter les erreurs de syntaxe courantes

De nombreux problèmes liés SPF sont dus à des erreurs simples mais préjudiciables. Méfiez-vous de ces pièges :

• Balise de version manquante : chaque enregistrement doit commencer par v=spf1.
• Qualificateurs en double : l'utilisation de plusieurs qualificatifs pour un même mécanisme n'est pas autorisée.
• Mécanismes excessifs : les enregistrements longs et surchargés augmentent le risque d'erreurs et dépassent les limites du DNS.
• Problèmes de mise en forme syntaxique : des espaces mal placés, des fautes de frappe ou des caractères non pris en charge peuvent entraîner l'échec de l'enregistrement.
• Plusieurs SPF : un domaine ne doit comporter qu’un seul SPF — s’il en existe plusieurs, la validation échouera.
• Mécanismes obsolètes : à éviter ptr, qui n'est plus recommandé et qui pourrait ne pas être pris en charge par tous les serveurs.

Rappelez-vous : même si l'intention de l'enregistrement est correcte, les erreurs de syntaxe entraîneront l'échec total de SPF .

Validez la syntaxe de votre enregistrement SPF

Avant de publier votre enregistrement SPF , la validation est essentielle. Les validateurs vérifient que la syntaxe est correcte et que l'enregistrement ne dépasse pas les limites de consultation du DNS ou ne contient pas de mécanismes non pris en charge.

• Utilisez des outils de vérification SPF , tels que celui de PowerDMARC SPF , pour identifier rapidement les problèmes.
• La validation permet de s'assurer que l'enregistrement fonctionne de manière cohérente sur différents serveurs de messagerie.
• Il est recommandé de tester les nouveaux enregistrements ou les enregistrements mis à jour dans un environnement d'essai avant de les appliquer en direct.
• Une validation régulière après les changements permet de maintenir votre politique SPF à jour et fonctionnelle.

En validant, vous réduisez le risque que les courriels rebondissent, soient envoyés dans les spams ou rendent votre domaine vulnérable à l'usurpation d'identité.

La syntaxe des enregistrements SPF en action

Une syntaxe correcte SPF est essentielle pour garantir la sécurité de la transmission des e-mails et la protection contre l'usurpation d'identité. Chaque élément (balise de version, mécanismes, qualificatifs et modificateurs) contribue à définir la manière dont les serveurs de messagerie traitent vos messages. 

Alors que SPF ne cesse de progresser, avec un taux de réussite mondial s'élevant désormais à 80,24 %, les entreprises qui investissent dans SPF propre et validée bénéficient d'un avantage mesurable en matière de délivrabilité, de conformité et de sécurité. 

Pour obtenir un guide complet, étape par étape, du processus de configuration initiale, consultez comment configurer SPF . Et pour vous assurer de respecter les dernières exigences de conformité, consultez les exigences d'authentification des e-mails de Google et Yahoo pour 2026.

Foire aux questions

1. Comment rédiger un SPF ?

Commencez par v=spf1, ajoutez des mécanismes pour répertorier les expéditeurs autorisés (tels que ip4: pour des adresses IP spécifiques ou include: pour des services tiers), puis terminez par un qualificateur tel que -all pour bloquer tout le reste. Publiez cet enregistrement sous la forme d'un seul enregistrement DNS de type TXT à la racine de votre domaine.

2. Que se passe-t-il si la syntaxe de mon SPF est incorrecte ?

Les serveurs de messagerie peuvent rejeter vos e-mails ou les signaler comme spam, et votre domaine devient plus vulnérable à l'usurpation d'identité. Une erreur de syntaxe, telle qu'une balise de version manquante, SPF en double ou le dépassement de la limite de 10 requêtes DNS, peut entraîner SPF complet SPF .

3. Pouvez-vous donner un exemple d'SPF utilisant un SPF MX ?

Un SPF utilisant MX se présente comme suit : v=spf1 mx -all, ce qui autorise uniquement les serveurs de messagerie du domaine à envoyer des e-mails en son nom.

4. Combien de requêtes DNS sont autorisées dans un SPF ?

SPF un maximum de 10 requêtes DNS par évaluation, conformément à la RFC 7208. Les mécanismes pris en compte sont les suivants : include, a, mx, exists, redirect et ptr. En cas de dépassement, SPF une erreur « PermError ».

5. Peut-on avoir plusieurs SPF pour un même domaine ?

Non. Un domaine ne doit comporter qu'un seul enregistrement SPF . La présence de plusieurs enregistrements commençant par « v=spf1 » entraîne une erreur « PermError ». Regroupez tous les expéditeurs autorisés dans un seul enregistrement.

6. Quelle est la différence entre SPF et ~all ?

-all (refus définitif) indique aux destinataires de rejeter les e-mails provenant d'expéditeurs non répertoriés. ~all (refus temporaire) indique aux destinataires de les accepter, mais de les marquer. Utilisez ~all pendant la phase de test, puis passez à -all une fois que tous les expéditeurs légitimes ont été validés.

7. SPF suffit-il SPF à empêcher l'usurpation d'adresse e-mail?

Non. SPF valide SPF l'expéditeur de l'enveloppe (Return-Path), et non l'adresse « De » visible. Il doit être associé aux protocoles DKIM et DMARC pour offrir une protection complète contre l'usurpation d'identité et le hameçonnage.

8. Qu'est-ce que l'aplatissement SPF et dans quels cas en ai-je besoin ?

SPF remplace les mécanismes « include » par les adresses IP résolues, ce qui réduit le nombre de requêtes DNS. Cette opération est nécessaire lorsque votre SPF dépasse ou approche la limite de 10 requêtes DNS. Des outils automatisés tels que PowerSPF gèrent cela de manière dynamique.

9. Combien de temps faut-il pour qu'un SPF se propage ?

La propagation DNS prend généralement entre 1 et 4 heures, selon votre fournisseur DNS et vos paramètres TTL. Dans certains cas, cela peut prendre jusqu'à 48 heures. Vérifiez toujours votre enregistrement après sa publication.

• À propos de
• Derniers messages

Ahona Rudra

Expert en sécurité des domaines et des e-mails chez PowerDMARC

Ahona est la responsable du marketing chez PowerDMARC, avec plus de 5 ans d'expérience dans l'écriture sur des sujets de cybersécurité, spécialisée dans la sécurité des domaines et des courriels. Ahona est titulaire d'un diplôme de troisième cycle en journalisme et communication, solidifiant sa carrière dans le secteur de la sécurité depuis 2019.

Derniers messages de Ahona Rudra (voir tous)

• Protocoles SSL et TLS : quelle est la différence ? - 13 août 2026
• Qu'est-ce que la manipulation d'URL (réécriture d'URL) ? Comment les pirates détournent des liens fiables pour dissimuler des tentatives d'hameçonnage - 10 août 2026
• E-mail d'alerte de sécurité concernant le compte Microsoft : comment repérer les arnaques et protéger votre domaine - 9 août 2026