SPF ~all vs -all : Softfail ou Hardfail — Ce qu'ont choisi 139 millions d'enregistrements (2026)

Publié 2026-07-03

Chiffres au 2026-06-29 · méthodologie v7. Données agrégées du recensement portant sur 261 millions de domaines notés. Tous les chiffres sont agrégés — nous ne publions jamais l’enregistrement d’une entreprise individuelle. Voir comment nous notons.

Chaque enregistrement SPF se termine par un mécanisme « all » — le verdict sur le courrier provenant de partout où votre liste ne le prévoit pas — et Internet a massivement choisi le plus doux : 55,8 % des 139 millions de domaines qui publient un SPF se terminent par ~all (softfail), contre 39,3 % qui se terminent par -all (hardfail). Un seul caractère sépare « rejeter les falsifications » de « probablement une falsification — livrez-la quand même ». Lequel vous convient dépend d’un second réglage que la plupart des propriétaires ne configurent jamais.

Que disent réellement ~all et -all à un serveur récepteur ?

-all (hardfail) : « Rejetez le courrier provenant de tout autre endroit. » Un non ferme.
~all (softfail) : « Le courrier provenant d’ailleurs n’est probablement pas légitime — acceptez-le, signalez-le peut-être. » Un haussement d’épaules.
?all (neutre) : « Aucun avis. » Choisi par 3,0 % des émetteurs ; une protection de nom seulement.
+all : « N’importe qui peut envoyer en mon nom. » Publié par 36 014 domaines, et pire que l’absence d’enregistrement — le problème du paillasson de bienvenue a son propre rapport.

~all est-il donc une erreur ? Seulement s’il est seul — et il l’est presque toujours

Le softfail a un argument moderne défendable : les directives pour expéditeurs de Google, et avec elles la plupart des pratiques de délivrabilité, convergent vers ~all associé à une politique DMARC contraignante (p=reject). Cette association protège aussi bien que -all auprès de chaque récepteur qui évalue le DMARC — ce qui inclut désormais tous les grands fournisseurs de boîtes aux lettres — sans rejeter durement le courrier légitime réacheminé, la victime classique de -all. Dans cette configuration, le haussement d’épaules a du mordant : le DMARC fournit le verdict que le SPF a refusé de donner.

Mais l’association est tout l’intérêt, et voici ce que le recensement ajoute et que les guides de configuration ne peuvent pas apporter : sur les 77 484 057 enregistrements en softfail présents sur Internet, seuls 7,1 millions — environ 1 sur 11 — ont une politique DMARC contraignante derrière eux. Pour les 70,4 millions d’autres domaines, ~all est exactement ce qu’il paraît. Leur enregistrement identifie la falsification et la laisse passer.

Les mandats de 2024 n’ont-ils pas réglé cela ?

Non — et la distinction compte plus que ne le suggère la plupart des articles. Google et Yahoo ont commencé à exiger une authentification des expéditeurs en masse en février 2024, Microsoft leur emboîtant le pas en mai 2025 : un SPF ou un DKIM valide et aligné, plus un enregistrement DMARC d’au minimum p=none. Les mandats ne vont pas jusqu’à exiger l’application — un domaine avec ~all, un enregistrement p=none et un DKIM aligné se conforme pleinement, et reste entièrement usurpable. Les mandats ont normalisé la paperasse, pas la protection. Cet entre-deux non appliqué — conforme, publié, falsifiable — est précisément la faille que ce recensement mesure, et c’est la population la plus importante de la sécurité du courriel.

Alors, par quoi votre enregistrement devrait-il se terminer ?

Vous envoyez du courrier et le réacheminement compte (newsletters, listes de diffusion, alias) : ~all avec un DMARC p=reject derrière — l’association recommandée ci-dessus.
Vous envoyez du courrier depuis une configuration strictement contrôlée : -all fonctionne et énonce la politique dans l’enregistrement lui-même. Cartographiez d’abord vos expéditeurs — une terminaison stricte sur un enregistrement mal cartographié casse du vrai courrier, voire pire.
Le domaine n’envoie jamais : -all plus p=reject, dès aujourd’hui. Aucun courrier légitime à protéger, donc rien à casser.

Quelle que soit la terminaison que vous choisissez, la leçon en une ligne du recensement tient : le qualificateur ne compte que dans la mesure de ce qui l’applique. Votre position sur cette échelle est mesurable.

Foire aux questions

SPF ~all ou -all, lequel est meilleur ? Aucun, de manière universelle. ~all avec une politique DMARC contraignante est le modèle que recommandent les directives de Google — une protection égale auprès des récepteurs qui évaluent le DMARC, sans casser le courrier réacheminé. -all convient aux expéditeurs strictement contrôlés. ~all seul — l’état de tous les domaines en softfail sauf 1 sur 11 — est l’option faible.

Que signifie le softfail SPF ? ~all indique aux récepteurs que le courrier provenant de serveurs non répertoriés est probablement illégitime mais devrait tout de même être accepté, généralement avec méfiance. Cela ne devient une véritable protection que lorsqu’une politique DMARC agit sur l’échec ; voir SPF sans DMARC.

Le hardfail -all va-t-il casser mon courrier réacheminé ? C’est possible : le réacheminement renvoie votre courrier depuis le serveur du réachemineur, que votre SPF ne répertorie pas, et un hardfail invite au rejet avant même que le DKIM ou le DMARC ne se prononcent. C’est ce risque qui justifie l’existence de l’association ~all + p=reject.

Google et Microsoft exigent-ils désormais -all ? Non. Les mandats pour expéditeurs en masse exigent une authentification alignée et valide et un enregistrement DMARC d’au minimum p=none — sans application, sans qualificateur spécifique. Le rejet par Google du courrier en masse non conforme est en vigueur ; Microsoft place les échecs en indésirables et évolue vers un rejet pur et simple. La conformité n’est pas la protection.

Vérifiez par quoi se termine votre enregistrement — et ce qui se tient derrière

Deux recherches vous disent les deux, gratuitement, en 30 secondes. Si vous faites partie des 70,4 millions de haussements d’épaules non appliqués, le correctif est un enregistrement DNS, pas un achat.

Vérifiez votre domaine → · Corriger le SPF → · Corriger le DMARC → · Le modèle de maturité SPF → · La carte du +all → · Données agrégées uniquement. Données stockées et traitées dans l’UE.