Échecs SPF des e-mails : 5 erreurs d’enregistrement qui cassent la délivrabilité (et comment les corriger)

janvier 5, 2026 • février 3, 2026 • Lecture : 29 min • Views: 6

Cet article vous a aidé ?

Les défaillances de délivrabilité des e-mails n’apparaissent que rarement sous la forme d’une alerte nette « tout tombe » . Elles se manifestent par un glissement dans la chaîne : le marketing dit que les campagnes « sous-performent », les ventes disent que les leads « disparaissent », et le support commence à recevoir des captures d’écran de messages de rejet qui ont l’air d’avoir été rédigés par un comité de RFC.

SPF est un coupable fréquent parce qu’il est à la fois simple et incroyablement facile à mal configurer dans le DNS de production. Le pire : vous pouvez casser SPF en pensant l’améliorer. Arrêtons de faire ça.

SPF en termes opérationnels (ce qu’il fait réellement)

SPF (Sender Policy Framework) est une politique publiée dans le DNS qui indique à un récepteur quelles IPs sont autorisées à envoyer du courrier en utilisant un domaine dans l’identité SMTP « envelope-from » (le domaine Return-Path). Le récepteur compare l’adresse IP de connexion à cette politique et produit un résultat : pass, fail, softfail, neutral, none, temperror ou permerror.

En production, SPF remplit deux fonctions :

Empêcher le spoofing occasionnel de votre domaine dans l’envelope-from (pas nécessairement dans l’en-tête From: visible).
Nourrir la politique en aval, notamment DMARC. DMARC utilise SPF (et/ou DKIM) plus des règles d’alignement pour décider s’il faut mettre en quarantaine ou rejeter.

SPF n’est pas magique. Il n’en crypte rien. Il ne prouve pas qu’un humain a tapé le courriel. Il ne résiste pas au transfert dans de nombreux cas. C’est une vérification de politique liée à l’IP du client SMTP au moment de la livraison. Voilà pourquoi un enregistrement SPF « valide » peut encore échouer dans le monde réel lorsque votre chemin de messagerie change.

Une nuance supplémentaire : SPF est évalué sur le domaine de l’envelope-from (Return-Path), pas sur l’en-tête From: que les gens voient. Si votre fournisseur utilise bounces.vendor.example comme return-path et que votre domaine DMARC est example.com, SPF peut passer mais ne pas s’aligner. C’est un problème distinct avec le même symptôme : « DMARC a échoué ».

Idée paraphrasée de Werner Vogels : Vous le construisez, vous le gérez. Le courrier n’échappe pas à la règle. Si vous déléguez l’envoi à des fournisseurs, vous restez responsable des résultats d’authentification.

Blague #1 : SPF, c’est comme le videur d’une boîte de nuit qui vérifie la liste des invités. Si vous réécrivez la liste pendant le service, ne soyez pas surpris quand personne ne passera la porte.

Faits intéressants et contexte historique

SPF est apparu avant DMARC. SPF s’est largement déployé au milieu des années 2000 ; DMARC est arrivé plus tard pour unifier SPF et DKIM sous une politique du propriétaire du domaine.
La « limite de 10 recherches DNS » est une friction intentionnelle. Elle existe pour empêcher un récepteur d’être forcé à effectuer un travail DNS récursif coûteux par message (un vecteur DoS classique).
Le type TXT a gagné la bataille des enregistrements. SPF avait autrefois un type RR dédié, mais TXT est devenu la norme pratique en raison du support DNS et des outils incohérents.
SPF vérifie l’IP de connexion, pas « l’expéditeur ». Voilà pourquoi les relayeurs sortants, les pools SaaS partagés et les NAT d’egress sur site sont des pièges courants.
« ~all » est devenu populaire car il semblait plus sûr. Le softfail est souvent utilisé lors du déploiement, mais de nombreuses organisations n’achèvent jamais la migration vers « -all », laissant des couloirs de spoofing ouverts.
Les récepteurs traitent le permerror sévèrement. Une erreur de syntaxe ou une explosion de recherches peut produire un « permerror », et certains récepteurs le traitent effectivement comme un échec pour les décisions d’application.
Les macros SPF existent et valent rarement le coup. Elles sont puissantes et fragiles, et peuvent créer un comportement de recherche imprévisible selon les récepteurs.
L’alignement est la raison pour laquelle DMARC a changé la donne. Un « pass » SPF ne suffit pas ; il doit être aligné avec le domaine From: visible pour satisfaire DMARC via SPF.
Le flattening SPF est un contournement, pas une vertu. Il échange l’indirection DNS contre la maintenance d’une liste d’IP, et il peut devenir obsolète rapidement à moins d’être automatisé.

Playbook de diagnostic rapide

Si vous êtes en astreinte et que des e-mails sont rejetés, vous n’avez pas le temps pour la philosophie. Vous avez besoin d’une séquence déterministe qui trouve rapidement le goulot d’étranglement.

Première étape : identifiez quelle identité échoue (SPF vs DMARC vs « un truc fournisseur »)

Récupérez un vrai bounce ou un en-tête du récepteur provenant d’une livraison échouée. Recherchez : spf=, dmarc=, dkim=, Authentication-Results:, ou un « SPF fail » explicite.
Extrayez le domaine envelope-from (Return-Path) et l’IP de connexion (souvent indiqués dans le bounce ou dans le log SMTP).
Décidez si vous corrigez SPF, l’alignement, ou le routage. Si SPF passe mais DMARC échoue, vous pouvez avoir affaire à un problème d’alignement ou de DKIM.

Deuxième étape : validez la publication DNS et la propagation

Interrogez la vue autoritative du DNS (pas le résolveur mis en cache de votre laptop). Confirmez qu’il y a exactement une politique SPF cohérente et qu’elle commence par v=spf1.
Comparez plusieurs résolveurs (publics et internes). Si les résultats diffèrent, c’est de la propagation ou du DNS split-horizon.
Vérifiez les TTL pour estimer quand le monde convergera. Ne devinez pas. Lisez le TTL.

Troisième étape : évaluez l’enregistrement SPF tel que le récepteur le ferait

Comptez les recherches DNS (includes, a, mx, ptr, exists, redirect). Si vous êtes proche de 10, supposez que vous dépassez 10 quelque part.
Testez l’IP expéditrice spécifique contre l’enregistrement. SPF porte sur l’IP qui s’est connectée, pas sur le nom du fournisseur.
Recherchez des mécanismes fragiles : ptr, macros, chaînes redirect, includes excessifs.

Quatrième étape : décidez de la correction la moins risquée

Si vous avez plusieurs TXT SPF : fusionnez en un seul. C’est généralement la victoire la plus rapide.
Si vous dépassez la limite de recherches : réduisez les includes, supprimez a/mx si non nécessaires, ou aplatissez (avec automatisation) si nécessaire.
Si vous échouez à cause d’un fournisseur qui envoie depuis des plages IP inattendues : corrigez le chemin d’envoi ou la configuration du fournisseur, pas seulement l’enregistrement SPF.
Si DMARC applique une politique et que SPF n’est pas aligné : corrigez l’alignement (return-path personnalisé) ou appuyez-vous sur l’alignement DKIM.

Les 5 erreurs d’enregistrement SPF qui cassent la délivrabilité (et leurs corrections)

1) Publier plusieurs enregistrements TXT SPF pour le même nom

Ce qui arrive : Le récepteur interroge les TXT de example.com et obtient deux chaînes qui commencent toutes deux par v=spf1. Selon la spécification SPF, c’est un permerror. Beaucoup de récepteurs traitent le permerror comme un échec ou au moins comme « suspect », et votre politique DMARC peut le punir.

Pourquoi ça arrive en entreprise : Différentes équipes « possèdent » différents expéditeurs. Le marketing ajoute un enregistrement SPF pour une plateforme. L’informatique ajoute un autre pour le relais corporate. Un fournisseur ajoute le sien lors de l’intégration. Personne ne les fusionne parce que les interfaces DNS ne crient pas quand vous faites quelque chose d’auto-destructeur.

Correction : Vous devez avoir exactement un enregistrement SPF par domaine (par nom DNS). Fusionnez les mécanismes dans une seule chaîne, gardez-la sous les limites, et supprimez l(es) enregistrement(s) supplémentaire(s).

Conseil opérationnel : Traitez SPF comme une bibliothèque partagée : un seul package, plusieurs contributeurs, revue stricte. Si vous ne contrôlez pas qui modifie le DNS, vous ne contrôlez pas la délivrabilité.

2) Dépasser la limite de 10 recherches DNS (permerror déguisé)

Ce qui arrive : L’évaluation SPF autorise au maximum 10 recherches DNS « mécanismes » lors du traitement (includes, redirects, a, mx, ptr, exists). Il est facile de dépasser ce nombre quand vous enchaînez les includes (fournisseur inclut fournisseur inclut fournisseur). Quand vous dépassez la limite, les récepteurs retournent permerror. Ce n’est pas « temporaire ». C’est « votre politique est invalide ».

Options de correction (choisir selon le risque) :

Privilégier moins d’includes. Supprimez les expéditeurs non utilisés. Remplacez a et mx par des ip4/ip6 explicites si vous connaissez l’egress réel.
Utiliser des sous-domaines par expéditeur. Placez les fournisseurs sur bounce.vendor.example.com et alignez DMARC via DKIM ou return-paths personnalisés. Cela évite de tout entasser dans l’enregistrement apex.
Aplatir en dernier recours. Remplacez les chaînes d’includes par des plages IP littérales. Automatisez les mises à jour ou acceptez qu’elles se dégradent.

À éviter : N’utilisez pas ptr pour « simplifier » SPF. Ça ajoute des recherches et de l’imprévisibilité, et beaucoup de récepteurs s’en méfient. N’empilez pas les includes « au cas où ». SPF n’est pas une liste de souhaits.

3) Utiliser le mauvais domaine : SPF s’applique au Return-Path, pas au From:

Ce qui arrive : Vous publiez SPF sur example.com. Votre plateforme SaaS utilise bounce.vendor-mail.example.net comme envelope-from. Les récepteurs vérifient SPF pour example.net (ou le domaine return-path utilisé), pas pour example.com. Votre enregistrement SPF peut être parfait et pourtant hors de propos.

Symptômes : Vous « passez SPF » pour certains flux (MTA corporate) et « échouez SPF » pour d’autres (plateforme marketing), même si les deux semblent provenir de « example.com » pour un humain.

Correction :

Configurez le fournisseur pour utiliser un return-path personnalisé sous votre domaine (patron courant : bounce.mail.example.com).
Publiez SPF pour ce domaine de return-path qui autorise le fournisseur.
Si DMARC est en enforcement, assurez-vous de l’alignement : SPF ne peut satisfaire DMARC que si le domaine envelope-from s’aligne avec le domaine From: (même domaine ou sous-domaine selon l’alignement relax/strict).

Prise de position : Si un fournisseur ne peut pas supporter un return-path personnalisé et DKIM aligné, considérez-le comme un risque pour la délivrabilité, pas comme un partenaire.

4) Erreurs de syntaxe, problèmes de guillemets et formatage « utile » des interfaces DNS

Ce qui arrive : SPF est du texte, mais pas de la poésie libre. Un espace manquant, une guillemet errante, ou un enregistrement mal scindé peut transformer un « pass » en permerror. Certains fournisseurs DNS replient automatiquement les TXT longs en plusieurs chaînes citées (ce qui convient), tandis que d’autres créent plusieurs enregistrements TXT (ce qui ne convient pas). Certaines UI tentent d’être aidantes et finissent destructrices.

Fauts de syntaxe courants :

Absence de v=spf1 au début.
Utiliser des virgules au lieu d’espaces : v=spf1,ip4:... (non).
Oublier complètement le mécanisme all (politique ambiguë).
Fautes de frappe dans les mécanismes : incldue:, ip:1.2.3.4 (incorrect), ou CIDR mal formé.
Utiliser des majuscules d’une manière que certains parseurs cassés gèrent mal (rare, mais pourquoi tenter le sort ?).

Correction : Validez l’enregistrement publié exactement comme les récepteurs le liront. Utilisez des requêtes autoritatives. Ensuite exécutez un évaluateur SPF contre une IP expéditrice connue. Ne faites pas confiance à l’aperçu de l’UI DNS.

5) Mal comprendre le qualificateur : -all vs ~all vs ?all (et prétendre que c’est « juste une préférence »)

Ce qui arrive : Le mécanisme all définit le comportement par défaut pour tout ce qui n’est pas explicitement autorisé. Le qualificateur exprime votre posture :

-all : échec dur. Les expéditeurs non autorisés doivent être rejetés.
~all : softfail. « Probablement non autorisé, mais accepter avec suspicion. »
?all : neutral. « Aucune opinion. »
+all : tout passer. Ce n’est pas SPF ; c’est de l’art de performance.

Correction : Utilisez -all quand vous connaissez réellement vos expéditeurs. Utilisez ~all uniquement comme état temporaire de déploiement avec une date butoir. Utilisez ?all rarement, et seulement si vous ne pouvez vraiment pas énumérer les expéditeurs (et acceptez alors le risque de spoofing).

Blague #2 : Si votre SPF se termine par +all, vous n’avez pas configuré la sécurité des e-mails — vous avez installé un paillasson « Bienvenue, attaquants ».

Erreurs courantes : symptômes → cause racine → correction

Un permerror SPF apparaît soudain après un « petit changement DNS »

Symptômes : Les bounces mentionnent « SPF permerror », « trop de recherches DNS », ou « SPF invalide ». Cela a commencé dans l’heure qui a suivi une mise à jour DNS.

Cause racine : Vous avez franchi la limite de 10 recherches en ajoutant un include de plus, ou vous avez créé plusieurs enregistrements TXT SPF.

Correction : Fusionnez en un seul enregistrement TXT SPF et réduisez les recherches. Supprimez les includes non nécessaires ; remplacez a/mx par des plages IP explicites lorsque c’est possible.

SPF passe mais DMARC échoue (et le récepteur rejette encore)

Symptômes : L’en-tête montre spf=pass mais dmarc=fail ; les bounces mentionnent la politique DMARC. Les utilisateurs rapportent « ça marche vers Gmail mais pas vers des domaines d’entreprise », ou inversement.

Cause racine : SPF a passé pour un domaine envelope-from qui ne s’aligne pas avec le domaine From:. Ou DKIM manque/est cassé et SPF est le seul recours.

Correction : Configurez un return-path personnalisé sous votre domaine (alignement), ou assurez-vous que DKIM signe en alignement avec le domaine From: et survive au chemin d’envoi.

SPF échoue seulement pour un flux fournisseur

Symptômes : Le courrier Office 365 passe ; la plateforme marketing échoue. Ou le transactional passe ; le ticketing échoue.

Cause racine : Le fournisseur envoie depuis des IPs non couvertes par l’enregistrement SPF pour le domaine de return-path pertinent ; ou le fournisseur utilise un domaine envelope-from différent de celui que vous supposiez.

Correction : Identifiez l’IP de connexion et le domaine envelope-from à partir d’en-têtes réels. Mettez à jour l’enregistrement SPF correct (souvent un sous-domaine). Privilégiez l’include du fournisseur pour son pool d’envoi si cela reste sous la limite de recherches.

SPF « none » apparaît même si vous « avez configuré SPF il y a des mois »

Symptômes : Les récepteurs affichent spf=none. Vous jurez que SPF existe.

Cause racine : Vous avez publié SPF sur www.example.com ou sur un domaine différent de celui du return-path. Ou le DNS split-horizon sert des réponses différentes publiquement.

Correction : Interrogez le domaine return-path réellement utilisé dans le message. Validez le DNS autoritatif visible depuis l’extérieur. Supprimez les enregistrements internes uniquement ou alignez les zones internes/externes.

SPF échoue après activation d’un nouveau relais sortant ou changement de NAT

Symptômes : Tout était stable ; puis l’infrastructure a changé (nouvelles IPs d’egress, nouveau pool de relais). Maintenant les livraisons se dégradent.

Cause racine : SPF autorisait seulement les anciennes IPs d’egress. L’IP client SMTP a changé.

Correction : Mettez à jour SPF avec les nouvelles plages d’egress (ou l’include publié du relais). Vérifiez aussi que le relais est bien utilisé pour tous les flux ; les configurations hybrides fuient souvent du trafic direct vers Internet.

Résultats SPF intermittents selon les destinataires

Symptômes : Certains destinataires voient pass, d’autres fail ou none. Cela varie selon la région/le fournisseur.

Cause racine : Différences de propagation DNS, caches obsolètes, ou serveurs de noms autoritatifs non synchronisés. Parfois c’est un échec DNSSEC ou un problème de chemin de résolveur.

Correction : Vérifiez les serveurs autoritatifs directement et comparez entre les résolveurs. Assurez-vous que tous les NS servent des TXT SPF identiques. Corrigez le processus de déploiement DNS ; réduisez temporairement le TTL lors de fenêtres de changement contrôlées.

Tâches pratiques (commandes, sorties, décisions)

Ci‑dessous des tâches éprouvées sur le terrain que vous pouvez exécuter depuis un hôte Linux avec des outils communs. Chaque tâche inclut : la commande, une sortie représentative, ce que ça signifie, et la décision à prendre.

Task 1: Pull the published SPF TXT record (simple view)

cr0x@server:~$ dig +short TXT example.com
"v=spf1 ip4:203.0.113.10 include:_spf.google.com -all"

Ce que ça signifie : Il y a au moins un enregistrement TXT ; une chaîne ressemble à SPF.

Décision : Si vous voyez plus d’une chaîne v=spf1 ici, vous avez probablement le problème « plusieurs TXT SPF » et vous devez fusionner immédiatement.

Task 2: Detect multiple SPF records explicitly

cr0x@server:~$ dig TXT example.com +noall +answer
example.com.  300 IN TXT "v=spf1 ip4:203.0.113.10 -all"
example.com.  300 IN TXT "v=spf1 include:spf.mailvendor.example ~all"

Ce que ça signifie : Deux politiques SPF sont publiées sur le même nom propriétaire.

Décision : Considérez-le comme un risque de permerror. Remplacez-les par une seule chaîne SPF fusionnée. Ne « laissez pas les deux et espérez que les récepteurs en choisiront une ». Ils ne devraient pas le faire.

Task 3: Query authoritative nameservers (avoid caching lies)

cr0x@server:~$ dig +short NS example.com
ns1.dnsprovider.example.
ns2.dnsprovider.example.

cr0x@server:~$ dig +noall +answer TXT example.com @ns1.dnsprovider.example
example.com.  300 IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.google.com -all"

Ce que ça signifie : Vous inspectez ce que le serveur autoritatif sert, pas ce que résolveur a mis en cache hier.

Décision : Si ns1 et ns2 diffèrent, vous avez un problème de publication DNS. Corrigez cela d’abord ; le courrier suit ensuite.

Task 4: Inspect TTL to estimate propagation time

cr0x@server:~$ dig TXT example.com +noall +answer
example.com.  3600 IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.google.com -all"

Ce que ça signifie : Le TTL est de 3600 secondes (une heure). Les récepteurs peuvent mettre en cache jusqu’à cette durée (parfois plus longtemps avec des résolveurs défectueux).

Décision : Si vous avez besoin d’un rollback rapide, réduisez le TTL avant les changements risqués pendant une fenêtre planifiée. Pendant un incident, changer le TTL ne va pas instantanément vider les caches.

Task 5: Check if your outbound IP is what you think it is

cr0x@server:~$ curl -s ifconfig.me
203.0.113.55

Ce que ça signifie : L’egress Internet de cet hôte est 203.0.113.55.

Décision : Si votre SPF n’inclut pas cette IP (ou la plage de votre relais), SPF échouera pour les envois directs depuis cet hôte/réseau. Décidez si vous devez router le mail via le relais prévu ou mettre à jour SPF.

Task 6: Confirm which SMTP client actually connects to the internet (Postfix logs)

cr0x@server:~$ sudo grep -E "to=<|relay=" /var/log/mail.log | tail -n 3
Jan 03 10:11:12 mx1 postfix/smtp[23144]: 3F2A0123: to=, relay=aspmx.l.google.com[142.250.115.27]:25, delay=1.2, delays=0.1/0.1/0.4/0.6, dsn=2.0.0, status=sent
Jan 03 10:12:01 mx1 postfix/smtp[23188]: 9ABCD456: to=, relay=203.0.113.200[203.0.113.200]:587, delay=0.9, delays=0.1/0.1/0.2/0.5, dsn=2.0.0, status=sent
Jan 03 10:12:45 mx1 postfix/smtp[23210]: 7CDE9012: to=, relay=aspmx.l.google.com[142.250.115.27]:25, delay=1.0, delays=0.1/0.1/0.3/0.5, dsn=2.0.0, status=sent

Ce que ça signifie : Certains mails partent directement vers les destinataires ; d’autres passent par un smarthost à 203.0.113.200.

Décision : Le routage mixte augmente la complexité SPF parce que l’IP de connexion change. Décidez si vous imposez un chemin sortant unique (préféré) ou si SPF doit couvrir toutes les IPs d’egress possibles.

Task 7: Extract Return-Path and Authentication-Results from a raw message

cr0x@server:~$ sed -n '1,80p' message.eml | egrep -i '^(return-path|authentication-results|received|from:|dkim-signature):'
Return-Path: 
Authentication-Results: mx.recipient.example; spf=fail (sender IP is 198.51.100.77) smtp.mailfrom=bounce.mail.example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com
Received: from mta77.vendor.example (mta77.vendor.example [198.51.100.77])
From: Billing 
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; ...

Ce que ça signifie : SPF a échoué pour bounce.mail.example.com depuis l’IP 198.51.100.77, mais DKIM a passé et DMARC a passé (parce que DKIM s’est aligné avec example.com).

Décision : Si DMARC passe via DKIM, l’échec SPF peut être tolérable mais reste néfaste pour la réputation. Décidez si vous corrigez SPF quand même (recommandé) ou si vous l’acceptez temporairement en assurant la stabilité de DKIM.

Task 8: Resolve the include chain (and spot hidden lookup bombs)

cr0x@server:~$ dig +short TXT _spf.google.com
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

Ce que ça signifie : Un include se déploie en plusieurs includes. C’est normal, mais cela consomme le budget de recherches.

Décision : Quand vous empilez plusieurs « gros » includes, vous pariez que vous ne dépasserez pas 10 recherches. Comptez-les. Si vous êtes proche, refactorez avant que ça casse.

Task 9: Count DNS-lookups roughly (pragmatic method)

cr0x@server:~$ spfquery -ip 198.51.100.77 -sender bounces@bounce.mail.example.com -helo mta77.vendor.example
result: pass
smtp.mailfrom: bounce.mail.example.com
Received-SPF: pass (bounce.mail.example.com: domain of bounces@bounce.mail.example.com designates 198.51.100.77 as permitted sender)

Ce que ça signifie : L’évaluation SPF locale retourne pass pour cette IP et cet expéditeur. Ce n’est pas identique au comportement de chaque récepteur, mais c’est un signal fort.

Décision : Si votre test dit pass mais qu’un récepteur dit fail, suspectez qu’il a évalué un domaine différent (mismatch alignement/return-path), vu un DNS différent (propagation/split-horizon), ou atteint la limite de recherches à cause d’un comportement de résolution différent.

Task 10: Verify you didn’t accidentally publish SPF on the wrong name

cr0x@server:~$ dig +short TXT www.example.com
"v=spf1 include:spf.mailvendor.example -all"

cr0x@server:~$ dig +short TXT example.com
"google-site-verification=abc123"

Ce que ça signifie : SPF existe sur www.example.com mais pas sur l’apex example.com.

Décision : Si votre courrier utilise example.com en return-path, SPF est effectivement absent. Déplacez l’enregistrement SPF vers le nom de domaine correct (ou mettez-le sur le domaine return-path que vous utilisez réellement).

Task 11: Check for split-horizon DNS (internal vs external answers)

cr0x@server:~$ dig +short TXT example.com @10.0.0.53
"v=spf1 ip4:10.10.10.10 -all"

cr0x@server:~$ dig +short TXT example.com @1.1.1.1
"v=spf1 ip4:203.0.113.10 include:_spf.google.com -all"

Ce que ça signifie : Le résolveur interne sert un SPF interne (incompréhensible pour l’Internet public), tandis que les résolveurs publics voient la vraie politique.

Décision : Si des systèmes internes envoient vers Internet et évaluent SPF (ou si des décisions de routage/signature dépendent de lui), le split-horizon peut causer des échecs auto-infligés. Alignez les zones ou assurez-vous que les résolveurs internes voient la même vue publique de SPF.

Task 12: Confirm DKIM alignment when SPF is fragile

cr0x@server:~$ sed -n '1,120p' message.eml | egrep -i '^(from:|dkim-signature|authentication-results):'
From: Notifications 
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; ...
Authentication-Results: mx.recipient.example; spf=softfail smtp.mailfrom=bounce.vendor.example; dkim=pass header.d=example.com; dmarc=pass header.from=example.com

Ce que ça signifie : DKIM passe pour example.com, et DMARC passe même si SPF est softfail parce que SPF ne s’aligne pas (ou est faible).

Décision : Si vous ne pouvez pas corriger rapidement SPF (contraintes fournisseur, transfert, limites d’includes), assurez-vous que DKIM est robuste et aligné. Mais ne laissez pas SPF cassé indéfiniment ; il affecte toujours la confiance et certains heuristiques de récepteur.

Task 13: Validate that your SPF ends with a sane default

cr0x@server:~$ dig +short TXT example.com | tr ' ' '\n' | tail -n 1
-all"

Ce que ça signifie : La politique se termine par -all, une posture claire.

Décision : Si elle se termine par ~all et que vous pensez connaître tous les expéditeurs, planifiez la migration vers -all après vérification des logs pour expéditeurs inconnus.

Task 14: Inspect whether you’re using risky mechanisms (ptr, exists, macros)

cr0x@server:~$ dig +short TXT example.com
"v=spf1 ptr exists:%{i}._spf.example.com include:spf.mailvendor.example -all"

Ce que ça signifie : ptr et exists sont en jeu ; des macros sont utilisées. C’est du SPF avancé et souvent fragile.

Décision : À moins d’avoir un besoin très spécifique et de tester sur plusieurs récepteurs, retirez ptr et les exists pilotés par macros. Remplacez par des ip4/ip6 explicites ou des includes fournisseurs stables.

Trois mini-récits d’entreprise depuis les tranchées SPF

Mini-récit n°1 : L’incident causé par une mauvaise hypothèse

L’entreprise semblait propre sur le papier : DMARC en p=reject, DKIM signé via un relais sortant central, et un enregistrement SPF soigné. Quelqu’un a approuvé une nouvelle plateforme RH pour envoyer des e-mails d’onboarding. C’était « juste un e-mail », donc les achats ont été plus rapides que l’ingénierie.

La checklist d’onboarding du fournisseur disait « Ajoutez cet enregistrement SPF ». L’admin RH a fait exactement cela — ajoutant un second enregistrement TXT à l’apex avec un nouveau v=spf1. Personne n’a remarqué parce que les changements DNS ne déclenchent pas d’astreinte tant qu’ils ne cassent rien.

En quelques heures, plusieurs récepteurs ont commencé à retourner permerror sur SPF. L’application DMARC s’est déclenchée là où DKIM n’était pas présent (certains flux transactionnels ne signaient pas — de vieilles applis envoyaient encore directement). Ces messages ont commencé à rebondir. Le symptôme visible n’était pas « SPF cassé ». C’était « les réinitialisations de mot de passe n’arrivent pas ». C’est comme ça qu’on apprend que le mail fait partie de votre système d’authentification.

Les ingénieurs ont finalement extrait un en-tête défaillant, vu spf=permerror, et trouvé deux réponses TXT SPF. Ils ont fusionné les politiques en un seul enregistrement et supprimé le duplicata. Puis ils ont découvert pire : la moitié des mails de l’entreprise ne passait même pas systématiquement par le relais.

La vraie correction n’a pas été seulement de fusionner les TXT. Ils ont imposé le routage sortant pour empêcher les applis d’envoyer directement vers Internet, puis renforcé SPF avec -all. L’hypothèse erronée n’était pas technique ; elle était organisationnelle : « quelqu’un d’autre gère le mail ». En réalité, le mail vous possède.

Mini-récit n°2 : L’optimisation qui a tourné court

Une équipe plateforme voulait « simplifier le DNS » et réduire les dépendances fournisseurs. Ils ont remplacé plusieurs includes par une liste aplatie d’adresses IP. Cela avait l’air pro : moins de recherches, évaluation déterministe, et SPF plus rapide. Ils ont même écrit un petit script pour générer l’enregistrement aplati.

Puis la gestion du changement a eu lieu. Le script n’a pas été intégré au CI/CD ; il vivait sur un laptop. Ça a fonctionné jusqu’à ce que la personne parte en vacances, et le fournisseur a fait pivoter son infrastructure d’envoi. Ce n’est pas hypothétique — de grandes plateformes e-mail déplacent leur espace IP pour la capacité et la réputation.

En une semaine, des échecs SPF sporadiques sont apparus. Seuls certains destinataires étaient affectés parce que le fournisseur utilisait des pools différents par région et par type de message. L’équipe a chassé « filtrage spécifique au destinataire » pendant deux jours avant que quelqu’un compare l’IP de connexion défaillante à la liste aplatie SPF.

Le retour de manivelle n’était pas l’aplatissement en soi ; c’était l’aplatissement sans automatisation, surveillance et cadence de mise à jour. Ils sont revenus aux includes fournisseurs, puis ont réintroduit l’aplatissement correctement via un job programmé qui récupérait les plages fournisseurs et publiait le DNS via la pipeline standard, avec rollback et visibilité des diffs.

La leçon : l’ingénierie de fiabilité déteste les « améliorations ponctuelles ». Si l’amélioration crée une nouvelle obligation de maintenance, automatisez-la ou n’en faites rien.

Mini-récit n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre organisation avait une politique : chaque changement DNS lié aux e-mails (SPF, sélecteurs DKIM, DMARC, MX) nécessitait une pull request dans l’infrastructure-as-code, avec un linter et un simple contrôle canari. Personne ne trouvait ça glamour. C’était surtout du YAML et des discussions sur les TTL.

Un vendredi, un account manager fournisseur a envoyé un e‑mail « urgent » : ajoutez un include au SPF avant la fin de la journée, sinon les campagnes seraient retardées. L’équipe marketing a escaladé, bien sûr. L’ingénieur d’astreinte a ajouté le changement via la PR habituelle.

Le linter CI a échoué. Il a signalé que le nouvel include pousserait l’évaluation SPF au-delà de la limite de recherches à cause d’une chaîne existante. L’ingénieur n’avait pas besoin d’être un expert en deliverability ; le processus l’a intercepté.

Ils ont répondu avec une alternative sensée : publier un sous-domaine dédié pour le return-path de ce fournisseur et garder l’apex SPF lean. Le fournisseur a accepté, les campagnes sont parties, et rien n’a cassé. La pratique ennuyeuse n’a pas seulement « évité un incident ». Elle a évité un incident un vendredi soir avec un public de parties prenantes.

Listes de contrôle / plan étape par étape

Étape par étape : corriger SPF en production en toute sécurité

Inventaire des expéditeurs. Listez chaque système qui envoie des mails en tant que votre domaine : suite corporate, ticketing, marketing, facturation, monitoring, CRM, applications personnalisées, et « appareils mystères ».
Collectez des preuves réelles. Pour chaque expéditeur, capturez au moins un message livré et enregistrez :
- Return-Path (domaine envelope-from)
- IP de connexion
- La ligne Authentication-Results
Décidez votre stratégie d’identité. Privilégiez :
- Un ou deux sous-domaines return-path contrôlés pour les tiers
- DKIM aligné sur le domaine From: visible
- Politique DMARC qui correspond à votre niveau de confiance
Construisez un unique enregistrement SPF par nom de domaine. Fusionnez les entrées. Supprimez les fournisseurs morts. Évitez ptr. Évitez les longues chaînes d’includes.
Comptez les recherches avant publication. Les includes s’étendent. Les redirects comptent. A/MX comptent. Gardez une marge.
Planifiez le TTL. Pour les changements planifiés, baissez le TTL (par ex. de 3600 à 300) au moins un cycle TTL avant le changement. Puis remontez-le après stabilité.
Publiez et vérifiez sur les NS autoritatifs. Vérifiez que chaque NS renvoie le même enregistrement.
Vérifiez via plusieurs résolveurs. Vous ne déboguez pas « votre DNS », vous déboguez « la vue Internet de votre DNS ».
Surveillez les conséquences. Suivez les raisons des bounces, les signaux agrégés DMARC si vous les avez, et les dashboards de délivrabilité des fournisseurs. Recherchez les permerrors SPF et l’augmentation des softfails.
Passez de ~all à -all selon un calendrier. Fixez une date. Faites en sorte que quelqu’un en soit responsable. Sinon le softfail devient votre politique définitive.

Checklist : pré-lancement avant d’ajouter un nouvel include fournisseur

Connaissons-nous le domaine envelope-from du fournisseur et peut-il être un sous-domaine personnalisé sous le nôtre ?
Cette chaîne d’includes restera-t-elle sous 10 recherches DNS dans le pire des cas ?
Ajoutons-nous par erreur un second enregistrement SPF ?
DKIM est-il aligné et stable pour ce flux ?
La mise en application DMARC va-t-elle punir les erreurs immédiatement ?
Pouvons-nous revenir rapidement en arrière (TTL bas, enregistrement précédent sauvegardé, pipeline de changement prêt) ?

Checklist : mitigation d’urgence quand SPF casse activement

Arrêtez de faire des modifications DNS parallèles depuis plusieurs consoles. Un seul propriétaire de changement.
Si plusieurs TXT SPF existent : fusionnez et supprimez les duplicatas en priorité.
Si permerror dû aux recherches : retirez l’include le plus récent et retestez. Restaurez la délivrabilité, puis redesign.
Si une nouvelle IP sortante est apparue : routez temporairement le trafic via le relais connu au lieu d’étendre SPF à l’aveugle.
Si DMARC rejette et que vous ne pouvez pas corriger SPF rapidement : assurez-vous que la signature DKIM alignée fonctionne pour le flux affecté (souvent le contournement fonctionnel le plus rapide).

FAQ

1) Puis-je avoir plusieurs enregistrements SPF si je les répartis en chaînes TXT ?

Vous pouvez scinder un seul enregistrement SPF en plusieurs chaînes citées au sein du même RRset TXT (certains fournisseurs DNS le font automatiquement). Vous ne pouvez pas publier plusieurs enregistrements TXT séparés qui commencent chacun par v=spf1 pour le même nom.

2) Quelle est la différence entre SPF fail et SPF softfail ?

-all produit un fail pour les expéditeurs non autorisés ; ~all produit un softfail. Le softfail signifie « non autorisé, mais peut-être accepter ». Certains récepteurs traitent le softfail presque aussi sévèrement que le fail lorsqu’il est combiné à une mauvaise réputation ou à l’application DMARC.

3) Pourquoi je vois SPF pass mais je suis quand même rejeté ?

Parce que le pass SPF ne garantit pas le pass DMARC. DMARC exige l’alignement entre le domaine From: et le domaine SPF-authentifié envelope-from (ou l’alignement DKIM). Vous pouvez aussi être rejeté pour le contenu, la réputation, des listes de blocage, ou des politiques sans rapport avec SPF.

4) SPF protège-t-il l’en-tête From: visible ?

Pas directement. SPF authentifie le domaine envelope-from (Return-Path). DMARC est ce qui lie l’authentification (SPF/DKIM) à l’en-tête From: visible via des règles d’alignement.

5) Comment les forwarders cassent-ils SPF ?

Le renvoi classique change l’IP de connexion vers l’IP du forwarder, mais le domaine envelope-from reste le domaine de l’expéditeur original. À moins que l’expéditeur original n’autorise l’IP du forwarder (ce qui est rare), SPF échoue. C’est une des raisons pour lesquelles DKIM est crucial, et pourquoi certains forwarders implémentent SRS (Sender Rewriting Scheme) pour préserver la compatibilité SPF.

6) Dois-je utiliser les mécanismes “a” et “mx” dans SPF ?

Seulement si vous comprenez vraiment et contrôlez ce à quoi ils résolvent. Ils coûtent des recherches DNS et peuvent involontairement autoriser des infrastructures qui ne devraient pas envoyer de mail. Pour un egress contrôlé, des ip4/ip6 explicites ou un include fournisseur connu sont généralement plus sûrs.

7) Qu’est-ce que le “redirect” SPF et pourquoi peut-il être dangereux ?

redirect= confie l’évaluation à l’enregistrement SPF d’un autre domaine. C’est pratique pour centraliser la politique, mais cela ajoute des dépendances et un risque de recherche. Si l’enregistrement ciblé change ou casse, votre domaine casse aussi.

8) Combien de temps prend une correction SPF pour « fonctionner » ?

Cela dépend du TTL et du comportement de cache. Le meilleur cas est quelques minutes si le TTL est bas et que les résolveurs coopèrent. Le pire cas peut être des heures. Certains récepteurs mettent en cache de façon agressive. Planifiez les changements avec une stratégie TTL et attendez une période de propagation résiduelle.

9) SPF suffit-il en 2026 ?

Non. SPF seul est insuffisant car il ne survit pas bien au transfert et n’authentifie pas l’en-tête From: visible. Utilisez SPF plus DKIM plus DMARC. Considérez SPF comme nécessaire mais pas suffisant.

10) Quand dois-je passer de ~all à -all ?

Après avoir validé que tous les expéditeurs légitimes sont autorisés et que vous avez un plan de rollback. En pratique : utilisez ~all brièvement pendant la découverte, puis passez à -all une fois votre inventaire fiable. Mettez une date butoir pour que cela se fasse réellement.

Conclusion : prochaines étapes à exécuter aujourd’hui

Si SPF casse la délivrabilité, ce n’est généralement pas parce que SPF est « difficile ». C’est parce que les changements DNS sont non revus, les inventaires d’expéditeurs sont fictifs, et l’intégration des fournisseurs se fait par copier-coller. Corrigez le processus, pas seulement la chaîne.

Faites ceci ensuite :

Récupérez un vrai message défaillant et extrayez le domaine return-path et l’IP de l’expéditeur.
Interrogez le DNS autoritatif et confirmez qu’il existe exactement un TXT v=spf1 pour ce nom de domaine.
Vérifiez le budget de recherches ; retirez les mécanismes risqués et les includes inutiles.
Alignez les identités : utilisez des sous-domaines return-path personnalisés pour les fournisseurs et assurez-vous que DKIM s’aligne avec votre domaine From:.
Verrouillez le contrôle des changements pour SPF/DKIM/DMARC dans une pipeline avec linting et rollback.

SPF n’est pas glamour, mais c’est un de ces coins d’infrastructure où le « presque bon » échoue encore en production. Rendez-le ennuyeux. Gardez-le ennuyeux. Vos métriques d’inbox vous remercieront.