Envoyer un email depuis un domaine mal configuré revient à poster une lettre sans adresse d'expéditeur : les serveurs destinataires n'ont aucune raison de lui faire confiance. Tester son SPF est la première vérification à faire avant de lancer une campagne de prospection, mais encore faut-il savoir lire ce que l'outil affiche.

Ce que vérifie un test SPF

Le SPF (Sender Policy Framework) est un mécanisme d'authentification défini dans la RFC 7208. Il permet à un domaine de déclarer, via un enregistrement DNS de type TXT, quels serveurs sont autorisés à envoyer des emails en son nom. Quand un serveur destinataire reçoit un message, il interroge ce registre pour vérifier si l'adresse IP de l'expéditeur y figure bien. Si ce n'est pas le cas, le message risque d'être rejeté ou relégué en spam.

La nature de la configuration dépend de votre fournisseur d'envoi. Que vous utilisiez SMTP chez OVH ou Infomaniak, Gmail via OAuth ou Microsoft 365, chaque provider dispose d'adresses IP d'envoi différentes. Toutes doivent être incluses dans votre enregistrement SPF par l'intermédiaire de mécanismes include: pointant vers les domaines SPF du fournisseur. L'enregistrement évolue donc à chaque changement ou ajout de prestataire, ce qui rend le test régulier indispensable.

Comment lancer un test

Le plus direct est d'utiliser le diagnostic Fluenzr, qui analyse votre domaine et restitue immédiatement l'état de votre enregistrement SPF, mais aussi DKIM et DMARC. Vous renseignez votre nom de domaine, l'outil interroge vos DNS et affiche les résultats.

Pour un diagnostic complet, l'idéal est de tester depuis l'adresse IP réelle utilisée pour vos envois. Certains outils permettent de renseigner une IP source spécifique ; d'autres se contentent de vérifier la syntaxe de l'enregistrement et de simuler la résolution. Dans tous les cas, l'outil vous restitue un résultat SPF standardisé et le contenu brut de votre enregistrement TXT.

Prenez également l'habitude de relire l'enregistrement lui-même : un v=spf1 suivi de plusieurs mécanismes include:, d'éventuels ip4: ou ip6:, et d'un qualificateur final (-all, ~all ou ?all). Si vous voyez deux lignes v=spf1 pour le même domaine, c'est une erreur : il ne doit en exister qu'une seule.

Les trois familles de résultats

Les résultats d'un test SPF se regroupent en trois catégories : Pass, les résultats d'échec (Fail et SoftFail), et les états d'erreur (None, PermError, TempError). Chacun appelle une réaction différente.

Pass : la configuration est correcte

Le résultat Pass signifie que l'adresse IP testée est explicitement autorisée par votre enregistrement SPF. C'est le seul résultat qui valide totalement la configuration pour ce fournisseur d'envoi.

Un Pass ne garantit pas à lui seul une délivrabilité parfaite : DKIM et DMARC jouent également un rôle, et les filtres anti-spam examinent de nombreux autres signaux (réputation de domaine, taux de plaintes, contenu). Mais sans Pass SPF, les deux autres mécanismes perdent une part importante de leur efficacité.

Même en cas de Pass, vérifiez que votre enregistrement ne dépasse pas la limite de dix résolutions DNS fixée par la RFC 7208. Un enregistrement techniquement bien formé mais qui déclenche plus de dix résolutions produit un PermError sur les serveurs strictement conformes à la RFC, ce qui annule le bénéfice d'un SPF par ailleurs correct.

Fail et SoftFail : l'IP n'est pas autorisée

Fail (-all) signifie que le domaine déclare explicitement que l'IP testée n'est pas autorisée. Les serveurs destinataires qui appliquent strictement le SPF doivent rejeter le message. En pratique, beaucoup tiennent compte d'autres facteurs avant de rejeter, mais le risque de rejet ou de classement en spam est élevé.

SoftFail (~all) indique que l'IP n'est pas autorisée, mais que le domaine suggère de ne pas rejeter le message - seulement de le marquer. C'est souvent une configuration de transition, utilisée pendant une migration pour ne pas bloquer les envois existants. Laisser un SoftFail indéfiniment envoie un signal négatif aux filtres sans résoudre le problème de fond.

Dans les deux cas, les causes courantes sont :

un changement de fournisseur SMTP sans mise à jour du DNS ;
l'ajout d'un nouvel outil d'envoi (plateforme de prospection, outil marketing) sans avoir ajouté son mécanisme include: dans l'enregistrement ;
une migration d'IP chez le fournisseur, sans notification préalable - ce qui arrive ponctuellement chez certains hébergeurs.

La correction consiste à identifier le service ou l'adresse IP manquante et à l'ajouter à l'enregistrement TXT. Après modification, attendez la propagation DNS avant de relancer le test.

None, PermError, TempError : erreurs de configuration

None signifie qu'aucun enregistrement SPF n'existe pour le domaine testé. C'est fréquent sur un domaine récemment créé, sur un sous-domaine utilisé pour l'envoi mais jamais configuré, ou après une migration d'hébergeur où le DNS a été recréé sans reprendre l'enregistrement SPF. Les serveurs destinataires interprètent l'absence d'enregistrement comme une absence de politique, ce qui dégrade la confiance accordée au message.

PermError (erreur permanente) signale un problème de syntaxe ou une configuration non conforme à la RFC. Les causes les plus fréquentes sont :

un dépassement de la limite de dix résolutions DNS ;
la présence de deux enregistrements SPF distincts pour le même domaine, ce qu'interdit la RFC ;
une syntaxe incorrecte : espace manquant entre les mécanismes, qualificateur mal placé, mécanisme include: pointant vers un domaine inexistant.

TempError (erreur temporaire) est généralement liée à une indisponibilité du serveur DNS interrogé au moment du test. Relancer le test quelques minutes plus tard suffit souvent à la résoudre. Si elle persiste, le domaine DNS lui-même rencontre un problème qu'il faut investiguer auprès de votre hébergeur.

Ce que ces résultats changent en pratique

Un enregistrement en Fail, SoftFail ou None affecte directement le placement en boîte principale. Les grandes messageries ont renforcé leurs exigences en matière d'authentification : un domaine sans SPF valide voit ses messages traités avec méfiance, même si le contenu est irréprochable et que l'expéditeur n'a aucune intention de spam.

Pour les indépendants, consultants et équipes commerciales qui pratiquent la prospection par email, chaque message qui atterrit en spam représente une opportunité perdue. La configuration SPF n'est pas optionnelle : c'est une condition de base pour que les efforts de prospection produisent un effet. Elle s'inscrit dans un ensemble plus large que détaille le guide de configuration SPF, DKIM et DMARC, qui couvre les trois mécanismes d'authentification et leur interaction.

Après le test : corriger selon votre provider

La démarche est la même quel que soit votre fournisseur, mais le contenu de l'enregistrement varie. Pour Gmail via Google Workspace, la documentation officielle est disponible sur support.google.com. Pour Microsoft 365, les informations se trouvent dans la documentation Microsoft. Pour SMTP chez OVH ou Infomaniak, le mécanisme include: à utiliser est documenté directement dans l'interface de gestion de chaque hébergeur.

Si vous utilisez plusieurs providers simultanément - par exemple un SMTP principal et Gmail pour certains comptes - tous doivent figurer dans le même enregistrement SPF. L'enregistrement final doit rester sous la limite de dix résolutions ; si ce n'est pas possible, des outils de mise à plat ("flattening") permettent de remplacer les include: par les adresses IP résolues, au prix d'une maintenance manuelle en cas de changement d'IP chez le fournisseur.

Après chaque correction, attendez la propagation DNS, puis relancez une vérification via le diagnostic Fluenzr pour confirmer que le résultat passe bien en Pass.

À retenir

Pass confirme que l'IP d'envoi est bien autorisée par votre enregistrement SPF : c'est le seul résultat valide.
Fail et SoftFail signalent une IP non déclarée ; identifiez le provider manquant et ajoutez son mécanisme include: dans votre enregistrement TXT.
None indique l'absence totale d'enregistrement SPF ; PermError pointe vers une syntaxe incorrecte ou un dépassement de la limite de dix résolutions DNS.
Un seul enregistrement SPF est autorisé par domaine ; si vous en avez deux, fusionnez-les.
Chaque ajout d'un nouvel outil d'envoi implique une mise à jour de l'enregistrement SPF et un nouveau test.
SPF seul ne suffit pas : DKIM et DMARC complètent l'authentification et sont indispensables pour une délivrabilité solide.

Tester son SPF en ligne : lire le résultat