SPF : la liste des serveurs autorisés à écrire en votre nom

SPF indique quels serveurs ont le droit d’envoyer du courrier pour votre domaine. Comment l’enregistrement se lit, pourquoi il casse en silence, et comment le corriger.

SPF est une liste d’invités. Vous la publiez dans le DNS de votre domaine et elle répond à une seule question : quels serveurs ont le droit d’expédier du courrier au nom de ce domaine ? Quand un message arrive, le serveur destinataire regarde d’où vient la connexion, lit votre liste et compare. L’adresse y figure : le contrôle passe. Elle n’y figure pas : le destinataire applique la consigne inscrite à la fin de la liste.

La comparaison a ses limites. SPF ne regarde ni l’expéditeur affiché dans le logiciel de messagerie, ni le contenu du message, mais seulement l’adresse d’enveloppe que les serveurs se transmettent entre eux. C’est pour cela que SPF seul ne suffit pas et que DMARC existe.

À quoi ressemble l’enregistrement

L’enregistrement SPF est une simple ligne de texte, publiée en TXT sur le domaine lui-même – pas sur un sous-domaine, pas sur _spf.

exemple.fr.  IN  TXT  "v=spf1 include:_spf.google.com include:spf.brevo.com ip4:92.0.2.17 ~all"

L’ordre n’a d’importance que pour le mécanisme final : il ferme la liste et tout ce qui vient après est ignoré. Un enregistrement qui se termine par ~all include:spf.mailjet.com n’autorise pas Mailjet.

La limite des dix requêtes, qui casse tout en silence

C’est le défaut SPF le plus fréquent, et le plus discret. Un enregistrement SPF ne peut déclencher que dix requêtes DNS, imbrications comprises. Au-delà, le résultat n’est pas « un peu moins bon » : il est permerror, et un serveur destinataire qui rencontre permerror traite votre domaine comme s’il n’avait pas de SPF du tout.

Le compte ne se lit pas dans votre ligne : chaque include: coûte au moins une requête, souvent davantage, parce que la liste du prestataire en contient elle-même. Valeurs relevées dans le DNS à la rédaction de cette page :

Six services d’envoi et vous êtes à la limite. Comme les prestataires modifient leurs listes sans vous prévenir, un enregistrement qui tenait l’an dernier peut la dépasser aujourd’hui sans que rien n’ait bougé chez vous.

Comment le mettre en place

L’enregistrement appartient à la zone DNS de votre domaine, qui n’est pas forcément chez l’hébergeur de votre messagerie : serveurs de noms chez OVHcloud et boîtes chez Microsoft 365, la ligne se publie chez OVHcloud. La page sur la réception explique comment reconnaître qui héberge quoi.

Nous avons interrogé chacun de ces noms dans le DNS avant de le publier ici. Un avertissement qui vaut pour ce que vous lirez ailleurs : _spf.ionos.com circule dans quantité de tutoriels et n’existe pas. Un include: qui ne mène nulle part n’est pas seulement inutile, il compte dans les dix requêtes.

Le chemin chez OVHcloud, pas à pas

1. Connectez-vous à l’espace client OVHcloud et ouvrez la section Web Cloud.
2. Dans Noms de domaine, sélectionnez le domaine concerné.
3. Ouvrez l’onglet Zone DNS. Vous voyez la liste complète des entrées.
4. Cherchez une entrée TXT dont la valeur commence par v=spf1. Si elle existe, modifiez-la – n’en ajoutez pas une seconde.
5. Sinon : Ajouter une entrée, type TXT, sous-domaine laissé vide, valeur v=spf1 include:mx.ovh.com ~all, complétée par les include: de vos autres services d’envoi.
6. Validez. La zone est republiée en quelques minutes ; comptez jusqu’à quelques heures avant que tous les destinataires voient la nouvelle version.

Les libellés changent d’une refonte d’interface à l’autre, mais la structure reste la même partout : zone DNS, entrée TXT sur le domaine nu, une seule ligne v=spf1.

Les constats en détail

Aucun enregistrement SPF

Nous avons interrogé les enregistrements TXT du domaine et aucun ne commence par v=spf1.

Sans SPF, aucune liste de serveurs autorisés n’existe. Un destinataire ne peut pas distinguer votre courrier d’un message écrit en votre nom depuis n’importe où. Deux effets : les usurpations passent sans obstacle, et votre propre courrier finit plus souvent en indésirables.

Ce qu’il faut faire. Recensez tout ce qui envoie en votre nom : messagerie de l’entreprise, outil de newsletter, boutique, facturation, formulaire de contact, outil de support. Publiez ensuite un seul enregistrement TXT qui les cite tous et se termine par ~all. Ne commencez pas par -all : si vous avez oublié un canal, son courrier disparaît.

Plusieurs enregistrements SPF

Nous avons trouvé plus d’une entrée TXT commençant par v=spf1.

Le standard n’en autorise qu’une. Face à deux, un serveur destinataire ne choisit pas la plus juste : il écarte SPF entièrement. Le cas typique survient lors d’un changement de prestataire, quand une ligne est ajoutée à côté de l’ancienne au lieu de la remplacer.

Ce qu’il faut faire. Fusionnez le contenu en une seule ligne : un seul v=spf1 au début, tous les include: et ip4: à la suite, un seul mécanisme final à la fin. Puis supprimez les autres entrées. Vérifiez ensuite que le compte de requêtes tient toujours – une fusion fait souvent franchir la limite des dix.

SPF dépasse la limite de requêtes

L’évaluation de votre enregistrement, imbrications comprises, demande plus de dix requêtes DNS.

C’est une panne silencieuse : l’enregistrement a l’air correct, il est publié, et les destinataires stricts le traitent comme inexploitable. Rien ne le signale dans la ligne, puisque le dépassement vient des listes de vos prestataires.

Ce qu’il faut faire. Le rapport indique le compte atteint et par quel chemin. Retirez d’abord les services que vous n’utilisez plus ; c’est presque toujours suffisant. Sinon, déplacez les envois secondaires vers des sous-domaines dédiés. Les services dits d’aplatissement résolvent le compte mais figent des plages d’adresses qui, elles, continuent de changer.

SPF se termine par +all

Le mécanisme final de l’enregistrement est +all.

Cela déclare que tous les serveurs du monde ont le droit d’écrire en votre nom : l’enregistrement est correct et ne protège de rien. On le rencontre surtout après un dépannage, quand le réglage pris dans l’urgence est resté.

Ce qu’il faut faire. Remplacez +all par ~all. Si vous êtes certain d’avoir recensé tous vos canaux d’envoi et que les rapports DMARC ne montrent plus d’échec légitime depuis quelques semaines, passez à -all.

SPF se termine par ?all

Le mécanisme final est ?all, c’est-à-dire « neutre ».

Neutre signifie : je ne me prononce pas sur les serveurs non listés. Les destinataires traitent ce résultat presque comme une absence d’enregistrement. Certains hébergeurs livrent encore ?all par défaut, et personne ne relit ensuite la ligne.

Ce qu’il faut faire. Passez à ~all. Observez quelques semaines les rapports DMARC pour vérifier qu’aucun canal légitime n’échoue, puis à -all.

SPF sans mécanisme final

L’enregistrement ne comporte ni all, ni redirect=.

Rien n’indique alors comment traiter un serveur absent de la liste : le résultat est neutre, la liste est publiée mais sans conséquence.

Ce qu’il faut faire. Ajoutez ~all à la fin de la ligne, après tous les autres éléments. Attention aux fusions bâclées : si un all se retrouve au milieu, tout ce qui suit est ignoré.

SPF utilise ptr

L’enregistrement contient un mécanisme ptr.

Ce mécanisme demande au destinataire de résoudre l’adresse de l’expéditeur à l’envers. Il est déconseillé depuis des années : lent, coûteux pour les serveurs de noms, et beaucoup de destinataires l’ignorent ou considèrent l’enregistrement comme erroné. On le trouve encore dans les listes de certains hébergeurs – celle d’OVHcloud en contient au moment où nous écrivons. Sur le contenu d’un include: vous ne pouvez rien ; sur votre propre ligne, si.

Ce qu’il faut faire. Retirez ptr et déclarez les serveurs concernés explicitement, en ip4:, ip6:, a: ou mx.

SPF renvoie dans le vide

Plusieurs domaines cités par un include: ne publient aucun enregistrement SPF.

Un include: qui ne trouve rien met cette branche en erreur. Un seul cas passe souvent inaperçu ; à partir de deux, des destinataires stricts écartent l’enregistrement. La cause est presque toujours un service résilié dont le domaine d’inclusion a disparu.

Ce qu’il faut faire. Le rapport nomme les éléments concernés. Vérifiez si le service est encore utilisé. Si oui, allez chercher le nom exact dans sa documentation actuelle – il a pu changer. Sinon, supprimez l’élément.

Enregistrement SPF très long

La ligne dépasse la longueur qu’une réponse DNS transporte confortablement.

Au-delà de 255 caractères, la valeur doit être découpée en plusieurs morceaux dans le même enregistrement. Le standard le prévoit, mais les interfaces d’hébergeurs se trompent régulièrement sur ce point, et un morceau mal recollé produit un enregistrement inexploitable.

Ce qu’il faut faire. Traitez la longueur comme un symptôme : un enregistrement très long contient presque toujours des restes. Retirez ce qui ne sert plus, puis vérifiez dans le rapport que la ligne est reconstituée telle que vous l’avez saisie.

SPF tourne en boucle

Un domaine inclus renvoie vers un domaine déjà visité pendant l’évaluation.

L’évaluation s’arrête là. Le cas se produit quand deux domaines s’incluent mutuellement, par exemple après une fusion d’entreprises où chacun a ajouté l’autre « pour être sûr ».

Ce qu’il faut faire. Défaites l’imbrication : chaque domaine liste les serveurs qui envoient réellement pour lui, sans renvoyer vers l’autre. Si les deux domaines partagent une infrastructure, citez-la directement des deux côtés.

Le domaine inclus a plusieurs SPF

Un domaine que vous incluez publie lui-même plusieurs enregistrements v=spf1.

La règle de l’unicité s’applique à chaque niveau : cette branche de l’évaluation est en erreur, et cela ne vient pas de chez vous.

Ce qu’il faut faire. Signalez-le à l’exploitant du domaine inclus, avec le nom exact que le rapport indique. En attendant, vous pouvez remplacer l’include: par les adresses ip4: que le prestataire documente – solution provisoire, à revoir dès qu’il a corrigé.

Élément inconnu dans le SPF

Un morceau de la ligne n’appartient pas au standard SPF.

Les causes ordinaires : une faute de frappe (incude:), un point-virgule au lieu d’une espace, un fragment collé par erreur, un mécanisme inventé par un tutoriel. Certains destinataires ignorent l’élément, d’autres considèrent l’enregistrement entier comme erroné.

Ce qu’il faut faire. Le rapport nomme l’élément. Comparez-le à la documentation du service concerné. Si vous n’en retrouvez pas l’origine, retirez-le : un élément dont personne ne sait à quoi il sert n’autorise probablement plus rien.

Questions fréquentes

Faut-il un enregistrement SPF pour un domaine qui n’envoie jamais de courrier ?

Oui, et il est plus simple : v=spf1 -all. Aucun serveur n’est alors autorisé à écrire au nom de ce domaine. Les anciens noms de marque et les domaines redirigés vers le site principal sont des cibles commodes parce que personne ne les surveille. La page sur la réception traite ce cas.

~all ou -all ?

~all demande au destinataire de considérer le message comme suspect ; -all lui demande de le refuser. -all est plus efficace, et plus risqué : un canal d’envoi oublié cesse d’arriver, sans que vous en soyez averti. L’ordre raisonnable est donc ~all d’abord, puis les rapports DMARC pendant quelques semaines pour voir ce qui échoue encore, puis -all.

SPF empêche-t-il l’usurpation de mon adresse ?

Pas à lui seul. SPF contrôle l’adresse d’enveloppe, que le destinataire ne voit pas. Un message peut passer SPF avec un domaine d’enveloppe quelconque et afficher votre adresse dans le champ « De ». C’est DMARC qui exige la correspondance entre les deux, et c’est pourquoi SPF sans DMARC ne protège pas votre nom.

Pourquoi mes messages transférés échouent-ils à SPF ?

Parce que le transfert change le serveur émetteur sans changer le domaine d’enveloppe : le serveur qui remet le message n’est pas sur votre liste. Ce n’est pas un défaut de votre enregistrement. C’est aussi pourquoi DKIM compte autant : une signature survit au transfert, et DMARC se satisfait de l’un des deux contrôles.