SPF -all ou ~all : quelle différence, et lequel choisir

À la fin de presque tous les enregistrements SPF, il y a un petit mécanisme qui change tout : -all, ~all, parfois ?all ou — catastrophe — +all. C'est la qualification terminale : elle dit au serveur destinataire quoi faire d'un message dont l'IP n'apparaît dans aucun mécanisme de ton enregistrement. Le choix entre -all et ~all revient sans cesse, et il est entouré de confusions. Ce guide explique précisément ce que signifie chaque qualificateur, ce que les destinataires en font, comment ils interagissent avec DMARC, et lequel tu devrais publier.

Les quatre qualificateurs, expliqués

Devant all (qui « attrape » tout ce qui n'a pas matché avant), on place un symbole qui en définit le sens :

• -all (hardfail). « Tout serveur non listé n'est PAS autorisé à émettre pour ce domaine. » C'est l'affirmation forte, celle d'un domaine qui connaît et maîtrise toutes ses sources.
• ~all (softfail). « Un serveur non listé est probablement illégitime, mais ne le rejette pas franchement — marque-le seulement comme suspect. » C'est une position prudente, intermédiaire.
• ?all (neutral). « Je ne me prononce pas sur les serveurs non listés. » Autant dire que ton SPF n'affirme presque rien. À éviter en production.
• +all (pass). « N'IMPORTE QUEL serveur est autorisé à émettre pour mon domaine. » C'est une erreur grave (voir plus bas) : tu déclares toi-même que le monde entier peut t'usurper.

Ce que les destinataires en font

La théorie ne vaut que par l'effet pratique. Face à un message dont l'IP n'est pas autorisée :

• avec -all, le destinataire a un signal clair pour rejeter ou filtrer durement ;
• avec ~all, il a un signal mou : la plupart des serveurs ne rejettent pas sur un softfail seul, ils l'utilisent comme un indice parmi d'autres (souvent pour pousser vers l'indésirable, pas pour bloquer) ;
• avec ?all, il n'a aucun signal exploitable ;
• avec +all, il a un signal… qui valide l'usurpateur. Catastrophique.

Retiens l'essentiel : -all est la seule qualification qui dit fermement « ce qui n'est pas dans ma liste n'est pas moi ».

-all vs ~all : le vrai débat

Pourquoi tant de domaines restent-ils en ~all alors que -all est l'objectif ? Par peur, exactement comme pour la montée en politique DMARC. Tant qu'une équipe n'est pas certaine d'avoir listé toutes ses sources d'envoi légitimes, passer en -all lui fait craindre de bloquer son propre courrier (une plateforme oubliée, un nouvel outil). Le ~all est alors un compromis : il signale la rigueur sans risquer le rejet franc.

Ce compromis est acceptable en transition, le temps d'inventorier et d'aligner ses sources. Mais il ne doit pas devenir un état permanent : un domaine bloqué éternellement en ~all ressemble à un domaine bloqué en p=none — il documente une bonne intention sans aller au bout de la protection. La cible reste -all.

L'erreur fatale : +all

Un mot ferme sur +all, parce qu'on le croise plus souvent qu'on ne le devrait — généralement par accident, un copier-coller malheureux ou une mauvaise compréhension. +all signifie « toute IP est autorisée à émettre pour mon domaine ». Tu transformes ton SPF, censé restreindre, en une autorisation universelle. N'importe quel spammeur ou usurpateur passe alors ton SPF. C'est strictement pire que de ne pas avoir de SPF du tout, car ça donne une fausse caution. Si tu vois +all dans un enregistrement, corrige-le immédiatement — c'est une porte grande ouverte.

L'interaction avec DMARC change la donne

Voici la nuance que beaucoup d'articles ratent. Quand DMARC est en place et appliqué, c'est la politique DMARC (p=quarantine, p=reject) qui décide du sort du courrier non authentifié — pas directement le qualificateur SPF. DMARC s'appuie sur l'alignement (SPF ou DKIM aligné avec ton From:), et c'est ta politique qui dispose.

Conséquence : pour un domaine en p=reject avec un alignement propre, le débat -all vs ~all devient moins critique, car DMARC tranche de toute façon. Mais cela ne veut pas dire que le qualificateur n'a plus d'importance :

• tous les destinataires n'appliquent pas DMARC — un SPF en -all protège aussi auprès de ceux-là ;
• un SPF rigoureux est un signal de réputation cohérent avec ta politique DMARC ;
• garder ~all « parce que DMARC fait le travail » est un relâchement inutile : si tu connais tes sources, autant l'affirmer.

La bonne hygiène consiste donc à viser -all et p=reject : les deux couches se renforcent, elles ne se remplacent pas. Le chemin vers cette double rigueur est décrit dans atteindre p=reject sans casser ses emails.

Un exemple concret

Imagine deux domaines identiques côté sources, mais l'un en ~all et l'autre en -all. Un attaquant usurpe leur From: depuis un serveur quelconque.

• Chez le domaine ~all : un destinataire sans DMARC voit un softfail et, selon sa politique anti-spam, peut tout de même délivrer le message (en boîte ou en indésirable). L'usurpation a une chance de passer.
• Chez le domaine -all : le même destinataire a un signal franc d'échec SPF, et le rejet est bien plus probable.

Ajoute DMARC en p=reject des deux côtés, et l'usurpation est refusée dans les deux cas — mais le domaine -all reste mieux protégé auprès des destinataires qui n'appliquent pas DMARC. Le -all n'est jamais un handicap ; il n'a d'inconvénient que si tes sources sont incomplètes.

Comment passer de ~all à -all sans risque

La méthode est la même que pour durcir DMARC, et elle repose sur les données :

1. Inventorie toutes tes sources d'envoi depuis tes rapports agrégés — ils révèlent chaque IP émettant en ton nom.
2. Assure-toi qu'elles sont toutes dans ton SPF (ou alignées en DKIM), sans dépasser la limite des dix résolutions.
3. Bascule en -all une fois que tu es sûr que rien de légitime ne tombe en dehors de la liste.
4. Surveille quelques jours : aucune source légitime ne doit soudain échouer.

Tant que l'étape 1 n'est pas faite sereinement, reste en ~all — mais avec l'objectif clair de basculer.

Le cas des domaines qui n'envoient pas

Un cas mérite une mention à part : les domaines d'où tu n'émets aucun courrier — domaines parqués, domaines de marque défensifs, anciens domaines conservés. Pour eux, la qualification terminale n'est pas un compromis, c'est une évidence : publie v=spf1 -all, sans le moindre mécanisme avant. Tu déclares ainsi qu'aucun serveur n'est autorisé à émettre en leur nom — ce qui est exactement vrai, puisque tu n'envoies pas. Couplé à un DMARC p=reject (et, avec DMARCbis, à np=reject pour les sous-domaines inexistants), c'est la configuration la plus stricte et la plus simple à tenir, car elle ne demande aucune maintenance : il n'y a pas de source à suivre.

C'est d'autant plus important que les domaines dormants sont des cibles d'usurpation privilégiées, justement parce que personne ne les surveille. Un attaquant adore un domaine de marque que tu possèdes mais que tu as oublié de protéger. Le v=spf1 -all est ta première ligne de défense, gratuite et définitive. Ne laisse aucun domaine que tu possèdes sans cette ligne — c'est l'un des gestes de sécurité au meilleur rapport effort/bénéfice qui soient, et il se pose en une minute.

Vérifier ton qualificateur

Un coup d'œil rapide suffit à savoir où tu en es. Notre analyseur gratuit lit ton enregistrement, t'indique ta qualification terminale et signale les configurations dangereuses comme +all. Pour le détail des contrôles, vois comment vérifier son enregistrement SPF. Et si ton SPF renvoie une erreur plutôt qu'un simple résultat, vois la PermError, ce que ça signifie.

Questions fréquentes

-all peut-il bloquer du courrier légitime ? Seulement si une source légitime n'est pas listée dans ton SPF (et pas alignée en DKIM). C'est pourquoi on bascule en -all après avoir inventorié et listé toutes ses sources, pas avant.

Si j'ai DMARC en p=reject, le qualificateur a-t-il encore de l'importance ? Moins, mais oui. DMARC tranche pour les destinataires qui l'appliquent ; -all protège en plus auprès de ceux qui ne l'appliquent pas, et reste un signal de rigueur cohérent.

~all est-il « plus sûr » que -all ? Plus sûr pour toi à court terme (moins de risque de bloquer ton propre courrier si ton inventaire est incomplet), mais moins protecteur contre l'usurpation. C'est un compromis de transition, pas une cible.

Pourquoi mon prestataire recommande-t-il ~all ? Souvent par prudence, pour ne pas risquer de casser le courrier de clients dont l'inventaire de sources est incertain. C'est défendable au démarrage, mais ne t'empêche pas de viser -all une fois ton parc maîtrisé.

Que faire si je trouve ?all ? Le considérer comme presque équivalent à pas de SPF utile, et le remplacer par ~all (transition) puis -all. ?all n'affirme rien et n'apporte aucune protection.

Laisse Thomas sécuriser ta qualification

Savoir si tu peux passer en -all sans casser ton courrier suppose de connaître toutes tes sources. Thomas, ton RSSI virtuel, les nomme depuis tes rapports, vérifie qu'elles sont toutes couvertes par SPF ou DKIM, et te dit le moment précis où basculer en -all sans risque — et te prévient si un +all ou un ?all dangereux traîne dans ton enregistrement.

Analyse ton domaine gratuitement → ou crée un compte pour passer à -all en confiance.