Échec SPF : comprendre l’erreur et la corriger vite

Votre e-mail a été rejeté. Les en-têtes indiquent spf=fail. Un 550 5.7.1 ou un 550 5.7.26 vous fait face, tandis qu'un client attend une réponse qui n'est jamais arrivée.

Un échec SPF n'est pas un problème de contenu. C'est un échec d'authentification DNS. Le serveur de messagerie destinataire a consulté votre enregistrement SPF, constaté que l'IP d'envoi ne figurait pas dans la liste autorisée et rejeté le message avant même qu'il puisse atteindre un dossier de spam.

Depuis février 2024, Google et Yahoo rejettent les e-mails non authentifiés au niveau du protocole, au lieu de simplement les signaler comme suspects. Ce guide explique le code d'erreur précis, montre où trouver l'IP en échec dans les en-têtes et détaille les trois corrections DNS qui résolvent la grande majorité des échecs SPF. Aucune supposition. Commencez par la bonne correction.

Si vous configurez la messagerie sur votre domaine pour la première fois, établissez correctement la configuration DNS de base avant de rechercher les erreurs; les problèmes SPF viennent presque toujours d'une configuration initiale incomplète.

Qu'est-ce qu'un échec SPF ?

Un échec SPF se produit lorsqu'un serveur destinataire évalue l'enregistrement Sender Policy Framework de votre domaine et constate que l'adresse IP d'envoi n'est pas autorisée. SPF est publié sous forme d'enregistrement DNS TXT sur votre domaine et répertorie toutes les adresses IP et tous les services de messagerie autorisés à envoyer en votre nom. Si la vérification échoue, le serveur rejette le message (rejet strict) ou l'accepte comme suspect (rejet souple). Dans les deux cas, votre politique DMARC le comptabilise comme un échec.

SPF vérifie l'expéditeur de l'enveloppe, c'est-à-dire l'adresse MAIL FROM négociée pendant l'échange SMTP, et non l'en-tête « From » visible par le destinataire. Cette différence compte lorsque vous recherchez l'origine de la rupture.

Lisez le code d'erreur avant toute modification

Les serveurs de messagerie renvoient des codes SMTP différents en cas d'échec SPF. Le code d'erreur indique précisément la décision du destinataire et sa raison; traiter un 550 5.7.26 comme un 550 5.7.1 générique fait perdre du temps. Associez le code à sa cause avant de modifier le moindre enregistrement DNS.

Étape 1 : trouvez l'IP en échec dans les en-têtes

Ne devinez pas quelle IP a causé l'échec SPF. Ouvrez les en-têtes bruts du message rejeté (ou la notification de rejet elle-même) et recherchez Authentication-Results. Cet en-tête indique l'IP exacte évaluée par le destinataire et la décision prise.

Authentication-Results: mx.google.com;
   spf=fail (google.com: domain of team@example.com does not designate
   192.0.2.55 as permitted sender)

Deux données d'enquête apparaissent ici : l'IP d'envoi (192.0.2.55) et le domaine vérifié (example.com). Identifiez maintenant le propriétaire de cette IP :

• Un outil SaaS récemment adopté ? (HubSpot, Zendesk, Shopify)
• Votre serveur Web ? (WordPress, cPanel)
• Un service de transfert ? (Voir la section sur le piège du transfert ci-dessous)

Confirmez ensuite votre enregistrement SPF actuel avec une recherche rapide :

dig +short txt yourdomain.com | grep spf

Si plusieurs lignes commencent par v=spf1, vous avez déjà trouvé l'un des problèmes.

Étape 2 : les trois corrections les plus courantes

La plupart des échecs SPF ont l'une de ces trois causes : l'include d'un fournisseur manque, un enregistrement est en double ou la limite de 10 recherches DNS est dépassée. Choisissez la correction correspondant à votre constat de l'Étape 1.

Correction 1 : l'include manquant du fournisseur

Vous avez ajouté un nouvel outil de messagerie, comme HelpScout, HubSpot, Zendesk ou la messagerie transactionnelle de Shopify, sans mettre à jour votre DNS. Le service envoie en votre nom avec une IP que vous n'avez pas autorisée. C'est la cause la plus courante d'un échec SPF après l'adoption d'un nouveau fournisseur.

Enregistrement en échec :

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

Enregistrement validé (après ajout de HelpScout) :

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

Recherchez dans la documentation du fournisseur la chaîne include SPF requise. Ajoutez-la à votre enregistrement SPF TXT existant; ne créez pas un nouvel enregistrement. Chaque service utilisé pour envoyer doit y figurer.

Correction 2 : le double enregistrement, une erreur de syntaxe fatale

Un domaine ne peut avoir qu'un seul enregistrement SPF. Si vous ajoutez un second enregistrement TXT pour un nouvel outil au lieu de le fusionner avec l'enregistrement existant, les destinataires voient deux politiques contradictoires et invalident les deux. Vous obtenez un PermError, soit un échec SPF strict pour chaque e-mail du domaine, y compris ceux qui étaient auparavant bien acheminés.

Incorrect : deux enregistrements distincts :

v=spf1 include:spf.trekmail.net -all
v=spf1 include:_spf.google.com -all

Correct : fusionnés en un seul :

v=spf1 include:spf.trekmail.net include:_spf.google.com -all

Connectez-vous à votre fournisseur DNS, supprimez tous les enregistrements SPF TXT sauf un et fusionnez le tout sur une seule ligne. Un PermError dû à un double enregistrement provoque un échec SPF silencieux pour tous les expéditeurs jusqu'à sa correction.

Correction 3 : la limite de 10 recherches, une erreur d'architecture

La norme RFC 7208 limite l'évaluation SPF à 10 recherches DNS. Cela évite l'utilisation des serveurs comme vecteurs d'amplification DNS. Les mécanismes tels que include, a et mx comptent dans cette limite, tout comme les include imbriqués, quand votre fournisseur inclut à son tour l'enregistrement d'un autre fournisseur.

Au-delà de 10 recherches, vous obtenez PermError. SPF échoue pour tous les expéditeurs. Vérifiez le nombre actuel de recherches en suivant votre enregistrement :

dig +short txt yourdomain.com

Comptez manuellement chaque mécanisme include, a et mx, puis suivez les include imbriqués de chaque fournisseur. Si vous dépassez la limite, deux méthodes sont possibles :

1. Répartissez les expéditeurs entre des sous-domaines. Déplacez les outils marketing à fort volume vers marketing.yourdomain.com. Ce sous-domaine dispose de son propre quota neuf de 10 recherches, entièrement distinct de l'enregistrement du domaine principal.
2. Aplatissez votre enregistrement. Remplacez les chaînes include par les IP auxquelles elles renvoient, au moyen des mécanismes ip4: ou ip6:. Ceux-ci ne comptent pas comme recherches. En contrepartie, vous devrez mettre à jour l'enregistrement manuellement lorsque les fournisseurs changeront d'IP.

Autre piège : la limite des recherches sans résultat. Si plus de deux recherches de votre chaîne renvoient NXDOMAIN, par exemple à cause d'une faute comme include:spf.gogle.com, l'enregistrement est invalidé selon RFC 7208 §11.1. Une seule faute dans un include imbriqué peut faire échouer toute l'évaluation SPF.

Le piège du transfert : pourquoi SPF échoue sur des e-mails légitimes

Voici un échec SPF sans rapport avec votre configuration DNS. Vous envoyez un e-mail à une adresse d'anciens élèves (alice@university.edu), qui le transfère automatiquement vers Gmail (alice@gmail.com). Gmail voit l'e-mail arriver depuis l'IP du serveur de l'université. Votre enregistrement SPF n'autorise pas cette IP. SPF échoue, même si vous avez tout fait correctement.

Le parcours : Votre serveur → Serveur de l'université → Gmail. La vérification : Gmail évalue le dernier saut. Vous ne pouvez pas corriger les échecs de transfert avec SPF, car SPF n'autorise que l'IP d'envoi d'origine. Dès qu'un service de transfert intervient, la vérification de l'IP échoue.

La bonne solution est DKIM. DKIM signe cryptographiquement le corps et les en-têtes du message. Le service de transfert ne modifie généralement pas le corps; la signature DKIM survit donc au relais. Même en cas d'échec SPF, une signature DKIM valide permet au message de passer DMARC.

Si vous gérez un transfert au niveau de l'infrastructure et souhaitez des réécritures compatibles avec SPF, il est utile de comprendre le Sender Rewriting Scheme (SRS). Ce mécanisme permet aux services de transfert de réécrire l'expéditeur de l'enveloppe afin que SPF soit validé à destination. Pour les autres échecs d'acheminement liés au transfert, notre guide de configuration et de correction du transfert d'e-mails présente le diagnostic complet.

Vérifiez la correction avant de continuer

Après la mise à jour de l'enregistrement DNS, attendez sa propagation; elle prend généralement entre 5 et 30 minutes chez la plupart des fournisseurs, mais peut durer quelques heures dans certains cas. Vérifiez ensuite que la correction a bien été appliquée avant de conclure.

Envoyez un e-mail de test à une adresse Gmail et ouvrez les en-têtes bruts. Recherchez Authentication-Results. Voici le résultat attendu :

Authentication-Results: mx.google.com;
   spf=pass (google.com: domain of team@example.com designates
   192.0.2.55 as permitted sender)

Si vous voyez encore spf=fail ou spf=softfail, la correction ne s'est peut-être pas encore propagée ou l'enregistrement comporte toujours un problème. Comparez l'IP des en-têtes avec celle de l'enregistrement mis à jour. Elles doivent correspondre.

Vous pouvez aussi vérifier directement l'enregistrement :

dig +short txt yourdomain.com

Confirmez qu'il existe exactement un enregistrement commençant par v=spf1, qu'il inclut tous vos services d'envoi et qu'il se termine par -all (rejet strict) ou ~all (rejet souple).

Gérer SPF sur plusieurs domaines

Pour un seul domaine, la gestion de SPF est une tâche ponctuelle. Ajoutez vos include, fusionnez les doublons et corrigez le nombre de recherches. Mais si vous gérez la messagerie de 10, 50 ou 500 domaines, chacun ayant son enregistrement SPF et ses fournisseurs SaaS, diagnostiquer manuellement chaque échec SPF devient une charge opérationnelle réelle.

Le SMTP géré de TrekMail, disponible avec Starter à partir de $3.50/mo, réduit la configuration à un seul include par domaine. TrekMail gère la rotation des IP, la surveillance des rejets, l'alignement DKIM et l'infrastructure d'acheminement sous-jacente. Avec l'offre Agency ($23.25/mo), les agences appliquent un modèle DNS standardisé à tous les domaines clients au lieu de rechercher des échecs SPF dans des centaines d'enregistrements.

Commencez un essai gratuit de 14 jours pour découvrir concrètement le fonctionnement de l'acheminement géré.

Échec SPF : en bref

Un échec SPF signifie que le serveur destinataire a consulté votre DNS, constaté que l'IP d'envoi n'y figurait pas et appliqué votre politique. Un rejet strict (-all) entraîne un refus. Un rejet souple (~all) conduit souvent au dossier des spams. PermError signifie que votre enregistrement est incorrect et que SPF échoue pour tous les expéditeurs jusqu'à la correction de l'enregistrement lui-même.

Appliquez les corrections dans l'ordre :

1. Trouvez l'IP en échec dans l'en-tête Authentication-Results
2. Ajoutez l'include manquant si un nouveau service a causé l'échec SPF
3. Fusionnez les enregistrements SPF en double
4. Ramenez le nombre de recherches DNS sous 10 ou répartissez les expéditeurs à fort volume entre des sous-domaines
5. Si SPF échoue sur un e-mail transféré, mettez en place DKIM; SPF ne peut pas survivre à un relais

Appliquez d'abord la bonne correction, vérifiez-la dans les en-têtes et le problème est résolu.