Outil gratuit

Générateur SPF

Cochez les services qui envoient des emails avec votre domaine, ajoutez vos serveurs et obtenez un enregistrement SPF prêt à publier, avec le nombre de requêtes DNS estimé.

  • Gratuit, sans inscription
  • Aperçu instantané
  • Lecture DNS : 5 par jour

Sert au nom d'hôte et à lire l'enregistrement publié. La lecture compte dans la limite de 5 analyses gratuites par jour.

Services qui envoient vos emails

Valeurs usuelles, à vérifier dans la documentation de chaque fournisseur : elles peuvent changer ou dépendre de votre offre.

Un domaine par ligne, fourni par votre CRM, outil de facturation ou hébergeur.

IPv4 ou IPv6, avec ou sans préfixe (/24, /32…). Une par ligne. Ne consomme aucune requête DNS.

Serveurs du domaine

Utile si votre serveur web ou votre serveur de réception envoie aussi des emails (formulaires, notifications).

Politique finale

Votre enregistrement

Type
TXT
Nom d'hôte
@

Racine du domaine : laissez le nom vide ou saisissez @ selon votre interface DNS.

Valeur

v=spf1 ~all
À vérifier avant publication
Enregistrement généré automatiquement, à titre indicatif. Nous ne pouvons pas garantir qu'il convient à votre configuration : vérifiez-le avec votre fournisseur de messagerie ou votre prestataire avant de le publier. Une erreur peut empêcher la délivrance de vos emails.

Requêtes DNS estimées 0 / 10 11 caractères

Chaque include, mx, a ou redirect compte pour une requête, limitée à 10 au total. Les include de vos fournisseurs en ajoutent souvent d'autres, non comptés ici.

Aucun expéditeur autorisé : tout email envoyé avec ce domaine échouera au contrôle SPF. Cochez vos services d'envoi.

Surveillez votre SPF et votre DMARC : alerte dès qu'ils changent

Un enregistrement modifié ou supprimé par erreur peut bloquer vos emails. Domains Defender surveille vos enregistrements DNS et vous prévient. Gratuit pour un domaine.

Guide · Mis à jour le

Enregistrement SPF : le guide pratique

Ce que fait SPF, et ce qu'il ne fait pas

SPF (Sender Policy Framework) est un enregistrement DNS de type TXT qui liste les serveurs autorisés à envoyer des emails pour un domaine. Quand un message arrive, le serveur destinataire regarde l'adresse de l'expéditeur d'enveloppe (le Return-Path, transmis lors de la commande SMTP MAIL FROM), récupère le SPF de ce domaine et vérifie que l'adresse IP du serveur émetteur y figure.

SPF ne vérifie pas l'adresse affichée dans le champ From, celle que lit le destinataire. Un fraudeur peut donc utiliser son propre domaine d'enveloppe, passer SPF, et afficher votre adresse. SPF casse aussi lors d'un transfert automatique, car le serveur qui retransmet n'est pas dans votre liste. C'est pour combler ces limites qu'existe DMARC : il exige que le domaine visible soit aligné avec SPF ou avec DKIM, la signature cryptographique des emails.

La syntaxe, mécanisme par mécanisme

Un enregistrement SPF est une ligne de termes séparés par des espaces, lue de gauche à droite. Le premier terme qui correspond à l'IP du serveur émetteur donne le résultat.

  • v=spf1 : obligatoire, toujours en premier. Il identifie l'enregistrement comme un SPF.
  • include:domaine : autorise les serveurs listés dans le SPF d'un autre domaine, typiquement celui de votre fournisseur (include:_spf.google.com). Chaque include coûte au moins une requête DNS.
  • ip4: et ip6: : autorisent une adresse ou une plage (ip4:203.0.113.0/24). Aucune requête DNS.
  • a : autorise les adresses IP du domaine lui-même, utile si votre serveur web envoie des emails.
  • mx : autorise les serveurs de réception du domaine (enregistrements MX), utile s'ils envoient aussi.
  • redirect=domaine : délègue toute la politique au SPF d'un autre domaine. Il n'est utilisé que si aucun autre terme ne correspond, et il est ignoré si l'enregistrement contient un mécanisme all.
  • all : correspond à tout le reste, et se place en dernier. Son qualificatif fixe le sort des serveurs non listés : -all échec (fail), ~all échec souple (softfail), ?all neutre, qui ne protège pratiquement pas. +all autorise tout le monde et est à proscrire.

La limite de 10 requêtes DNS

Pour éviter les abus, la norme (RFC 7208) plafonne à 10 le nombre de termes qui déclenchent une requête DNS pendant l'évaluation : include, a, mx, ptr, exists et redirect. Les requêtes faites par les include imbriqués comptent aussi : le SPF d'un fournisseur peut lui-même en contenir plusieurs. Au-delà de 10, le résultat est permerror, une erreur permanente que beaucoup de messageries traitent comme un échec. Le générateur ci-dessus compte les requêtes de votre enregistrement ; vérifiez le total réel, include compris, avec l'outil Sécurité Email.

Pour réduire le compte : retirez les services que vous n'utilisez plus, remplacez a ou mx par les adresses IP concernées, et déplacez les envois marketing sur un sous-domaine (par exemple news.exemple.fr) doté de son propre SPF.

L'« aplatissement » (SPF flattening) consiste à remplacer les include par la liste des IP qu'ils contiennent. C'est risqué : les fournisseurs changent leurs adresses sans prévenir, et un enregistrement aplati devenu obsolète fait échouer vos emails légitimes. Si vous y recourez, faites-le avec un outil qui le met à jour automatiquement.

Un seul SPF par domaine

Un nom de domaine ne doit publier qu'un seul enregistrement TXT commençant par v=spf1. Deux enregistrements donnent aussi permerror. C'est une erreur fréquente lorsqu'un nouveau service demande « d'ajouter son SPF » : il faut fusionner. Par exemple, v=spf1 include:_spf.google.com ~all et v=spf1 include:spf.brevo.com ~all deviennent v=spf1 include:_spf.google.com include:spf.brevo.com ~all, avec un seul v=spf1 et un seul all à la fin.

Le SPF ne s'hérite pas : un sous-domaine qui envoie des emails a besoin de son propre enregistrement.

Où publier l'enregistrement

  1. Ouvrez l'éditeur de zone DNS du domaine, chez votre registrar ou votre hébergeur DNS (OVHcloud, Cloudflare, Gandi…). Si vos serveurs DNS sont ailleurs que chez le registrar, c'est là qu'il faut agir.
  2. Cherchez un enregistrement TXT existant commençant par v=spf1. S'il existe, modifiez-le au lieu d'en créer un nouveau.
  3. Sinon, ajoutez un enregistrement de type TXT sur la racine du domaine : nom vide ou @ selon l'interface. N'utilisez pas le type « SPF », obsolète.
  4. Collez la valeur générée, sans ajouter de guillemets si l'interface les gère elle-même, puis enregistrez.
  5. Patientez : une modification est prise en compte quand l'ancienne valeur expire des caches, selon le TTL.

Vérifier après publication

Relancez l'outil Sécurité Email sur votre domaine : il affiche le SPF publié, le nombre de requêtes et les éventuels problèmes. Envoyez ensuite un email vers une boîte externe et affichez le message original. Cherchez l'en-tête Received-SPF: pass ou la mention spf=pass dans Authentication-Results. Un softfail ou un fail indique qu'un serveur d'envoi manque à la liste.

Erreurs fréquentes

  • Oublier un expéditeur : CRM, facturation, formulaire du site, outil de support, newsletter.
  • Publier un second enregistrement SPF au lieu de fusionner.
  • Utiliser +all ou ?all, qui n'apportent aucune protection.
  • Faire une faute de frappe dans un include (_spf.gogle.com) : le domaine n'existe pas et la vérification échoue.
  • Laisser des espaces en trop, des guillemets doublés ou un all au milieu de la ligne : tout ce qui suit all est ignoré.

Exemples

Les valeurs ci-dessous sont des valeurs usuelles : confirmez-les dans la documentation de chaque fournisseur, certains services d'envoi utilisant leur propre domaine d'enveloppe sans include de votre côté.

Google Workspace seul

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

Microsoft 365 et Brevo pour les newsletters

v=spf1 include:spf.protection.outlook.com include:spf.brevo.com ~all

Votre propre serveur et la messagerie OVH

v=spf1 ip4:203.0.113.10 include:mx.ovh.com ~all

Domaine qui n'envoie aucun email

v=spf1 -all

Ces exemples et l'enregistrement généré sont fournis à titre indicatif. Vérifiez-les avec votre fournisseur de messagerie ou votre prestataire avant de les publier : une erreur peut empêcher la délivrance de vos emails.

FAQ

Questions fréquentes

Faut-il choisir ~all ou -all ?

Commencez par ~all (échec souple) : un expéditeur oublié est signalé sans que ses emails soient rejetés d'office. Une fois tous vos services d'envoi listés et vos rapports DMARC sans échec légitime, vous pouvez passer à -all. Avec DMARC en place, ~all suffit souvent, car c'est la politique DMARC qui décide du sort des emails.

Pourquoi le SPF est-il limité à 10 requêtes DNS ?

La norme SPF (RFC 7208) limite à 10 les mécanismes et modificateurs qui déclenchent une requête DNS : include, a, mx, ptr, exists et redirect. Les include de vos fournisseurs en contiennent souvent d'autres, qui comptent aussi. Au-delà, le résultat est permerror et vos emails peuvent échouer à l'authentification.

Peut-on publier plusieurs enregistrements SPF ?

Non. Un nom de domaine ne doit publier qu'un seul enregistrement TXT commençant par v=spf1. S'il en existe deux, le résultat est permerror. Pour ajouter un service, insérez son include dans l'enregistrement existant, avant le mécanisme all.

Le SPF protège-t-il l'adresse affichée dans l'email ?

Pas directement. SPF vérifie le domaine de l'expéditeur d'enveloppe (Return-Path), que le destinataire ne voit généralement pas. L'adresse visible (From) peut être différente. C'est DMARC qui exige que ce domaine visible soit aligné avec SPF ou DKIM.

Faut-il un SPF sur un domaine qui n'envoie pas d'emails ?

Oui, c'est recommandé. Publiez v=spf1 -all pour indiquer qu'aucun serveur n'est autorisé, et complétez avec un DMARC en p=reject. Les domaines inactifs sont souvent utilisés pour l'usurpation justement parce qu'ils ne sont pas protégés.

Combien de temps faut-il pour que le SPF soit pris en compte ?

Un nouvel enregistrement est généralement visible en quelques minutes. Une modification dépend du TTL de l'ancien enregistrement : tant que ce délai n'est pas écoulé, certains serveurs utilisent encore l'ancienne version en cache.

L'enregistrement généré est-il garanti ?

Non. Le résultat est fourni à titre indicatif, à partir de vos réponses et de valeurs usuelles de fournisseurs qui peuvent changer. Vérifiez-le avec votre fournisseur de messagerie ou votre prestataire avant de le publier : une erreur peut empêcher la délivrance de vos emails.