Syntaxe de l'enregistrement SPF
par
Dernière mise à jour : 5 Temps de lecture : 5 min
Points clés à retenir
- SPF Les enregistrements utilisent des mécanismes, des qualificatifs et des modificateurs pour définir quelles sources sont autorisées à envoyer des e-mails au nom de votre domaine.
- Des mécanismes tels que « include », « a », « mx », « ptr » et « exists » peuvent déclencher des requêtes DNS, tandis que « ip4 », « ip6 » et « all » ne sont pas pris en compte dans la limite.
- SPF Les qualificatifs déterminent la manière dont les serveurs destinataires traitent les expéditeurs correspondant aux critères ; « -all » correspond à « Fail » et « ~all » à « SoftFail ».
- Un enregistrement « SPF » peut déclencher une erreur « PermError » s'il dépasse la limite de 10 requêtes DNS, ce qui peut entraîner l'échec de l'authentification « SPF » pour des e-mails légitimes.
- Un domaine ne doit comporter qu'un seul enregistrement « SPF » ; les erreurs de syntaxe, telles que l'absence de « v=spf1 », un formatage incorrect ou l'utilisation de « ptr » (désuet), peuvent entraîner des problèmes d'authentification.
Un enregistrement « SPF » est une chaîne de texte unique publiée sous la forme d'un enregistrement DNS de type TXT. Il s'agit d'un ensemble de règles définissant précisément quelles adresses IP sont autorisées à envoyer des e-mails au nom de votre domaine. Un enregistrement correctement formaté commence toujours par une balise de version, suivie d'un ou plusieurs mécanismes, et se termine par une règle d'application.
Voici un enregistrement type de « SPF » décomposé en ses différents éléments :
v=spf1 ip4:192.0.2.0/24 include:_spf.google.com ~all
- v=spf1: L'identifiant de version qui marque le début de l'enregistrement.
- ip4:192.0.2.0/24: Mécanisme permettant d'autoriser une plage IPv4 spécifique.
- inclure :_spf.google.com: un mécanisme associé à un domaine, renvoyant vers la liste des adresses IP approuvées d'un expéditeur tiers.
- ~all: Le qualificatif (~) et le mécanisme (all) définissant la politique de repli pour les expéditeurs non autorisés.
Si vous devez créer une nouvelle entrée pour votre domaine, utilisez un SPF générateur d'enregistrements pour générer automatiquement la chaîne de caractères exacte.
Mécanismes SPF
Les mécanismes constituent les éléments fondamentaux de votre enregistrement « SPF ». Ils indiquent au serveur de messagerie destinataire comment identifier les sources d'envoi autorisées.
| Mécanisme | Avec quoi cela va bien ? | Exemple | Compte dans la limite de 10 recherches |
|---|---|---|---|
| tous | Correspond toujours. Utilisé à la toute fin d'un enregistrement comme règle fourre-tout pour toute adresse IP non prise en compte par les mécanismes précédents. | ~tout | Non |
| inclure | Correspond si l'adresse IP de l'expéditeur est autorisée par la politique « SPF » du domaine spécifié. | inclure :_spf.google.com | Oui |
| a | Correspond si l'adresse IP de l'expéditeur correspond à l'adresse IP associée à l'enregistrement DNS de type A ou AAAA du domaine. | a:exemple.com | Oui |
| mx | Correspond si l'adresse IP de l'expéditeur correspond à l'une des adresses IP répertoriées dans les enregistrements MX du domaine. | mx:exemple.com | Oui |
| ip4 | Correspond si l'adresse IP de l'expéditeur se situe exactement dans la plage du réseau ou du sous-réseau IPv4 définie. | ip4:192.0.2.0/24 | Non |
| ip6 | Correspond si l'adresse IP de l'expéditeur se trouve exactement dans la plage du réseau ou du sous-réseau IPv6 définie. | ip6:2001:db8::/32 | Non |
| ptr | Renvoie « vrai » si la résolution DNS inverse de l'adresse IP renvoie le domaine spécifié. (Fonctionnalité obsolète et fortement déconseillée en raison de son impact sur les performances). | ptr:exemple.com | Oui |
| existe | Renvoie « vrai » si l'enregistrement A DNS correspondant au nom de domaine spécifié est résolu avec succès. | existe : example.com | Oui |
Le mécanisme d'inclusion
Le mécanisme « include » est l'un des composants les plus utilisés dans l'authentification moderne des e-mails. Il indique aux serveurs destinataires de consulter et d'évaluer les règles d'SPF d'un service tiers, tel que Google Workspace, Microsoft 365 ou une plateforme marketing. Si ce fournisseur tiers met à jour les adresses IP de ses propres serveurs, votre enregistrement reste valide sans nécessiter de mises à jour manuelles.
Le mécanisme dans son ensemble
Toujours placé tout à la fin de la chaîne, le mécanisme « all » fait office de règle par défaut ultime. Il intercepte toute adresse IP d’expéditeur qui n’a pas pu être mise en correspondance avec les mécanismes précédents de l’enregistrement. Pour être efficace, il doit être associé à un qualificatif (tel que « – » ou « ~ ») qui indique au serveur destinataire s’il doit rejeter ou accepter le courrier non autorisé.
Le mécanisme a
Ce mécanisme autorise l'adresse IP associée à l'enregistrement A ou AAAA d'un domaine. Il s'avère particulièrement utile lorsque le serveur web hébergeant votre site web principal est également utilisé pour envoyer des e-mails sortants, tels que les notifications issues des formulaires de contact du site ou les alertes système.
Le mécanisme mx
Si les serveurs désignés pour recevoir votre courrier entrant (tels qu'ils figurent dans vos enregistrements MX) gèrent également l'envoi de vos messages sortants, le mécanisme MX est la solution appropriée. Il autorise les adresses IP de ces serveurs de messagerie entrants spécifiques à envoyer du courrier sortant au nom du domaine.
Qualificatifs SPF
Les qualificatifs font office de préfixes associés à des mécanismes (le plus souvent le mécanisme « all »). Ils déterminent précisément comment le serveur destinataire doit traiter un e-mail lorsque l'adresse IP de l'expéditeur correspond au mécanisme.
| Qualification | Résultat | Signification | Exemple |
|---|---|---|---|
| + | Passez | L'adresse IP est entièrement autorisée à envoyer des e-mails. Le symbole « + » est facultatif et est implicite par défaut. | +tout |
| - | Échec | L'adresse IP est strictement interdite. L'e-mail doit être intégralement rejeté. | -tout |
| ~ | Défaillance logicielle | L'adresse IP n'est pas autorisée, mais l'e-mail est accepté et généralement marqué comme spam ou mis en quarantaine. | ~tout |
| ? | Neutre | Aucune politique n'est explicitement énoncée. L'e-mail est traité comme s'il n'y avait aucune règle d'SPF . | ?tout |
Modificateurs SPF
Les modificateurs fournissent des instructions supplémentaires ou des détails contextuels concernant l'enregistrement « SPF ». Ils sont facultatifs et ne doivent apparaître qu'une seule fois, généralement à la toute fin de la chaîne.
| Modificateur | Ce qu'il fait | Exemple | Notes |
|---|---|---|---|
| rediriger | Indique au serveur destinataire d'ignorer les règles actuelles et d'utiliser à la place l'enregistrement « SPF » d'un autre domaine. | v=spf1 redirect=example.com | La redirection est totalement ignorée si un mécanisme « all » est également présent dans l'enregistrement. |
| exp | Spécifie un domaine personnalisé hébergeant un enregistrement TXT qui fournit une explication en cas d'échec d'une vérification d'SPF . | exp=explain.example.com | Rarement utilisé dans les configurations modernes d'authentification des e-mails et souvent ignoré par les principaux serveurs de réception. |
SPF Résultats de l'évaluation
Lorsqu'un serveur de messagerie récepteur traite un message entrant en fonction de votre enregistrement « SPF », il renvoie l'un des sept résultats d'évaluation standardisés, en fonction de votre syntaxe.
| Résultat | Ce que cela signifie | Ce que fait généralement le récepteur |
|---|---|---|
| Passez | L'adresse IP de l'expéditeur a bien correspondu à un mécanisme autorisé figurant dans votre enregistrement. | L'e-mail est accepté, sous réserve de vérifications supplémentaires concernant les protocoles DMARC et DKIM, ainsi que de contrôles anti-spam généraux. |
| Échec | L'adresse IP de l'expéditeur correspondait à un mécanisme comportant un qualificatif « - ». | Il bloque ou rejette l'e-mail au niveau du serveur avant qu'il n'atteigne la boîte de réception. |
| SoftFail | L'adresse IP de l'expéditeur correspondait à un mécanisme comportant le qualificatif « ~ ». | Il accepte l'e-mail, mais le signale comme suspect, ce qui le fait souvent atterrir dans le dossier des spams. |
| Neutre | L'adresse IP de l'expéditeur correspondait à un qualificatif « ? », ou l'enregistrement n'a pas permis de tirer de conclusion définitive. | Traite l'e-mail en se basant strictement sur les critères du filtre anti-spam propre au serveur. |
| Aucun | Aucun enregistrement SPF valide n'a été trouvé pour le domaine en question. | Considère l'e-mail comme non authentifié, ce qui nuit considérablement à sa délivrabilité. |
| Erreur de permission | L'enregistrement contient une erreur de syntaxe irrémédiable ou dépasse la limite de 10 recherches. | Cela entraîne immédiatement l'échec de la vérification « SPF », l'e-mail étant alors considéré comme non authentifié et susceptible d'être rejeté. |
| TempError | Un délai d'expiration temporaire du DNS ou une panne de réseau a empêché la vérification d'aboutir. | Reporte temporairement l'envoi de l'e-mail et tente à nouveau la vérification ultérieurement. |
La limite de 10 requêtes DNS
Afin d’empêcher des acteurs malveillants d’utiliser la fonction « SPF » pour lancer des attaques par déni de service contre des serveurs DNS, la spécification « SPF » impose une limite stricte. Un serveur destinataire n’effectuera au maximum que 10 requêtes DNS pour évaluer un seul enregistrement « SPF ».
Les mécanismes qui nécessitent une requête DNS en arrière-plan sont notamment : « include », « a », « mx », « ptr », « exists » et le modificateur « redirect ». Il est important de noter que les mécanismes tels que « ip4 », « ip6 » et « all » fonctionnent instantanément sans nécessiter de requêtes DNS, ce qui signifie qu'ils ne sont pas pris en compte dans votre limite.
Si votre configuration dépasse 10 requêtes, les serveurs destinataires renverront immédiatement une erreur « PermError » liée à l'SPF . Cela invalide complètement votre politique et empêche les e-mails légitimes de passer l'authentification. Les entreprises qui font appel à plusieurs fournisseurs de messagerie tiers (tels qu'un CRM, un service d'assistance ou une plateforme d'automatisation du marketing) peuvent très facilement atteindre ce seuil.
Pour remédier à cette limitation, vous pouvez mettre en place la fonctionnalité de PowerDMARC solution hébergée SPF de PowerDMARC. Celle-ci compresse vos mécanismes de domaine tiers en adresses IP simples, ce qui réduit instantanément le nombre de requêtes de recherche. Vous devriez également soumettre votre domaine à un SPF outil de vérification des enregistrements afin de mesurer le nombre total de requêtes actuelles et de repérer les vulnérabilités avant qu’elles n’affectent la délivrabilité.
Erreurs courantes de syntaxe dans l'SPF
La création d'un enregistrement « SPF » conforme nécessite le respect scrupuleux des règles de mise en forme. Un seul caractère erroné peut compromettre votre authentification. Voici les erreurs de syntaxe les plus fréquentes :
- Plus d'un enregistrement « SPF » sur un domaine: un domaine doit publier exactement un enregistrement TXT commençant par v=spf1. La publication de plusieurs enregistrements entraîne immédiatement une erreur PermError.
- v=spf1 manquant: Si la chaîne ne commence pas exactement par cette balise de version, les serveurs destinataires ignoreront tout simplement l'enregistrement TXT.
- Utilisation de +all : Cette combinaison indique que littéralement toutes les adresses IP sur Internet sont autorisées à envoyer des e-mails en votre nom, ce qui rend l'enregistrement pratiquement inutile.
- Ptr de suivi: Le mécanisme ptr impose une charge considérable aux serveurs récepteurs. Il est officiellement obsolète et entraînera des problèmes de performances s'il est inclus.
- Dépassement de la limite de 10 requêtes: l'imbrication d'un trop grand nombre d'instructions « include » dépasse la limite de recherches DNS et invalide automatiquement l'enregistrement.
- Espaces ou deux-points manquants dans les mécanismes: Les erreurs de formatage, comme le fait de taper « include _spf.google.com » au lieu de la commande correcte « include:_spf.google.com », perturberont la lecture de la syntaxe.
[NE RIEN CHANGER : blocs CTA existants]
Foire aux questions
Quelle est la syntaxe correcte pour un enregistrement « SPF » ?
Un enregistrement « SPF » doit être publié sous la forme d'un enregistrement DNS de type TXT commençant par la balise de version « v=spf1 », suivie de vos adresses IP ou mécanismes autorisés séparés par des espaces, et se terminant par un mécanisme de repli strict tel que « ~all » ou « -all ».
Que signifie « ~all » dans un enregistrement « SPF » ?
Le mécanisme « ~all » correspond à une politique de repli de type « SoftFail ». Il indique aux serveurs destinataires que toute adresse IP d'expéditeur ne figurant pas explicitement dans votre enregistrement n'est pas autorisée, mais que le courriel doit tout de même être accepté et acheminé vers le dossier de courrier indésirable du destinataire.
Quelle est la différence entre « include » et « redirect » ?
Le mécanisme « include » évalue les règles d’ SPF d’un autre domaine parallèlement aux vôtres, ce qui vous permet de combiner plusieurs sources d’envoi. Le modificateur « redirect » indique au serveur destinataire d’ignorer complètement votre enregistrement et d’utiliser à la place l’enregistrement « SPF » du domaine spécifié.
Comment puis-je vérifier la syntaxe de mon enregistrement « SPF » ?
Vous pouvez vérifier votre mise en forme et calculer le nombre de recherches actives en saisissant votre domaine dans un outil gratuit de vérification des enregistrements SPF . Celui-ci signalera instantanément les erreurs syntaxiques, les mécanismes obsolètes et les violations des limites.
Puis-je avoir deux enregistrements « SPF » ?
Non, la publication de plusieurs enregistrements « SPF » pour un même domaine constitue une violation du protocole de base. Si un serveur destinataire détecte plusieurs enregistrements commençant par « v=spf1 », il renverra immédiatement une erreur « PermError » et l'authentification échouera.
Expert en sécurité des domaines et des e-mails chez PowerDMARC
Yunes est chef d'équipe des opérations chez PowerDMARC et possède des connaissances approfondies en matière d'authentification et de sécurité des courriels. Yunes est certifié Microsoft Azure Administrator Associate et possède des certifications CompTIA A+ et bien d'autres encore.
Derniers messages de Yunes Tarada (voir tous)
- Guide d'authentification des e-mails AppRiver (Zix) : SPF, DKIM et DMARC - 30 septembre 2026
- SPF Syntaxe des enregistrements - 14 septembre 2026
- Guide de configuration de DKIM, DMARC et de l’ SPF pour la messagerie Oracle - 14 septembre 2026
