SPF Softfail vs Fail : choisissez le réglage qui ne vous nuira pas

Ce qu’est (et n’est pas) SPF : cessez de blâmer le mauvais outil

SPF (Sender Policy Framework) répond à une question étroite : cette IP est-elle autorisée à envoyer du courrier en utilisant ce domaine dans le MAIL FROM / return-path SMTP ?
C’est tout. Il n’authentifie pas directement l’en‑tête « From: ». Il ne certifie pas l’identité humaine de l’expéditeur. Et il n’empêche certainement pas un phisher de mettre le nom de votre CEO dans le champ d’affichage.

SPF est une vérification d’autorisation effectuée par le récepteur, basée sur l’IP de l’expéditeur et le DNS. Le récepteur évalue l’enregistrement SPF du domaine dans l’expéditeur d’enveloppe (bounce address), pas celui visible dans le From:. DMARC est la couche qui relie SPF (et/ou DKIM) au domaine du From: via l’alignement.

Les principaux codes de résultat SPF que vous verrez réellement

• pass : l’IP expéditrice est autorisée.
• fail : explicitement non autorisée (typiquement issu de -all).
• softfail : non autorisée, mais « peut‑être » (typiquement issu de ~all).
• neutral : aucune affirmation (souvent depuis ?all ou mécanismes ambigus).
• none : aucun enregistrement SPF trouvé.
• temperror : problème transitoire (timeout DNS, SERVFAIL).
• permerror : erreur d’évaluation permanente (erreur de syntaxe, trop de recherches DNS).

Le piège opérationnel : les récepteurs traitent ces résultats différemment. SPF n’est pas un « interrupteur de rejet » universel. C’est un signal.
Certains systèmes traitent le softfail presque comme un fail ; d’autres considèrent le fail comme un fort indicateur de spam mais délivrent quand même. Vous ne contrôlez pas le récepteur.
Vous contrôlez la robustesse de votre signal.

Paraphrase de Gene Kranz : « Dur et compétent. » C’est l’attitude que vous voulez pour l’authentification des e-mails : strict là où ça aide, prudent là où ça casse.

~all vs -all : ce que ça signifie et comment les récepteurs les traitent vraiment

Le dernier mécanisme dans la plupart des enregistrements SPF est un qualificateur « all ». C’est votre politique par défaut pour tout ce qui n’a pas été matché plus tôt.
Voici les deux options entre lesquelles vous hésitez :

• ~all (softfail) : « Non autorisé, mais ne soyez pas sévère. » Les récepteurs acceptent souvent mais marquent ou notent.
• -all (fail) : « Non autorisé. C’est explicitement incorrect. » Les récepteurs peuvent rejeter, mettre en quarantaine ou appliquer un score sévère.

Comportement des récepteurs : la vérité inconfortable

Un fail SPF ne garantit pas le rejet. Un softfail SPF ne garantit pas la livraison. Les récepteurs combinent SPF avec la réputation, l’analyse du contenu,
DKIM, DMARC, ARC, le comportement historique de l’expéditeur, et parfois ce que leur fournisseur d’intelligence a vendu ce trimestre.

Voici la différence pratique sur laquelle vous pouvez compter : -all rend votre intention sans équivoque. Si un récepteur veut utiliser SPF comme signal décisif,
vous lui avez donné la permission. Avec ~all, vous laissez une marge de manœuvre — et les attaquants adorent la marge de manœuvre.

Les deux grands modes de défaillance

1. Faux négatifs (vous bloquez vos propres e-mails légitimes).
   Causes courantes : prestataires non listés, plateformes SaaS qui font varier les IPs, passerelles « scan-and-send », outils CRM, systèmes de ticketing, et
   le classique : « on a changé le routage sortant et on a oublié SPF. »
2. Faux positifs (les attaquants obtiennent un meilleur accueil).
   Avec ~all, les sources non autorisées ont encore un échec « soft ». Beaucoup de récepteurs vont livrer mais en dossier spam. Certains auront une livraison en boîte de réception si d’autres signaux sont favorables.
   Ce n’est pas une victoire.

Blague #1 : SPF, c’est comme un videur avec un clipboard. Si la liste est mauvaise, le VIP se fait refuser l’entrée et le fauteur de troubles entre avec une fausse moustache.

Ma recommandation tranchée (et quand la contourner)

Recommandation par défaut : passez à -all une fois que vous avez inventaire et surveillance

Si vous contrôlez votre trafic sortant et que vous pouvez lister chaque expéditeur légitime, utilisez -all.
Le softfail convient comme état transitoire, pas comme destination. Les attaquants n’ont pas besoin de votre permission pour envoyer ; ils ont besoin de votre ambiguïté pour échapper aux filtres stricts.

Cela dit, vous ne « basculez vers -all » pas au feeling. Vous le faites quand :

• vous avez une liste complète des sources sortantes (MTAs, relais, expéditeurs SaaS, helpdesk, marketing, paie, outils de supervision),
• vous pouvez tester l’évaluation SPF depuis plusieurs points de vue,
• vous ne rencontrez pas systématiquement des permerrors SPF (limite de recherches),
• vous avez des rapports DMARC et vous les lisez réellement,
• vous avez un plan de retour arrière (discipline TTL DNS, contrôle des changements).

Quand ~all est justifié

Utilisez ~all temporairement si l’une de ces conditions est vraie :

• Vous êtes encore en train de découvrir des expéditeurs et vous n’avez pas encore de rapports DMARC.
• Votre activité dépend de forwarders ou de listes de diffusion où SPF casse et vous n’avez pas de couverture DKIM alignée.
• Vous avez hérité d’un domaine avec des expéditeurs « shadow IT » inconnus et vous avez besoin d’une fenêtre sûre pour inventorier sans supprimer silencieusement des e-mails critiques.

Arrière‑pensée : un ~all « temporaire » a tendance à devenir permanent. Fixez une date. Mettez un responsable. Si vous ne pouvez pas, vous choisissez la dérive.

Quand éviter les deux et réparer le problème plus large

Si vous essayez d’utiliser la politique SPF pour résoudre la usurpation du champ From:, vous utilisez le mauvais tournevis.
C’est le rôle de DMARC (avec DKIM qui fait la majeure partie du travail pour les transferts). Votre enregistrement SPF doit être exact et strict,
mais la stratégie anti‑usurpation est SPF + DKIM + DMARC, pas SPF seul.

Faits et historique : pourquoi SPF se comporte ainsi

• SPF est apparu au début des années 2000 alors que les opérateurs tentaient de réduire les expéditeurs d’enveloppe falsifiés et le backscatter des rebonds.
• L’évaluation SPF est liée à l’enveloppe SMTP (MAIL FROM / return-path), pas à l’en‑tête From: visible aux humains.
• La limite de 10 recherches DNS existe parce que l’évaluation SPF pouvait autrefois submerger le DNS et devenir un vecteur de déni de service.
• Le mécanisme ptr est devenu pratiquement obsolète car il est lent, fragile et peut être abusé via le contrôle DNS.
• SPF casse lors du forwarding par conception : le forwarder change l’IP expéditrice mais ne réécrit généralement pas le return-path vers un domaine qu’il contrôle.
• DKIM a été introduit en partie pour le forwarding : une signature cryptographique survit au transit si les intermédiaires ne modifient pas les en‑têtes signés.
• DMARC est arrivé plus tard pour relier les résultats d’authentification au domaine visible du From: et fournir politique et rapports.
• ARC (Authenticated Received Chain) existe parce que DMARC strict peut casser des flux légitimes (listes, gateways), et les récepteurs ont voulu un moyen de faire confiance aux intermédiaires.
• Les grands récepteurs considèrent l’authentification comme un facteur de réputation plutôt que comme une porte binaire, parce que les attaquants s’adaptent vite et les faux positifs coûtent cher.

Playbook de diagnostic rapide : trouver le goulot en quelques minutes

Quand la livraison d’e-mails déraille après un changement SPF, il faut arrêter de deviner. Voici l’ordre qui trouve rapidement le problème.

Première étape : confirmer quel enregistrement SPF le monde voit

• Interrogez des résolveurs relativement autoritatifs (pas seulement la vue cache de votre laptop).
• Confirmez qu’il y a exactement un enregistrement TXT SPF (ou au moins pas plusieurs chaînes « v=spf1 »).
• Vérifiez le TTL ; vous pouvez courir après des fantômes de propagation.

Deuxième étape : confirmer quelle IP envoie réellement

• Utilisez les en‑têtes Received d’un message exemple pour identifier l’IP de connexion au destinataire.
• Ne confondez pas les sauts internes avec l’IP de relais externe.
• Vérifiez si le prestataire envoie directement ou via votre relais.

Troisième étape : évaluer SPF et compter les recherches DNS

• Exécutez un évaluateur SPF (ou parsez les logs si vous êtes récepteur).
• Recherchez permerror (trop de recherches) ou temperror (échecs DNS).
• Vérifiez les includes et redirects ; ce sont des multiplicateurs de recherches.

Quatrième étape : vérifier l’alignement DMARC et la couverture DKIM

• Si l’échec est de l’« usurpation », DMARC est le contrôle de politique.
• Si l’échec est du « forwarding », DKIM aligné est votre bouée de sauvetage.
• Si vous avez une enforcement DMARC sans couverture DKIM, vous vous êtes tendu un piège.

Cinquième étape : décider de l’action immédiate

• Si le courrier business est bloqué : revenez en arrière sur le changement SPF (ou adoucissez temporairement) et ouvrez un incident pour inventorier correctement les expéditeurs.
• Si l’usurpation passe : renforcez SPF en -all et déplacez DMARC vers quarantine/reject une fois DKIM stabilisé.
• Si permerror : réduisez les recherches, aplatissez, ou placez les expéditeurs derrière un relais contrôlé.

Tâches pratiques : 12+ commandes, sorties et décisions

Ce ne sont pas des « agréments ». Ce sont les réglages que vous tournez à 2h du matin quand les commerciaux disent que les devis ont disparu.
Chaque tâche inclut : la commande, ce que signifie la sortie, et la décision à prendre.

Task 1: Fetch the SPF TXT record (and spot duplicates)

cr0x@server:~$ dig +short TXT example.com
"v=spf1 ip4:203.0.113.0/24 include:_spf.vendor.example ~all"
"google-site-verification=abc123"

Signification : Un enregistrement SPF existe (bien). L’autre TXT est sans rapport. Si vous voyez deux chaînes distinctes commençant par v=spf1,
beaucoup de récepteurs considéreront cela comme un permerror.

Décision : Si des doublons existent, fusionnez en un seul enregistrement SPF immédiatement.

Task 2: Check the record as seen by specific resolvers (propagation sanity)

cr0x@server:~$ dig @8.8.8.8 +short TXT example.com
"v=spf1 ip4:203.0.113.0/24 include:_spf.vendor.example ~all"

Signification : Le résolveur public voit la valeur prévue.

Décision : Si des résolveurs différent, ne « réparez » pas SPF immédiatement — attendez le TTL ou identifiez un DNS à horizon partagé.

Task 3: Check TTL to estimate how long the blast radius lasts

cr0x@server:~$ dig TXT example.com +noall +answer
example.com.        3600    IN      TXT     "v=spf1 ip4:203.0.113.0/24 include:_spf.vendor.example ~all"

Signification : Le TTL est de 3600 secondes. Au pire, les caches conservent l’ancien état pendant une heure.

Décision : Avant des changements SPF majeurs, abaissez le TTL un jour à l’avance ; en incident, basez vos attentes sur la réalité du TTL.

Task 4: Verify the sending IP from a received message header (sender truth serum)

cr0x@server:~$ grep -iE '^(received: from|authentication-results:)' sample.eml | head
Received: from outbound.vendor.example (outbound.vendor.example [198.51.100.77])
Authentication-Results: mx.receiver.example; spf=softfail (example.com: domain of bounce@example.com does not designate 198.51.100.77 as permitted sender)

Signification : Le récepteur a évalué SPF pour example.com et l’IP de connexion était 198.51.100.77.

Décision : Si cette IP n’est pas dans votre SPF, soit ajoutez le mécanisme/include du prestataire, soit routez‑le via votre relais autorisé.

Task 5: Evaluate SPF with a local tool (quick and blunt)

cr0x@server:~$ spfquery -ip 198.51.100.77 -sender bounce@example.com -helo outbound.vendor.example
fail

Signification : Pour le domaine de l’expéditeur d’enveloppe, cette IP n’est pas autorisée.

Décision : Ne changez pas -all en ~all pour « corriger » cela. Réparez la liste d’autorisation ou le chemin d’envoi.

Task 6: Count DNS lookups risk with an SPF inspection (detect permerror candidates)

cr0x@server:~$ dig +short TXT example.com
"v=spf1 include:_spf.a.example include:_spf.b.example include:_spf.c.example include:_spf.d.example -all"

Signification : Chaque include peut déclencher plusieurs recherches. Vous pouvez atteindre 10 rapidement.

Décision : Si vous approchez la complexité maximale, consolidez les expéditeurs derrière un relais ou aplatissez prudemment (voir Task 9/10).

Task 7: Detect an SPF permerror (too many DNS lookups) via receiver logs (Postfix example)

cr0x@server:~$ sudo grep -i spf /var/log/mail.log | tail -5
Jan  4 11:02:18 mx postfix/smtpd[22190]: NOQUEUE: reject: RCPT from unknown[203.0.113.55]: 550 5.7.1 SPF permerror; too many DNS lookups; from=<bounce@example.com> to=<user@receiver.example> proto=ESMTP helo=<sender.example>

Signification : L’évaluation SPF a échoué de façon permanente. Certains récepteurs rejettent sur permerror, d’autres traitent comme neutral ; en tout cas, c’est négligé.

Décision : Réduisez includes/redirects. Considérez le permerror comme un incident pour la délivrabilité.

Task 8: Confirm you didn’t publish two SPF records (classic self-own)

cr0x@server:~$ dig +short TXT example.com | grep -c '^"v=spf1'
2

Signification : Deux enregistrements SPF existent. Beaucoup de récepteurs retournent permerror.

Décision : Fusionnez immédiatement en un seul enregistrement. Puis revérifiez avec plusieurs résolveurs.

Task 9: Extract and validate include targets (are you depending on a broken vendor?)

cr0x@server:~$ dig +short TXT _spf.vendor.example
"v=spf1 ip4:198.51.100.0/24 ip4:203.0.113.128/25 -all"

Signification : Le prestataire publie un SPF propre avec des plages IP explicites et -all.

Décision : Si le SPF du prestataire est malformé ou gonflé, faites pression : soit il corrige, soit vous routez via un relais contrôlé.

Task 10: Check SPF redirect usage (and understand its blast radius)

cr0x@server:~$ dig +short TXT mail.example.com
"v=spf1 redirect=example.com"

Signification : Le SPF du sous‑domaine est entièrement délégué à la politique de l’apex.

Décision : Si vous avez besoin d’expéditeurs différents pour des sous‑domaines (marketing vs transactionnel), évitez redirect et définissez explicitement.

Task 11: Verify DKIM is present for a sender that will be forwarded (SPF-proofing)

cr0x@server:~$ grep -i '^dkim-signature:' sample.eml | head -1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1; h=from:to:subject:date; bh=...; b=...

Signification : Le message est signé DKIM par example.com. Cela peut survivre au forwarding, préservant l’alignement DMARC même si SPF échoue.

Décision : Si le mail transféré est critique, priorisez la bonne configuration DKIM plutôt que d’essayer de « faire marcher SPF » via des forwarders.

Task 12: Query DMARC policy (because SPF strictness alone isn’t the point)

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"

Signification : DMARC applique quarantine et exige un alignement strict pour DKIM et SPF.

Décision : Si vous n’avez pas une large couverture DKIM pour tous les expéditeurs légitimes, l’alignement strict couplé au fail SPF peut causer des douleurs utilisateurs. Corrigez d’abord les configurations expéditeurs.

Task 13: Check alignment symptoms in Authentication-Results

cr0x@server:~$ grep -i '^authentication-results:' sample.eml | head -1
Authentication-Results: mx.receiver.example; spf=pass smtp.mailfrom=bounce.example.com; dkim=pass header.d=example.com; dmarc=fail header.from=example.com

Signification : SPF a passé pour bounce.example.com, DKIM a passé pour example.com, mais DMARC a échoué pour header.from=example.com.
C’est un décalage d’alignement : les domaines ne sont pas alignés selon vos réglages DMARC.

Décision : Alignez le domaine expéditeur d’enveloppe avec le domaine From (ou assouplissez l’alignement) et assurez‑vous que DKIM utilise le domaine From quand c’est possible.

Task 14: Identify who is sending for you (Postfix outbound logs example)

cr0x@server:~$ sudo grep -E 'status=sent|relay=' /var/log/mail.log | tail -5
Jan  4 10:55:01 mta postfix/smtp[21011]: 1A2B3C4D: to=<user@outside.example>, relay=aspmx.l.google.com[142.250.102.27]:25, delay=1.2, status=sent (250 2.0.0 OK)
Jan  4 10:56:44 mta postfix/smtp[21022]: 5E6F7A8B: to=<user@outside.example>, relay=mail.protection.outlook.com[52.101.73.5]:25, delay=0.9, status=sent (250 2.6.0 Queued mail for delivery)

Signification : Vous voyez les destinations sortantes, et pouvez aussi déduire si vous envoyez directement ou si vous relayez via un smart host.

Décision : Si vous routez via un relais unique, SPF peut être plus simple (autorisez le relais). Si vous envoyez depuis de nombreuses IPs, un inventaire est obligatoire.

Task 15: Sanity-check your outbound public IP (cloud NAT surprises)

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

Signification : L’IP egress publique de cet hôte est 203.0.113.55 du point de vue d’Internet.

Décision : Assurez‑vous que cette IP (ou la plage NAT) est autorisée dans SPF si elle peut envoyer du courrier directement. Si l’IP change, cessez d’envoyer directement ; utilisez un relais stable.

Trois mini-récits d’entreprise depuis le terrain

1) Incident causé par une mauvaise hypothèse : « Le prestataire utilise notre relais »

Une entreprise de taille moyenne avait un relais SMTP interne et un SPF net : une plage IP, un include, -all.
Ils avaient aussi une nouvelle plateforme RH qui envoyait des e-mails d’onboarding. Tout le monde croyait que la plateforme était configurée pour passer par le relais.
L’interface disait même « SMTP configured », une phrase qui a induit plus de gens en erreur que n’importe quel e‑mail de phishing.

Le premier symptôme n’était pas un bounce. C’était le silence. Les nouvelles recrues ne recevaient pas leurs liens d’onboarding, les managers n’avaient pas d’approbations,
et l’équipe RH pensait que l’application était « instable ». Pendant ce temps, quelques destinataires externes recevaient les messages — mais dans le spam.
Différents récepteurs, comportements différents. Voilà la vie SPF.

Quand quelqu’un a finalement extrait un message brut, l’IP de connexion appartenait à l’infrastructure du prestataire, pas au relais de l’entreprise.
Le prestataire était passé en « direct send » parce que le relais exigeait des paramètres TLS qu’il ne supportait pas entièrement pour ce tenant.
SPF a fait exactement son travail : signaler le mail comme non autorisé. L’hypothèse était fausse, pas le mécanisme.

La correction fut ennuyeuse et efficace : soit forcer le prestataire à utiliser réellement le relais, soit autoriser l’include du prestataire dans SPF et exiger la signature DKIM
avec le domaine de l’entreprise. Ils ont choisi la voie du relais pour garder SPF petit et stable. Ils ont aussi ajouté une revue hebdomadaire des rapports DMARC.
L’incident fut clos, et la leçon resta : si vous ne pouvez pas pointer vers l’IP et la config, vous ne « connaissez » pas le chemin d’envoi.

2) Optimisation qui s’est retournée contre eux : « Aplatissons SPF pour la performance »

Une autre organisation avait fait grandir son SPF comme un tiroir fouillis : six includes, deux blocs ip4, et un redirect pour un sous‑domaine.
Ils ont été effrayés par la limite des 10 recherches et ont décidé d’aplatir — copier les plages IP des prestataires directement dans l’enregistrement.
On présentait ça comme de la « performance » et de la « résilience » parce que ça supprimait les dépendances au DNS du prestataire.

L’aplatissement a bien marché un mois. Puis la délivrabilité a commencé à vaciller. Une plateforme marketing a commencé à utiliser une nouvelle pool d’IPs,
et comme l’org avait figé les anciennes plages dans son SPF, ces messages ont commencé à échouer SPF. Certains récepteurs ont mis en quarantaine ; d’autres ont rejeté.
L’include du prestataire avait été mis à jour correctement, mais l’org avait choisi de sortir de ce flux de mises à jour.

Le mode d’échec était subtil : les tests internes « passaient » car les ingénieurs testaienr depuis une région et un expéditeur.
En production, le prestataire utilisait différents egress selon la géographie et le débit. L’enregistrement SPF aplati était devenu un instantané obsolète,
et l’org s’était accidentellement chargée de la gestion du cycle de vie des IP du prestataire.

Ils sont revenus aux includes pour les prestataires qui les maintiennent bien, et n’ont aplati que les sources qu’ils possédaient.
Le changement le plus important fut processuel : la mise en onboard d’un prestataire exige désormais soit (a) un include stable avec pratiques de changement publiées, soit (b) le routage via le relais de l’entreprise.
L’optimisation est excellente — jusqu’à ce qu’elle change qui est responsable de la correction.

3) Pratique ennuyeuse mais correcte qui a sauvé la mise : sévérité progressive avec rapports DMARC

Une société de services financiers tenait un programme discipliné d’authentification des mails. Pas excitant. Très efficace.
Ils ont commencé avec SPF ~all sur un domaine legacy parce qu’ils ne connaissaient vraiment pas tous les expéditeurs. Plutôt que de deviner, ils ont instrumenté.
DMARC était réglé sur p=none avec rapports activés, et l’équipe sécurité consultait les rapports agrégés chaque semaine.

Ils ont trouvé les surprises habituelles : un système de supervision envoyant des alertes « disque plein » depuis une IP colo, une imprimante d’agence régionale avec auth SMTP,
et un petit outil de facturation SaaS que personne n’avait signalé au service central. Aucun n’était malveillant. Ils n’étaient que non‑gérés.
Les rapports les ont rendus visibles, ce que fait la bonne télémétrie : transformer des mystères en tickets.

Après avoir aligné ou remplacé ces expéditeurs, ils ont basculé SPF en -all et DMARC en p=quarantine.
Ce n’est qu’ensuite qu’ils sont passés à p=reject pour le domaine principal, les sous‑domaines étant traités séparément.
Quand un attaquant a tenté une campagne basique d’usurpation, la plupart des récepteurs ont rejeté proprement. Les équipes internes ont à peine remarqué.

Le « sauvetage » est venu plus tard : une panne prestataire a forcé un reroutage temporaire du courrier sortant via un relais de secours.
Parce que la firme avait un inventaire explicite des expéditeurs et un processus de changement, la mise à jour SPF fut un changement contrôlé avec TTL préalablement abaissé et plan de rollback.
Leur courrier a continué de circuler. Personne n’a écrit un post à ce sujet sur internet, ce qui montre que c’était bien fait.

Erreurs courantes : symptôme → cause racine → correction

1) Les messages vont soudainement en spam après le passage de ~all à -all

Symptôme : Les e‑mails transactionnels légitimes atterrissent en spam/quarantaine chez de gros fournisseurs.

Cause racine : Un ou plusieurs expéditeurs légitimes n’étaient jamais autorisés ; le softfail était toléré, le fail ne l’est pas.

Correction : Identifiez les IPs expéditrices via les en‑têtes ou logs, autorisez via ip4/ip6 ou include, ou routez via un relais connu. Puis retestez SPF et l’alignement DMARC.

2) Des récepteurs aléatoires rejettent avec « SPF permerror »

Symptôme : Certains destinataires rejettent avec 5.7.1 et mentionnent permerror ou « too many DNS lookups. »

Cause racine : Votre enregistrement SPF dépasse 10 recherches DNS à cause des includes/redirect/a/mx.

Correction : Réduisez les recherches : supprimez des includes inutilisés, évitez a/mx sauf si nécessaire, consolidez les expéditeurs, ou utilisez un relais. Revérifiez aussi duplications et erreurs de syntaxe.

3) SPF passe mais DMARC échoue (et vous n’arrivez pas à expliquer)

Symptôme : Authentication-Results montre spf=pass mais dmarc=fail.

Cause racine : SPF a passé pour un domaine d’enveloppe non aligné (ex. domaine de bounce du prestataire), et DKIM est absent ou non aligné.

Correction : Assurez‑vous que DKIM signe avec votre domaine From, ou alignez le domaine expéditeur d’enveloppe ; n’ajustez l’alignement DMARC que si vous comprenez le compromis.

4) Le mail transféré échoue SPF et est bloqué après enforcement DMARC

Symptôme : Des employés qui transfèrent des mails vers des comptes personnels (ou partenaires) voient des rejets/quarantines.

Cause racine : Les forwarders cassent SPF ; l’enforcement DMARC s’appuie sur DKIM passant et aligné, ce qui peut manquer.

Correction : Améliorez la couverture DKIM de votre trafic sortant ; penchez-vous sur des récepteurs ARC-aware et les bonnes pratiques listes/forwarding. N’utilisez pas SPF pour les chemins forwardés.

5) Vous avez publié « v=spf1 » en plusieurs morceaux TXT et certains systèmes le lisent mal

Symptôme : Échecs SPF intermittents ; différents outils montrent des chaînes différentes.

Cause racine : Longueur de l’enregistrement/quoting ou enregistrements multiples ; certaines interfaces DNS segmentent mal les chaînes.

Correction : Assurez‑vous d’avoir exactement un RRset TXT SPF et qu’il soit une chaîne SPF valide. Validez avec la sortie dig et un évaluateur local.

6) Le prestataire vous dit d’utiliser « +all » ou « ?all » pour éviter les problèmes

Symptôme : Le support du prestataire suggère d’affaiblir SPF pour « corriger la délivrabilité ».

Cause racine : Ils ne peuvent pas (ou ne veulent pas) fournir d’autorisation d’envoi stable et veulent que vous acceptiez tout.

Correction : Ne le faites pas. Routez via votre relais ou exigez la signature DKIM avec votre domaine et une stratégie d’include SPF appropriée. Si le prestataire ne peut pas, reconsidérez son usage.

Checklists / plan étape par étape

Étape par étape : chemin sûr de ~all vers -all

1. Inventoriez les expéditeurs : listez tous les systèmes qui envoient comme votre domaine (humains + applis + devices + prestataires).
2. Activez les rapports DMARC avec p=none si vous ne les avez pas ; assignez un responsable pour les lire chaque semaine.
3. Confirmez la couverture DKIM pour chaque expéditeur qui le peut : marketing, ticketing, facturation, RH, etc.
4. Corrigez l’alignement : assurez‑vous que DKIM d= et/ou le return-path SPF s’alignent avec le From selon vos réglages DMARC.
5. Nettoyez SPF : un seul enregistrement, pas d’includes morts, évitez ptr, minimisez a/mx.
6. Vérifiez le budget de recherches : gardez une marge confortable sous 10. Ne vivez pas à 9/10 en prétendant que c’est OK.
7. Abaissez le TTL à l’avance (24–48 heures) avant de passer à -all pour qu’un rollback soit réaliste.
8. Étalez le changement : appliquez -all d’abord sur des sous‑domaines moins critiques ou un domaine pilote si possible.
9. Surveillez : suivez les bounces, les retours des récepteurs et les rapports DMARC pendant au moins un cycle business complet (une semaine+).
10. Passez à -all et documentez la liste des expéditeurs comme un artefact vivant lié à l’onboarding/offboarding des prestataires.

Checklist opérationnelle : avant de toucher SPF dans le DNS

• Connaît‑on tous les chemins d’envoi légitimes, y compris les outils « petits » (alertes, imprimantes, apps legacy) ?
• Avons‑nous un plan de rollback et une copie récente de l’ancien TXT ?
• Le TTL est‑il assez bas pour que le rollback ait un effet ?
• Avons‑nous vérifié qu’il existe exactement un enregistrement SPF aujourd’hui ?
• Ce changement nous pousse‑t‑il vers la limite des 10 recherches ?
• Faisons‑nous appliquer DMARC ? Si oui, DKIM est‑il aligné pour tous les expéditeurs majeurs ?
• Qui est en charge des tickets de délivrabilité pour les prochaines 24–48 heures ?

Rubrique décisionnelle : que devriez‑vous publier aujourd’hui

• Publiez -all si : l’inventaire des expéditeurs est exact, DKIM est largement déployé, les rapports DMARC sont lus, et vous contrôlez ou pouvez contraindre les expéditeurs.
• Publiez ~all si : vous découvrez activement des expéditeurs avec un plan limité dans le temps, et vous pouvez tolérer que des envois non autorisés obtiennent un meilleur score que d’habitude.
• Ne « résolvez » pas des problèmes de prestataires avec ?all ou +all. Ce n’est pas une politique ; c’est une reddition.

Blague #2 : Changer SPF sans vérifier l’alignement DMARC, c’est comme serrer des écrous sur une voiture à trois roues. Techniquement, vous avez fait quelque chose.

FAQ

1) Est‑ce que -all garantit que les récepteurs rejettent les mails non autorisés ?

Non. C’est un signal « fail », mais le récepteur décide. Beaucoup rejettent, certains mettent en quarantaine, d’autres livrent quand même en appliquant un score sévère.
Votre contrôle porte sur l’exactitude et la sévérité du signal, plus la politique DMARC et DKIM.

2) ~all est‑il plus sûr parce qu’il ne casse pas le mail légitime ?

Il est plus « sûr » seulement dans le sens où certains récepteurs sont plus tolérants. Il offre aussi un atterrissage plus doux aux expéditeurs non autorisés.
Si vous utilisez ~all, considérez‑le comme une transition pendant que vous inventorie et corrigez les expéditeurs.

3) Nous utilisons plusieurs prestataires. Devons‑nous simplement ajouter tous leurs includes ?

Parfois. Mais les includes multiplient les recherches et vous avez une limite dure. Si vous empilez des prestataires, il peut être préférable
de router le courrier sortant via un relais centralisé que vous contrôlez, puis d’autoriser seulement ce relais dans SPF.

4) Pourquoi le forwarding casse SPF ?

SPF vérifie l’IP de connexion par rapport à l’enregistrement SPF du domaine de l’expéditeur d’enveloppe. Un forwarder change l’IP de connexion mais garde généralement l’expéditeur d’enveloppe d’origine.
Résultat : IP non autorisée, SPF échoue. DKIM peut survivre au forwarding et sauver l’alignement DMARC s’il est correctement configuré.

5) Dois‑je utiliser include ou lister directement des plages IP ?

Utilisez include quand le prestataire le maintient bien et change ses IPs. Listez les IPs directement quand vous les possédez et les contrôlez.
Aplatir les plages d’un prestataire dans votre SPF vous rend responsable de suivre leur churn IP, une tâche pour laquelle vous n’avez probablement pas budgété.

6) Qu’est‑ce qui est pire : temperror ou permerror ?

En pratique, permerror est pire parce qu’il est persistant et signale une configuration cassée (syntax, enregistrements multiples, limite de recherches).
Temperror peut être intermittent (pannes DNS), mais à grande échelle ça nuit aussi à la délivrabilité. L’un ou l’autre est une raison de simplifier et durcir le DNS.

7) Puis‑je utiliser SPF pour empêcher quelqu’un d’usurper mon adresse From: ?

Pas de façon fiable. SPF authentifie le domaine de l’expéditeur d’enveloppe. Les attaquants peuvent choisir un domaine d’enveloppe qu’ils contrôlent tout en usurpant votre From: visible.
DMARC lie l’authentification au domaine From (alignement). Utilisez SPF comme partie d’un ensemble, pas comme la solution complète.

8) Nous avons DMARC en reject. Est‑ce que ça signifie que SPF doit être -all ?

Pas strictement. DMARC peut réussir via DKIM même si SPF échoue. Mais si la couverture DKIM est incomplète, la sévérité SPF devient beaucoup plus critique.
Si vous appliquez DMARC, soyez d’abord confiant en DKIM, puis rendez SPF strict et exact.

9) Qu’en est‑il des sous‑domaines — doivent‑ils hériter du SPF apex ?

Seulement si l’ensemble des expéditeurs est vraiment identique. Les plateformes marketing et les systèmes produit utilisent souvent des sous‑domaines pour une raison.
Si vous redirigez tout vers l’apex, vous pouvez accidentellement autoriser des expéditeurs là où ils ne devraient pas, ou casser des expéditeurs légitimes de sous‑domaines.

10) Comment savoir si passer à -all va mal tourner ?

Si vous ne pouvez pas répondre « quelles sont toutes les IPs/domaines légitimes d’envoi ? » et « signent‑ils DKIM alignés ? » avec des preuves (logs, en‑têtes, rapports DMARC),
vous n’êtes pas prêt. Utilisez ~all temporairement, instrumentez, corrigez, puis passez à -all avec un déploiement progressif.

Conclusion : que faire ensuite

Si vous voulez le réglage qui ne vous jouera pas de mauvais tour, ne traitez pas ~all vs -all comme un débat moral. Traitez‑le comme une question de préparation.
Le softfail est une période de probation. Le fail est la production.

Prochaines étapes pratiques :

1. Exécutez les vérifications DNS ci‑dessus et confirmez que vous avez exactement un enregistrement SPF et un TTL raisonnable.
2. Récupérez des en‑têtes de vrais e‑mails et notez les IPs de connexion réelles pour chaque système expéditeur.
3. Corrigez DKIM et l’alignement DMARC pour vos expéditeurs majeurs, en particulier tout ce qui est susceptible d’être transféré.
4. Réduisez la complexité des recherches SPF avant que ça ne devienne une roulette permerror.
5. Passez à -all avec un changement étagé, surveillé pendant au moins une semaine de trafic réel.

L’objectif n’est pas de publier un enregistrement qui a l’air impressionnant. L’objectif est de publier un enregistrement que vous pouvez défendre à 2h du matin avec des logs, des en‑têtes et un plan de rollback.
C’est ainsi que vous empêchez l’authentification e‑mail de devenir un déni de service accidentel contre votre propre activité.