Vous avez trouvé un générateur d'enregistrement SPF gratuit, coché toutes les cases, Google Workspace, Mailchimp et votre CRM, puis collé le résultat directement dans le DNS. Deux semaines plus tard, Gmail rejette vos factures avec 550 5.7.26. Outlook renvoie 550 5.7.515. Votre file d'assistance déborde.
Le générateur a produit un résultat dont la syntaxe est valide. Il n'a pas produit un enregistrement opérationnel. C'est précisément dans cet écart que la délivrabilité disparaît. Si vous assemblez encore l'ensemble de votre configuration DNS, commencez par configurer la messagerie sur votre domaine; SPF s'inscrit dans un ensemble plus vaste avec MX, DKIM et DMARC.
Ce guide explique pourquoi les générateurs automatiques échouent en production, comment auditer leur résultat en cinq minutes avec les outils dont vous disposez déjà et à quoi ressemble un enregistrement SPF prêt pour la production.
Ce que fait réellement un générateur d'enregistrement SPF
Un générateur d'enregistrement SPF est un outil Web qui construit un enregistrement DNS TXT en concaténant des mécanismes include: propres à chaque fournisseur selon les cases cochées. Vous choisissez les expéditeurs et obtenez une chaîne. Il n'interroge pas votre DNS actif, ne compte pas les recherches récursives et ignore combien d'enregistrements SPF votre domaine possède déjà.
La plupart des générateurs gratuits ne sont que des assembleurs de chaînes : ils produisent quelque chose de vraisemblable sans vérifier son fonctionnement dans votre environnement DNS réel. La syntaxe est correcte. Une syntaxe correcte ne garantit pas un fonctionnement correct.
Les 3 modes d'échec ignorés par tous les générateurs SPF
Chaque échec SPF majeur en production remonte à l'un de trois problèmes. Un générateur standard ne voit aucun d'eux, car il fonctionne sans accès à vos données DNS actives ni à la logique de comptage utilisée par les destinataires.
1. PermError causé par un double enregistrement
Un domaine doit posséder exactement un enregistrement SPF. La norme RFC 7208 est explicite : si le serveur destinataire trouve deux enregistrements TXT commençant par v=spf1, il renvoie PermError, soit un échec permanent. Gmail et Yahoo traitent PermError comme une absence totale de SPF. Vos e-mails sont rejetés ou discrètement classés comme indésirables.
Les générateurs ne recherchent jamais un enregistrement existant. Si votre domaine est actif depuis plus de quelques mois, il en possède probablement déjà un, créé par votre bureau d'enregistrement, votre ancien hébergeur ou la personne ayant configuré Google Workspace trois ans plus tôt. Publier le résultat sans contrôle crée un doublon. Vous venez de casser ce qui fonctionnait.
2. La limite des recherches récursives
RFC 7208 limite l'évaluation SPF à exactement 10 recherches DNS. Ce nombre comprend chaque include:, a, mx, exists et redirect, ainsi que toutes les recherches imbriquées déclenchées par ces include. Un générateur compte les mécanismes sélectionnés. Il ne compte pas leur contenu.
| Fournisseur sélectionné | Compte du générateur | Recherches réelles |
|---|---|---|
| Google Workspace | 1 | 4 (_netblocks.google.com imbriqués, etc.) |
| Zendesk | 1 | 2-3 |
| Mailchimp | 1 | 2 |
| Salesforce | 1 | 2-3 |
| Total | 4 | 10-12 → PermError |
Le générateur affiche 4 recherches. Le serveur destinataire atteint la n° 11 et s'arrête. SPF échoue pour chaque message de votre domaine. Aucun avertissement dans l'interface, aucun e-mail de rejet. Ce sont vos clients mécontents qui vous préviennent.
3. La limite des recherches sans résultat (RFC 7208 §11.1)
Il existe une contrainte secondaire : pas plus de 2 requêtes DNS renvoyant un résultat vide (NXDOMAIN). Une seule faute dans un include: crée une recherche sans résultat. Deux erreurs de ce type font échouer l'ensemble de l'enregistrement SPF, même si le contrôle syntaxique du générateur l'a validé.
Exemple :
include:spf.trekmaill.net(un 'l' en trop). La syntaxe est valide. Le générateur le déclare correct. Le serveur destinataire effectue une recherche, ne trouve rien et enregistre la recherche vide n° 1. Un second include incorrect suffit à faire échouer tout l'enregistrement.
Comment auditer le résultat avant de le déployer
Avant de publier quoi que ce soit produit par votre générateur, effectuez ces trois contrôles sur le DNS actif. Cinq minutes suffisent pour détecter chaque problème critique ignoré par l'outil : doublons, profondeur excessive des recherches et syntaxe incorrecte. La procédure fonctionne sous macOS, Linux et l'invite de commandes Windows.
Étape 1 : recherchez un enregistrement existant
Exécutez cette commande avant toute modification du DNS :
nslookup -type=txt yourdomain.comSi deux lignes commencent par v=spf1, vous avez un doublon. Fusionnez-les manuellement en un seul enregistrement avant toute nouvelle publication.
# Broken - two records, PermError guaranteed:
"v=spf1 include:_spf.google.com -all"
"v=spf1 include:spf.trekmail.net -all"
# Fixed - merged into one:
v=spf1 include:_spf.google.com include:spf.trekmail.net -allÉtape 2 : comptez les recherches récursives
Pour chaque include: de votre enregistrement, consultez son contenu :
dig +short txt _spf.google.comRésultat :
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"Ce seul include:_spf.google.com déclenche 4 recherches réelles. Répétez l'opération pour chaque fournisseur de l'enregistrement et additionnez-les. Si le total dépasse 10, vous devez restructurer l'ensemble, généralement en déplaçant le courrier transactionnel vers un sous-domaine (send.yourdomain.com) doté de son propre enregistrement plus court.
Étape 3 : auditez les mécanismes
Comparez la chaîne produite par votre générateur avec ce tableau :
| Mécanisme | État | Action |
|---|---|---|
ptr | Obsolète | Supprimez-le. RFC 7208 le déconseille explicitement. Il est lent et peu fiable. |
+all | Non sécurisé | Supprimez-le. Il autorise tout Internet à envoyer au nom de votre domaine. |
ip4: 1.2.3.4 | Syntaxe non valide | Supprimez l'espace. La forme correcte est ip4:1.2.3.4. |
?all | Faible | Évitez-le. Une politique neutre n'offre aucune protection contre l'usurpation. |
~all | Acceptable | SoftFail. Utilisez-le seulement pendant une migration, pas comme réglage permanent. |
-all | Correct | HardFail. Les expéditeurs non autorisés sont rejetés. Utilisez-le en production. |
Liste de contrôle de la syntaxe SPF
Que vous ayez utilisé un générateur pour le premier brouillon ou écrit la chaîne à la main, parcourez cette liste avant de toucher au DNS. Ces contrôles couvrent chaque problème qu'un générateur ne peut pas détecter : doublons, limites des recherches récursives et indicateurs de politique non sécurisés.
- Un enregistrement par domaine. Fusionnez-les s'il existe un doublon. N'en publiez jamais deux.
- Commence par
v=spf1. Aucune variante. La chaîne exacte. - Se termine par
-allou~all. Jamais par+allou?all. - Les IP avant les include. Les mécanismes
ip4:etip6:ne consomment aucune recherche DNS. Placez-les en premier pour accélérer l'évaluation. - Aucune autoréférence.
include:yourdomain.comcrée une boucle infinie. Supprimez-la. - Pas d'aplatissement manuel des IP sans automatisation pour les tenir à jour. Si Google change ses IP et que vous ne mettez pas l'enregistrement à jour, vos e-mails cessent de fonctionner sans avertissement.
- Nombre total de recherches ≤ 10. Comptez-les toutes, y compris les include imbriqués.
Un enregistrement prêt pour la production :
v=spf1 ip4:192.0.2.1 include:spf.trekmail.net include:_spf.google.com -allLes IP d'abord (aucun coût de recherche), les include ensuite, puis le rejet strict à la fin. C'est tout.
Pourquoi les agences et PME dépassent les possibilités des générateurs SPF
Un générateur convient à un seul domaine avec un ou deux expéditeurs. Dès que l'échelle augmente, avec des agences gérant des dizaines de clients ou des PME dotées de nombreux outils SaaS, il devient un risque opérationnel récurrent, sans visibilité centralisée des recherches ou doublons dans l'ensemble du portefeuille.
L'ancienne méthode : un enregistrement SPF propre à chaque client, issu d'une session de générateur différente, sans piste d'audit. Un domaine atteint le plafond de recherches. Trois jours passent avant que quelqu'un s'en aperçoive. La réputation d'acheminement du client en pâtit.
Pour une vue complète de la protection de l'infrastructure de messagerie d'une entreprise, consultez notre guide sur la sécurisation de la messagerie professionnelle, qui présente les mesures essentielles au-delà du seul SPF.
Comment TrekMail élimine le problème du générateur SPF
La complexité de SPF vient de la gestion de plusieurs expéditeurs tiers tout en restant sous le plafond de 10 recherches. TrekMail élimine ces deux problèmes pour votre infrastructure de messagerie principale, ce qui vous évite d'utiliser un générateur, de compter les recherches imbriquées ou d'auditer les mécanismes de votre domaine d'envoi principal.
Pour les PME : un include, sans maintenance
Avec l'offre Starter de TrekMail ($3.50/mo), l'acheminement sortant passe par le SMTP géré de TrekMail. Votre enregistrement SPF se réduit à une seule ligne :
v=spf1 include:spf.trekmail.net -allTrekMail gère la rotation des IP et la réputation de l'expéditeur derrière cet include. Vous n'avez normalement plus à modifier l'enregistrement. Aucune nouvelle session de générateur, ni audit des recherches six mois plus tard à l'ajout d'un outil SaaS.
Pour les agences : un modèle pour chaque client
L'ancienne méthode : 100 clients, 100 enregistrements SPF issus de 100 exécutions différentes du générateur, chacun avec son propre risque de recherches récursives. Chacun peut échouer sans vous alerter.
La méthode TrekMail : un modèle pour tous les domaines clients :
v=spf1 include:spf.trekmail.net -allAvec l'offre Agency ($23.25/mo), vous pouvez gérer 1,000+ domaines depuis un seul tableau de bord. La standardisation de la messagerie professionnelle sur TrekMail élimine le problème des recherches récursives pour votre principal canal de communication. Si vous développez une configuration multidomaine, découvrez comment l'hébergement de messagerie multidomaine transforme la gestion.
Pour connaître la configuration DNS complète attendue par TrekMail en plus de SPF, notamment MX, DKIM et DMARC, la documentation sur les enregistrements DNS requis couvre les quatre au même endroit.
FAQ sur les générateurs d'enregistrement SPF
Ces questions apparaissent lorsque la première session avec un générateur produit un enregistrement inutilisable. Elles remontent toutes à l'écart entre la validation syntaxique, effectuée par le générateur, et la validation opérationnelle, qui exige d'inspecter le DNS actif.
Puis-je utiliser deux générateurs pour comparer leurs résultats ?
Oui, mais un second générateur ne résout pas le problème fondamental. Deux outils différents produiront deux chaînes différentes, sans détecter les doublons dans votre DNS actif ni compter précisément les recherches récursives. Les étapes CLI ci-dessus fournissent un contrôle fiable.
Le générateur déclare l'enregistrement valide. Pourquoi mes e-mails sont-ils rejetés ?
Pour un générateur SPF, « valide » signifie que la syntaxe est correcte, pas que l'enregistrement fonctionne dans votre environnement. Les deux causes les plus fréquentes de cet écart sont un doublon qui déclenche PermError ou plus de 10 recherches récursives. Les deux nécessitent d'inspecter le DNS actif, et pas seulement de valider le résultat dans une interface.
Quand utiliser -all plutôt que ~all ?
Utilisez -all (HardFail) en production : les expéditeurs non autorisés sont rejetés. Utilisez ~all (SoftFail) uniquement pendant une migration si vous n'êtes pas certain d'avoir répertorié tous les expéditeurs. C'est un état temporaire, pas un objectif. Un générateur qui utilise par défaut ?all ou +all cherche surtout à donner l'impression que le résultat fonctionne, plutôt qu'à assurer une réelle délivrabilité.
En bref
Un générateur gratuit constitue un point de départ raisonnable pour rédiger la chaîne SPF, mais pas une bonne étape finale pour la production. Les trois problèmes qu'il ignore, doublons, dépassement des recherches récursives et recherches sans résultat, provoquent des rejets silencieux et des PermError dont le diagnostic peut prendre des heures.
La solution n'est pas un meilleur générateur. C'est un audit CLI de cinq minutes : recherchez les doublons, comptez les recherches imbriquées et examinez les mécanismes. Publiez ensuite.
Si vous préférez éviter entièrement le processus du générateur, TrekMail regroupe vos envois sortants dans un seul include:. Une ligne dans le DNS. Aucun calcul de recherches. Aucun débogage de PermError.
Commencez un essai gratuit de 14 jours; carte bancaire requise, annulation possible à tout moment.
