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

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.

L'essentiel tient en une phrase : -all est la seule qualification qui dit fermement « ce qui n'est pas dans la 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 ce domaine ». Le SPF, censé restreindre, se transforme en autorisation universelle. N'importe quel spammeur ou usurpateur le passe alors sans effort. C'est strictement pire que de ne pas avoir de SPF du tout, car ça donne une fausse caution. Un +all repéré dans un enregistrement se corrige 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 le From:), et c'est la politique publiée 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 la politique DMARC ;
• garder ~all « parce que DMARC fait le travail » est un relâchement inutile : quand les sources sont connues, 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

Imaginons 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.

Avec DMARC en p=reject des deux côtés, 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 l'inventaire des sources est incomplet.

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. Inventorier toutes les sources d'envoi depuis les rapports agrégés — ils révèlent chaque IP émettant au nom du domaine.
2. Vérifier qu'elles figurent toutes dans le SPF (ou qu'elles sont alignées en DKIM), sans dépasser la limite des dix résolutions.
3. Basculer en -all une fois acquise la certitude que rien de légitime ne tombe en dehors de la liste.
4. Surveiller quelques jours : aucune source légitime ne doit soudain échouer.

Tant que l'étape 1 n'est pas faite sereinement, ~all reste de mise — 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ù aucun courrier ne part — 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 : publier v=spf1 -all, sans le moindre mécanisme avant. L'enregistrement déclare ainsi qu'aucun serveur n'est autorisé à émettre en leur nom — ce qui est exactement vrai, puisqu'ils n'émettent 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 qu'une entreprise possède mais qu'elle a oublié de protéger. Le v=spf1 -all est la première ligne de défense, gratuite et définitive. Aucun domaine du portefeuille ne devrait rester 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 la qualification en place

Un coup d'œil rapide suffit à faire le point. Notre analyseur gratuit lit l'enregistrement, indique la qualification terminale et signale les configurations dangereuses comme +all. Pour le détail des contrôles, voir comment vérifier son enregistrement SPF. Et quand le SPF renvoie une erreur plutôt qu'un simple résultat, voir 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 le 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.

Avec 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 l'expéditeur à court terme (moins de risque de bloquer son propre courrier quand l'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 rien n'interdit de viser -all une fois le 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.

Thomas sécurise la qualification terminale

Savoir si un domaine peut passer en -all sans casser son courrier suppose de connaître toutes ses sources. Thomas, le RSSI virtuel, les nomme depuis les rapports, vérifie qu'elles sont toutes couvertes par SPF ou DKIM, et indique le moment précis où basculer en -all sans risque — et signale si un +all ou un ?all dangereux traîne dans l'enregistrement.

Analyser un domaine gratuitement ou créer un compte pour passer à -all en confiance.