SPF DNS : comment ça marche et comment le configurer

Chaque e-mail envoyé par votre organisation reflète la réputation de votre domaine. Si votre SPF est mal configuré, voire absent, les serveurs de réception n'ont aucun moyen fiable de vérifier que l'e-mail provient bien de vous. Les e-mails légitimes finissent dans les courriers indésirables. Les campagnes marketing sont rejetées. Les pirates envoient des messages qui semblent provenir de votre domaine.

SPF Sender Policy Framework) est l'un des trois principaux protocoles d'authentification , aux côtés de DKIM et DMARC, qui indique aux serveurs de messagerie destinataires quelles adresses IP sont autorisées à envoyer des e-mails au nom de votre domaine. Il est publié sous la forme d'un enregistrement DNS TXT. À première vue, cela semble simple. En pratique, SPF que commencent la plupart des problèmes d'authentification des e-mails. 

Ce guide explique en détail ce qu'est un SPF , comment fonctionne SPF étape par étape, comment en créer un et comment résoudre les SPF les plus courantes, notamment la limite de 10 requêtes DNS qui empêche discrètement la livraison des e-mails pour les entreprises en pleine croissance.

Qu'est-ce qu'un SPF DNS ?

Un enregistrement DNS SPF Sender Policy Framework) est un type d'enregistrement DNS TXT qui précise quels serveurs de messagerie sont autorisés à envoyer des e-mails au nom de votre domaine. Il aide les serveurs de messagerie destinataires à vérifier que les messages entrants proviennent de sources légitimes, réduisant ainsi le risque d'usurpation d'identité et d'hameçonnage. Lorsqu'un e-mail est reçu, le serveur vérifie SPF du domaine de l'expéditeur afin de s'assurer que l'adresse IP d'origine est autorisée. 

Si l'adresse IP ne figure pas dans la liste, le message risque d'être signalé, rejeté ou envoyé dans le dossier des spams. Une configuration correcte SPF améliore la délivrabilité des e-mails et renforce l'authentification du domaine.

Vous pouvez vérifier immédiatement SPF de votre domaine à l'aide d'un outil SPF gratuit. Cela ne prend que cinq secondes et vous indique exactement ce qui est publié dans votre DNS.

Comment fonctionne SPF ?

SPF suit un processus structuré de recherche et de validation DNS à chaque fois qu'un e-mail est reçu :

• Votre domaine publie un SPF sous la forme d'une entrée DNS de type TXT. Cet enregistrement définit toutes les sources d'envoi autorisées à l'aide de mécanismes tels que ip4, ip6, includeet une, ainsi qu'une politique par défaut (-all, ~allou ?all).
• Lorsqu'un e-mail est envoyé, le serveur d'envoi inclut une adresse « Return-Path » (expéditeur de l'enveloppe) qui désigne le domaine chargé de la distribution.
• Le serveur de messagerie destinataire extrait le domaine de l'adresse Return-Path.
• Il effectue une requête DNS pour récupérer SPF associé à ce domaine.
• L'adresse IP du serveur expéditeur est ensuite comparée à chaque mécanisme de SPF , traitée dans l'ordre jusqu'à ce qu'une correspondance soit trouvée ou qu'une décision soit prise.
• SPF une limite de 10 requêtes DNS pendant cette évaluation afin d'éviter une récursivité excessive ; tout dépassement de cette limite entraîne une erreur PermError.
• En fonction du résultat, SPF une valeur telle que « Pass », « Fail », « SoftFail », « Neutral », « None », « PermError » ou « TempError ».
• Le serveur destinataire utilise ce résultat, ainsi que l'authentification DKIM et la conformité à la politique DMARC, pour déterminer comment le message doit être traité (livré, quarantine ou rejeté).

Un détail crucial : SPF le domaine du champ « Return-Path » (expéditeur de l'enveloppe), et non celui du champ « From » visible. Si ces domaines diffèrent, ce qui est courant avec les plateformes d'envoi tierces, SPF être validé, mais l'alignement DMARC peut échouer, ce qui affecte directement le placement dans la boîte de réception.

Chaque code SPF a une signification concrète bien précise :

Rapports agrégés DMARC vous indiquent précisément quels e-mails passent ou échouent SPF l'ensemble de vos sources d'envoi. Sans les rapports DMARC, SPF se produisent en silence et vous ne vous en rendez compte que lorsque quelqu'un se plaint.

Explication de la syntaxe et du format SPF

Pour comprendre SPF , il faut commencer par lire un enregistrement complet et savoir comment chaque partie est évaluée. En voici un exemple typique :

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ip4:203.0.113.0/24 -all (où /24 représente une plage de 256 adresses IP selon la notation CIDR (Classless Inter-Domain Routing))

Cette seule ligne indique aux serveurs destinataires quelles sources sont autorisées à envoyer des e-mails pour votre domaine et comment réagir si un expéditeur ne figure pas dans la liste.

Balise SPF (v=spf1)

Chaque SPF doit commencer par v=spf1. Cela identifie l'enregistrement TXT comme une SPF . Il n'existe aucune autre version valide. Si cette balise est manquante ou incorrecte, l'enregistrement est entièrement ignoré.

SPF (expéditeurs autorisés) 

Les mécanismes déterminent qui est autorisé à envoyer des e-mails. Ils sont évalués de gauche à droite, et la première correspondance détermine le résultat.

Parmi comprend : mécanisme est le plus couramment utilisé et celui qui pose le plus de problèmes. Chaque « include: » déclenche une recherche DNS récursive. Si SPF de Google inclut trois autres domaines, ceux-ci sont tous pris en compte dans votre limite de 10 recherches.

Une source fréquente de confusion : le mécanisme mécanisme SPF l'enregistrement DNS de type A du domaine. Il ne crée pas d'« enregistrement A spécifique à SPF ». Lorsque vous ajoutez un à votre SPF , vous autorisez toutes les adresses IP vers lesquelles l'enregistrement A de votre domaine effectue la résolution.

Modificateurs (redirect=)

Les modificateurs déterminent le fonctionnement SPF plutôt que de définir les expéditeurs.

• redirect=
  Transfère l'intégralité de SPF vers un autre domaine. Contrairement à include :, qui ajoute une autre politique à votre enregistrement, redirect= remplace complètement votre évaluation.
  N'utilisez cette option que lorsqu'un domaine doit hériter intégralement de SPF d'un autre domaine.

Limite de requêtes DNS (contrainte critique)

SPF un maximum de 10 requêtes DNS par évaluation. Parmi les mécanismes concernés, on peut citer :, un, mx, existe :, et redirect= comptent tous dans cette limite.

Si cette limite est dépassée, SPF une erreur « PermError » et l'authentification échoue, même si l'expéditeur est légitime. C'est pourquoi les enregistrements volumineux et complexes nécessitent souvent une optimisation (comme la suppression des inclusions inutilisées ou l'aplatissement).

SPF (le mécanisme « all »)

La condition sur le « all » à la fin de votre SPF définit votre SPF : que se passe-t-il avec les e-mails provenant de serveurs qui ne sont pas explicitement répertoriés :

SPF comme un ensemble de règles logiques. Le serveur destinataire lit votre enregistrement de gauche à droite, vérifie chaque mécanisme et s'arrête dès la première correspondance. Si aucune correspondance n'est trouvée, le règle s'applique.

SPF bien structuré est :

• Complet (tous les expéditeurs légitimes sont inclus)
• Efficace (dans les limites de la recherche)
• Strict (en utilisant -all une fois validé)

Cela garantit une authentification fiable et empêche toute utilisation non autorisée de votre domaine pour l'envoi d'e-mails.

Comment créer et publier un SPF

La configuration d'un SPF consiste à identifier toutes les sources d'envoi légitimes, à les définir clairement dans le DNS et à vérifier que la configuration fonctionne comme prévu. Suivez les 5 étapes ci-dessous dans l'ordre.

Étape 1 : Identifiez toutes vos sources d'envoi

Répertoriez tous les services qui envoient des e-mails au nom de votre domaine. Cela comprend généralement votre principal fournisseur de messagerie (tel que Google Workspace ou Microsoft 365), les plateformes marketing (comme Mailchimp ou HubSpot), les systèmes de gestion de la relation client (CRM) (Salesforce), les outils d'assistance (Zendesk) et les services d'e-mails transactionnels (SendGrid, Amazon SES). Chacun de ces services utilise une infrastructure différente pour l'envoi, ils doivent donc tous être explicitement autorisés. La plupart des fournisseurs publient une valeur SPF dans leur documentation, qui indique aux serveurs destinataires de faire confiance à leurs adresses IP d'expédition.

Étape 2 : Créez votre SPF

Un SPF est une entrée TXT d'une seule ligne qui commence par v=spf1. Vous définissez ensuite les expéditeurs autorisés à l'aide des mécanismes suivants :

• inclure : pour les services tiers (par exemple, include:_spf.google.com)
• ip4: ou ip6: pour les adresses IP ou plages d'adresses spécifiques que vous contrôlez
  Les mécanismes sont évalués de gauche à droite. À la fin, vous définissez une politique :
• ~all (erreur non critique) signale les expéditeurs non autorisés comme suspects
• -all (erreur fatale) les refuse catégoriquement

Exemple :

v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:198.51.100.0/24 ~all

Ce fichier indique aux serveurs destinataires quelles sources sont autorisées et comment traiter toutes les autres.

Étape 3 : Publier l'enregistrement dans le DNS

Connectez-vous à votre fournisseur de services DNS (tel que Cloudflare, Route 53 ou GoDaddy). Créez un nouvel enregistrement TXT pour votre domaine racine :

• Hôte/Nom : @ (ou laisser vide, selon le fournisseur)
• Valeur : votre SPF complet
  Une fois enregistré, l'enregistrement devient accessible au public via le DNS. La propagation des modifications peut prendre un certain temps.

Étape 4 : Valider l'enregistrement

Après la publication, vérifiez que :

• SPF est correctement formaté (aucune erreur de syntaxe)
• Tout s'est bien passé
• Le nombre total de requêtes DNS ne dépasse pas la limite de 10 (en cas de dépassement,SPF une erreur permanente)

La validation garantit que les serveurs destinataires peuvent traiter votre enregistrement de manière fiable et sans erreur.

Étape 5 : Suivre SPF

La configuration SPF pas une opération ponctuelle. À mesure que vous ajoutez ou supprimez des sources d'envoi, votre SPF doit être mis à jour. Pour surveiller les performances :

• Activer DMARC pour recevoir des rapports agrégés indiquant les taux SPF
• Vérifiez quelles sources réussissent ou échouent à l'authentification
• Supprimer les services inutilisés et corriger les expéditeurs mal configurés ou non autorisés

Important : Un seul SPF est autorisé par domaine. Si plusieurs enregistrements TXT commençant par v=spf1 , SPF échoue complètement et génère une erreur permanente (PermError). Regroupez toujours toutes les sources d'envoi en un seul enregistrement complet.

La limite SPF (et pourquoi elle perturbe votre messagerie)

SPF n'est pas illimitée. Conformément à la RFC 7208, un serveur destinataire peut effectuer au maximum 10 requêtes DNS lors du traitement SPF votre SPF . Si cette limite est dépassée, SPF une erreur permanente (PermError) et la vérification échoue complètement.

Il ne s'agit pas d'un échec partiel. Une erreur « PermError » signifie que SPF absolument SPF être évalué. Par conséquent, tous les e-mails envoyés depuis votre domaine ne passent pas SPF , que l'expéditeur soit légitime ou non.

Qu'est-ce qui est pris en compte dans la limite de 10 recherches ?

Les mécanismes suivants déclenchent des requêtes DNS :

• parmi lesquels : (les plus courants et les plus marquants)
• a
• mx
• ptr (obsolète, mais est toujours pris en compte s'il est utilisé)
• existe :
• redirect=

Les mécanismes « ip4: » et « ip6: » ne sont pas pris en compte dans la limite de requêtes, car ils font directement référence à des adresses IP, sans nécessiter de résolution DNS

Pourquoi cette limite est facile à dépasser

Le problème principal provient des recherches imbriquées (récursives).

Lorsque vous ajoutez un « include: », vous n'ajoutez pas seulement une entrée, mais vous héritez également de tout ce qui se trouve dans SPF de ce fournisseur.

Par exemple :

• Si vous incluez Google, SPF de Google SPF inclure plusieurs autres domaines
• Si vous incluez Microsoft 365 → cela ajoute plusieurs recherches supplémentaires
• Vous intégrez des outils marketing et transactionnels → chacun ajoute sa propre chaîne

Ces opérations s'accumulent rapidement. Même si votre enregistrement semble court, le nombre réel de recherches peut dépasser 10 lors de l'évaluation.

La limite des deux « recherches de vide » (souvent négligée)

SPF impose SPF une limite de deux requêtes infructueuses.

Une recherche infructueuse se produit lorsqu'une requête DNS ne renvoie aucun résultat (domaine inexistant (NXDOMAIN) ou réponse vide).

Causes courantes :

• Exemples d'erreurs ou d'informations obsolètes : domaines
• Fautes de frappe dans SPF
• Références à des domaines qui n'existent plus

Si plus de deux recherches aboutissent à un résultat nul, SPF renvoie SPF une erreur PermError.

A PermError ne signifie pas « échec pour certains expéditeurs ». Cela signifie :

• SPF considéré comme non valide
• Les serveurs destinataires ne peuvent pas se fier à votre SPF
• SPF n'offre SPF aucune protection ni authentification

Étant donné que SPF l'un des indicateurs utilisés par DMARC, cela peut également entraîner :

• Échecs DMARC (si DKIM ne correspond pas)
• Augmentation du nombre de spams
• Rejet des messages par des destinataires plus stricts

À mesure que votre infrastructure de messagerie s'étend, votre SPF devient naturellement plus complexe. Sans une gestion active :

• Le nombre de requêtes augmente sans qu'on s'en aperçoive
• Les services non utilisés restent enregistrés
• Les erreurs s'accumulent avec le temps

SPF cette fragilité. Il ne fonctionne de manière fiable que si les données sont conservées dans des limites raisonnables, sont exactes et font l'objet d'une mise à jour constante.

À quelle vitesse on atteint la limite (exemple concret)

Voici à quoi ressemble généralement une pile SaaS destinée au marché intermédiaire en termes de requêtes DNS :

Vous n'avez même pas encore ajouté Zendesk, SendGrid, votre service d'assistance ou votre prestataire de paie. Si votre entreprise utilise Google Workspace ainsi que quatre ou cinq outils SaaS qui envoient des e-mails, vous avez probablement déjà atteint, voire dépassé, la limite.

Comment résoudre les problèmes liés à la limite SPF

Si votre SPF dépasse la limite de 10 requêtes DNS, vous devez en réduire la complexité sans pour autant bloquer les sources d'envoi légitimes. Voici trois approches concrètes, classées par ordre d'impact :

Supprimer les mécanismes superflus

Commencez par réaliser un audit complet de votre SPF .

• Identifiez tous les y compris : et mécanisme actuellement répertorié
• Vérifiez si chaque service continue d'envoyer activement des e-mails pour votre domaine
• Retirez tout ce qui n'est plus utilisé

Problèmes courants :

• Les anciens outils marketing restés dans les archives
• Inclusions en double entre sous-domaines
• Les services de test ou temporaires n'ont jamais été nettoyés

Chaque élément inutilisé : que vous supprimez immédiatement libère une ou plusieurs requêtes DNS. C'est le moyen le plus simple et le moins risqué de repasser sous la limite.

Remplacer inclure : par ip4:/ip6: dans la mesure du possible

Si un expéditeur utilise un ensemble fixe et restreint d'adresses IP, vous pouvez remplacer ses inclure : par des entrées IP directes.

• Exemple : remplacer include:vendor.com par ip4:x.x.x.x
• Cela supprime complètement les requêtes DNS pour cet expéditeur

Quand cela fonctionne bien :

• Infrastructure interne
• Adresses IP dédiées fournies par un fournisseur
• Fournisseurs disposant de plages d'adresses IP clairement documentées et stables

Compromis à prendre en compte :

• Vous vous chargez de l'entretien
• Si le fournisseur met à jour ou change d'adresses IP, votre SPF devient obsolète
• Cela peut entraîner SPF silencieux SPF jusqu'à ce que le problème soit résolu

N'utilisez cette option que lorsque la stabilité de l'adresse IP est garantie.

Utilisation des macrosSPF ou SPF

Lorsque vous utilisez plusieurs services tiers, un nettoyage manuel ne suffit généralement pas. Il vous faut un moyen de réduire le nombre de requêtes sans perdre en couverture.

Aplatissement du SPF

• Résout tous , y compris : mécanismes en leurs adresses IP sous-jacentes
• Les remplace par une liste plate de ip4: / ip6: entrées
• Élimine la plupart des requêtes DNS

Limitation :

• Les enregistrements aplatis sont statiques
• Si un fournisseur (comme Google ou Microsoft) met à jour ses adresses IP d'envoi, votre enregistrement n'est pas automatiquement mis à jour
• Cela crée une faille qui peut faire que des e-mails légitimes échouent SPF avertissement

SPF (solution dynamique)

• Maintenir SPF dynamique SPF tout en contrôlant la profondeur de recherche
• Réduire le recours aux longues chaînes d'inclusion
• Mieux adapté aux environnements où l'infrastructure des expéditeurs change fréquemment

Vous ne savez pas combien de recherches votre SPF utilise ? Vérifiez le nombre de recherches grâce à notre SPF gratuit SPF

Pour les entreprises qui doivent rester en dessous de la limite de 10 requêtes sans avoir à gérer manuellement leur DNS, la solution PowerSPF de PowerDMARC PowerSPF offre à la fois l' et modernes et SPF modernes, vous permettant de choisir la technique la mieux adaptée à votre environnement. L'enregistrement se met à jour automatiquement lorsque des fournisseurs tiers modifient leurs plages d'adresses IP autorisées.

Pourquoi un indice de protection solaire ( SPF ) ne suffit pas SPF

SPF une méthode d'authentification fondamentale, mais il n'a pas été conçu pour offrir une protection totale contre les techniques modernes d'usurpation d'identité et d'abus. Il présente trois limites majeures qui le rendent insuffisant à lui seul.

Limite n° 1 : SPF l'expéditeur de l'enveloppe, et non l'en-tête « From »

SPF le champ « Return-Path » (expéditeur de l'enveloppe), c'est-à-dire le domaine utilisé lors de l'envoi du courriel. Cependant, les utilisateurs voient l'en-tête « From », qui peut être différent.

Cela crée une faille que les pirates peuvent exploiter :

• Un pirate envoie un e-mail depuis son propre domaine (qui passe SPF)
• Ils configurent l'adresse d'expéditeur visible pour qu'elle apparaisse comme votre domaine ou celle d'une personne de confiance
• SPF car le domaine d'origine est légitime
• Le destinataire voit toujours une identité falsifiée

SPF aucun mécanisme intégré permettant de vérifier que le domaine d'origine correspond bien à l'expéditeur affiché. DMARC résout ce problème en imposant l'alignement entre SPF ou le DKIM) et le domaine de l'en-tête « From ».

Limite n° 2 : SPF lors du transfert d'e-mails

SPF sur l'adresse IP du serveur expéditeur. Lorsqu'un e-mail est transféré :

• Le serveur de transfert devient la nouvelle source d'envoi
• Son adresse IP est comparée à SPF du domaine d'origine. Le serveur de redirection ne figurant pas parmi les expéditeurs autorisés, SPF .
• Comme il n'est pas répertorié, SPF

Cela se produit même lorsque l'e-mail est tout à fait légitime. Il ne s'agit pas d'une erreur de configuration, mais d'une limite inhérente au SPF .

Conséquences :

• Les e-mails transférés légitimes échouent souvent au test SPF
• Les systèmes de réception doivent s'appuyer sur d'autres signaux (tels que DKIM) pour valider le message

Limite n° 3 : SPF ne SPF pas en soi de mécanisme de signalement

SPF ne propose pas de fonctionnalité de création de rapports intégrée.

Sans couche supplémentaire :

• Vous ne savez pas quelles sources passent ou échouent au test SPF
• Vous ne pouvez pas détecter les expéditeurs non autorisés qui utilisent votre domaine
• Vous n'avez aucune visibilité sur les problèmes d'authentification qui affectent la délivrabilité

DMARC intègre une fonctionnalité de rapports qui vous fournit des données agrégées sur les résultats SPF DKIM pour l'ensemble des destinataires.

Les infrastructures de messagerie modernes, avec leurs fonctionnalités de transfert, leurs listes de diffusion, leurs expéditeurs tiers et leurs techniques sophistiquées d'usurpation d'identité, ont dépassé les SPF à lui seul. DKIM ajoute une signature cryptographique qui résiste au transfert, résolvant ainsi la plus grande faiblesse SPF. DMARC est la couche de politique qui relie SPF DKIM à l'en-tête « From ».

Pour une comparaison complète du fonctionnement conjoint de ces protocoles, consultez notre guide sur SPF DKIM et DMARC.

Erreurs courantes concernant SPF (et comment les corriger)

La plupart SPF se résument à quelques problèmes récurrents. Le problème tient principalement à un manque de maintenance et de validation. Voici comment les identifier et les résoudre grâce à des mesures concrètes.

Erreur n° 1 : présence de plusieurs SPF sur le même domaine.

SPF une seule politique faisant autorité. Si plusieurs enregistrements TXT commencent par v=spf1, les serveurs destinataires ne peuvent pas déterminer lequel évaluer. Il en résulte une erreur « PermError », ce qui signifie que SPF complètement pour chaque message.

Pourquoi cela se produit-il :

• Différentes équipes ajoutent des enregistrements de manière indépendante (marketing, informatique, outils d'assistance)
• Les nouveaux fournisseurs fournissent des instructions du type « ajoutez cet enregistrement » sans vérifier la configuration existante

Comment y remédier ?

• Vérifiez tous les enregistrements TXT de votre domaine
• Identifier toutes les entrées SPF
• Regrouper tous les mécanismes en un seul dossier complet

À surveiller :

• Des archives incomplètes laissées sur place après les migrations
• Des sous-domaines utilisés à tort à la place du domaine racine 

Erreur n° 2 : dépasser la limite de 10 requêtes DNS

Dès que SPF dépasse 10 requêtes DNS, elle s'arrête immédiatement et renvoie une erreur permanente (PermError). Cela invalide SPF tous les expéditeurs, même légitimes.

Pourquoi cela se produit-il :

• La surutilisation de comprend : pour plusieurs outils SaaS
• Inclusions imbriquées provenant de fournisseurs (vous les incluez, et celles-ci en incluent d'autres)
• Pas de visibilité sur le nombre cumulé de recherches

Comment y remédier ?

• Répertorier chaque mécanisme et son impact sur les requêtes
• Commencez par supprimer les inclusions inutilisées ou redondantes
• Réévaluez si chaque outil doit vraiment envoyer des e-mails depuis votre domaine

À surveiller :

• Recherches « cachées » dans les fichiers d'inclusion tiers
• Une évolution progressive au fil du temps, à mesure que de nouveaux outils sont ajoutés

Erreur n° 3 : Utiliser +all (transmettre tout)

Cela indique explicitement aux serveurs destinataires de faire confiance à toute source d'envoi, ce qui revient à désactiver SPF mesure de sécurité.

Pourquoi cela se produit-il :

• Interprétation erronée de SPF
• Les configurations de test temporaires n'ont jamais été rétablies

Comment y remédier ?

• Remplacer par ~tout lors de la validation de votre configuration
• Aller à -tous une fois que tous les expéditeurs légitimes ont été confirmés

À surveiller :

• Anciens documents copiés à partir de sources peu fiables
• Les domaines qui semblent « authentifiés » mais ne bénéficient d'aucune protection réelle

Erreur n° 4 : Utilisation du ptr obsolète

Des mécanismes tels que ptr introduisent des recherches lentes et peu fiables et peuvent être ignorés par les destinataires modernes, ce qui conduit à SPF incohérents.

Pourquoi cela se produit-il :

• Configurations héritées conservées au fil du temps
• Documentation ou modèles obsolètes

Comment y remédier ?

• Supprimer les mécanismes obsolètes tels que ptr
• Remplacer par : ou ip4: / ip6: entrées

À surveiller :

• Des enregistrements trop complexes conçus pour gérer les cas limites
• Des mécanismes qui ajoutent de la complexité sans apporter d'avantage évident

Erreur n° 5 : absence de sources d'envoi légitimes

Les e-mails provenant de plateformes valides échouent SPF, ce qui peut entraîner :

• Messages qui atterrissent dans le dossier spam
• Retards de livraison ou refus de livraison
• Échecs DMARC en l'absence de solution de secours compatible

Pourquoi cela se produit-il :

• Ajout de nouveaux outils sans mise à jour SPF
• Manque de coordination entre les équipes chargées de la gestion des systèmes de messagerie électronique

Comment y remédier ?

• Tenir à jour une liste centralisée de toutes les sources d'envoi approuvées
• Intégrer SPF dès le début du processus d'intégration, et non pas une fois que des problèmes sont apparus
• Vérifiez régulièrement que tous les expéditeurs actifs sont bien pris en compte

À surveiller :

• Les systèmes transactionnels (facturation, alertes) sont souvent négligés
• Outils régionaux ou spécifiques à une équipe envoyés de manière indépendante

Erreur n° 6 : SPF dépassant 255 caractères dans une seule chaîne DNS

SPF qui dépassent les limites du DNS ou qui sont mal formatés peuvent être tronqués ou mal interprétés, ce qui peut entraîner des échecs silencieux.

Pourquoi cela se produit-il :

• Trop d'inclusions et de mécanismes dans un seul enregistrement
• Les fournisseurs de services DNS traitent différemment les valeurs TXT longues

Comment y remédier ?

• Rédigez ce compte rendu de la manière la plus concise possible
• Si nécessaire, utilisez plusieurs chaînes entre guillemets au sein d'un même enregistrement TXT
• Vérifiez à nouveau l'enregistrement publié après l'avoir enregistré (et pas seulement les données saisies)

À surveiller :

• Des enregistrements qui semblent corrects dans votre panneau DNS mais qui ne se résolvent pas correctement
• Problèmes de mise en forme apparus lors des modifications manuelles

Effectuez un contrôle gratuit SPF pour vérifier si votre enregistrement contient l'une de ces erreurs

SPF pratiques SPF pour 2026

SPF correcte ne se résume pas à une simple question de syntaxe. Il s'agit de mettre en place une politique qui reste pertinente à mesure que votre infrastructure de messagerie évolue. Ces bonnes pratiques vous aideront à garantir que votre SPF reste fiable, efficace et conforme aux exigences actuelles imposées aux expéditeurs.

1. Ne conserver qu'un seul SPF par domaine

SPF qu'un seul enregistrement TXT commençant par v=spf1. La présence de plusieurs enregistrements provoque une erreur PermError, ce qui empêche toute authentification. Intégrez toujours les nouvelles entrées à votre enregistrement existant.

2. Veillez à inclure toutes les sources d'envoi légitimes

Votre SPF doit inclure tous les systèmes qui envoient des e-mails en votre nom. Si un expéditeur est omis, cela entraîne SPF , ce qui a un impact direct sur la délivrabilité et la conformité DMARC.

3. Ne pas dépasser la limite de 10 requêtes DNS

Parmi comprend :, un, mx, existe :, et redirect= compte dans la limite. Dépasser 10 entraîne une erreur permanente (PermError), invalidant SPF tous les e-mails. Vérifiez et optimisez régulièrement votre enregistrement.

4. Supprimez les fichiers d'inclusion inutilisés ou obsolètes

Les anciens outils, les environnements de test et les services obsolètes restent souvent présents dans SPF longtemps après avoir cessé d'envoyer des messages. Cela ajoute une complexité inutile et épuise le budget de recherche.

5. Préférez ip4 : et ip6 : pour une infrastructure contrôlée

Si vous gérez des adresses IP dédiées ou des plages d'envoi stables, utilisez des mécanismes d'IP directes plutôt que include :. Cela réduit les requêtes DNS et améliore les performances.

6. Évitez d'utiliser +all en aucune circonstance

Le qualificateur permet à n'importe quel serveur d'envoyer des e-mails au nom de votre domaine, ce qui rend SPF inefficace SPF mesure de sécurité. Il ne doit jamais être utilisé en production.

7. Utiliser ~tout lors de la configuration, puis passez à -all

Commencez par ~all (softfail) lors de la validation de votre configuration. Une fois que tous les expéditeurs légitimes ont été confirmés et mis en conformité avec DMARC, passez à -all (hardfail) pour une application stricte.

8. Évitez les mécanismes obsolètes ou risqués tels que ptr

Le mécanisme est obsolète et peu fiable. Il entraîne des recherches DNS inutiles et peut être ignoré par les récepteurs modernes. Utilisez plutôt des mécanismes explicites.

9. Surveiller SPF à l'aide des rapports DMARC

SPF pas à lui seul SPF une visibilité. Activez les rapports DMARC pour savoir quelles sources sont conformes ou non SPF tous les destinataires et pour identifier les activités non autorisées.

10. Considérer SPF un système faisant l'objet d'une gestion continue

SPF pas une opération ponctuelle. Chaque nouvel outil, chaque nouvelle plateforme ou chaque nouveau fournisseur qui envoie des e-mails doit être pris en compte dans votre SPF . Vérifiez-le et mettez-le à jour régulièrement afin d'éviter les échecs silencieux.

Comment SPF avec DKIM et DMARC

SPF, DKIM et DMARC sont conçus pour fonctionner comme un système coordonné. Chacun d'entre eux traite un aspect différent du problème de fiabilité des e-mails, notamment la légitimité de l'expéditeur, l'intégrité du message et la cohérence des identités ; ce n'est qu'ensemble qu'ils offrent une protection et une mise en œuvre fiables.

Lorsqu'un e-mail est reçu, l'authentification s'effectue en plusieurs étapes :

• SPF si l'adresse IP du serveur expéditeur est autorisée pour le domaine indiqué dans le champ Return-Path (expéditeur de l'enveloppe)
• Le protocole DKIM vérifie la signature cryptographique associée au message, confirmant ainsi qu'il n'a pas été altéré et que le domaine signataire est valide
• DMARC analyse les résultats des vérifications SPF DKIM et vérifie si l'un ou l'autre correspond à l'adresse « De » visible

SPF DKIM fournissent des résultats d'authentification bruts, mais c'est le protocole DMARC qui détermine si ces résultats sont pertinents au regard de ce que le destinataire perçoit réellement.

Vous avez besoin à la fois de SPF DKIM, car chacun compense les faiblesses de l'autre. SPF en cas de transfert de message. DKIM, lui, continue de fonctionner. DKIM peut être supprimé par certains intermédiaires, tandis que SPF dépend SPF du contenu du message. Ensemble, ils offrent une redondance.

DMARC ajoute une couche de politique : que doivent faire les destinataires lorsque ni SPF DKIM ne permettent de vérifier la conformité ? Les trois options sont les suivantes aucune (surveillance uniquement), quarantine (envoyer vers le dossier spam) et refus (bloquer complètement). DMARC ajoute également des rapports – sans cela, vous ne savez jamais quand l'authentification échoue.

Conclusion

SPF la pierre angulaire de l'authentification des e-mails, mais son efficacité dépend entièrement de sa configuration et de l'utilité du cadre DMARC auquel il s'intègre. Un SPF mal configuré perturbe la distribution des e-mails, expose votre domaine à l'usurpation d'identité et met votre organisation en situation de non-conformité avec les exigences actuelles applicables aux expéditeurs.

Que vous configuriez SPF la première fois ou que vous cherchiez à résoudre un problème lié à un enregistrement défectueux, la prochaine étape est la même : vérifiez votre configuration actuelle.

Vérifiez la configuration de l'authentification des e-mails de votre domaine grâce à notre outil gratuit Domain Analyzer . Il évalue SPF, DKIM, DMARC et bien d'autres en quelques secondes. Vous avez besoin d'une surveillance continue, SPF automatisée SPF et de rapports DMARC ? 

Commencez un essai gratuit de 15 jours

Foire aux questions

Un domaine peut-il avoir plusieurs SPF ?

Non. La RFC 7208 exige exactement un SPF par domaine. Si deux enregistrements TXT commençant par v=spf1 , les deux renvoient une erreur « PermError » et SPF complètement. Regroupez toutes les sources autorisées en un seul enregistrement.

Qu'est-ce que cela signifie si mon domaine génère trop de requêtes DNS ?

Votre SPF dépasse la limite de 10 requêtes DNS fixée par la RFC 7208. Cela provoque SPF , qui empêche SPF pour tous les e-mails, et pas seulement pour ceux qui dépassent cette limite. Réduisez le nombre d'inclusions et remplacez par ip4:/ip6:, ou utilisez SPF ou des macros pour rester en dessous de la limite.

Quelle est la différence entre SPF » (~all) et « hardfail » (-all) SPF ?

Softfail (~all) indique aux destinataires d'accepter l'e-mail mais de le marquer comme suspect. Hardfail (-all) indique aux destinataires de rejeter purement et simplement l'e-mail. Utilisez softfail lors de la configuration initiale et des tests ; passez à hardfail une fois que tous les expéditeurs légitimes ont été confirmés et que DMARC est en place.

SPF l'usurpation d'adresse e-mail ?

Pas en soi. SPF l'expéditeur de l'enveloppe (Return-Path), et non l'en-tête « From » que voient les destinataires. Un pirate peut passer SPF usurpant l'adresse « From » visible. Il faut recourir au DMARC – qui vérifie la cohérence entre les résultats SPF et l'en-tête « From » – pour empêcher l'usurpation du nom d'affichage.

Que se passe-t-il en cas de SPF ?

Cela dépend du SPF et de la configuration de DMARC. Avec -all et une politique DMARC de rejet, l'e-mail est bloqué. Avec ~all et en l'absence de DMARC, l'e-mail peut tout de même être remis, mais il sera signalé comme suspect. En l'absence SPF , les destinataires ne disposent d'aucun SPF à évaluer.

Comment puis-je vérifier mon SPF ?

Utilisez un outilSPF . Saisissez votre domaine, et l'outil récupère votre SPF depuis le DNS, valide la syntaxe, compte les requêtes DNS et signale toute erreur, y compris les violations de type PermError et les requêtes nulles.

Ai-je besoin SPF j'utilise déjà DKIM et DMARC ?

Oui. Pour que l'alignement DMARC soit validé, il faut qu'au moins l'un des protocoles SPF DKIM soit validé. Bien que DKIM puisse à lui seul satisfaire aux exigences DMARC, le fait de disposer à la fois de SPF de DKIM offre une redondance. Si l'un des deux échoue (par exemple, SPF lors d'un transfert), l'autre peut tout de même permettre de valider l'alignement DMARC.

Qu'est-ce que l'alignement SPF ?

SPF signifie que le domaine figurant dans le champ Return-Path (expéditeur de l'enveloppe) correspond au domaine indiqué dans l'en-tête From. DMARC vérifie cet alignement. En son absence, SPF être réussi, mais DMARC échouera tout de même – ce qui est le cas pour de nombreux expéditeurs tiers, à moins qu'ils ne soient configurés pour utiliser votre domaine dans le champ Return-Path.

À quelle fréquence dois-je mettre à jour mon SPF ?

Vérifiez votre SPF chaque fois que vous ajoutez ou supprimez un service d'envoi, et procédez à un audit au moins une fois par trimestre. SPF deviennent obsolètes à mesure que les fournisseurs modifient leurs plages d'adresses IP et que l'infrastructure d'envoi de votre organisation évolue. Un SPF qui était valide il y a six mois peut aujourd'hui être erroné ou incomplet.

Qu'est-ce que SPF ?

SPF résout tous les : en adresses IP brutes, ce qui réduit le nombre de requêtes DNS. Cela vous permet de rester en dessous de la limite de 10 requêtes, mais crée un enregistrement statique qui doit être mis à jour chaque fois qu'un fournisseur modifie ses adresses IP. Des alternatives modernes telles que SPF permettent de conserver un enregistrement dynamique tout en restant en dessous de la limite.

• À propos de
• Derniers messages

Ahona Rudra

Expert en sécurité des domaines et des courriels 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)

• SPF Avanan : comment configurer, corriger et optimiser votre SPF Check Point Harmony Email - 7 mai 2026
• SPF DNS : comment ça marche et comment le configurer - 6 mai 2026
• Qu'est-ce que v=spf1 ? À quoi cela sert-il ? - 5 mai 2026