6 principales défaillances SPF et comment les corriger

Vos emails sont authentifiés, vos DNS semblent propres et votre délivrabilité est au rendez-vous. Puis, du jour au lendemain, une nouvelle plateforme marketing entre en service, quelqu’un modifie un enregistrement DNS, et soudain la moitié de vos emails part dans les spams. Cela vous parle ?

Les défaillances SPF (Sender Policy Framework) figurent parmi les problèmes d’authentification email les plus répandus que nous rencontrons auprès des 1 200+ organisations utilisant Red Sift OnDMARC. Et en 2026, avec Google, Yahoo et Microsoft qui imposent tous une authentification aux grands expéditeurs, un enregistrement SPF défectueux ne pénalise pas seulement la délivrabilité. Il coupe toute communication avec vos clients.

Le SPF est l’un des trois protocoles d’authentification email fondamentaux, avec DKIM (DomainKeys Identified Mail) et DMARC (Domain-based Message Authentication, Reporting, and Conformance). Il fonctionne en publiant un enregistrement DNS TXT qui liste quelles adresses IP et quels serveurs sont autorisés à envoyer des emails pour votre domaine. À la réception d’un message, le serveur de messagerie vérifie l’IP émettrice dans votre enregistrement SPF. Si aucune correspondance n’est trouvée, l’email échoue à l’authentification.

Voilà pourquoi cela compte : en février 2024, Google et Yahoo ont exigé que tous les grands expéditeurs (5 000+ messages/jour) authentifient leurs emails avec SPF, DKIM et publient un enregistrement DMARC [1]. Microsoft a suivi en mai 2025, imposant les mêmes exigences pour Outlook.com, Hotmail.com et Live.com [2]. Ensemble, ces trois fournisseurs couvrent environ 90 % d’une base B2C typique. Un seul enregistrement SPF défaillant peut bloquer l’envoi à la majorité de votre audience du jour au lendemain.

Mais l’enjeu va au-delà de la délivrabilité. Le rapport 2024 du FBI sur la cybercriminalité Internet recense 193 407 signalements d’hameçonnage et d’usurpation (phishing et spoofing), la catégorie de cybercriminalité la plus signalée, pour des pertes estimées à 16,6 milliards de $, soit une hausse de 33 % par rapport à 2023 [3]. Les compromissions de messagerie professionnelle (BEC) représentent à elles seules 2,77 milliards de $ de pertes sur 21 442 incidents [4]. Une authentification email bien configurée, dès le SPF, constitue votre première ligne de défense contre l’usurpation de domaine.

Et ce ne sont pas que les fournisseurs de boîtes de réception qui renforcent la pression. PCI DSS v4.0.1, en vigueur en mars 2025, impose DMARC en quarantaine ou rejet pour toute organisation traitant des paiements par carte [5]. CISA BOD 18-01 impose p=reject aux domaines fédéraux américains. Le NCSC britannique, l’ASD australien et le CCCS canadien exigent tous DMARC pour les domaines gouvernementaux. Les assurances cyber imposent de plus en plus DMARC comme critère d’octroi. Pour un panorama complet, consultez notre synthèse mondiale des obligations DMARC.

En résumé : échouer SPF en 2026 n’est pas une simple contrariété. C’est un problème de délivrabilité, de conformité et de sécurité tout à la fois.

Voyons ensemble les six échecs SPF les plus courants et comment les résoudre.

À quoi cela ressemble : Les emails de services d’envoi légitimes (CRM, outil support ou système RH/ERP) échouent SPF parce que leurs adresses IP ne figurent pas dans votre enregistrement SPF.

Pourquoi cela arrive : C’est l’échec SPF le plus fréquent, généralement dû à une seule cause : un nouveau service d’envoi est installé et personne ne met à jour le DNS. Votre support commence à communiquer via Zendesk. Votre équipe technique intègre un ERP pour les notifications. Chacun de ces services utilise votre domaine comme expéditeur, et chacun doit être explicitement autorisé dans votre enregistrement SPF.

Le problème s’amplifie au fil du temps. Les organisations rachètent des sociétés utilisant d’autres systèmes d’envoi. Les prestataires changent leurs IP sans avertir. Un compte d’essai email passe en production sans que l’équipe DNS ne soit prévenue. Les groupes disposant de Salesforce, SAP, Zendesk et d’une messagerie principale sont particulièrement à risque.

Comment corriger :

Commencez par auditer tous les services expédiant des emails pour votre compte. Examinez vos rapports d’agrégation DMARC : ils affichent toutes les adresses IP qui envoient en votre nom, et si elles passent ou échouent SPF. Si vous utilisez Red Sift OnDMARC, la plateforme identifie automatiquement les expéditeurs non autorisés et les signale.

Une fois tous les services légitimes listés, ajoutez leurs mécanismes SPF à votre enregistrement. Chaque service possède son mécanisme include, du style include:spf.protection.outlook.com pour Microsoft 365 ou include:_spf.google.com pour Google Workspace.

Exemple : vous utilisez Google Workspace et Zendesk. Votre enregistrement SPF doit alors ressembler à :

v=spf1 include:_spf.google.com include:mail.zendesk.com ~all

Conseil pro : Planifiez un audit SPF trimestriel. À chaque fois qu’un nouveau prestataire est ajouté ou supprimé, mettez le DNS à jour. Les rapports DMARC facilitent la tâche en vous indiquant précisément les sources et les échecs. Pensez aussi à retirer les enregistrements SPF devenus inutiles, notamment pour éviter les problèmes d’alignement SPF (voir plus loin !).

À quoi cela ressemble : Votre enregistrement SPF provoque une PermError (erreur permanente) et tous les emails du domaine échouent l’authentification SPF. Aucun message ne passe.

Pourquoi cela arrive : RFC 7208 (la spécification SPF) limite l’évaluation SPF à 10 mécanismes DNS consultés à chaque vérification [6]. Les mécanismes include, a, mx et exists, ainsi que le modificateur redirect, comptent dans cette limite. ip4 et ip6 ne comptent pas, car ils sont littéraux et ne sollicitent pas le DNS.

La limite est vite atteinte : Microsoft 365 en consomme 2, Google Workspace 4, ajoutez SendGrid (1), Salesforce (2) et quelques services de plus et la limite est franchie. Chaque include peut aussi contenir des includes imbriqués qui s’ajoutent au total. Il s’agit bien de 10 requêtes DNS, y compris celles déclenchées par chaînage d’include.

Au-delà du 10e, si l’IP n’est pas trouvée, le serveur destinataire retourne PermError et arrête l’évaluation. DMARC traduit cela en échec SPF [7]. Vos emails sont rejetés ou passés en spam, et vous dépendez uniquement de DKIM, qui ne sert à rien si le service n’a pas configuré de signature DKIM.

Received-SPF: permerror (yourdomain.com: too many DNS lookups)
  client-ip=203.0.113.45;
  envelope-from=noreply@yourdomain.com;
  helo=mail.yourdomain.com;

À retenir : permerror indique que le serveur destinataire a atteint la limite des 10 recherches avant d’identifier un expéditeur autorisé, non que l’expéditeur est non autorisé. La raison est explicitée dans la string. client-ip et envelope-from sont à comparer avec votre SPF pour trouver la chaîne d’include fautive.

Autre limite moins connue : la règle des 2 recherches DNS vides. Si deux requêtes DNS renvoient NXDOMAIN (domaine inexistant) ou vide, une 3e requête void déclenche une PermError [8]. Cela arrive souvent si un include pointe vers un domaine qui n’a plus d’enregistrement SPF, comme un fournisseur obsolète.

Comment corriger :

D’abord, comptez vos requêtes DNS. Utilisez Red Sift Investigate pour interroger votre SPF et connaître le nombre exact de recherches.

Puis, réduisez ce nombre :

• Supprimez les services abandonnés. Si vous avez résilié Mailchimp il y a 6 mois mais laissé l’include, retirez-le. Les anciens CRM, outils d’email et includes ajoutés par des ex-collaborateurs sont fréquents.
• Éliminez les mécanismes ptr.ptr. Leur usage est fortement déconseillé, ils sont obsolètes et gaspillent des recherches.
• Déléguez certains envois à des sous-domaines. Chaque sous-domaine dispose de ses 10 requêtes autorisées. Faites passer vos emails marketing par info.votredomaine.com avec son propre SPF, et allégez le SPF du domaine principal.

Si même ainsi vous restez au-dessus de 10 recherches, le Dynamic SPF de Red Sift OnDMARC règle automatiquement le souci. Dynamic SPF remplace votre enregistrement complexe par un seul include intelligent, qui pointera exclusivement sur les IP actives pour votre domaine. Vous gérez les services sur OnDMARC sans modifier le DNS et restez sous la limite.

À quoi cela ressemble : SPF échoue pour tous les emails, ou l’enregistrement n’est tout simplement pas reconnu comme un SPF. Vous pouvez voir PermError ou None dans vos rapports DMARC.

Pourquoi cela arrive : Les enregistrements SPF suivent des règles de formatage strictes définies par RFC 7208. La moindre erreur peut tout faire échouer. Exemples d’erreurs fréquentes :

• Tag de version absent ou incorrect. Chaque enregistrement SPF doit commencer par v=spf1. Les fautes comme v=spf2, v=spf11 ou un espace en trop avant le tag invalidant l’enregistrement.
• Absence d’espaces entre les mécanismes. Chaque élément doit être séparé par un espace unique. Exemple contraire : include:_spf.google.cominclude:mail.zendesk.com (sans espace) rend l’évaluation impossible.
• Mécanismes mal formatés. Les mécanismes ip4 et ip6 exigent un deux-points devant la valeur (ip4:192.168.1.1), pas de signe égal ou slash.
• Mécanismes mal orthographiés. Taper incldue au lieu de include, ou ipv4 au lieu de ip4 invalide le champ.
• Utilisation du mécanisme désapprouvé ptr.ptr. Il reste parfois accepté mais est formellement déconseillé (RFC 7208) et surcharge le DNS inutilement.

Toutes ces erreurs impactent 100 % des emails. Le serveur destinataire ne parvient pas à analyser le SPF et retourne PermError (si l’évaluation est partielle) ou None (s’il n’identifie aucun SPF).

Comment corriger :

Passez systématiquement votre enregistrement SPF par un validateur avant publication. Red Sift Investigate décèle ces erreurs (syntaxe, nombre de requêtes, autres soucis) en quelques secondes.

Voici un modèle d’enregistrement SPF sain pour référence :

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all

Remarquez : v=spf1 en tête, espaces entre chaque mécanisme, deux-points (pas d’égal) après ip4, et un seul qualificateur ~all à la fin. Validez toujours après modification, puis attendez la propagation DNS (jusqu’à 24h) et contrôlez vos rapports DMARC pour tout échec inattendu.

À quoi cela ressemble : SPF retourne PermError, et toute l’authentification SPF échoue. Il s’agit d’un échec total, pas partiel.

Pourquoi cela arrive : La spécification SPF impose exactement un enregistrement TXT SPF par domaine [6]. Si un domaine dispose de plusieurs TXT SPF, les serveurs ne peuvent pas choisir lequel utiliser et retournent PermError.

Ce problème apparait souvent quand plusieurs équipes gèrent l’infrastructure email : l’IT publie SPF pour Microsoft 365, le marketing pose un SPF séparé pour sa plateforme, un consultant ajoute le sien pour la délivrabilité… Personne ne vérifie l’existant, et trois SPF cohabitent inutilement.

$ dig yourdomain.com TXT +short

"v=spf1 include:spf.protection.outlook.com ~all"
"v=spf1 include:_spf.google.com ~all"

À retenir : deux chaînes débutant par v=spf1. Un serveur ne sait pas choisir, donc il écarte les deux et retourne PermError, identique à la défaillance « limite de requête », mais avec la cause opposée : trop de SPF au lieu de trop de recherches. La solution consiste à fusionner tous les éléments dans un unique enregistrement, puis à vérifier par dig qu’un seul SPF subsiste.

Cela arrive aussi lors de migrations. Vous passez de Google Workspace à Microsoft 365 ? Si l’ancien SPF Google n’est pas supprimé lors de l’ajout du nouveau, vous vous retrouvez avec deux SPF et une configuration bancale.

Comment corriger :

Interrogez vos TXT DNS et cherchez les chaînes débutant par v=spf1. Il ne doit y en avoir qu’une.  S’il y en a plusieurs, fusionnez toutes les sources autorisées dans un seul enregistrement.

Exemple :

Enregistrement 1 : v=spf1 include:spf.protection.outlook.com ~all Enregistrement 2 : v=spf1 include:_spf.google.com ~all

Fusionnez-les pour obtenir :

v=spf1 include:spf.protection.outlook.com include:_spf.google.com ~all

Puis supprimez l’excédentaire. Après fusion, validez que le SPF combiné ne dépasse pas les 10 recherches DNS. Centraliser la gestion DNS et imposer une validation à chaque changement évite ce problème. Si plusieurs équipes gèrent les sources d’envoi, privilégiez une plateforme comme Red Sift OnDMARC où tous les expéditeurs sont centralisés.

À quoi cela ressemble : Vos emails passent SPF en direct, mais échouent lors d’un transfert ou via une liste de diffusion. Vos rapports DMARC révèlent des échecs SPF sur des IP connues comme des serveurs de transfert (universités, FAI, relais d’entreprise).

Pourquoi cela arrive : C’est une limite fondamentale du SPF, et le seul cas de cette liste qui n’est pas causé par une mauvaise configuration.

SPF vérifie que l’IP du serveur émetteur est autorisée par le domaine du destinataire. En cas de transfert email, le serveur de relais (B) envoie l’email au serveur final (C), en utilisant sa propre IP. Ce dernier vérifie l’enregistrement SPF de l’envoyeur initial et échoue car l’IP du relais n’est pas autorisée. SPF échoue donc.

Les listes de diffusion aggravent le problème, car elles modifient souvent le contenu (pied de page, headers de liste, liens de désabonnement…), ce qui invalide aussi les signatures DKIM. Si SPF et DKIM échouent, DMARC échoue aussi.

C’est voulu. SPF ne prend en compte que la livraison directe ; il n’a aucune solution native pour les serveurs intermédiaires.

Comment corriger :

Il n’existe pas de « correction » SPF pour le transfert, mais on peut bâtir une authentification résiliente qui compense :

• Faites de DKIM votre filet de sécurité principal. DKIM se base sur le contenu, pas le chemin. Si le corps de l’email n’est pas modifié lors du transfert, la signature DKIM reste valide et DMARC passe. Vérifiez que tous vos services signent en DKIM sur votre domaine. Voir notre guide de configuration SPF, DKIM et DMARC. Notre guide de configuration des protocoles email couvre aussi la gestion des clés DKIM, la sélection des sélecteurs et le dépannage.
• Privilégiez ~all (soft fail), pas -all (hard fail). Certains serveurs évaluent SPF avant DMARC. Avec -all, ils peuvent rejeter l’email avant d’examiner DKIM ou DMARC. En soft fail, le message arrive jusqu’à DMARC : une signature DKIM valide sauve la livraison. L’industrie, en 2026, recommande ~all pour les domaines émetteurs actifs [9]. Combiné à DMARC p=reject, vous gardez le même niveau d’exigence sans rejet précoce.
• Comprenez ARC (Authenticated Received Chain). ARC permet aux serveurs intermédiaires de préserver les résultats d’authentification initiaux. Quand un relais de confiance (Gmail, Microsoft 365…) scelle les résultats SPF et DKIM, le serveur final peut s’y référer même si SPF échoue sur la dernière étape. ARC est appliqué automatiquement par les principaux fournisseurs, rien à faire côté émetteur [10].

Remarque : l’IETF vient d’approuver l’abandon d’ARC. DKIM2 devrait prendre la relève.DKIM2 devrait prendre la relève.

• Surveillez les échecs liés au transfert via les rapports DMARC. Distinguez les échecs liés au transfert des vraies tentatives d’usurpation. Un relais affiche généralement SPF fail/DKIM pass et provient d’IP connues (mail.universite.edu, relais corporate). Les tentatives de spoof apparaissent sur des IP inconnues et combinent SPF + DKIM en échec.

À quoi cela ressemble : SPF passe (IP expéditrice autorisée), mais DMARC échoue tout de même. Cela surprend beaucoup de monde, mais SPF pass ≠ DMARC pass. Pour comprendre la complémentarité de SPF, DKIM et DMARC, la nuance est clé.

Pourquoi cela arrive : DMARC exige que le domaine ayant réussi l’authentification corresponde à celui visible dans le champ From. Pour SPF, cela signifie que le domaine Return-Path (aussi appelé bounce address, envelope from, ou MAIL FROM) doit être identique, ou un sous-domaine, du domaine From qui s’affiche côté destinataire.

Beaucoup de services tiers utilisent leur propre domaine par défaut en Return-Path. Par exemple, Salesforce emploiera son domaine pour la gestion des rebonds, sauf configuration contraire. SPF vérifie le domaine Return-Path, trouve l’IP Salesforce dans le SPF Salesforce, SPF passe. Mais DMARC contrôle ensuite l’alignement : « Le domaine Return-Path correspond-il au From visible ? » Si votre From est @votredomaine.com et le Return-Path @bounce.salesforce.com, l’alignement échoue. SPF passe, mais l’alignement DMARC échoue. Si vous ne pouvez aligner SPF, DKIM devient critique.

C’est là que nombre d’organisations s’y perdent, surtout au moment de déployer DMARC. SPF est correct, mais DMARC refuse, et la cause est invisible.

Comment corriger :

Pour chaque service expéditeur, configurez le Return-Path (adresse bounce) pour utiliser votre domaine ou un sous-domaine. Selon la plateforme :

• Salesforce : Désactivez la gestion des rebonds pour que Return-Path utilise votre domaine.
• Microsoft 365 : L’alignement Return-Path est automatique dès lors que vous utilisez votre propre domaine.
• Plateformes marketing (HubSpot, Marketo, Mailchimp) : La plupart proposent des options envelope-from personnalisées. Consultez leur documentation pour la config.

DMARC propose deux modes :

• Alignement strict (aspf=s)aspf=s) : Return-Path doit correspondre exactement au From.
• Alignement relâché (aspf=r)aspf=r) : Return-Path peut être un sous-domaine du From. C’est le mode par défaut, recommandé pour la plupart.

Avec l’alignement relâché, si votre From est @votredomaine.com et le Return-Path @mail.votredomaine.com, l’alignement passe. Cela permet d’utiliser des sous-domaines tout en restant DMARC compliant.

Votre outil diagnostic clé : les rapports DMARC, qui affichent les statuts SPF pass/fail et l’alignement, ce qui vous indique si le souci tient à l’autorisation (SPF) ou à l’alignement (correspondance Return-Path/From).

Red Sift OnDMARC affiche cela visuellement, pour voir d’un coup d’œil quels expéditeurs passent SPF mais échouent l’alignement, et où la discordance de domaine se trouve. Lancez votre mise en place DMARC pas à pas pour corriger chaque expéditeur.

Les rapports d’agrégation DMARC contiennent tout ce dont vous avez besoin pour repérer et corriger les échecs SPF. Voici ce qu’il faut surveiller :

Si vous analysez manuellement les rapports DMARC (en lisant le XML), vous passez des heures sur un travail qu'une plateforme peut réaliser en quelques secondes. Red Sift OnDMARC transforme les données brutes des rapports agrégés en tableaux de bord clairs et exploitables, qui indiquent précisément quels expéditeurs échouent, pourquoi ils échouent, et comment résoudre les problèmes. Pour découvrir les meilleurs outils à utiliser à chaque étape, consultez notre guide des meilleurs outils d'authentification email.

Les échecs SPF peuvent être corrigés. Chacun des six cas d'échec abordés dans ce guide dispose d'une méthode de diagnostic claire et d'une solution concrète. Le véritable défi n'est pas la complexité, c'est la visibilité.

Sans rapport DMARC, vous avancez à l’aveugle. Vous ne savez pas quels services envoient au nom de votre domaine, lesquels échouent à l’authentification, ni pourquoi. Avec, chaque échec devient un élément traçable que vous pouvez analyser et résoudre.

Si vous faites face à des échecs SPF actuellement, commencez par une analyse gratuite avec Red Sift Investigate pour vérifier l’état actuel de votre enregistrement. Pour une surveillance continue, la gestion automatisée des expéditeurs et un chemin clair vers l’application de DMARC, démarrez un essai gratuit de Red Sift OnDMARC.

[1] An update on bulk sender requirements - Google

[2] Strengthening Email Ecosystem - Microsoft Community Hub

[3] FBI Releases Annual Internet Crime Report

[4] 2024 IC3 Annual Report

[5] PCI DSS v4.0.1 Summary of Changes

[6] RFC 7208 - Sender Policy Framework (SPF)

[7] The SPF lookup limit explained - Mailhardener

[8] RFC 7208 Section 4.6.4 - DNS Lookup Limits

[9] SPF failures: Hard fail vs Soft fail - Red Sift

[10] ARC: Solving the DMARC Problem with Email Forwarding - Mailflow Authority