Enregistrement SPF : configuration et erreurs courantes

Pour une infrastructure de messagerie en 2026, votre enregistrement SPF est un élément important de l'authentification. Une erreur peut contribuer au filtrage ou au rejet, mais SPF ne décide pas seul de l'arrivée en boîte de réception.

Depuis février 2024, Google et Yahoo appliquent des exigences d'authentification renforcées au trafic concerné. Un SPF absent ou incorrect peut intervenir dans un rejet tel que SMTP 550, selon les autres vérifications et la politique du serveur, sans provoquer cette réponse pour tous les messages.

Pour une entreprise avec un seul domaine, une erreur peut compromettre un envoi aux investisseurs. Pour un prestataire gérant 500 domaines clients, elle peut transformer le lundi matin en succession de demandes sur les envois vers Gmail. Une vérification préalable réduit les risques sans éviter tous les incidents.

Ce guide explique le rôle de SPF, la construction de l'enregistrement, les pièges de configuration et les contrôles utiles lorsque vous gérez de nombreux domaines.

Ce que SPF fait, et ne fait pas

Sender Policy Framework (SPF) est un protocole d'autorisation fondé sur le DNS, défini dans la RFC 7208. Il publie une politique permettant au serveur récepteur de vérifier les serveurs autorisés pour une identité SMTP donnée. Il ne constitue pas une protection générale et n'authentifie pas tout le contenu.

Comment fonctionne la vérification

Pour un message de alice@yourcompany.com, Gmail ne vérifie pas directement le From affiché dans l'interface avec SPF. Il évalue le domaine de l'expéditeur d'enveloppe SMTP, reflété dans le Return-Path à la livraison, ou HELO dans les cas applicables. Il consulte sa politique DNS et compare l'IP de connexion aux autorisations.

Une règle d'autorisation correspondante peut donner pass. Si l'évaluation atteint SoftFail (~all) ou HardFail (-all), elle renvoie ce résultat. Ce ne sont pas des ordres automatiques d'acceptation ou de rejet; d'autres résultats existent et le récepteur décide du traitement.

La différence entre From et Return-Path

Les 90% du texte d'origine sont une illustration, pas une statistique mesurée. La distinction essentielle est que SPF ne vérifie pas directement le From visible dans Outlook ou Apple Mail, mais l'identité SMTP applicable.

Le piège : Mailchimp peut utiliser son propre Return-Path pour gérer les rebonds, par exemple bounce-mc.us1.mailchimp.com. Le récepteur consulte alors SPF de Mailchimp, pas nécessairement celui de votre domaine. Votre enregistrement peut être valide sans participer à cet envoi.

C'est pourquoi SPF seul ne suffit pas à vérifier l'identité visible. Lisez comment SPF, DKIM et DMARC interagissent dans le guide de configuration de l'authentification email.

Pourquoi SPF reste utile

SPF complète DKIM et DMARC. Son absence peut enfreindre des exigences applicables; Microsoft peut renvoyer 550 5.7.515 Access Denied pour certains flux soumis à ses règles d'authentification. N'attribuez pas universellement ce code à SPF et ne négligez pas les vérifications techniques.

Configuration de base avec un fournisseur

Une petite entreprise utilisant TrekMail, Google Workspace ou Microsoft 365, éventuellement avec un outil marketing, a besoin d'une politique SPF cohérente pour chaque domaine SMTP utilisé. Avec peu de services, la configuration peut être simple, mais une erreur fréquente reste à éviter.

Règle de base : au maximum un enregistrement SPF applicable par nom de domaine; si vous publiez SPF, il doit être unique.

Lors de l'ajout d'un service, ne créez pas un deuxième TXT SPF au même nom. Plusieurs politiques SPF applicables produisent PermError; le récepteur ne les fusionne pas. D'autres TXT sans rapport avec SPF peuvent parfaitement coexister.

Les composants d'un enregistrement

Consultez le guide de configuration SPF pour des exemples détaillés. Vérifiez les modèles avec les instructions actuelles des fournisseurs avant publication.

TrekMail pour les petites entreprises

Le texte d'origine compare Google Workspace à $6-$18 par utilisateur et par mois. Pour dix utilisateurs, il indique $720-$2,160 par an. Il cite aussi Starter de TrekMail à $3.50 par mois, jusqu'à 100 utilisateurs. Ce sont des références illustratives, pas des tarifs actuels vérifiés. Ajouter include:spf.trekmail.net peut convenir au transport utilisé, mais exige de revoir tous les expéditeurs et le reste de l'authentification. Le modèle forfaitaire dépend des limites et conditions en vigueur, sans garantir une messagerie fonctionnelle avec une seule ligne.

Plusieurs fournisseurs : le cas des agences

Une agence gérant des dizaines de domaines peut rencontrer HubSpot pour les ventes, Zendesk pour le support, Klaviyo pour le marketing et TrekMail pour la messagerie professionnelle. Inventoriez les flux : tous n'ont pas besoin du SPF racine s'ils utilisent d'autres domaines d'enveloppe.

Fusionnez les services utilisant réellement la même identité SMTP dans une politique, en respectant la limite de 10 recherches applicable aux termes évalués.

La limite de 10 recherches

La RFC 7208 §4.6.4 limite à 10 les mécanismes et modificateurs évalués qui nécessitent des recherches DNS, y compris ceux imbriqués. Il ne s'agit pas d'un compte de paquets DNS individuels. La restriction limite le travail et les abus possibles, mais peut aussi concerner des configurations légitimes.

Termes consommant le budget : include:, a, mx, exists, redirect. Cette liste n'est pas exhaustive : ptr en fait aussi partie.

Termes ne consommant pas ce budget : ip4:, ip6:, all

Le piège des include imbriqués

Ajouter include:bluehost.com semble consommer 1 terme. À titre hypothétique, si cette politique évalue aussi spf.protection.outlook.com et mail.bluehost.com, trois termes pourraient être évalués. De plus, spf.protection.outlook.com peut avoir sa propre chaîne. L'exemple ne décrit pas nécessairement les données actuelles, ni un parcours systématique de toute la chaîne.

Si l'évaluation dépasse 10 termes concernés, elle renvoie PermError, distinct de fail. Le récepteur peut rejeter ou filtrer selon sa politique; cela ne signifie pas disparition silencieuse de tous les messages.

Comment auditer le budget

Ne devinez pas. Utilisez la ligne de commande ou un visualiseur fiable. Sur Mac ou Linux :

dig +short txt yourdomain.com

Consultez ensuite chaque domaine include: et suivez l'évaluation applicable, avec mécanismes DNS et modificateurs, pas seulement les include. Le guide des recherches et limites SPF explique l'audit des dépendances et la correction des dépassements.

Aplatissement ou séparation par sous-domaines

Si votre configuration approche ou dépasse la limite de 10, examinez ces deux options. Toutes les agences ne l'atteignent pas nécessairement.

Option 1 : aplatissement SPF, avec maintenance

L'aplatissement résout les dépendances include: et les remplace par des autorisations IP explicites, comme ip4:. Les termes ip4: ne consomment pas ce budget; des centaines d'IP peuvent toutefois poser des questions de taille et de maintenance. Toute politique ne se prête pas à une substitution mécanique, notamment selon les familles d'adresses et les macros.

Le risque : HubSpot, Klaviyo et d'autres services peuvent modifier leurs IP. Après quelques mois, une liste fixe pourrait devenir obsolète, omettre de nouveaux serveurs ou conserver des adresses qui ne devraient plus être autorisées.

Si vous choisissez cette voie, prévoyez détection fiable des changements, validation des autorisations, mise à jour DNS, tests et possibilité de retour arrière. L'automatisation aide, mais ne supprime ni les risques ni la supervision.

Option 2 : séparation par sous-domaines

Une autre solution répartit les identités entre sous-domaines. SPF évalue le domaine d'enveloppe SMTP, reflété dans le Return-Path : celui-ci doit réellement changer pour bénéficier de la séparation.

Le marketing doit-il utiliser team@company.com, ou peut-il envoyer avec news@marketing.company.com ? Changer le From affiché ne suffit pas; configurez aussi l'identité technique adaptée.

Domaine racine (company.com) - Gardez une politique adaptée au courrier professionnel et aux services essentiels. Exemple illustratif à vérifier :

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

Sous-domaine marketing (marketing.company.com) - Placez ici les services utilisant réellement ce domaine d'enveloppe. Exemple, pas une politique prête à publier :

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

L'évaluation d'un domaine d'enveloppe distinct a un budget de 10 termes; un include imbriqué ne crée pas un nouveau budget. Vérifiez l'alignement DMARC relâché ou strict. Séparer marketing.company.com facilite la gestion sans protéger absolument l'adresse du dirigeant : les récepteurs peuvent agréger réputation du domaine organisationnel et des IP.

Consultez les modèles de configuration SPF et la configuration pour plusieurs expéditeurs. Adaptez les exemples à l'inventaire et aux instructions actuelles des fournisseurs.

Vérifications après publication

Enregistrer le TXT dans l'éditeur DNS ne termine pas le travail. Ces contrôles permettent de vérifier publication et envois réels.

1. Vérifier la mise à jour DNS

Les changements peuvent prendre des minutes ou des heures, selon publication et caches TTL. En plus du cache local, consultez un résolveur public et les serveurs faisant autorité lorsque nécessaire :

nslookup -type=txt yourdomain.com 8.8.8.8

8.8.8.8 sélectionne le DNS public de Google, qui peut lui-même avoir un cache. Voir le TXT confirme cette réponse, pas la mise à jour immédiate de tous les résolveurs ou récepteurs.

2. Valider la syntaxe

Examinez les erreurs de syntaxe et les règles susceptibles de changer l'évaluation :

• Un espace avant v=spf1 peut empêcher l'identification correcte de la politique.
• ip4: 192.1.1.1 - L'espace après les deux-points est incorrect.
• Plusieurs mécanismes all : le premier correspond toujours, les termes suivants ne sont donc pas évalués.
• Des entrées include: dupliquées peuvent gaspiller le budget sur le parcours évalué, sans être systématiquement une erreur de syntaxe.

Utilisez un validateur. L'assistant DNS TrekMail peut aider selon ses contrôles disponibles; vérifiez également le résultat publié.

3. La limite des recherches sans résultat

La RFC 7208 recommande un maximum de 2 recherches sans résultat, telles que NXDOMAIN ou réponse sans données pertinentes. Ce plafond peut dépendre de l'implémentation; le dépasser, et non l'atteindre, peut provoquer PermError.

Par exemple, include:spf.trekmaill.net contient une lettre supplémentaire. Si le nom n'existe pas, la recherche pourrait constituer 1 résultat vide; toutefois, un include sans politique SPF peut produire PermError à lui seul. Deux fautes ne démontrent pas universellement un dépassement du plafond des recherches vides.

Vérifiez les réponses DNS, pas seulement le texte : une syntaxe correcte peut référencer des dépendances inexistantes.

4. Analyser les en-têtes d'un envoi réel

Envoyez vers un compte Gmail que vous contrôlez. Dans le menu à trois points, choisissez « Afficher l'original » et recherchez Authentication-Results ajouté par le serveur récepteur de confiance. Exemple illustratif :

spf=pass (google.com: domain of user@yourdomain.com designates 192.0.2.1 as permitted sender)

spf=neutral ou spf=softfail mérite examen si vous attendiez pass, mais peut refléter une politique voulue ou un transfert. Vérifiez IP, domaine évalué et parcours; cela ne prouve pas l'échec DMARC si DKIM est valide et aligné. Consultez la vérification du statut DNS.

Erreurs qui affectent la messagerie

Ces situations apparaissent dans les incidents SPF. Les connaître aide à diagnostiquer sans leur attribuer une proportion mesurée de tous les tickets.

1. SPF et transfert

SPF compare l'IP de connexion à la politique de l'identité SMTP. Cette dépendance peut compliquer le transfert.

Alice écrit à Bob, qui transfère à Charlie. Si l'expéditeur d'enveloppe d'Alice est conservé, Charlie compare l'IP de Bob à cette politique. SPF peut échouer pour un message légitime, selon les autorisations et la configuration du transfert.

SPF seul ne résout pas tous ces cas. DKIM signe des données précises du corps et des en-têtes; la signature peut survivre si elles ne sont pas modifiées de manière incompatible. Elle doit rester valide et alignée pour DMARC. SRS peut permettre SPF pour le domaine de l'intermédiaire sans restaurer l'alignement avec le From original.

Consultez le transfert de messagerie de domaine pour l'interaction de SPF, DKIM et SRS, sans présumer un placement garanti.

2. Le mécanisme ptr

Au début des années 2000, le mécanisme ptr, fondé sur le DNS inverse, était utilisé :

v=spf1 ptr -all

La RFC déconseille ptr en raison de son coût et de ses limites, mais il reste défini dans le protocole. Cela ne prouve pas que Gmail ignore toute politique qui l'inclut. Si vous héritez de ptr, inventoriez ses autorisations et testez son remplacement; ne le confondez pas avec le PTR du serveur, qui a un autre rôle.

3. Le risque de +all

Cet exemple illustre une politique dangereuse; ne le publiez pas :

v=spf1 include:spf.google.com +all

Les qualificateurs signifient :

• -all = HardFail pour les IP dont l'évaluation atteint ce terme; le récepteur décide du rejet.
• ~all = SoftFail pour ces IP; n'impose pas une acceptation avec marquage.
• +all = Pass pour toute IP dont l'évaluation atteint ce terme.

+all peut autoriser des IP arbitraires pour l'identité SPF évaluée et faciliter les abus. Les erreurs ou règles négatives précédentes restent possibles et le récepteur applique d'autres contrôles; ce n'est pas une garantie d'usurpation réussie. Une politique avec +all mérite une révision. Remplacez +all par des autorisations limitées, par exemple -all, après inventaire et tests des flux légitimes.

4. Return-Path des services externes

Un outil marketing peut utiliser son domaine de rebond sans que Return-Path soit absent. Le domaine de suivi n'est pas nécessairement un domaine d'enveloppe personnalisé. Pour SPF aligné, le domaine évalué doit s'aligner sur From, au niveau organisationnel en mode relâché ou exactement en mode strict. DMARC peut aussi passer grâce à une signature DKIM valide et alignée.

Certains fournisseurs permettent un sous-domaine de retour tel que bounce.yourcompany.com. Vérifiez prise en charge, instructions et mode d'alignement; il n'est pas toujours indispensable si DKIM fournit déjà une voie alignée. Consultez alignement DMARC et réputation du domaine.

Générateurs : utilité et précautions

La qualité et la portée des générateurs SPF varient. Ils peuvent aider, mais vérifiez ce qu'ils contrôlent et les informations utilisées.

Les outils utiles

Les visualiseurs de chaînes include: aident à auditer dépendances et termes évalués. Certains outils de délivrabilité email proposent cette fonction; confirmez la couverture du parcours pertinent.

Les validateurs de syntaxe détectent certaines erreurs de séparateurs et de caractères. Les dépendances absentes et recherches vides nécessitent aussi des vérifications DNS, pas seulement une lecture du texte.

Les points à contrôler

Un assistant en un clic peut produire ?all, qui renvoie Neutral pour les IP atteignant ce terme. Ce n'est ni pass ni une preuve universelle de mauvaise réputation. Choisissez -all ou ~all selon inventaire, tests et objectifs, sans présumer que le réglage par défaut convient.

Découpage des chaînes TXT : chaque chaîne peut contenir jusqu'à 255 octets. Un SPF long peut être réparti sur plusieurs chaînes entre guillemets dans un seul enregistrement. Elles sont concaténées sans ajout d'espace et doivent donc conserver les séparateurs nécessaires :

• Structure correcte : "v=spf1 include:a..." "include:b... -all" représente deux chaînes dans un enregistrement, mais cet exemple abrégé nécessite un séparateur approprié à la concaténation.
• Incorrect : deux TXT SPF indépendants provoquent PermError.

Vérifiez comment votre DNS publie les chaînes et validez le texte concaténé. Un générateur peut mal les découper et produire une syntaxe incorrecte.

Consultez le guide des outils et de la configuration SPF pour orienter les contrôles, sans présumer que tout outil cité est validé pour votre cas.

Configuration et centralisation avec TrekMail

Les grandes suites proposent des fonctions utiles à certains clients, moins à d'autres. Certains plans facturent par utilisateur; comparez prestations, contrats et besoins sans supposer que toutes les fonctions supplémentaires sont inutiles.

Si TrekMail est le seul transport autorisé, ce modèle peut servir d'exemple après vérification des instructions actuelles :

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

Héberger un domaine sur TrekMail ne suffit pas à rendre cette politique complète : d'autres expéditeurs ou un SMTP externe peuvent exister. L'infrastructure gérée peut prendre en charge IP, PTR et ressources de rétroaction dans son périmètre. Cela ne dispense pas d'adapter progressivement les flux et de traiter les abus, ni ne garantit la livraison.

Un prestataire avec 50 domaines utilisant exclusivement le même transport pourrait publier 50 politiques équivalentes. Répéter cent fois une configuration standard facilite la gestion, mais chaque client exige inventaire et validation propres. Le modèle sans facturation par siège dépend du plan et n'élimine pas les différences légitimes entre domaines.

Pour une migration, consultez la présentation de la migration IMAP et les enregistrements DNS requis. IMAP copie les données accessibles des boîtes; MX, SPF, DKIM et DMARC se préparent séparément, avec tests et plan de bascule. L'importation groupée de domaines peut être disponible selon le tableau de bord et le plan : consultez l'importation de domaines.

Bonnes pratiques SPF

Les exigences d'authentification se sont renforcées en 2024 pour certains services et volumes. Un enregistrement SPF adapté contribue à les respecter, mais son absence ou sa validité ne détermine pas seule le sort de tout message légitime.

Voici les contrôles à retenir :

1. Auditez la publication. Lancez dig +short txt yourdomain.com et distinguez SPF des autres TXT. Plusieurs SPF applicables, pas simplement plusieurs TXT, provoquent PermError.
2. Fusionnez les autorisations pertinentes. Une politique par nom pour les services utilisant ce domaine d'enveloppe, avec chaînes TXT correctement concaténées.
3. Comptez les termes évalués. Utilisez un visualiseur. Au-delà de 10, envisagez de réduire les dépendances ou séparer les identités par sous-domaine; l'aplatissement exige de la maintenance.
4. Évaluez -all. Passez éventuellement de ~all après inventaire et tests. Remplacez +all par des autorisations limitées sans interrompre les flux légitimes.
5. Vérifiez Return-Path et alignement. Pour Mailchimp ou HubSpot, évaluez un domaine de rebond personnalisé si nécessaire. DMARC requiert SPF validé et aligné ou une signature DKIM valide et alignée.
6. Ne vous arrêtez pas à SPF. Le transfert peut affecter SPF et aussi DKIM s'il modifie les données signées. Configurez les trois : SPF, DKIM et DMARC.

Un enregistrement illustratif de 50 octets mérite autant de soin qu'un long. Vérifiez la configuration initiale et chaque changement; une revue annuelle peut compléter le suivi, pas le remplacer.

Centralisez le DNS lorsque c'est utile. Consultez l'offre gratuite TrekMail et les conditions actuelles de son hébergement forfaitaire et de ses outils SPF, DKIM et DMARC.