SPF Sender Policy Framework) : qu'est-ce que c'est et comment ça marche
par
Dernière mise à jour :
7 Temps de lecture : 7 min
Points clés à retenir
- SPF Sender Policy Framework) est un protocole d'authentification des e-mails qui permet aux propriétaires de domaines de publier une liste de serveurs de messagerie autorisés dans leur DNS.
- Un SPF est un enregistrement DNS de type TXT qui répertorie les adresses IP et les services d'envoi autorisés. Il doit commencer par « v=spf1 », respecter SPF et être publié sous la forme d'un seul enregistrement.
- SPF de réelles limites. Il ne fonctionne pas avec les e-mails transférés, ne peut pas protéger l'adresse d'expéditeur visible par les utilisateurs et est limité à 10 requêtes DNS. Le dépassement de cette limite entraîne une erreur « PermError » susceptible de rejeter silencieusement des e-mails légitimes.
- SPF ne suffit pas. Il doit être associé à DKIM et DMARC pour offrir une protection complète contre l'usurpation d'adresse e-mail, les attaques de phishing et l'utilisation abusive des domaines.
L'usurpation d'adresse e-mail est l'une des astuces les plus anciennes du répertoire des pirates, et elle fonctionne toujours car le nombre excessif de domaines facilite la tâche. Le Sender Policy Framework (SPF) constitue la première ligne de défense. Il s'agit d'un protocole fondamental d'authentification des e-mails qui indique aux serveurs de messagerie destinataires quelles adresses IP sont réellement autorisées à envoyer des e-mails en votre nom.
Ce guide explique ce SPF , comment fonctionne le SPF , comment le configurer correctement et quelles sont ses limites.
Qu'est-ce que SPF Sender Policy Framework) ?
Le Sender Policy Framework (SPF) est un protocole d'authentification des e-mails conçu pour empêcher l'usurpation d'adresse e-mail, l'une des techniques les plus couramment utilisées dans les attaques de phishing et les campagnes de spam.
Ce système permet aux propriétaires de domaines de publier une liste de serveurs de messagerie autorisés dans leur DNS, afin que les serveurs destinataires puissent vérifier si un message entrant provient bien d'une source approuvée.
SPF un élément fondamental de l' l'authentification des e-mails car il fournit aux systèmes destinataires une réponse claire et faisant autorité à une question simple : ce serveur est-il autorisé à envoyer des e-mails pour ce domaine ?
SPF dans le contexte plus large de la sécurité des e-mails
SPF fonctionne pas de manière isolée. Il s'agit de l'un des trois principaux protocoles d'authentification des e-mails, aux côtés de DomainKeys Identified Mail (DKIM) et Domain-based Message Authentication, Reporting, and Conformance (DMARC). Ensemble, ces protocoles forment une défense complète contre la fraude par e-mail.
| Protocole | Ce qu'il vérifie |
|---|---|
| SPF | Si le serveur expéditeur est autorisé par le propriétaire du domaine |
| DKIM | Le contenu du message a-t-il été modifié pendant la transmission ? |
| DMARC | Si SPF DKIM correspondent à l'adresse d'expéditeur, et que faire dans le cas contraire |
SPF également un élément indispensable à la configuration du DMARC. Sans SPF valide, le DMARC ne peut pas fonctionner correctement.
Lecture recommandée : SPF, DKIM et DMARC : comment ils fonctionnent ensemble
Fonctionnement du SPF
SPF entièrement via le DNS. Lorsqu'un e-mail est envoyé, le serveur de messagerie destinataire effectue une série de vérifications afin de déterminer si le message est fiable. Voici comment ce processus se déroule du début à la fin.
Le processus SPF du SPF
- Un e-mail est envoyé depuis un serveur, avec le domaine de l'expéditeur indiqué dans l'adresse Return-Path
- Le serveur destinataire identifie le domaine de l'expéditeur à partir de cette adresse Return-Path
- Le serveur destinataire effectue une rechercheSPF dans le DNS du domaine pour trouver SPF publié
- L'adresse IP du serveur expéditeur est comparée à la liste des adresses IP autorisées figurant dans SPF
- En cas de correspondance, l'e-mail passe SPF . En l'absence de correspondance, l'e-mail peut être signalé comme suspect ou rejeté, selon la politique du domaine
Résultats de SPF
| Résultat | Signification |
|---|---|
| Passez | L'adresse IP d'origine est autorisée dans SPF |
| Échec | L'adresse IP d'origine n'est pas autorisée |
| SoftFail | L'adresse IP n'est pas autorisée, mais le domaine n'applique pas de rejet |
| Neutre | Le propriétaire du domaine n'a fait aucune déclaration concernant l'adresse IP d'origine |
| Aucun | Aucun SPF n'a été trouvé pour ce domaine |
| TempError | Une erreur de résolution DNS s'est produite lors de la vérification |
| Erreur de permission | SPF contient une erreur de syntaxe ou dépasse la limite de recherche |
Il est important de noter que SPF vérifie SPF l'adresse IP du serveur expéditeur. Il n'authentifie ni l'identité réelle de l'expéditeur, ni le contenu du message. C'est là qu'interviennent DKIM et DMARC viennent combler les lacunes.
À quoi ressemble un SPF ?
Un SPF est un enregistrement DNS TXT publié dans les paramètres DNS de votre domaine. Il suit une syntaxe spécifique composée de mécanismes et de qualificatifs qui définissent quels serveurs sont autorisés à envoyer des e-mails pour votre domaine.
Structure de base SPF
v=spf1 ip4:192.0.2.0/24 include:mailprovider.com -all
| Composant | Signification |
|---|---|
| v=spf1 | Balise de version : doit apparaître en premier dans chaque SPF |
| ip4 : | Autorise une adresse IPv4 ou une plage d'adresses IPv4 spécifique |
| ip6 : | Autorise une adresse IPv6 ou une plage d'adresses IPv6 spécifique |
| inclure : | Autorise SPF d'un expéditeur tiers |
| a : | Autorise l'adresse IP de l'enregistrement A du domaine |
| mx : | Autorise les serveurs de messagerie du domaine |
| -tout | Échec définitif : rejeter tous les messages qui ne correspondent pas à l'enregistrement |
| ~tout | Échec sans conséquence : signaler le problème, mais livrer le courrier même s'il ne correspond pas à l'enregistrement |
| ?tout | Neutre : aucune politique concernant les e-mails non correspondants |
SPF pour les domaines non émetteurs
Même pour les domaines qui n'envoient jamais d'e-mails, il convient de publier un SPF restrictif afin d'empêcher toute usurpation d'identité :
v=spf1 -all
Cela indique aux serveurs destinataires de rejeter tous les e-mails prétendant provenir de ce domaine.
La limite de 10 requêtes DNS
SPF une limite de 10 requêtes DNS par évaluation d'enregistrement. Chaque comprend :, a:, mx:, et redirect: déclenche une recherche.
Le dépassement de cette limite entraîne une erreur « PermError », ce qui peut empêcher les e-mails légitimes de échouer silencieusement à SPF sans qu'aucun message d'erreur ne soit généré. Il s'agit de l'un des problèmes SPF les plus courants et les plus souvent négligés, en particulier pour les organisations disposant d'environnements de messagerie complexes.
Configurer SPF avec PowerDMARC !Pourquoi choisir PowerDMARC plutôt que d'autres SPF ?
|
Comment créer et publier un SPF
La création et la publication d'un SPF constituent l'une des étapes les plus importantes pour sécuriser la messagerie de votre domaine.
Si elle est correctement configurée, elle indique à chaque serveur de messagerie destinataire quelles sources sont autorisées à envoyer des e-mails en votre nom. Si elle est mal configurée, elle peut, sans que vous vous en rendiez compte, empêcher l'authentification de vos propres e-mails légitimes. Voici comment procéder correctement.
Étape 1 : Vérifiez toutes vos sources d'envoi d'e-mails
Avant de rédiger la moindre ligne de votre SPF , identifiez tous les services et systèmes qui envoient des e-mails depuis votre domaine. C'est l'étape que la plupart des entreprises négligent, et c'est la raison la plus fréquente pour laquelle SPF échouent après leur publication.
Votre audit devrait porter sur :
- Votre serveur de messagerie principal
- Plateformes d'email marketing
- Outils de gestion de la relation client (CRM) et outils de vente
- Logiciels d'assistance et de support
- Services de facturation et d'e-mails transactionnels
- Tout fournisseur tiers effectuant des envois en votre nom
Pour chaque source, recueillez soit les adresses IP d'expédition spécifiques, soit la chaîne SPF fournie par ce service.
Étape 2 : Rédigez votre SPF
Regroupez tous les expéditeurs autorisés dans un seul enregistrement DNS TXT en utilisant SPF appropriée. Voici un exemple simple :
v=spf1 ip4:192.0.2.1 include:sendingservice.com include:marketingplatform.com -all
Principales règles à respecter lors de la rédaction :
| Règle | Pourquoi est-ce important ? |
|---|---|
| Commencez toujours par v=spf1 | Il s'agit de la balise de version obligatoire. Sans elle, l'enregistrement n'est pas valide |
| N'utilisez qu'un seul enregistrement | La présence de plusieurs enregistrements SPF sur un même domaine provoque une erreur « PermError » et empêche l'authentification |
| Ne pas dépasser 10 requêtes DNS | Chaque mécanisme « include: », « a: » et « mx: » est pris en compte dans le calcul de la limite. Tout dépassement de cette limite entraîne une erreur « PermError ». |
| Se terminer par -all ou ~all | Définit le traitement des e-mails qui ne répondent pas aux critères. Utilisez l'option -all pour appliquer une politique de rejet strict. |
Étape 3 : Publiez l'enregistrement dans votre DNS
Une fois votre enregistrement créé, connectez-vous à votre fournisseur de DNS et ajoutez-le en tant qu'enregistrement TXT sur votre domaine racine.
L'enregistrement doit être ajouté à @ ou votredomaine.com, et non sur un sous-domaine, sauf si vous créez spécifiquement un enregistrement distinct pour un sous-domaine.
Si vous utilisez des sous-domaines distincts pour différents services d'envoi, chaque sous-domaine doit disposer de son propre SPF . Il s'agit également d'une technique utile pour respecter la limite de 10 requêtes lors de la gestion de plusieurs expéditeurs tiers.
Étape 4 : Testez votre enregistrement après sa publication
La publication de votre enregistrement n'est pas la dernière étape. Vérifiez-le toujours après publication afin de vous assurer que :
- L'enregistrement est correctement formaté et ne contient aucune erreur de syntaxe
- Toutes les adresses IP autorisées et toutes les chaînes de caractères sont présentes
- La limite de requêtes DNS n'a pas été dépassée
- Il n'y a pas SPF en double sur ce domaine
Utilisation de l'outil SPF de PowerDMARC pour effectuer cette vérification immédiatement après la publication, puis à chaque fois que vous apportez des modifications.
Étape 5 : Tenez votre dossier à jour
Un SPF n'est pas une configuration que l'on met en place une fois pour toutes.
Chaque fois que vous ajoutez une nouvelle plateforme d'envoi, que vous changez de fournisseur de services de messagerie ou que vous désactivez un ancien fournisseur, votre enregistrement SPF doit être mis à jour. Un enregistrement obsolète faisant référence à d'anciennes adresses IP ou à des services qui n'existent plus est l'une des causes les plus courantes d'échec SPF pour des e-mails légitimes.
Prévoyez un calendrier régulier pour vérifier votre SPF , en particulier après toute modification de votre infrastructure de messagerie.
SPF délivrabilité des e-mails
L'un des avantages les plus directs de la mise en place SPF une meilleure délivrabilité des e-mails. Voici comment SPF le parcours de vos e-mails, de l'envoi à la boîte de réception.
Comment SPF la délivrabilité
- Les serveurs de réception et les fournisseurs de boîtes aux lettres utilisent SPF indicateur de fiabilité pour déterminer s'il faut acheminer, filtrer ou rejeter les e-mails entrants
- SPF valide réduit le risque que des e-mails légitimes soient classés comme spam
- SPF cohérente renforce la réputation du domaine au fil du temps, ce qui réduit le risque que vos e-mails soient bloqués ou redirigés vers les dossiers de courrier indésirable
- La mise en œuvre SPF un engagement en faveur de la sécurité des e-mails auprès des FAI, ce qui contribue positivement à la réputation de l'expéditeur
Comment une mauvaise configuration SPF nuire à la délivrabilité
| Problème | Impact |
|---|---|
| SPF manquant | Le domaine peut être facilement usurpé ; il n'y a aucun indicateur de fiabilité pour les destinataires |
| PermError (limite de recherche dépassée) | Il arrive que des e-mails légitimes échouent à SPF |
| Adresses IP autorisées obsolètes | Les e-mails provenant de sources d'envoi nouvelles ou modifiées échouent au test SPF |
| SPF multiples | Provoque une erreur « PermError », ce qui empêche complètement l'authentification |
| Trop permissif ~tout ou ?tout | Réduit la valeur protectrice du dossier |
Il est essentiel de maintenir un SPF précis et à jour pour protéger la réputation de votre domaine et garantir une délivrabilité constante de vos e-mails.
Les limites du SPF
SPF un protocole méthode d'authentification des e-mails , mais il présente des limites bien documentées que tout propriétaire de domaine devrait connaître. Se fier SPF au SPF laisse d'importantes failles dans votre dispositif de sécurité des e-mails.
Ce que SPF faire
| Limitation | Pourquoi est-ce important ? |
|---|---|
| Impossible de masquer l'adresse de l'expéditeur | SPF le champ « Return-Path », et non l'en-tête « From » que voient les destinataires |
| Interruptions dans les e-mails transférés | L'adresse IP du serveur de transfert ne figure pas dans SPF d'origine, ce qui entraîne des échecs |
| Impossible de vérifier le contenu du message | SPF vérifie SPF l'adresse IP de l'expéditeur, et non si le message a été modifié |
| Impossible de bloquer les tentatives de phishing par des domaines similaires | Les pirates peuvent enregistrer un domaine similaire avec son propre SPF valide |
| Limité à 10 requêtes DNS | Les environnements complexes peuvent dépasser la limite, ce qui provoque des erreurs PermError |
SPF un début, pas une fin
SPF ne permet pas de protéger l'adresse d'expéditeur visible par les utilisateurs, ne résiste pas au transfert de messages et ne permet pas d'authentifier le contenu des messages.
Pour bénéficier d'une protection complète contre l'usurpation de domaine et les attaques de phishing, SPF être associé aux protocoles DKIM et DMARC. Le protocole DMARC comble précisément la faille SPF en exigeant que l'adresse d'expéditeur corresponde aux informations d'authentification de l'expéditeur.
| Conseil d'expert : Je conseille toujours à mes clients de tenir un journal SPF répertoriant toutes les modifications, en particulier dans les environnements complexes comportant plusieurs services de messagerie. Cela permet d'éviter les dérives de configuration et facilite considérablement le dépannage. |
Protégez votre domaine avec SPF PowerDMARC
SPF le point de départ de l'authentification des e-mails, mais il ne s'agit que d'une pièce du puzzle.
C'est en configurant correctement votre SPF , en veillant à ce qu'il reste à jour à mesure que votre infrastructure d'envoi évolue, et en l'associant aux protocoles DKIM et DMARC que vous protégez réellement votre domaine contre l'usurpation d'identité, le phishing et les problèmes de délivrabilité.
Un client raconte :
« PowerDMARC a simplifié la SPF pour notre équipe informatique. La délivrabilité et la sécurité de nos e-mails se sont améliorées du jour au lendemain. » – Responsable de la sécurité des systèmes d'information, établissement financier
PowerDMARC facilite la gestion de l'ensemble de ce processus. De la création et la validation SPF votre SPF au suivi des résultats d'authentification sur tous vos domaines d'envoi, en passant par la mise en place d'une application stricte du protocole DMARC, PowerDMARC vous offre la visibilité et le contrôle nécessaires pour réussir du premier coup et maintenir cette configuration à long terme.
Commencez dès aujourd'hui avec PowerDMARC dès aujourd'hui !
FAQ
1. Qu'est-ce que le cadre de politique SPF ?
Le SPF Sender Policy Framework) est un protocole d'authentification des e-mails qui permet aux propriétaires de domaines de désigner les serveurs de messagerie autorisés à envoyer des e-mails au nom de leur domaine. Il fonctionne grâce à la publication d'un enregistrement DNS de type TXT répertoriant les sources d'envoi approuvées, ce qui aide les serveurs destinataires à vérifier l'authenticité des e-mails et à prévenir l'usurpation d'identité.
2. En quoi SPF -t-il des protocoles DKIM et DMARC ?
SPF l'adresse IP du serveur expéditeur, le DKIM utilise des signatures cryptographiques pour vérifier l'intégrité du message, et le DMARC assure l'application des politiques et la génération de rapports. SPF l'expéditeur de l'enveloppe, le DKIM s'assure que le contenu du message n'a pas été altéré, et le DMARC indique aux serveurs destinataires comment réagir en cas d'échec SPF du DKIM. Ces trois protocoles fonctionnent de concert pour assurer une authentification complète des e-mails.
3. Comment utiliser le Sender Policy Framework ?
Identifiez tous les services qui envoient des e-mails depuis votre domaine, recensez leurs adresses IP autorisées, puis publiez un seul enregistrement DNS de type TXT commençant par « v=spf1 ». Testez-le après sa publication et mettez-le à jour à mesure que votre infrastructure d'envoi évolue.
4. Quelles sont les limites des enregistrements SPF ?
SPF vérifie SPF le serveur d'origine, et non l'identité de l'expéditeur ni le contenu du message. Il ne fonctionne pas avec les e-mails transférés et impose une limite stricte de 10 requêtes DNS ; si cette limite est dépassée, l'authentification peut échouer sans avertissement.
5. SPF est-il identique au protocole DKIM ?
Non. SPF l'adresse IP du serveur expéditeur. Le protocole DKIM utilise une signature cryptographique pour vérifier que le contenu du message n'a pas été altéré pendant le transfert.
6. Pourquoi un e-mail échouerait-il SPF?
Les causes les plus courantes sont un serveur d'envoi non autorisé, un SPF obsolète ne mentionnant pas d'expéditeur légitime, des erreurs de syntaxe dans l'enregistrement ou le dépassement de la limite de 10 requêtes DNS.
Expert en cybersécurité, PDG de PowerDMARC
Maitham est un entrepreneur technologique, expert en cybersécurité, PDG et fondateur de PowerDMARC avec plus de 15 ans d'expérience dans l'industrie. Maitham est titulaire d'un Global MBA de l'Université de Manchester et de diverses certifications professionnelles, notamment CISSP, CISM, CRISC et ISC2 CCSP.
Derniers messages de Maitham Al Lawati (voir tous)
- Statistiques sur le phishing et le DMARC : tendances 2026 en matière de sécurité des e-mails - 6 janvier 2026
- Comment corriger « Aucun SPF trouvé » en 2026 - 3 janvier 2026
- SPF : comment corriger un nombre trop élevé de requêtes DNS - 24 décembre 2025
