Vérificateur et générateur d'enregistrement SPF

Comment vérifier un enregistrement SPF

1. Saisissez un nom de domaine dans le champ ci-dessus. Une adresse e-mail complète fonctionne aussi : l'outil extrait automatiquement le domaine.
2. Cliquez sur Vérifier l'enregistrement SPF. L'outil interroge les serveurs DNS publics faisant autorité, exactement comme le ferait un serveur de messagerie récepteur.
3. Consultez d'abord le résumé global : il indique si l'enregistrement est valide, s'il comporte des avertissements ou s'il est rompu.
4. Examinez ensuite la liste des alertes et avertissements éventuels. Chaque point explique précisément quelle modification apporter.
5. En dessous, chaque terme de l'enregistrement est expliqué avec son coût en requêtes DNS. Dépliez les directives include pour voir ce que chaque service délègue.

L'URL de la page conserve votre recherche. Vous pouvez partager ce lien direct avec un collègue ou le support de votre hébergeur. Notez une limite : un serveur récepteur évalue le SPF en fonction de l'adresse IP du serveur expéditeur. Cet outil n'ayant pas de message sous la main, il valide la syntaxe et la conformité DNS de l'enregistrement. Il ne peut pas exécuter les macros dynamiques dépendant de l'IP du client.

Qu'est-ce qu'un enregistrement SPF ?

Un enregistrement SPF est un enregistrement TXT publié dans la zone DNS d'un domaine. Il spécifie quels serveurs de messagerie sont autorisés à envoyer des e-mails au nom de ce domaine. SPF signifie Sender Policy Framework et ses spécifications sont régies par la RFC 7208. Un domaine utilisant Google Workspace dispose généralement d'un enregistrement comme celui-ci :

v=spf1 include:_spf.google.com ~all

v=spf1 identifie le début de l'enregistrement SPF. include:_spf.google.com autorise l'ensemble des serveurs gérés par Google. ~all indique aux serveurs récepteurs de marquer comme suspect tout e-mail provenant d'un serveur non listé.

Lorsqu'un message arrive, le serveur récepteur extrait le domaine de l'adresse de retour technique (le Return-Path ou enveloppe). Il consulte l'enregistrement SPF de ce domaine et vérifie si l'adresse IP émettrice y figure. Le SPF ne vérifie pas l'adresse d'expéditeur visible (From) affichée dans le client de messagerie. C'est pourquoi le SPF travaille conjointement avec DKIM et DMARC. Pour comprendre leur fonctionnement combiné, consultez SPF, DKIM et DMARC expliqués.

Depuis février 2024, Gmail exige SPF ou DKIM pour tous les expéditeurs, et les deux pour les expéditeurs en masse. Yahoo applique des exigences identiques.

Que signifie chaque terme d'un enregistrement SPF

Un enregistrement SPF est une séquence de mécanismes et de modificateurs séparés par des espaces. Les serveurs récepteurs lisent de gauche à droite et s'arrêtent au premier terme correspondant à l'IP d'envoi.

Tout mécanisme peut être précédé d'un qualificateur qui détermine le résultat de l'évaluation en cas de correspondance. + signifie Pass (réussite) et constitue la valeur par défaut implicite. - signifie Fail (échec strict), ~ signifie Softfail (échec partiel) et ? signifie Neutral (neutre). Ainsi, le mot all peut conclure un enregistrement sous la forme -all, ~all ou ?all.

Les mécanismes sont insensibles à la casse : Include: fonctionne de la même manière que include:. La RFC 7208 recommande de clore tout enregistrement par un mécanisme all ou un modificateur redirect. Sans conclusion explicite, les serveurs non listés reçoivent un résultat Neutral.

La limite stricte des 10 requêtes DNS

Chaque terme include, a, mx, ptr, exists et redirect force le serveur récepteur à effectuer une requête de résolution DNS. La RFC 7208 plafonne ce total à 10 requêtes par évaluation. Les requêtes effectuées à l'intérieur des include comptent également, de sorte qu'un seul include peut engendrer plusieurs requêtes. ip4, ip6 et all ne consomment aucune requête. Si un enregistrement dépasse 10 requêtes, les serveurs récepteurs arrêtent l'évaluation et renvoient un Permerror : le contrôle SPF échoue.

Atteindre cette limite arrive vite. Nous avons mesuré dans le DNS public le coût des includes courants : Google Workspace consomme 1 requête, Microsoft 365 consomme 1 requête, Salesforce en consomme 2, Mailgun en consomme 5 et Freshdesk 7. Une entreprise sur Google Workspace qui associe Mailgun et Freshdesk atteint déjà 13 requêtes. Une étude de 2024 sur les enregistrements SPF couvrant .com, .net, .org et .se a révélé que 6,5 % des domaines dépassaient les 10 requêtes, et les enregistrements de seulement deux hébergeurs étaient responsables de 83,7 % de ces dépassements.

Ces coûts évoluent également dans le temps. L'include de Google coûtait 4 requêtes jusqu'en décembre 2025, date à laquelle Google a remplacé ses includes imbriqués par une liste plate. De nombreux tutoriels et générateurs SPF indiquent encore l'ancien chiffre de 4. L'outil ci-dessus interroge le DNS en temps réel pour mesurer le coût exact.

Dépasser la limite ne fait pas nécessairement échouer tous les messages de façon uniforme. Comme l'explique Microsoft, les serveurs récepteurs évaluent les termes de gauche à droite et s'arrêtent dès la première correspondance. Les e-mails envoyés par un service listé en premier peuvent réussir, tandis que ceux d'un service listé plus loin échouent. Cette disparité rend les pannes difficiles à diagnostiquer si l'on ne compte pas l'intégralité des requêtes de l'arbre SPF.

Il existe une seconde limite : les requêtes infructueuses (void lookups), par exemple un include pointant vers un domaine supprimé ou introuvable. La RFC 7208 stipule que les serveurs doivent abandonner l'évaluation après 2 requêtes vides successives.

Comment rester sous la limite des 10 requêtes DNS

1. Supprimez les includes des services et outils marketing que vous n'utilisez plus.
2. Supprimez les includes que vos prestataires n'exigent plus. Mailchimp, Postmark, Brevo et Klaviyo ne requièrent plus d'include sur votre domaine racine. SendGrid et Amazon SES délèguent leur envoi via un sous-domaine dédié. Consultez la liste détaillée ci-dessous.
3. Déclarez vos propres serveurs de messagerie avec ip4 et ip6 au lieu de a ou mx. La RFC 7208 préconise cet ordre, et les adresses IP brutes ne consomment aucune requête DNS.
4. Envoyez vos e-mails transactionnels ou marketing depuis un sous-domaine dédié, comme newsletter.exemple.fr. Chaque sous-domaine possède son propre enregistrement et dispose de son propre quota de 10 requêtes.

Certains prestataires proposent le « SPF flattening », qui remplace les includes par la liste des adresses IP directes. Cela réduit les requêtes DNS, mais lorsque les fournisseurs modifient leurs plages IP, votre enregistrement statique devient obsolète. Microsoft déconseille le flattening pour les services dont les adresses changent fréquemment et demande une révision trimestrielle minimale si vous y recourez.

Includes SPF pour Google Workspace, Microsoft 365 et autres services

Voici les valeurs include recommandées dans la documentation officielle de chaque service, avec leur coût en requêtes DNS mesuré sur le DNS public le 12 octobre 2026. Vérifiez toujours la documentation de votre compte, car certains services attribuent des sous-domaines régionaux spécifiques.

HubSpot génère un include unique par portail client sous la forme [id].hubspotemail.net. Récupérez votre valeur exacte dans les paramètres de votre compte HubSpot. Il consomme 1 requête DNS.

Services ne nécessitant généralement aucun include SPF

Le contrôle SPF s'effectue sur le domaine de l'adresse de retour d'enveloppe (Return-Path), et non sur l'en-tête From visible. La plupart des plateformes d'envoi actuelles utilisent leur propre domaine de retour ou un sous-domaine CNAME dédié. Ajouter un include sur votre domaine apex ne fait que consommer inutilement vos requêtes DNS.

• Mailchimp. Mailchimp n’utilise plus d’include SPF sur le domaine racine et s’appuie sur DKIM et DMARC.
• Postmark. Postmark gère les retours via son propre domaine de Return-Path.
• Brevo. Brevo n’exige aucun enregistrement SPF sauf si vous disposez d’une IP dédiée.
• Klaviyo. Klaviyo utilise son infrastructure d’envoi sans requérir d’include racine.
• SendGrid. SendGrid isole le SPF sur un sous-domaine dédié généré lors de la validation.
• Amazon SES. SES utilise son propre domaine d’envoi sauf en cas de Return-Path personnalisé.

L'outil ci-dessus met en évidence ces includes superflus s'il en détecte dans votre enregistrement.

Comment créer un enregistrement SPF

Basculez sur l'onglet Créer ci-dessus pour utiliser le générateur SPF interactif. Cochez les services qui envoient des e-mails pour votre domaine, et l'outil compose automatiquement la syntaxe tout en surveillant le compteur de requêtes DNS. Si votre domaine possède déjà un enregistrement, chargez-le d'abord pour l'ajuster sans écraser vos réglages. Voici les étapes recommandées :

1. Recensez tous les services habilités à émettre des e-mails pour votre domaine : serveurs internes, suite bureautique, CRM, plateforme d'assistance, outil de facturation et formulaires de contact. Vos rapports DMARC permettent d'identifier les flux d'envoi oubliés.
2. Récupérez la valeur include de chaque prestataire dans sa documentation ou sélectionnez-le directement dans notre outil. Pour vos serveurs dédiés, privilégiez leurs adresses IP.
3. Sélectionnez la terminaison appropriée : ~all ou -all. La section suivante détaille leurs implications respectives.
4. Publiez l'entrée comme un enregistrement TXT unique sur le nom d'hôte racine de votre zone DNS (souvent représenté par @). Si un enregistrement commençant par v=spf1 existe déjà, modifiez-le sans créer de seconde entrée.
5. Patientez quelques minutes pour la propagation DNS, puis lancez une vérification avec cet outil pour confirmer la validité du résultat.

Chaque sous-domaine émetteur requiert son propre enregistrement, car les sous-domaines n'héritent pas du SPF de leur domaine parent. Un domaine ou sous-domaine qui n'envoie jamais de courrier électronique doit impérativement être protégé avec : v=spf1 -all. La RFC 7208 qualifie cela de bonne pratique reconnue pour empêcher toute usurpation d'identité. Le NCSC britannique recommande d'y adjoindre une politique DMARC p=reject et un enregistrement MX nul (Null MX).

Un enregistrement dépassant 255 caractères doit être découpé en plusieurs chaînes entre guillemets au sein du même enregistrement TXT. Les serveurs récepteurs concatènent ces chaînes sans ajouter d'espace : assurez-vous d'inclure les espaces de séparation à l'intérieur des segments. Vérifiez les directives de votre hébergeur DNS pour les chaînes longues.

~all ou -all : quelle terminaison choisir

Les principaux fournisseurs de messagerie et comités d'experts ont des recommandations différentes :

• Google recommande ~all (Softfail).
• Le M3AAWG, consortium regroupant les grands acteurs du courrier électronique, préconise la terminaison en ~all afin d'éviter le rejet brutal des messages avant le traitement de la politique DMARC.
• Microsoft recommande -all (Fail strict), à condition que DKIM et DMARC soient intégralement configurés.

Le principal inconvénient de -all réside dans le fait que certains serveurs récepteurs rejettent immédiatement le message lors de la connexion SMTP initiale, avant même d'avoir évalué la politique DMARC. La RFC 9989, norme DMARC de 2026, souligne que ces messages rejetés prématurément ne génèrent aucun rapport DMARC, ce qui complique grandement le dépannage de vos envois légitimes.

En pratique, ~all s'avère le choix le plus sûr pour les domaines actifs, en particulier pendant la phase de recensement de vos flux d'envoi. Si votre domaine est protégé par une règle DMARC quarantine ou reject, c'est DMARC qui déterminera le sort du message. Réservez -all aux domaines purement défensifs qui n'émettent jamais d'e-mails. N'utilisez jamais +all (qui autorise tout le web) et évitez ?all (équivalent à une absence totale de politique).

Signification des diagnostics du vérificateur SPF

Les serveurs de messagerie récepteurs appliquent une terminologie normalisée pour qualifier le résultat d'un contrôle SPF. Ces résultats figurent dans les en-têtes Authentication-Results et dans les rapports DMARC agrégés :

Erreurs courantes sur les enregistrements SPF et solutions

Une analyse de 12 millions de domaines populaires réalisée en 2023 a constaté que 56,5 % publiaient un enregistrement SPF, et que 2,9 % d'entre eux contenaient des erreurs bloquantes. L'anomalie la plus répandue était un include ou redirect pointant vers un domaine dépourvu de SPF, suivi de près par le dépassement du quota de requêtes DNS.

Deux enregistrements SPF sur le même domaine

Cette erreur survient généralement lorsqu’un nouveau service demande d’ajouter un enregistrement TXT et qu’une seconde ligne est créée au lieu de modifier la première. Publier plusieurs entrées SPF entraîne automatiquement un Permerror. Fusionnez l’ensemble des mécanismes dans une seule entrée commençant par v=spf1 et finissant par un unique all.

Include pointant vers un domaine invalide ou vide

Si une directive include cible un domaine ne publiant aucun enregistrement SPF valide, l’ensemble de votre politique SPF échoue avec une erreur Permerror. Cela provient généralement d’une faute de frappe ou d’un service résilié. Supprimez l’include obsolète ou rectifiez sa valeur.

+all, ?all ou omission de la conclusion all

+all autorise l’intégralité des serveurs d’Internet et détruit toute sécurité. ?all ou l’absence de clause finale renvoie un statut Neutral traité comme une absence de protection. Terminez toujours votre politique par ~all ou -all.

Présence du mécanisme ptr

La RFC 7208 déconseille formellement le mécanisme ptr. Lourd en ressources, il consomme une requête DNS et souffre de défaillances fréquentes lors de résolutions DNS lentes. Remplacez-le par des directives ip4 et ip6 explicites.

Erreurs de syntaxe et de ponctuation

Un espace inséré après les deux-points, un bloc IPv4 incomplet ou un terme inconnu déclenchent un Permerror immédiat. Une erreur plus insidieuse, include=example.com (avec un signe égal au lieu de deux-points), est ignorée comme modificateur inconnu : le service visé n’est alors jamais autorisé. Notre vérificateur détecte chacune de ces anomalies.

Trois idées reçues fréquentes sur le SPF

• « Un enregistrement SPF ne doit jamais comporter de majuscules. » La RFC 7208 précise expressément que les noms et mécanismes sont insensibles à la casse.
• « Un enregistrement SPF ne peut pas dépasser 255 caractères. » La limite de 255 caractères s’applique à chaque chaîne individuelle dans l’enregistrement DNS TXT. Un enregistrement plus long est simplement fragmenté en plusieurs chaînes concaténées.
• « On peut déclarer jusqu’à 10 directives include. » La limite s’applique au nombre total de requêtes DNS récursives, et non au nombre littéral de termes include déclarés.

Le SPF au sein de la chaîne d'authentification des e-mails

Un statut SPF pass ne garantit pas à lui seul une sécurité totale. Selon l'étude de 2023 précitée, 34,7 % des domaines autorisent indirectement plus de 100 000 adresses IP distinctes. De plus, le SPF échoue presque systématiquement lors du transfert automatique d'e-mails, l'IP du serveur relais n'étant pas répertoriée dans votre enregistrement.

DKIM résout cette limite en apposant une signature cryptographique sur le contenu du message, préservée lors des transferts. DMARC fait la synthèse en vérifiant la conformité du domaine visible (From) avec SPF ou DKIM, et ordonne aux serveurs destinataires la conduite à tenir en cas d'échec. Configurez ces défenses complémentaires grâce à notre générateur de DKIM et notre générateur de DMARC. Utilisez notre recherche MX pour identifier vos serveurs de réception.

Aucun protocole d'authentification ne protège toutefois contre les adresses destinataires invalides ou inexistantes. Celles-ci génèrent des rebonds qui dégradent votre réputation d'expéditeur. Nettoyez vos adresses avec notre vérificateur d'e-mail ou traitez vos listes complètes via notre vérificateur d'e-mails en masse. Pour partager une synthèse claire avec vos équipes, consultez la définition de l'enregistrement SPF dans le glossaire.