J'ai appris la leçon à mes dépens — j'ai basculé un domaine en production du mode softfail à hardfail un vendredi après-midi et j'ai vu tout un flux d'emails disparaître. Il s'avère que j'avais oublié une plateforme d'événements que j'avais mise en place plusieurs mois plus tôt. Cette erreur m'a appris quelque chose d'essentiel : avant de modifier votre enregistrement SPF, vous devez connaître tous les endroits d'où proviennent vos mails, et accepter les conséquences si vous vous trompez.

Laissez-moi vous expliquer ce qui compte vraiment ici. SPF (Sender Policy Framework) est essentiellement votre domaine disant aux serveurs récepteurs : voici mon enregistrement DNS TXT qui liste les hôtes autorisés à envoyer des mails pour moi. Lorsqu’un email arrive, le serveur destinataire vérifie votre enregistrement SPF par rapport au domaine du Return-Path, évalue vos mécanismes (ip4, ip6, a, mx, include), et décide quoi faire. Cette décision repose sur une seule chose : votre qualifier à la fin — le mode que vous choisissez.

Voici la différence fondamentale qui embrouille souvent : softfail (~all) indique « cela semble non autorisé, mais peut-être que ça va, faites preuve de prudence ». Vous le verrez généralement déclencher un filtrage anti-spam, pas un rejet immédiat. Hardfail (-all) indique « seuls les hôtes que j’ai listés sont légitimes — bloquez tout le reste ». C’est définitif, et lorsqu’il s’aligne avec DMARC, cela entraîne un rejet réel du message.

Je le compare souvent à la mise en scène versus la production. Softfail est votre mode de mise en scène prudent, pendant que vous testez. Hardfail, c’est comme couper le courant en production et assumer les conséquences.

La démarche pratique que je suis est méthodique : commencer avec ?all pour une observation pure, passer à softfail (~all) une fois que vous surveillez les rapports agrégés DMARC, puis passer à hardfail (-all) uniquement après avoir validé chaque expéditeur autorisé et que vos faux positifs sont proches de zéro. Je ne précipite jamais cela. J’inventorie tout — CRM, automatisation marketing, ticketing, RH, facturation, même des trucs bizarres comme les imprimantes. Je confirme quels fournisseurs supportent DKIM et DMARC. Je documente qui possède chaque changement.

Une chose qui peut vous piéger rapidement : SPF a une limite stricte de 10 recherches DNS. J’ai vu des gens imbriquer des includes si profondément qu’ils atteignaient cette limite soudainement, et tout se cassait. Réduisez vos includes, privilégiez les plages d’IP plutôt que les chaînes imbriquées, et éliminez les services inutiles. Si un expéditeur en masse change constamment d’IP, demandez-lui un include stable avec SLA.

Le transfert est un autre piège. Il casse SPF car l’IP de connexion change. Si le forwarding utilise SRS (Sender Rewriting Scheme), c’est parfait. Sinon, un softfail pourrait être la seule chose empêchant une erreur amicale. C’est pourquoi je m’appuie davantage sur DKIM et l’alignement DMARC pour ces chemins.

La liste de contrôle pour le déploiement en conditions réelles que j’ai affinée au fil du temps : cartographier chaque serveur mail et flux, valider DKIM partout, activer DMARC en p=none pour la télémétrie, passer SPF en softfail et surveiller au moins deux cycles d’envoi, examiner chaque expéditeur non autorisé et soit l’autoriser, soit couper le flux, puis déployer progressivement une politique reject avec application DMARC avant de passer en hardfail. Cette dernière étape — ne passer en hardfail que lorsque la couverture des expéditeurs légitimes est complète — est non négociable.

Une autre chose que j’ai remarquée : Google et Yahoo ont considérablement renforcé leurs standards. L’application de la politique email combine désormais mode SPF, signatures DKIM, politique DMARC, analyse du contenu et score de réputation. C’est pourquoi je ne traite jamais SPF isolément. Un hardfail SPF sans support DKIM solide peut encore nuire à la délivrabilité si le forwarding est fréquent dans votre environnement.

Les plus grands pièges que je vois : imbriquer des includes jusqu’à dépasser la limite de 10 recherches DNS, oublier des fournisseurs saisonniers qui envoient en utilisant votre domaine, supposer que DMARC sauvera une configuration SPF cassée, compter sur le softfail indéfiniment pendant que les attaquants s’adaptent, ou passer en hardfail avant que DKIM ne soit partout. Ce dernier point surtout — excellent pour la sécurité, mais catastrophique pour la délivrabilité quand le forwarding est courant.

Si vous utilisez actuellement softfail et vous demandez si vous devriez passer en mode plus strict, la réponse est : seulement quand vous êtes prêt. Avez-vous validé tous les expéditeurs ? DKIM est-il aligné ? Vos faux positifs sont-ils proches de zéro ? Si oui, le passage en hardfail a du sens. Sinon, restez patient. Le softfail n’est pas un état permanent — c’est une étape.