Échec SPF : causes, diagnostic et correctifs

Que signifie un échec SPF (« SPF failed ») ?

SPF (Sender Policy Framework) permet au propriétaire d'un domaine de publier dans le DNS un enregistrement TXT qui liste les hôtes autorisés à envoyer des e-mails pour ce domaine. À l'arrivée de votre message, le serveur destinataire prend l'adresse IP de connexion et consulte l'enregistrement SPF du domaine indiqué dans la commande SMTP MAIL FROM (reporté ensuite dans l'en-tête Return-Path). Il parcourt alors les mécanismes de l'enregistrement de gauche à droite. Si l'IP correspond à l'un d'eux, le résultat est pass. Si rien ne correspond, c'est le qualificateur du « all » final qui décide : -all donne fail, ~all donne softfail.

La plupart des guides passent un détail sous silence : SPF ne regarde jamais l'adresse From visible. Un message peut afficher votre domaine dans le From et être vérifié contre l'enregistrement d'un autre domaine, par exemple le domaine de bounce de votre service d'envoi. Avant de toucher au DNS, identifiez donc le domaine réellement vérifié. Dans la pratique, on parle d'échec SPF pour tout résultat autre que pass. Dans les messages de rejet, il apparaît souvent sous la forme d'un refus 550 5.7.1 avec « SPF fail » dans le texte. L'article de Mailtester.com d'octobre 2026 sur les échecs SPF décrit ce code comme un signe direct d'un échec d'authentification.

Résultats SPF : none, neutral, softfail, fail, temperror, permerror

Résultat	Ce que signifie le résultat	Cause typique	Que faire
pass	L'IP est autorisée pour le domaine vérifié	L'IP correspond à un mécanisme d'adresse IP, a, mx ou include	Rien côté SPF, mais vérifiez quand même l'alignement DMARC
none	Aucun enregistrement SPF trouvé pour le domaine vérifié	Aucun TXT ne commence par v=spf1, ou il est publié sur le mauvais hôte ou sous-domaine	Publier un enregistrement sur le domaine exact utilisé dans MAIL FROM
neutral	Le domaine ne se prononce pas sur cette IP	L'enregistrement se termine par ?all	Remplacer ?all par ~all ou -all une fois tous les expéditeurs listés
softfail	L'IP n'est probablement pas autorisée	L'IP n'est pas listée et l'enregistrement se termine par ~all	Ajouter l'include ou l'IP de l'expéditeur manquant
fail	L'IP n'est explicitement pas autorisée	L'IP n'est pas listée et l'enregistrement se termine par -all	Ajouter l'expéditeur manquant, ou découvrir qui utilise votre domaine
temperror	Erreur DNS temporaire pendant la vérification	Timeout DNS ou serveur de noms injoignable	Vérifier vos serveurs de noms. Le destinataire peut réessayer
permerror	L'enregistrement ne peut pas être interprété	Deux enregistrements SPF, une erreur de syntaxe ou trop de requêtes DNS	Fusionner, corriger ou aplatir l'enregistrement

Pourquoi le SPF échoue-t-il ?

• Un nouveau service d'envoi n'est pas dans l'enregistrement. Vous avez branché un CRM, un outil de support ou un service d'e-mailing sans ajouter son include : ses IP ne correspondent donc pas.
• Il y a deux enregistrements SPF sur un même domaine. Un domaine ne peut porter qu'un seul TXT commençant par v=spf1. Avec deux, la vérification renvoie permerror, même si chacun est correct pris isolément. Cela arrive généralement quand le guide de configuration d'un second service vous dit d'« ajouter » un enregistrement au lieu de fusionner avec celui qui existe.
• L'enregistrement demande trop de requêtes DNS. Le guide de Valimail sur les échecs SPF et celui de PowerDMARC sur les échecs d'authentification SPF fixent tous deux la limite à 10 requêtes DNS par vérification, includes imbriqués compris. Les include, a, mx et redirect comptent. Les simples adresses IP, non. Au-delà de la limite, le résultat est permerror.
• Des includes pointent vers des domaines morts. Un include dont le domaine n'existe plus ne renvoie aucune réponse. Il consomme pourtant une requête, et les destinataires ne tolèrent que quelques requêtes vides avant d'interrompre la vérification.
• Des erreurs de syntaxe : préfixe v=spf1 manquant, espace après « include: », plage IP mal formée, ou texte collé avec des guillemets typographiques.
• L'enregistrement est sur le mauvais hôte. SPF ne s'hérite pas. Si votre service utilise bounce.example.com comme domaine MAIL FROM, l'enregistrement de example.com n'est jamais consulté.
• Transferts et listes de diffusion. Un serveur de transfert relaie votre message depuis sa propre IP, absente de votre enregistrement : SPF échoue donc à la destination finale. Seul DKIM survit à un transfert qui ne modifie pas le message.
• Des problèmes DNS pendant la requête, qui donnent temperror. Un fil Microsoft Q&A d'octobre 2024 décrit des résultats temperror apparus uniquement lors d'envois vers des destinataires Outlook en entreprise.

Comment vérifier SPF et DKIM

1. 1 Envoyez un message de test vers une boîte que vous contrôlez et ouvrez la source brute. Dans Gmail, « Afficher l'original » affiche en haut les résultats SPF, DKIM et DMARC.
2. 2 Repérez l'en-tête Authentication-Results. Notez spf= et smtp.mailfrom= (le domaine réellement vérifié par SPF), puis dkim= et header.d= (le domaine qui a signé le message).
3. 3 Interrogez l'enregistrement SPF avec dig TXT example.com +short. Comptez les réponses qui commencent par v=spf1. S'il y en a plus d'une, vous tenez votre permerror.
4. 4 Interrogez DKIM. Récupérez la valeur s= (le sélecteur) dans l'en-tête DKIM-Signature et lancez dig TXT selecteur._domainkey.example.com +short. Une réponse vide signifie qu'aucune clé publique n'est publiée sur cet hôte.
5. 5 Comparez les deux domaines avec votre domaine From. DMARC exige qu'au moins l'un d'eux corresponde.
6. 6 Comptez les requêtes. Check MX de Google Admin Toolbox et le SPF lookup de MxToolbox développent tous deux les includes imbriqués. Les deux lisent le DNS public : un enregistrement modifié il y a quelques minutes peut ne pas encore apparaître. Cela dépend du TTL de l'enregistrement.

Pour un tour complet des trois enregistrements du point de vue d'un expéditeur en prospection à froid, consultez notre guide SPF, DKIM et DMARC pour le cold emailing.

Quel enregistrement SPF Google pour Workspace, G Suite et Gmail ?

La documentation d'administration Google Workspace consacrée au dépannage SPF donne une seule valeur pour les domaines qui envoient via Google : un enregistrement TXT sur le domaine racine contenant v=spf1 include:_spf.google.com ~all. Chaque ligne ci-dessous répond à une variante de la question. La configuration DNS complète, enregistrements MX compris, se trouve dans notre article sur les enregistrements DNS Google Workspace pour MX, SPF et DKIM.

Question	Réponse
Enregistrement SPF Google Workspace	Un TXT sur votre domaine racine : v=spf1 include:_spf.google.com ~all. Si d'autres services envoient pour le même domaine, ajoutez leurs includes dans ce même enregistrement, avant ~all. Ne publiez pas de second enregistrement.
Enregistrement SPF G Suite	G Suite est l'ancien nom de Google Workspace, et l'enregistrement n'a pas changé : v=spf1 include:_spf.google.com ~all. Les guides qui parlent encore de G Suite restent valables.
Enregistrement SPF Gmail	Vous ne pouvez ni publier ni modifier le SPF d'une adresse Gmail personnelle, car Google contrôle le DNS de gmail.com. Un e-mail qui affiche un From Gmail mais part depuis les serveurs d'un autre service ne sera pas aligné avec gmail.com. La prospection doit partir d'un domaine qui vous appartient.
Enregistrements SPF Google : un ou plusieurs ?	Un seul. L'include de Google contient lui-même d'autres includes, et chacun compte dans la limite de requêtes. Vérifiez le total après avoir ajouté d'autres services.
Enregistrements SPF et DKIM Google	Le SPF va dans le TXT racine ci-dessus. Le DKIM se génère dans la console d'administration sous Applications > Google Workspace > Gmail > Authentifier les e-mails, se publie en TXT sur google._domainkey (le sélecteur par défaut), puis s'active avec Démarrer l'authentification.

Si Brevo signe aussi les e-mails du même domaine, notre guide de configuration DKIM G Suite montre comment garder séparées les clés de Google et celles de Brevo.

Que se passe-t-il sans enregistrement SPF ?

Sans enregistrement, le résultat SPF est none. Ce n'est pas un rejet en soi : c'est le serveur destinataire qui décide quoi en faire. Mais les grands fournisseurs de messagerie attendent désormais des e-mails authentifiés. Les consignes d'expéditeur de Google pour Gmail demandent à tout expéditeur de configurer SPF ou DKIM, et aux expéditeurs en masse de configurer les deux plus DMARC. Sans SPF, votre domaine n'a pas non plus de liste publiée d'expéditeurs autorisés : les destinataires n'ont rien pour confronter un message usurpé. Ajouter un enregistrement prend quelques minutes. Ne publiez simplement pas -all avant que chaque expéditeur légitime soit listé, sinon vos propres e-mails commencent à échouer. Le guide de Sendmarc de septembre 2026 sur le hard fail décrit l'ordre en trois étapes : auditer vos expéditeurs, déployer par paliers, puis appliquer la politique stricte.

Que signifie un échec DMARC quand le SPF échoue ?

DMARC passe lorsque SPF ou DKIM passe et que le domaine validé est aligné avec celui de l'en-tête From visible. Un échec SPF n'entraîne donc pas automatiquement un échec DMARC : une signature DKIM alignée suffit. L'inverse piège aussi beaucoup de monde. SPF peut passer sur le domaine de bounce de votre service d'envoi alors que DMARC échoue, parce que ce domaine n'est pas le vôtre. Un échec DMARC signifie qu'aucune des deux vérifications n'a donné un pass aligné. La suite dépend de votre politique : p=none se contente de rapports, tandis que p=quarantine et p=reject indiquent au destinataire comment traiter le message. Notre guide de configuration DMARC détaille l'enregistrement, ses tags et les rapports agrégés qui montrent quelles sources échouent.

Corriger un échec SPF étape par étape

1. 1 Lisez d'abord l'en-tête. Notez le résultat et le domaine smtp.mailfrom. Une correction sur le mauvais domaine ne change rien.
2. 2 Listez tous les services qui envoient avec votre domaine : votre fournisseur de messagerie, Brevo, la facturation, le support, le CRM.
3. 3 Fusionnez-les tous dans un seul TXT par domaine : v=spf1, puis les includes et les IP, puis un unique mécanisme all à la fin.
4. 4 Comptez les requêtes. Si vous dépassez la limite, retirez les services que vous n'utilisez plus, ou remplacez un include par les plages IP documentées par ce service. Les plages aplaties doivent être revérifiées chaque fois que le fournisseur change ses IP.
5. 5 Commencez avec ~all. Passez à -all seulement quand vos rapports DMARC ne montrent plus aucune source légitime en échec.
6. 6 Vérifiez DKIM en même temps que SPF. DKIM survit aux transferts, et c'est la voie habituelle vers l'alignement DMARC quand votre service d'envoi utilise son propre domaine de bounce.
7. 7 Une fois le TTL de l'enregistrement écoulé, envoyez un nouveau message de test.

Comment EmailFlow OS envoie, et ce que cela implique pour SPF

Avec EmailFlow OS, vous enregistrez une seule vidéo et la téléversez, vous connectez votre propre compte Brevo et votre domaine d'envoi, et vous importez votre liste de prospects dans EmailFlow OS. EmailFlow OS crée ensuite une version personnalisée de cet enregistrement pour chaque destinataire, et envoie chaque version depuis votre propre boîte, via votre compte Brevo et votre domaine. Aucun expéditeur partagé de la plateforme ne s'intercale. Les résultats SPF, DKIM et DMARC enregistrés par le destinataire concernent donc votre domaine et votre configuration Brevo, et les enregistrements DNS restent sous votre contrôle. Cela signifie aussi que tout échec SPF se corrige chez vous, dans votre propre DNS. L'endroit où atterrit un message est décidé par le serveur destinataire, pas par EmailFlow OS. La page d'accueil EmailFlow OS sur l'e-mail vidéo personnalisé montre comment s'articule la partie envoi.

Avant votre premier envoi, vous pouvez passer votre domaine dans le vérificateur SPF DKIM DMARC, un produit EmailFlow OS. Il lit vos enregistrements publiés : un SPF en double ou une clé DKIM manquante apparaît ainsi dès le départ.

Questions fréquentes

? Faut-il utiliser -all ou ~all dans son enregistrement SPF ?

Avec -all, les IP non listées obtiennent fail. Avec ~all, elles obtiennent softfail. DMARC traite les deux comme un SPF non validé : la différence compte surtout pour les destinataires qui agissent sur le seul SPF. Utilisez ~all tant que vous recensez encore tous vos expéditeurs. Passez à -all quand vos rapports agrégés DMARC montrent que chaque source légitime passe.

? Peut-on avoir deux enregistrements SPF sur un même domaine ?

Non. La spécification SPF n'autorise qu'un seul TXT commençant par v=spf1 par nom de domaine. Un second fait renvoyer permerror à toute la vérification, ce que la plupart des destinataires traitent comme un échec. Fusionnez les includes dans un seul enregistrement. Un sous-domaine comme mail.example.com est un nom distinct et peut porter son propre enregistrement.

? Pourquoi le SPF échoue-t-il alors que l'IP d'envoi est dans mon include ?

Il y a généralement trois raisons possibles. Le nombre de requêtes dépasse la limite, et la vérification s'arrête en permerror avant d'atteindre votre include. Ou le domaine vérifié n'est pas celui qui porte l'include, parce que MAIL FROM utilisait un sous-domaine ou le domaine de bounce du service. Ou il existe un second enregistrement SPF. L'en-tête Authentication-Results vous dit laquelle.

? Le SPF survit-il au transfert d'e-mails ?

En général, non. Un serveur de transfert envoie votre message depuis sa propre adresse IP, absente de votre enregistrement SPF : le destinataire final voit fail ou softfail. Une signature DKIM survit tant que le serveur de transfert ne touche ni aux en-têtes signés ni au corps. C'est pourquoi une signature DKIM alignée compte pour DMARC.