Générateur d'enregistrement SPF
Construisez un enregistrement SPF TXT correct avec presets fournisseurs et un compteur de lookups DNS en direct qui alerte avant le mur des 10 lookups.
Ce générateur d'enregistrement SPF écrit la valeur TXT v=spf1 exacte que vous publiez, directement dans votre navigateur, donc rien de ce que vous tapez ne quitte la page. Cochez les serveurs qui envoient du mail comme votre domaine, ajoutez des plages ip4 et ip6, ou cliquez un preset pour Google Workspace, Microsoft 365, OVH et les grands ESP. Il colle à la syntaxe RFC 7208 et n'invente rien. Un compteur en direct suit vos lookups DNS face à la limite stricte de 10, le plafond qui casse discrètement les records auxquels personne n'a touché, et vous prévient avant. Vous obtenez aussi des conseils honnêtes softfail contre hardfail, le bon hôte où publier, et des alertes pour les doublons, les mauvaises adresses et l'erreur +all.
100% dans votre navigateur. Rien de ce que vous tapez ne quitte cette page.
Générateur d'enregistrement SPF avec compteur de lookups DNS en direct
Un enregistrement SPF a l'air trivial. Une ligne de texte, quelques mécanismes, terminé. Puis le record grossit discrètement au-delà des dix lookups DNS, chaque message se met à échouer en permerror, et rien dans votre panneau DNS ne vous a prévenu. Ce générateur écrit la valeur TXT v=spf1 exacte à partir des mécanismes que vous cochez, colle à la syntaxe RFC 7208 sans rien inventer, et compte vos lookups au fil de la saisie pour que vous voyiez le mur avant de le prendre. Tout tourne dans votre navigateur. Une fois le record publié, collez votre domaine dans le vérificateur d'enregistrement SPF pour confirmer que le DNS sert bien ce que vous avez écrit, includes imbriqués compris.
Séparez plusieurs valeurs par des espaces ou des virgules. Ou cliquez un fournisseur ci-dessous pour l'activer.
Ce compteur ne voit que votre niveau racine. Chaque include tire son propre record, et les lookups qu'il contient comptent dans la même limite de 10. Vérifiez le total réel avec le vérificateur d'enregistrement SPF après publication.
v=spf1 ~all
Un seul enregistrement SPF par domaine, point final. Si un TXT record commençant par v=spf1 existe déjà, modifiez celui-là. En publier un deuxième est un permerror selon la RFC 7208, et les récepteurs traiteront votre SPF comme cassé.
Ce que fait un générateur d'enregistrement SPF
Un générateur d'enregistrement SPF écrit la valeur TXT v=spf1 exacte que vous publiez dans le DNS, construite à partir des serveurs que vous déclarez comme envoyant du mail pour votre domaine, afin que les récepteurs puissent vérifier qu'un message vient bien d'un hôte que vous avez autorisé. SPF répond à une seule question étroite : le serveur qui livre ce message a-t-il le droit d'envoyer pour le domaine de l'expéditeur d'enveloppe, l'adresse de return-path où partent les bounces ? Le serveur destinataire lit votre TXT record, parcourt les mécanismes de gauche à droite et s'arrête au premier qui correspond. Ce générateur transforme ça en une checklist, des champs ip4 et ip6, et des presets fournisseurs, puis imprime le record et l'hôte où le publier.
La limite des 10 lookups, ce qui casse les records auxquels personne n'a touché
La RFC 7208 plafonne à dix par vérification les mécanismes qui déclenchent des lookups DNS. include, a, mx, ptr, exists et redirect coûtent un chacun, et au-delà le résultat est permerror, ce qui sous une politique DMARC stricte veut dire que votre vrai courrier se met à rebondir. Le plus vicieux, c'est que les includes imbriqués comptent aussi. include:_spf.google.com ne vaut pas un lookup, mais un plus tout ce que Google tire en dessous, et ce record-là appartient à Google, pas à vous. Un domaine peut rester un an à huit lookups confortables, puis casser un mardi parce qu'une plateforme marketing a restructuré son propre arbre SPF. Le compteur en direct est votre alerte précoce, alors considérez tout ce qui dépasse sept comme un problème de budget.
Softfail ou hardfail, la version honnête
Le manuel dit que ~all marque les échecs comme suspects et que -all les rejette, ce qui est vrai mais incomplet. En pratique, la plupart des gros récepteurs injectent le résultat SPF dans DMARC et dans leur propre filtrage plutôt que de rejeter sur le SPF seul, donc l'écart au quotidien est plus petit que la syntaxe ne le laisse croire. Plus petit, pas nul. Restez en ~all tant que vous découvrez encore des expéditeurs, parce qu'un outil de facturation oublié sous ~all atterrit en spam où quelqu'un finit par le voir, alors que sous -all il disparaît. Passez à -all une fois l'inventaire vraiment terminé, soit quelques semaines de rapports DMARC propres. Sautez ?all, et ne publiez jamais +all, qui déclare l'internet entier autorisé à envoyer comme vous.
Confidentialité et exactitude
Tout le générateur tourne dans votre navigateur, donc le domaine et les expéditeurs que vous tapez ne quittent jamais votre machine et la page fonctionne hors ligne une fois chargée. Il suit la syntaxe RFC 7208 et n'invente rien, validant les hôtes ip4, ip6 et include au fil de la saisie et signalant les doublons, le plafond de 255 caractères par chaîne TXT et les qualificateurs dangereux. Une réserve : le compteur ne voit que votre niveau racine. Chaque include tire son propre record, et les lookups qu'il contient comptent dans la même limite de 10, alors confirmez le total réel face au DNS en direct avec un vérificateur d'enregistrement SPF après publication.
Questions fréquentes
Où dois-je publier l'enregistrement SPF ?
En TXT record sur le domaine lui-même, la racine, souvent affichée @ dans les panneaux DNS. Pas sur _spf, pas sur www. Les sous-domaines qui envoient du mail ont besoin de leur propre enregistrement SPF sur le nom du sous-domaine, car SPF ne s'hérite pas vers le bas.
Puis-je avoir deux enregistrements SPF sur un même domaine ?
Non. La RFC 7208 dit qu'un domaine avec plusieurs TXT records v=spf1 produit un permerror, et les récepteurs traitent ça comme un SPF cassé plutôt que d'en choisir un. Fusionnez plutôt les mécanismes dans un seul record.
Que se passe-t-il si je dépasse les 10 lookups DNS ?
Le check renvoie permerror. Sous DMARC, permerror signifie que SPF ne peut plus apporter de pass, donc si DKIM ne vous couvre pas, le courrier commence à échouer ou à rebondir. La limite existe pour empêcher les spammeurs de transformer la résolution SPF en chaîne d'amplification DNS.
~all ou -all, lequel choisir ?
~all tant que vous construisez encore l'inventaire de tout ce qui envoie comme votre domaine, puis -all une fois que quelques semaines de rapports DMARC ne montrent plus aucun expéditeur légitime en échec. Passer direct à -all le premier jour, c'est comme ça que le robot de facturation arrête de livrer en silence.