Points clés à retenir
- v=spf1 est la balise qui active un SPF ; sans elle, SPF fonctionne SPF .
- SPF quels serveurs sont autorisés à envoyer des e-mails pour votre domaine à l'aide de mécanismes tels que IPv4 et include.
- SPF une logique de « premier accord trouvé », évaluée de gauche à droite.
- Un seul SPF par domaine ; la présence de plusieurs enregistrements empêche l'authentification.
- Limite de 10 requêtes DNS ; tout dépassement de cette limite entraîne une erreur permanente (PermError) et SPF .
- par exemple : apporte plus de souplesse mais augmente le risque de recherche ; IPv4/IPv6 sont plus rapides mais nécessitent une maintenance.
- ~tout (softfail) est destiné aux tests ; -all (hardfail) impose un blocage strict.
- SPF à lui seul à protéger contre l'usurpation d'identité : il doit être associé à DKIM et DMARC.
- SPF être mis à jour régulièrement à mesure que les outils et les expéditeurs changent.
Vous êtes en train de consulter un enregistrement DNS qui commence par v=spf1, et vous savez que c'est important, mais le modifier sans en comprendre pleinement le fonctionnement peut perturber la distribution des e-mails sur l'ensemble de votre domaine.
Il suffit d'un « include: » manquant, d'une recherche de trop ou d'une erreur de syntaxe pour que les e-mails échouent à l'authentification, finissent dans le dossier spam ou soient tout simplement rejetés
SPF Sender Policy Framework) est un élément fondamental de l'authentification des e-mails. Il indique aux serveurs destinataires quelles sources sont autorisées à envoyer des e-mails en votre nom. Le balise v=spf1 active cette politique, mais tout ce qui suit détermine si vos e-mails sont considérés comme fiables ou bloqués.
Le problème, c'est que SPF simple à première vue, mais qu'il se complexifie à mesure que l'on ajoute des sources d'envoi multiples, des outils marketing et des infrastructures. Les limites de consultation, les inclusions imbriquées et les problèmes d'alignement introduisent des points de défaillance qui ne sont pas toujours visibles avant que le taux de délivrabilité ne baisse.
Ce guide explique en détail ce qu'est v=spf1 , comment SPF sont structurés, comment fonctionne l'évaluation, et comment créer et maintenir un enregistrement qui ne présente pas de défaillance dans des conditions réelles.
Comment fonctionne SPF
SPF est un processus de validation étape par étape qui s'effectue à chaque fois qu'un e-mail est reçu. Elle permet de déterminer si le serveur expéditeur est autorisé à envoyer des messages au nom du domaine indiqué dans le champ Return-Path.
Voici comment cela fonctionne concrètement :
- Vous recevez un e-mail prétendant provenir de votre domaine : Le message arrive sur le serveur de messagerie du destinataire avec à la fois les en-têtes visibles (From) et les détails de routage cachés (Return-Path).
- Le serveur destinataire extrait le domaine Return-Path : C'est le domaine que SPF vérifie SPF . Il représente l'expéditeur utilisé lors de la transmission de l'e-mail.
- Le serveur interroge le DNS pour obtenir SPF (v=spf1) : Il recherche l'enregistrement TXT publié sur ce domaine. Si aucun SPF n'existe, le résultat est None (pas d'authentification).
- L'adresse IP du serveur expéditeur est comparée à SPF : Le serveur traite SPF de gauche à droite :
- Vérifie chaque mécanisme (ip4, inclure, a, etc.)
- Effectue toutes les requêtes DNS nécessaires
- S'arrête à la première règle correspondante
- Un résultat est généré en fonction de la correspondance : Parmi les résultats possibles, on peut citer :
- Passer → L'expéditeur est autorisé
- Échec / Échec temporaire → L'expéditeur n'est pas autorisé (traitement strict ou souple)
- Neutre / Aucun → Pas de politique claire ou pas SPF
- PermError / TempError → SPF n'SPF pas SPF être évalué en raison d'erreurs
- Le résultat est combiné avec DKIM et DMARC: SPF ne détermine pas SPF la remise du message. Le serveur destinataire l'utilise en complément :
- DKIM (intégrité des messages)
- DMARC (alignement + politique)
pour décider s'il faut accepter, filtrer ou rejeter le message
Qu'est-ce qu'un SPF ?
Un SPF est un enregistrement DNS de type TXT qui définit l'ensemble des serveurs et des services autorisés à envoyer des e-mails au nom de votre domaine. Lorsqu'un e-mail est reçu, le serveur destinataire vérifie cet enregistrement afin de s'assurer que l'expéditeur est bien autorisé.
Que signifie « v=spf1 » ?
Le balise v=spf1 est l'identifiant qui indique aux serveurs de messagerie destinataires que cet enregistrement DNS TXT correspond à une SPF . Elle signale que l'enregistrement doit être analysé et évalué à l'aide SPF définies dans la RFC 7208.
Sans cette balise, l'enregistrement n'est pas SPF considéré comme SPF , aucune validation n'est effectuée et le domaine ne bénéficie donc d'aucune SPF .
Lorsqu'un serveur destinataire recherche votre domaine :
- Il analyse les enregistrements TXT à la recherche d'un enregistrement commençant par v=spf1
- Seul cet enregistrement est pris en compte pour SPF
- Tout ce qui suit est interprété comme des règles d'autorisation (mécanismes, qualificatifs, modificateurs)
Pour SPF fonctionne correctement, v=spf1 doit respecter des exigences strictes :
- Doit figurer tout au début de l'enregistrement
- Doit être écrit exactement comme v=spf1 (sans faute de frappe ni espace superflu)
- Il ne doit y avoir qu'un seul SPF par domaine
Si la balise de version comporte la moindre erreur, l'enregistrement est rejeté dans son intégralité :
- Absent → SPF Aucun (aucun enregistrement trouvé)
- Faute d'orthographe (spf , v=spf2, v=SPF1) → Syntaxe incorrecte → PermError
- Si elle est placée après une autre valeur → L'enregistrement est ignoré car il est mal formé
Les serveurs destinataires ne parviennent pas à interpréter votre SPF , et l'authentification échoue pour tous les e-mails.
Anatomie d'un SPF : analyse syntaxique complète
Chaque SPF suit une structure cohérente, avec un ensemble de règles qui s'exécutent dans l'ordre. C'est en comprenant comment chaque élément contribue à cette évaluation que l'on évite les erreurs de configuration.
Un SPF commence toujours par une balise de version (v=spf1), suivie d’une série de mécanismes qui définissent les expéditeurs autorisés. Ces mécanismes peuvent être combinés avec des qualificatifs, qui contrôlent la manière dont les correspondances sont traitées, et parfois avec des modificateurs, qui ajustent la façon dont l’enregistrement est évalué. Tout cela tient sur une seule ligne de texte, mais chaque élément a une incidence directe sur la manière dont les serveurs destinataires interprètent les e-mails de votre domaine.
Exemple d'enregistrement
v=spf1 ip4:192.0.2.0/24 include:_spf.google.com include:spf.protection.outlook.com -all
ip4:192.0.2.0/24 (où /24 représente une plage de 256 adresses IP selon la notation CIDR (Classless Inter-Domain Routing))
Rôle de chaque élément
- v=spf1 identifie l'enregistrement comme une SPF et active l'évaluation
- ip4:192.0.2.0/24 autorise explicitement une plage d'adresses IP connue, généralement celle de votre propre infrastructure
- inclure :_spf.google.com autorise Google Workspace en faisant référence à son SPF
- inclure :spf.protection.outlook.com fait de même pour Microsoft 365
- -all définit la politique par défaut : tout expéditeur non répertorié précédemment est refusé
Cette combinaison donne lieu à un modèle d'autorisation complet : seules certaines sources sont autorisées, tout le reste est refusé.
Comment fonctionne réellement l'évaluation
SPF traité selon une procédure rigoureuse et prévisible :
- Le serveur destinataire lit l'enregistrement de gauche à droite
- Chaque mécanisme est évalué tour à tour par rapport à l'adresse IP du serveur émetteur
- Dès qu'une correspondance est trouvée, l'évaluation s'arrête immédiatement
- Le critère associé à ce mécanisme détermine le résultat
Si aucun mécanisme ne correspond :
- Le mécanisme mécanisme sert de solution de repli
Cela signifie que SPF n'SPF pas un système où l'on « vérifie tout avant de prendre une décision ». C'est un système où la première correspondance trouvée l'emporte.
SPF expliqués
Les mécanismes constituent le cœur d'un SPF . Ils définissent les sources d'envoi autorisées et forment la logique que le serveur destinataire utilise pour évaluer l'adresse IP de l'expéditeur. Chaque mécanisme ajoute une règle, et ensemble, ils constituent la liste blanche de votre domaine.
En pratique, ce qui importe, ce n'est pas seulement ce que fait chaque mécanisme, mais aussi comment il se comporte lors de l'évaluation et quel est son impact sur les limites et la fiabilité.
Les mécanismes sont évalués dans l'ordre, et le premier qui correspond à l'adresse IP d'origine détermine le résultat. Cela signifie que chaque mécanisme que vous ajoutez a une incidence à la fois sur la couverture de l'autorisation et sur la complexité de l'évaluation.
Certains mécanismes associent directement les adresses IP, tandis que d'autres nécessitent des requêtes DNS pour obtenir des informations supplémentaires.
Comment fonctionnent les différents mécanismes
| Mécanisme | Ce qu'il fait | Une recherche DNS est-elle nécessaire ? | Exemple |
|---|---|---|---|
| inclure : | Autorise SPF d'un autre domaine | Oui | inclure :_spf.google.com |
| ip4 : | Autorise une adresse IPv4 spécifique ou une plage d'adresses | Non | ip4:192.0.2.0/24 |
| ip6 : | Permet d'autoriser une adresse IPv6 ou une plage d'adresses IPv6 spécifique | Non | ip6:2001:db8::/32 |
| a | Autorise les adresses IP associées aux enregistrements A/AAAA du domaine | Oui (1) | a |
| mx | Autorise les adresses IP issues des enregistrements MX du domaine | Oui (1) | mx |
| ptr | Utilise la recherche DNS inversée (obsolète) | Oui | ptr |
| existe : | Correspond si le domaine est résolu dans le DNS | Oui | exists:%{i}._spf.example.com |
| tous | Correspond à tous les expéditeurs (à utiliser avec des critères de sélection) | Non | -tout |
Parmi comprend : mécanisme est le plus couramment utilisé et le plus susceptible de provoquer des problèmes de limite de recherche en raison de requêtes DNS imbriquées.
SPF un maximum de 10 requêtes DNS par évaluation. Les mécanismes pris en compte dans cette limite sont les suivants :
- inclure :
- a
- mx
- existe :
- redirect=
- ptr
Les mécanismes qui ne :
- ip4 :
- ip6 :
Cela conduit à un compromis pratique :
- Simplicité d'utilisation (notamment :) → coût de recherche plus élevé
- Contrôle (IPv4/IPv6) → coût de recherche réduit, mais maintenance plus importante
Tout savoir sur SPF
Les qualificatifs définissent l'action à entreprendre lorsqu'un mécanisme est activé. Alors que les mécanismes déterminent « qui est autorisé », les qualificatifs déterminent « ce qui doit se passer ensuite ». Ensemble, ils déterminent le degré de rigueur avec lequel votre SPF est appliquée.
Chaque mécanisme peut être précédé d'un qualificatif. Si aucun qualificatif n'est spécifié, la valeur par défaut est « pass » (+). Le qualificateur influence directement la manière dont le serveur destinataire interprète la correspondance et le degré de confiance qu’il accorde au message ou son rejet.
Comportement des qualificatifs lors de l'évaluation
Lorsqu'un mécanisme correspond :
- Le qualificatif qui lui est associé détermine immédiatement le résultat
- SPF s'arrête à ce stade
- Ce résultat est ensuite utilisé (conjointement avec DKIM et DMARC) pour déterminer le traitement du message
Cela signifie que les qualifications sont des signaux de décision finale dans le SPF .
Ce que fait réellement chaque qualificatif (dans son contexte)
| Qualification | Symbole | Signification | Quand l'utiliser |
|---|---|---|---|
| Passez | + | L'expéditeur est expressément autorisé | Comportement par défaut (rarement indiqué explicitement) |
| Échec (échec total) | - | L'expéditeur n'est pas autorisé ; le message doit être rejeté | À utiliser une foisla configuration SPF terminéeavec DMARC |
| SoftFail | ~ | L'expéditeur n'est probablement pas autorisé ; accepter mais marquer comme suspect | À utiliser pendant l'installation et les tests |
| Neutre | ? | Aucune indication concernant l'expéditeur | À éviter en production |
Dans la plupart SPF , les qualificatifs s'appliquent à la tous » à la fin pour définir la politique par défaut.
Comment les qualificatifs sont généralement utilisés dans SPF
La plupart SPF s'appuient sur des qualificatifs situés à un seul endroit : le « all » à la fin.
- ~tout → Recourir par défaut à une application souple (phase de surveillance)
- -tout → Application stricte par défaut (politique prête pour la production)
Ce critère de sélection final définit comment traiter tout expéditeur qui n'a pas été explicitement identifié auparavant.
Conseils pratiques
- Commencez par ~all lors de la configuration : Cela vous permet d'observer SPF sans bloquer les expéditeurs légitimes que vous auriez pu manquer.
- Aller à -tout une fois votre enregistrement terminé : Après avoir vérifié que toutes les sources valides sont incluses, passez à « hardfail » pour une application stricte.
- Évitez ?all :Cela n'offre ni protection ni orientation significative aux serveurs destinataires.
- N'utilisez jamais +all : Cela permet à n'importe quel expéditeur de passer SPF, ce qui désactive de fait l'authentification pour votre domaine.
Tout savoir sur SPF (explications)
Les modificateurs constituent une partie modeste mais importante de SPF . Contrairement aux mécanismes, ils ne définissent pas qui est autorisé à envoyer des e-mails. Ils modifient plutôt la manière dont SPF est effectuée une fois que l'enregistrement est traité.
Elles sont facultatives et s'utilisent dans des cas particuliers où les règles standard basées sur des mécanismes ne suffisent pas.
Comment les modificateurs se comportent lors de l'évaluation
Les modificateurs sont évalués une fois les mécanismes traités, et ils influencent la manière dont le résultat global est déterminé ou présenté.
- Elles ne correspondent pas aux adresses IP d'origine
- Ils n'autorisent ni ne refusent directement les expéditeurs
- Ils ajustent le débit ou résultat de SPF du SPF
C'est pourquoi les modificateurs ne sont généralement utilisés que dans des configurations avancées ou structurées, et non dans SPF de base.
redirect= – délégation complète de SPF
Le modificateur redirect= transfère SPF vers un autre domaine.
- Cela indique au serveur destinataire : « Ignore le reste de cet enregistrement et évalue SPF la politique définie pour un autre domaine. »
- Contrairement à inclure ::
- inclure : ajoute une autre politique à votre évaluation
- redirect= remplace entièrement votre évaluation
Exemple :
v=spf1 redirect=_spf.example.com
Dans ce cas :
- Votre domaine ne définit pas ses propres SPF
- Toutes les évaluations sont gérées par _spf.example.com
Quand l'utiliser ?
- Gestion de plusieurs domaines à l'aide d'une SPF centralisée
- Garantir la cohérence entre les domaines sans dupliquer les enregistrements
exp= – explication personnalisée des échecs
L' modificateur exp= fournit une explication compréhensible par l'utilisateur lorsque SPF .
- Il renvoie vers un enregistrement DNS contenant un message texte
- Ce message peut être renvoyé au serveur expéditeur en cas d'échec
Exemple :
v=spf1 -all exp=explain._spf.example.com
Cela vous permet de définir une explication personnalisée, par exemple :
- Pourquoi le message a échoué
- Ce que l'expéditeur doit faire ensuite
Comment créer un SPF
Création d'un SPF est un processus contrôlé, étape par étape. L'objectif est de répertorier avec précision toutes les sources d'envoi légitimes, tout en veillant à ce que l'enregistrement reste valide, efficace et applicable.
Chaque étape compte, car SPF évalué exactement tel qu'il est écrit. L'absence d'un expéditeur ou l'ajout d'une logique erronée peut avoir un impact direct sur la délivrabilité.
- Commencez par v=spf1: Cela active SPF votre domaine. Sans cela, l'enregistrement est ignoré et aucune authentification n'a lieu.
- Ajoutez votre propre infrastructure d'envoi (ip4: / ip6:) : Incluez tous les serveurs que vous contrôlez directement, tels que les serveurs de messagerie transactionnelle ou les systèmes internes. Ce sont les entrées les plus fiables, car elles ne dépendent pas de recherches DNS externes.
- Ajoutez votre fournisseur de messagerie principal (inclure :) : Si vous utilisez une plateforme telle que Google Workspace ou Microsoft 365, vous devez inclure leur SPF . Cela garantit que l'ensemble de leur infrastructure d'envoi est autorisé en votre nom.
| Service | Valeur SPF | Notes |
|---|---|---|
| Espace de travail Google | inclure :_spf.google.com | Couvre l'infrastructure d'envoi de Gmail et de Google Workspace |
| Microsoft 365 | inclure :spf.protection.outlook.com | Requis pour Outlook / Exchange Online |
| Mailchimp | inclure : servers.mcsv.net | Utilisé pour les campagnes marketing |
| SendGrid | inclure : sendgrid.net | Plateforme d'e-mails transactionnels et en masse |
| HubSpot | inclure :spf.hubspot.com | Automatisation du marketing et e-mails CRM |
| Salesforce | notamment :_spf.salesforce.com | CRM et flux de travail automatisés |
| Zendesk | notamment : mail.zendesk.com | E-mails relatifs aux tickets d'assistance |
| Freshdesk | inclure :spf.freshdesk.com | Plateforme d'assistance à la clientèle |
Parmi comprend : ajoute au moins une requête DNS et peut entraîner des requêtes imbriquées supplémentaires en fonction de la SPF du fournisseur.
- Ajoutez tous les expéditeurs tiers : Cela inclut les outils marketing, les CRM, les plateformes d'assistance et tout service qui envoie des e-mails en utilisant votre domaine. Chacun d'entre eux doit être explicitement autorisé, car SPF pas automatiquement confiance aux services externes.
- Terminez par votre politique (~tout ou -tout) : Ceci définit la manière de traiter tout expéditeur ne figurant pas dans la liste ci-dessus :
- ~tout → accepter mais considérer comme suspect (utilisé lors de la configuration)
- -tout → rejeter les expéditeurs non autorisés (utilisé une fois la validation terminée)
- Publier sous la forme d'un seul enregistrement DNS de type TXT :SPF qu'un seul enregistrement par domaine. Tous les mécanismes doivent être regroupés dans cette seule entrée.
- Vérifiez avant et après la publication : Vérifiez les erreurs de syntaxe, les limites de recherche et les sources manquantes. Vérifiez également l'enregistrement DNS en ligne, et pas seulement ce qui a été saisi.
La gestion manuelle SPF difficile à mesure que vous ajoutez de nouvelles sources d'envoi. Chacune d'entre elles accroît la complexité des vérifications, et les fournisseurs peuvent modifier leurs adresses IP sans préavis.
Des outils tels que PowerSPF ( SPF hébergé) de PowerDMARC automatisent ce processus en :
- Respecter la limite de 10 consultations
- Mise à jour automatique des changements d'adresse IP des fournisseurs d'accès
- Réduire les erreurs humaines et les opérations de maintenance
Cela permet de garantir que votre SPF reste valide et que la délivrabilité ne soit pas affectée au fil du temps.
Exemple d'enregistrement
v=spf1 ip4:203.0.113.5 include:_spf.google.com include:servers.mcsv.net -all
Ce que fait réellement cet enregistrement
- Autorise un serveur dédié (ip4:203.0.113.5)
- Autorise Google Workspace (inclure :_spf.google.com)
- Autorise Mailchimp (include:servers.mcsv.net)
- Rejette tout expéditeur qui ne figure pas explicitement dans la liste (-all)
Cela permet de mettre en place une politique stricte et applicable : seules les sources connues peuvent envoyer des données, tout le reste est bloqué.
La limite de 10 recherches
Les mécanismes suivants déclenchent des requêtes DNS :
- inclure :
- a
- mx
- existe :
- redirect=
- ptr (obsolète, mais compte toujours s'il est utilisé)
Ces mécanismes obligent le serveur destinataire à interroger le DNS pour obtenir des informations supplémentaires avant de poursuivre l'évaluation.
Ce qui ne compte PAS
Ces éléments sont évalués directement et ne déclenchent pas de requêtes DNS :
- ip4 :
- ip6 :
- tous
- v=spf1
Le problème, c'est que SPF ne sont pas toujours visibles à première vue. Les inclusions imbriquées, les expéditeurs inactifs et les plages d'adresses IP masquées peuvent faire dépasser la limite à votre enregistrement sans qu'il y ait de signes évidents.
Comment le nombre de recherches augmente
Même un petit SPF peut dépasser les limites en raison d'inclusions imbriquées. Voici comment le nombre de requêtes augmente concrètement :
| Service | SPF | Recherches directes | Recherches imbriquées | Contribution totale |
|---|---|---|---|---|
| Espace de travail Google | inclure :_spf.google.com | 1 | 2–3 | 3–4 |
| Microsoft 365 | inclure :spf.protection.outlook.com | 1 | 1–2 | 2–3 |
| HubSpot | inclure :spf.hubspot.com | 1 | 0-1 | 1–2 |
| Salesforce | notamment :_spf.salesforce.com | 1 | 1 | 2 |
| Total | — | 4 | 4 à 7 | 8 à 11 |
Bien qu'il n'y en ait que quatre sont visibles : sont visibles, le nombre total de recherches peut dépasser la limite de 10 recherches une fois que les enregistrements imbriqués sont évalués.
Limite de recherche de valeurs nulles (souvent négligée)
SPF non seulement une limite de 10 requêtes DNS, mais aussi une limite de deux requêtes infructueuses.
On parle de recherche infructueuse lorsqu'une requête DNS ne renvoie aucun résultat, par exemple une réponse « domaine inexistant » (NXDOMAIN) ou une réponse DNS vide.
On parle de recherche infructueuse lorsqu'une requête DNS ne renvoie aucun résultat, par exemple une réponse « domaine inexistant » (NXDOMAIN) ou une réponse DNS vide.
Causes courantes :
- Les informations incorrectes ou obsolètes : domaines
- Erreurs typographiques dans SPF
- Références à des domaines qui n'existent plus
Si plus de deux recherches infructueuses se produisent lors de SPF :
- SPF une erreur permanente
- SPF échoue dans son ensemble
- Les e-mails légitimes peuvent ne pas être authentifiés
Contrairement aux problèmes liés au nombre de requêtes, les requêtes vaines sont souvent plus difficiles à détecter, car elles résultent de références DNS invalides ou obsolètes plutôt que d'une complexité apparente.
Vous ne savez pas combien de requêtes DNS votre SPF génère ?
Des solutions telles que SPF et Reporting de PowerDMARC offrent :
- Visibilité sur toutes les sources d'envoi et toutes les adresses IP (même celles imbriquées)
- Détection des problèmes liés aux limites de recherche et des erreurs de configuration
- Des diagnostics clairs accompagnés de solutions concrètes
Cela permet de mieux comprendre le fonctionnement réel de votre SPF et d'identifier les points à optimiser.
Conclusion
SPF un protocole de contrôle qui permet de définir qui est autorisé à envoyer des e-mails en utilisant votre domaine. Le balise v=spf1 lance ce processus, mais la fiabilité de votre configuration dépend de la qualité de la construction et de la maintenance de l'enregistrement, ainsi que de son respect des limites.
La plupart SPF ne sont pas dus à une configuration incorrecte, mais à des dérives, à l'ajout de nouveaux outils sans mise à jour, à des inclusions inutilisées laissées en place ou au dépassement des limites de requêtes au fil du temps. Ces défaillances passent souvent inaperçues jusqu'à ce qu'elles affectent la délivrabilité.
Pour que SPF correctement :
- Veillez à ce que vos données soient exactes et succinctes
- Vérifiez régulièrement les sources d'envoi
- Respectez les limites de recherche
- Valider les modifications avant et après la publication
SPF mieux lorsqu'il est considéré comme une configuration active plutôt que comme une configuration ponctuelle. Lorsqu'il est correctement géré, il fournit aux serveurs destinataires un signal clair et cohérent auquel ils peuvent se fier, ce qui favorise directement la délivrabilité et l'authentification dans l'ensemble de votre programme de messagerie.
N'attendez pas que SPF compromettent la délivrabilité de vos e-mails.
Bénéficiez d'une visibilité totale sur votre SPF , résolvez les problèmes de résolution et assurez-vous que votre configuration reste à jour à mesure que votre infrastructure d'envoi évolue.
Découvrez comment surveiller et gérer SPF avec PowerDMARC.
FAQ
1. Que se passe-t-il si mon SPF est manquant ou n'est pas configuré ?
Si aucun SPF n'existe, les serveurs destinataires renvoient un « None » . Cela signifie que votre domaine ne dispose d'aucune authentification SPF, et que les destinataires s'appuient sur d'autres signaux tels que le DKIM ou les filtres anti-spam. En pratique, cela augmente le risque d'usurpation d'identité et peut nuire à la délivrabilité.
2. Puis-je avoir plusieurs SPF sur mon domaine ?
Non. Un domaine doit comporter exactement un SPF . Si plusieurs enregistrements TXT commencent par v=spf1, SPF renvoie une PermErroret l'authentification échoue pour tous les e-mails. Regroupez toujours toutes les sources d'envoi dans un seul enregistrement.
3. Comment savoir si mon SPF est correct ?
Vous devez vérifier trois points :
- La syntaxe est correcte (pas de fautes de frappe ni de problèmes de mise en forme)
- Toutes les sources d'envoi légitimes sont incluses
- Le nombre de requêtes DNS reste dans la limite de 10 requêtes
Utilisez un outil SPF et examinez les résultats concrets à l'aide des rapports DMARC pour vous assurer que tout fonctionne comme prévu.
4. Quelle est la différence entre « SPF », « Fail » et « PermError » ?
- Passer → Le serveur d'envoi est autorisé
- Échec / Échec temporaire → L'expéditeur n'est pas autorisé (traitement strict ou souple)
- PermError → SPF défectueux en raison d'une mauvaise configuration (par exemple, trop de requêtes, syntaxe incorrecte)
L'erreur « PermError » est la plus grave, car elle signifie que SPF absolument pas être évalué.
5. Ai-je besoin de SPF j'utilise déjà DKIM et DMARC ?
Oui. SPF l'un des principaux indicateurs d'authentification utilisés par DMARC. Bien que le DKIM puisse fonctionner de manière autonome, la combinaison SPF du DKIM améliore la fiabilité et la couverture. De nombreux destinataires s'attendent à ce que ces trois éléments soient correctement configurés.
6. SPF -t-il contre l'usurpation d'adresse e-mail ?
Pas à lui seul. SPF vérifie SPF le domaine du champ « Return-Path », et non l'adresse « From » visible. Un pirate peut toujours usurper l'en-tête « From » et passer SPF son propre domaine. Le DMARC est nécessaire pour garantir la conformité et empêcher cela.
- Qu'est-ce que v=spf1 ? À quoi cela sert-il ? - 5 mai 2026
- Étude de cas DMARC pour les MSP : comment Digital Infinity IT Group a rationalisé la gestion DMARC et DKIM de ses clients grâce à PowerDMARC - 21 avril 2026
- Qu'est-ce que DANE ? Explication de l'authentification des entités nommées basée sur le DNS (2026) - 20 avril 2026


