Créer un enregistrement SPF : organiser les expéditeurs et les requêtes

Si vous devez créer un enregistrement SPF pour un domaine, l'objectif est simple : autoriser les bons expéditeurs sans transformer le DNS en un casse-tête qui provoquera des pannes quelques mois plus tard. Les problèmes commencent souvent de la même façon. Vous ajoutez un prestataire, puis un autre. Microsoft renvoie ensuite un 550 5.7.515, Google un 550 5.7.26, et vous voilà à fouiller les enregistrements TXT à 11 heures du soir.

C'est là le problème. SPF paraît simple jusqu'au moment où il ne l'est plus. L'enregistrement du domaine racine devient un fourre-tout, les includes récursifs s'accumulent et une évaluation supplémentaire peut déclencher PermError. Pour un domaine d'entreprise, une infrastructure client ou plusieurs marques, ce n'est pas anodin : la distribution peut en souffrir, même si PermError n'entraîne pas systématiquement un rejet. Pour comprendre l'ensemble de la configuration, commencez par notre guide sur la messagerie professionnelle pour les petites entreprises.

Ce guide présente une architecture plus pérenne : garder la messagerie d'entreprise sur le domaine racine, isoler les envois en masse et applicatifs sur des sous-domaines effectivement utilisés pour l'envoi, et considérer le budget de requêtes comme une ressource limitée. Vous obtenez ainsi des enregistrements SPF plus faciles à maintenir, sans supprimer la nécessité de les revoir lorsque les expéditeurs changent.

Pourquoi tant d'enregistrements SPF échouent

SPF échoue notamment parce que les destinataires limitent les termes qui déclenchent des requêtes DNS pendant l'évaluation. Empiler trop d'includes sur un domaine peut dépasser cette limite, produire PermError et nuire à la distribution ou provoquer un rejet selon la politique du destinataire, même lorsque la syntaxe semble correcte.

Le RFC 7208 est explicite. Les termes qui déclenchent des requêtes DNS comprennent include, a, mx, ptr, exists et redirect. Les destinataires doivent limiter à 10 les termes de ce type évalués, y compris de façon récursive ; il ne s'agit pas de compter tous les paquets DNS. Dépasser cette limite produit une erreur permanente, pas un avertissement. Le RFC précise aussi que plusieurs enregistrements SPF pour un même nom de domaine produisent PermError. Les autres enregistrements TXT, sans rapport avec SPF, restent autorisés.

Voilà pourquoi le conseil habituel est insuffisant. Des guides génériques recommandent de créer un enregistrement SPF en plaçant tous les expéditeurs dans une valeur TXT sur @. Cela paraît ordonné, mais le domaine racine devient une infrastructure partagée entre newsletters, outils d'assistance, alertes applicatives, prospection et boîtes aux lettres des collaborateurs. Si un prestataire élargit sa chaîne d'includes, tous les envois qui dépendent de cette politique peuvent être touchés.

Mauvais modèle : un seul enregistrement SPF racine qui tente d'autoriser tous les outils que l'entreprise a utilisés.

Les consignes de Google pour les expéditeurs soulignent également l'importance d'une authentification correcte et d'un alignement cohérent, particulièrement pour les envois en masse. SPF n'est qu'une partie de l'ensemble, mais ses erreurs sont souvent le premier symptôme visible.

La véritable contrainte : le budget de 10 requêtes

La règle est la suivante : une politique SPF dispose d'un budget fixe de 10 termes évalués qui déclenchent des requêtes DNS. Ce décompte est récursif. Lorsqu'un include conduit à d'autres termes de ce type et qu'ils sont évalués, ils comptent aussi. Votre hébergeur DNS ne corrige pas une politique SPF mal dimensionnée.

Ce qui compte dans le budget :

• include
• a
• mx
• ptr (à éviter)
• exists
• redirect

Ce qui ne compte pas dans le budget :

• ip4
• ip6
• all

Les requêtes sans résultat sont également importantes. Le RFC 7208 recommande aux destinataires de les limiter à deux. Une faute dans la cible d'un include peut consommer une partie de cette marge. C'est le dépassement de la limite recommandée, et non le simple fait de l'atteindre, qui peut produire un autre PermError.

Si votre domaine envoie par l'intermédiaire de plusieurs prestataires, calculez le budget réel avant de publier la politique SPF. Le risque ne dépend pas seulement du nombre de prestataires, mais des termes évalués dans leurs politiques et de votre architecture.

Créer un enregistrement SPF avec une architecture séparée

Pour réduire les risques, séparez la messagerie entre personnes des envois en masse ou applicatifs. Gardez votre fournisseur principal de boîtes aux lettres sur le domaine racine et configurez les expéditeurs spécialisés avec des sous-domaines qu'ils utilisent réellement dans MAIL FROM ou le return-path. Modifier seulement le From visible n'isole pas le budget SPF. L'alignement DMARC doit toujours être assuré par SPF ou DKIM, selon le mode strict ou souple.

Voici le modèle :

1. Le domaine racine @ pour les échanges entre personnes.
2. Des sous-domaines de MAIL FROM ou return-path pour les newsletters, l'assistance, les alertes transactionnelles et les autres expéditeurs spécialisés.
3. Un enregistrement SPF par nom d'hôte, sans doublon ni ancienne politique oubliée. D'autres TXT sans rapport avec SPF peuvent coexister.

Exemple d'enregistrement racine pour l'envoi géré par TrekMail, à vérifier selon sa configuration actuelle :

v=spf1 include:spf.trekmail.net -all

La politique est facile à examiner : un include et une terminaison explicite. Cet include peut toutefois avoir des dépendances récursives ; vérifiez son coût effectif.

Exemple indicatif pour un sous-domaine marketing, à confronter aux consignes officielles actuelles de chaque prestataire :

v=spf1 include:servers.mcsv.net include:hubspot.com -all

Mailchimp et HubSpot ne consomment le budget de marketing.example.com que si ce domaine est réellement utilisé dans MAIL FROM ou le return-path et si leur configuration prend en charge ce modèle. Leurs modifications SPF n'affectent alors pas directement la politique de example.com. L'alignement DMARC exige néanmoins toujours une configuration adaptée.

TrekMail s'intègre aussi dans cette organisation. Sa documentation de configuration des domaines présente include:spf.trekmail.net comme include de base pour l'envoi géré. Son vérificateur DNS peut aider à repérer les conflits, sans remplacer une vérification complète. Pour configurer les boîtes aux lettres et le DNS, consultez Ajouter un domaine à TrekMail et Vérifier l'état du DNS.

Pas à pas : créer les valeurs SPF sans improviser

Pour créer des enregistrements SPF faciles à maintenir, commencez par inventorier tous les expéditeurs, attribuez à chacun le bon nom d'hôte, puis construisez le TXT. Ne commencez pas par le DNS : identifiez d'abord qui envoie et avec quel domaine d'enveloppe. Cela évite d'accumuler des includes arbitraires sur le domaine racine.

Suivez ce processus :

1. Listez tous les services qui envoient du courrier avec votre domaine.
2. Classez chaque expéditeur : messagerie d'entreprise, transactionnel, assistance ou marketing.
3. Choisissez le nom d'hôte de MAIL FROM de chacun et vérifiez l'alignement DMARC.
4. Utilisez la politique SPF minimale qui autorise tous les envois légitimes de cet hôte.
5. Publiez un TXT SPF par hôte ; les autres TXT sans rapport avec SPF peuvent coexister.

Construisez ensuite l'enregistrement réel en suivant les consignes officielles actuelles du prestataire, notamment pour son MAIL FROM personnalisé.

Exemple de SMTP géré par TrekMail :

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net -all
TTL: 3600

Exemple combinant TrekMail et votre propre SMTP pour Nano ou une configuration hybride, qui ne constitue pas une recette universelle :

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net include:amazonses.com -all
TTL: 3600

Avec TrekMail Nano, le modèle décrit exige votre propre fournisseur SMTP pour l'envoi. Autorisez le prestataire qui remet réellement le courrier et le domaine d'enveloppe correspondant ; héberger les boîtes chez TrekMail ne justifie pas automatiquement d'inclure TrekMail et SES ensemble. L'exemple combiné ne convient que si les deux sont nécessaires, et SES demande de suivre ses consignes de MAIL FROM personnalisé. D'après les conditions présentées dans l'article, les offres payantes commencent à $3.50/mois et comprennent le SMTP géré. Nano est présenté comme gratuit, sous réserve des conditions actuelles. Les offres payantes comprennent également un essai gratuit de 14 jours nécessitant une carte bancaire. Vérifiez les conditions actuelles et consultez SMTP personnalisé (BYO) et SMTP géré par TrekMail.

Publier et vérifier l'enregistrement

Après avoir créé le SPF, publiez-le comme TXT et vérifiez ce que renvoie le DNS public. Ne vous fiez pas uniquement à l'interface du bureau d'enregistrement, à un tableau de bord en cache ou au voyant vert d'un outil. Interrogez le domaine et confirmez qu'il contient un seul enregistrement SPF valide. Ces commandes interrogent généralement un résolveur avec cache : elles ne garantissent ni une réponse directe des serveurs faisant autorité ni un délai de propagation exact.

Mac ou Linux :

dig txt example.com +short

Windows :

nslookup -type=txt example.com

Vous devez trouver une seule valeur SPF commençant par v=spf1, sans politique SPF en double ni ancien enregistrement oublié lors d'une migration. Les autres valeurs TXT sans rapport avec SPF sont compatibles.

Vérifications rapides :

• Commence par v=spf1
• Se termine par -all une fois l'inventaire des expéditeurs et les tests terminés
• Contient uniquement les expéditeurs réellement utilisés
• N'existe qu'une fois comme politique SPF par hôte

Lors d'un changement de prestataire, examinez les anciens enregistrements : des MX ou SPF ne correspondant plus à la configuration prévue peuvent subsister. La documentation DNS de TrekMail traite ces situations. Pour une migration plus large, ces guides peuvent aider : créer une adresse e-mail avec son domaine et héberger la messagerie de plusieurs domaines.

Erreurs SPF courantes et premières solutions

Beaucoup d'erreurs SPF proviennent d'un dépassement des termes évalués qui déclenchent des requêtes, de politiques SPF multiples, de mauvais domaines d'envoi ou de fautes dans les includes. Une cartographie claire des expéditeurs les rend plus faciles à repérer. L'improvisation complique rapidement le diagnostic.

Ces règles pratiques évitent bien des difficultés :

1. Utilisez ip4 pour les expéditeurs à adresse fixe que vous contrôlez. Cela ne consomme pas de termes dans le budget de requêtes.
2. Séparez le MAIL FROM des envois marketing de celui de la direction lorsque le prestataire le permet, tout en préservant l'alignement DMARC.

La documentation de Google rappelle utilement l'objectif complet : authentification et alignement, pas SPF seul. SPF peut réussir et DMARC échouer si le domaine du From visible n'est pas aligné avec le domaine d'enveloppe authentifié selon le mode strict ou souple, et qu'aucune signature DKIM alignée ne réussit. Consultez la FAQ de Google sur les consignes pour les expéditeurs pour diagnostiquer les envois en masse.

Quand TrekMail peut simplifier le travail

TrekMail peut faciliter une configuration cohérente sur plusieurs domaines. Le modèle décrit associe un include pour l'envoi géré, du stockage mutualisé, une facturation sans tarif par utilisateur, une migration IMAP intégrée et le choix entre SMTP propre ou géré selon l'offre. Vérifiez la disponibilité, les limites et les conditions actuelles ; un include unique ne garantit pas un faible coût récursif.

Pour les entrepreneurs seuls, l'intérêt peut être la simplicité : héberger les boîtes chez TrekMail, garder une politique racine claire et éviter la facturation par siège selon l'offre. Pour les équipes, une configuration standardisée peut faciliter les arrivées et réduire les erreurs DNS. Pour les agences et MSP, c'est un modèle réutilisable sur de nombreux domaines, à condition de vérifier chaque expéditeur et chaque migration.

Passer de piles SPF fragiles et différentes pour chaque client à une architecture répétable, un tableau de bord commun et une politique racine vérifiée améliore l'exploitation. Il ne s'agit pas seulement de raccourcir une chaîne TXT.

À titre de référence dans l'article, Nano propose 10 domaines, 5GB de stockage mutualisé et votre propre SMTP sans carte obligatoire. Pour l'envoi géré et des limites plus élevées, les offres payantes décrites commencent à $3.50/mois, avec un essai gratuit de 14 jours nécessitant une carte bancaire. Consultez les tarifs TrekMail pour confirmer les offres, limites et conditions actuelles.

Conclusion : créer un SPF plus facile à maintenir

Pour créer des enregistrements SPF durables, ne raisonnez plus en immense liste d'autorisation sur le domaine racine, mais en architecture. Le domaine racine pour les échanges entre personnes. Des sous-domaines de MAIL FROM pour les expéditeurs spécialisés. Des includes minimaux. Un -all explicite une fois l'inventaire complet. Une vérification DNS après publication, en tenant compte des caches et de l'alignement DMARC.

Cette approche aide à maîtriser le budget de requêtes et à limiter les incidents inattendus. Elle n'élimine pas les révisions lors des changements de prestataire, mais les simplifie. Si vous refondez votre messagerie, découvrez TrekMail et vérifiez si son modèle et ses conditions actuelles conviennent à votre croissance.