Choisissez les services qui envoient des e-mails pour votre domaine et obtenez un enregistrement SPF valide avec le nombre réel de requêtes DNS. Chargez l’enregistrement publié aujourd’hui, fusionnez-le avec le nouveau et vérifiez-le sur le DNS en direct. Gratuit, sans inscription.
Un enregistrement SPF est un enregistrement TXT dans le DNS d’un domaine qui liste les serveurs de messagerie autorisés à envoyer des e-mails pour ce domaine. Les serveurs destinataires comparent le serveur expéditeur à cette liste et traitent les messages de tous les autres comme suspects, ou les refusent. SPF est défini par la RFC 7208 et commence toujours par v=spf1.
Le générateur de cette page construit l’enregistrement à partir des services que vous utilisez réellement, compte les requêtes DNS qu’il provoque et vous avertit avant qu’il ne dépasse la limite de dix. C’est la raison la plus fréquente pour laquelle un enregistrement SPF qui semble correct ne fonctionne pas du tout.
1. Indiquez au générateur qui envoie vos e-mails. Cochez votre fournisseur de messagerie, votre outil de newsletter et tout autre service qui envoie avec votre domaine dans l’adresse d’expéditeur : la boutique, le service d’assistance, le CRM, le logiciel de facturation. Si votre propre serveur envoie des e-mails, cochez mx ou saisissez son adresse dans le champ IPv4.
2. Publiez un seul enregistrement TXT. Copiez la valeur dans le DNS de votre domaine, en enregistrement TXT sur le domaine lui-même. Si un enregistrement commençant par v=spf1 existe déjà, remplacez-le. N’en ajoutez pas un second : deux enregistrements SPF constituent une erreur, et les destinataires ignorent alors complètement SPF.
3. Vérifiez-le. « Vérifier avec le DNS en temps réel » résout chaque include du nouvel enregistrement et compte les requêtes comme le fait un destinataire. Après la publication, l’Email Security Check lit SPF avec DKIM et DMARC et montre si les trois concordent.
Vous avez déjà un enregistrement ? Saisissez votre domaine en haut et cliquez sur « Charger l’enregistrement publié ». Le générateur lit ce que vous publiez aujourd’hui, coche les services qu’il reconnaît et conserve tout le reste. Vous complétez ainsi l’enregistrement au lieu de repartir de zéro et de perdre un expéditeur dont plus personne ne se souvenait.
Chaque interface DNS demande les trois mêmes choses : un type, un nom et une valeur. Seul le champ du nom diffère, car les interfaces n’écrivent pas « le domaine lui-même » de la même manière.
| Ce que montre votre interface | Ce qu’il faut saisir comme nom | Par exemple chez |
|---|---|---|
| Un champ « Nom » ou « Hôte » | @ |
Cloudflare, IONOS, GoDaddy, Namecheap |
| Un champ nom suivi du domaine déjà affiché | laisser vide | Plesk, AWS Route 53, de nombreux panneaux d’hébergement |
| Un champ qui exige le nom complet | example.com. avec le point final |
éditeurs de type BIND, certains registraires |
| Un fichier de zone | example.com. 3600 IN TXT "v=spf1 ..." |
votre propre serveur de noms |
Le type est toujours TXT. L’ancien type SPF (type 99) a été abandonné en 2014 et les destinataires l’ignorent ; si votre interface le propose encore, ne l’utilisez pas. Le TTL peut rester à sa valeur par défaut. Saisissez la valeur sans guillemets, sauf si l’interface les demande. Si elle découpe une valeur longue en plusieurs chaînes entre guillemets, ce n’est pas un problème : les destinataires les recollent sans espace.
Pour évaluer un enregistrement SPF, un destinataire peut effectuer au maximum dix requêtes DNS (RFC 7208, section 4.6.4). Il compte chaque include, chaque a, mx, ptr et exists, ainsi que le modificateur redirect, et il les compte sur tout l’arbre : un include qui contient trois autres includes coûte quatre. À la onzième requête, le destinataire s’arrête et renvoie permerror, que la plupart traitent exactement comme une absence d’enregistrement SPF.
Le piège, c’est que rien ne paraît faux. L’enregistrement est court, la syntaxe valide, chaque service est listé. Il casse le jour où un fournisseur ajoute un include à son propre enregistrement, ce que vous ne voyez jamais. C’est pourquoi le générateur affiche le coût à côté de chaque service, et pourquoi « Vérifier avec le DNS en temps réel » recompte tout l’arbre au moment où vous cliquez.
include:, a, mx, ptr, exists: et redirect=, chaque occurrence, y compris dans chaque enregistrement inclus. Une seconde limite, distincte, porte sur les requêtes vides (void lookups) : des noms qui ne renvoient aucun enregistrement. Plus de deux, et c’est aussi un permerror.
ip4:, ip6: et all. Déclarer votre propre serveur par son adresse plutôt qu’avec a ou mx économise une requête à chaque fois, au prix d’une mise à jour de l’enregistrement quand l’adresse change.
Mesuré le 19 octobre 2026 sur le DNS public, compté comme le fait un destinataire. Un fournisseur peut modifier son enregistrement n’importe quel jour : prenez ces chiffres comme un instantané et laissez le dernier mot à la vérification en direct.
| Service | include | Requêtes |
|---|---|---|
| Microsoft 365 | spf.protection.outlook.com |
1 |
| Google Workspace | _spf.google.com |
1 |
| IONOS | _spf-eu.ionos.com |
1 |
| Brevo | spf.brevo.com |
1 |
| SendGrid | sendgrid.net |
2 |
| Proton Mail | _spf.protonmail.ch |
2 |
| GoDaddy | secureserver.net |
3 |
| Namecheap Private Email | spf.privateemail.com |
4 |
| Mailgun | mailgun.org |
5 |
| Zoho Mail | zoho.com |
5 |
| Freshdesk | email.freshdesk.com |
7 |
Freshdesk consomme à lui seul sept requêtes sur dix. Avec Zoho Mail et un autre service, l’enregistrement dépasse la limite avant même d’y avoir mis un seul serveur à vous. Le générateur connaît 34 services avec leur coût mesuré ; pour un domaine qu’il ne connaît pas, la vérification en direct compte le chiffre réel.
Le 19 octobre 2026, nous avons lu les enregistrements SPF des 1 000 domaines .de les mieux classés de la liste Tranco (liste 467YX), avec les mêmes règles de comptage que le générateur.
| Constat | Domaines |
|---|---|
| Aucun enregistrement SPF | 112 |
Se termine par -all |
507 |
Se termine par ~all |
320 |
Se termine par ?all, qui ne protège rien |
22 |
Seulement un redirect= vers un autre enregistrement |
33 |
| Plus de 10 requêtes, SPF échoue partout | 17 |
| 8 à 10 requêtes, à une modification de l’échec | 144 |
| Plus de 255 caractères | 79 |
Dix-sept grands domaines allemands publient un enregistrement SPF qu’aucun destinataire ne peut évaluer, et près d’un enregistrement sur six se situe entre huit et dix requêtes. Aucun n’aurait passé le générateur sans avertissement. La méthode et les données brutes sont documentées ; le comptage suit exactement la RFC 7208, comme décrit plus haut.
Le dernier terme indique aux destinataires quoi faire d’un serveur absent de la liste.
~all (softfail) marque ces e-mails comme suspects tout en demandant au destinataire de ne pas les refuser d’emblée. C’est le bon choix tant que vous recherchez encore chaque service qui envoie pour vous : un expéditeur oublié finit alors dans les spams au lieu de disparaître.
-all (fail) signifie : qui n’est pas listé n’est pas nous. Passez-y lorsque les rapports agrégés DMARC de quelques semaines ne montrent plus aucune source légitime en échec SPF. Avec DMARC, la différence s’atténue, car DMARC décide selon sa propre politique ; sans DMARC, -all est l’affirmation la plus nette.
?all (neutre) et +all rendent l’enregistrement inutile. +all autorise même n’importe quel serveur d’Internet à envoyer au nom de votre domaine. Le générateur ne le propose pas.
ip4 en /33 ou une adresse IPv6 dans le champ IPv4 est écartée de l’enregistrement et signalée, au lieu de le casser.SPF vérifie l’expéditeur d’enveloppe, l’adresse que les serveurs utilisent entre eux pour les retours. Il ne vérifie pas la ligne « De » que le lecteur voit dans son logiciel. Un message falsifié peut réussir SPF pour le propre domaine de l’attaquant et afficher malgré tout votre nom dans « De ».
C’est DMARC qui comble ce trou : il exige que le domaine de « De » corresponde à un domaine qui a réussi SPF ou DKIM, et indique aux destinataires quoi faire sinon. SPF casse aussi lors d’un transfert, car le serveur qui transfère n’est pas dans votre liste ; une signature DKIM, elle, survit au transfert. Un domaine n’est vraiment protégé qu’avec les trois : SPF, DKIM et DMARC.
Non. Un domaine peut publier exactement un enregistrement TXT commençant par v=spf1. Avec deux ou plus, les destinataires renvoient permerror et ignorent complètement SPF pour le domaine. Si plusieurs services vous demandent chacun « d’ajouter leur enregistrement SPF », regroupez leurs include dans un seul enregistrement. C’est exactement ce que fait le générateur.
Commencez par ~all tant que vous recensez encore les services qui envoient pour vous : un expéditeur oublié finit dans les spams au lieu d’être refusé. Passez à -all quand les rapports DMARC montrent que tout le courrier légitime passe. Avec DMARC en quarantine ou reject, la politique DMARC compte davantage que ce qualificatif.
Le destinataire s’arrête à la onzième requête et renvoie permerror. La plupart traitent alors le domaine comme s’il n’avait pas d’enregistrement SPF, et DMARC ne peut plus réussir que par DKIM. Retirez les services que vous n’utilisez plus, ou remplacez un include par les plages ip4 et ip6 qu’il représente, en acceptant de suivre vous-même ses changements.
Non. L’enregistrement est construit dans votre navigateur. Seuls les deux boutons qui ont besoin du DNS interrogent notre serveur : « Charger l’enregistrement publié » lit l’enregistrement TXT public du domaine, et « Vérifier avec le DNS en temps réel » résout les include de votre enregistrement. Aucun des deux ne le conserve. L’utilisation est comptée par outil, sans votre adresse.
Attendez que la modification ait atteint les résolveurs, en général quelques minutes, parfois quelques heures selon le TTL de l’ancien enregistrement. Rechargez ensuite l’enregistrement ici ou lancez l’Email Security Check, qui contrôle SPF avec DKIM et DMARC. Le DNS Checker montre si les résolveurs du monde entier voient déjà la nouvelle valeur.
Seulement si ces serveurs envoient des e-mails. mx autorise les serveurs de votre enregistrement MX, qui reçoivent le courrier et souvent n’en envoient pas ; a autorise le serveur web, utile si un formulaire de contact ou une boutique envoie directement depuis celui-ci. Chacun coûte une requête : laissez de côté ce dont vous n’avez pas besoin.
Non. SPF ne vérifie que l’expéditeur d’enveloppe, pas l’adresse « De » que voit le lecteur. Sans DMARC, un attaquant peut toujours mettre votre domaine dans la ligne « De ». SPF est le premier des trois enregistrements ; DKIM signe le message et DMARC décide quoi faire quand aucun des deux ne correspond à votre domaine.
L’enregistrement est assemblé dans le navigateur à partir des services, des adresses et du qualificatif que vous choisissez. Le coût en requêtes des 34 préréglages a été mesuré le 19 octobre 2026 en résolvant chaque include de façon récursive sur le DNS public. Pour tout autre include, le générateur compte une requête et marque le total comme un minimum jusqu’à la vérification en direct.
« Charger l’enregistrement publié » interroge les enregistrements TXT du domaine via notre résolveur et applique le même validateur que l’Email Security Check, comptage récursif compris. « Vérifier avec le DNS en temps réel » résout chaque include de l’enregistrement construit, en parallèle et avec une protection contre les boucles, et indique le coût de chacun : c’est le chiffre qu’un destinataire voit aujourd’hui. Les deux requêtes sont décomptées de la limite quotidienne des outils gratuits.
Ce que l’outil ne peut pas savoir : quels services envoient réellement pour votre domaine. Un service qui envoie avec votre adresse et manque dans l’enregistrement échoue SPF, et aucun vérificateur ne peut le déduire du seul DNS. Les rapports agrégés DMARC, eux, le peuvent. C’est pourquoi DMARC se met en place juste après SPF.