J'ai appris à la dure ce que signifie vraiment SPF. Un vendredi après-midi, j'ai basculé notre domaine de production du mode softfail au mode hardfail, oubliant complètement une plateforme d'événements que nous avions mise en place des mois auparavant. Les emails ont tout simplement disparu. Ce vendredi m'a appris quelque chose de crucial : connaissez-vous réellement tous les endroits d'où proviennent vos mails, et êtes-vous prêt aux conséquences en cas d'erreur de livraison ?

Depuis, je traite les changements SPF comme le font les pilotes avec leurs check-lists—de manière méthodique, avec des sauvegardes, et sans jamais se précipiter.

Laissez-moi vous expliquer ce qui se passe réellement sous le capot. SPF (framework de politique d'expéditeur) est un système d'authentification des emails basé sur DNS. Vous publiez un enregistrement SPF sous forme d'un enregistrement TXT DNS pour votre domaine, qui indique aux serveurs récepteurs quels hôtes sont autorisés à envoyer des mails en votre nom. Ces serveurs vérifient vos mécanismes (ip4, ip6, a, mx, include) et les qualificatifs, puis produisent un résultat : pass, none, neutral, softfail, hardfail, temperror, ou permerror.

La différence clé réside dans ce qualificatif terminal. Un softfail (~all) indique "cela semble non autorisé, mais continuez avec prudence." Un hardfail (-all) indique "seuls les hôtes listés sont légitimes—bloquez tout le reste." Ce seul caractère modifie la façon dont les fournisseurs de boîtes aux lettres traitent vos messages.

Voici où cela devient pratique. Avec softfail, vous voyez généralement un placement dans le dossier spam ou une quarantaine. Avec hardfail, surtout lorsque DMARC est en place, vous pouvez obtenir un rejet direct au niveau du serveur mail. Microsoft 365 et Outlook combinent souvent SPF avec DKIM et des filtres de contenu. Google et Yahoo s'appuient fortement sur DMARC et la réputation de l'expéditeur. Donc, un softfail peut finir dans Promotions ; un hardfail avec DMARC en alignement peut signifier un blocage décisif.

Je ne passe jamais directement au hardfail. Mon processus est toujours : neutre (?all) → softfail (~all) → hardfail (-all). Lors de la découverte, quand je ne suis pas certain des flux email legacy ou des plages d'IP des fournisseurs, j'utilise le softfail. Cela signale une mauvaise utilisation du domaine sans compromettre la délivrabilité pendant que j'inventorie toutes les sources d'envoi—CRM, automatisation marketing, ticketing, RH, finance, même imprimantes.

Une fois que j'ai validé chaque expéditeur autorisé et que DKIM est cohérent partout, je passe au hardfail. Le compromis de risque est réel : le softfail offre une meilleure délivrabilité pendant l'inventaire mais avec un risque accru que du phishing passe comme spam au lieu d'être bloqué. Le hardfail offre une sécurité renforcée mais peut casser un mail légitime si vous avez manqué un expéditeur.

J'ai vu des équipes dépasser la limite de 10 recherches DNS en imbriquant trop d'includes. J'ai vu des oublis de fournisseurs saisonniers comme Livestorm ou Prismic pour les webhooks. Et j'ai observé des gens supposer que DMARC sauverait un enregistrement SPF cassé—ce qui n'est pas le cas, pas sans alignement.

La vraie leçon : traitez SPF, DKIM et DMARC comme un système, pas comme des pièces isolées. La redirection casse SPF car l'IP de connexion change. Si vous utilisez SRS (Sender Rewriting Scheme), vous êtes en sécurité. Sinon, le softfail pourrait être tout ce qui empêche une erreur amicale. C'est pourquoi je surveille obsessivement les rapports agrégés DMARC et je lis les en-têtes Authentication-Results quand quelque chose échoue.

Mon déploiement sécurisé : cartographiez d'abord tous les serveurs mail et flux de travail, validez DKIM partout, activez DMARC en p=none pour la télémétrie, passez SPF en softfail et surveillez deux cycles d'envoi, enquêtez sur chaque expéditeur non autorisé, puis faites un test à blanc avec une politique de rejet avant de passer au hardfail.

Au cours des dernières années, Google et Yahoo ont renforcé leurs exigences en matière d'authentification. L'application des politiques devient de plus en plus multi-signal : mode SPF, signatures DKIM, politique DMARC, contenu, et réputation comptent tous. C'est pourquoi je ne traite jamais SPF isolément. Un hardfail SPF sans DKIM solide peut encore faire des dégâts en délivrabilité si la redirection est courante.

La plus grande erreur que je vois encore : des équipes passer au hardfail avant que DKIM ne soit généralisé, ou qu'elles comptent sur le softfail indéfiniment pendant que les attaquants s'adaptent et que le spoofing d'email prospère dans cette ambiguïté. C'est un équilibre, mais la voie est claire si vous y allez méthodiquement.