SPF ~all ou -all ? Softfail et hardfail expliqués simplement

D'abord vérifier : comment se termine votre SPF ?

Saisissez votre domaine dans le test de domaine gratuit : Contrôle de domaine gratuit. Il affiche votre enregistrement SPF et signale une fin manquante, +all ou ?all. Un enregistrement typique ressemble à ceci :

v=spf1 include:spf.protection.outlook.com include:[include-newsletter] ~all

La dernière partie, la terminaison, s'applique à tous les serveurs qui ne sont pas cités avant. Le signe qui la précède s'appelle qualificateur et détermine le résultat.

Les quatre terminaisons et ce que fait le destinataire

SPF vérifie l'adresse de l'enveloppe (Return-Path), pas l'expéditeur visible. Si l'e-mail vient d'un serveur absent de l'enregistrement, la terminaison s'applique :

• -all donne fail (hardfail) : « Ce serveur n'a pas le droit d'envoyer pour nous. » La norme RFC 7208 autorise le destinataire à refuser l'e-mail, avec de préférence le code 550. Beaucoup de destinataires le distribuent quand même, avec une moins bonne évaluation.
• ~all donne softfail : « Probablement pas autorisé, mais nous ne l'affirmons pas. » Selon la norme, le destinataire ne doit pas refuser l'e-mail pour cette seule raison, mais peut l'examiner de plus près, par exemple le classer en spam.
• ?all donne neutral : aucune indication. La norme impose de le traiter comme « pas de SPF ». Prévu pour les tests, pas pour l'exploitation.
• +all donne pass pour n'importe quel serveur au monde. Ce n'est pas une protection, c'est une autorisation générale.

Sans terminaison, le résultat pour les serveurs inconnus est aussi neutral, comme si ?all figurait à la fin.

Pourquoi DMARC rend la question moins décisive

DMARC ne distingue pas softfail et hardfail. Pour DMARC, seule compte la question : SPF réussit-il et correspond-il au domaine de l'expéditeur visible ? Les deux résultats sont un échec. Le refus d'un e-mail falsifié dépend de votre règle DMARC (p=quarantine ou p=reject), pas du signe devant all.

Il existe toutefois deux nuances :

• Certains destinataires vérifient SPF avant DMARC. La norme DMARC RFC 7489 le signale expressément : avec -all, un tel destinataire peut refuser l'e-mail avant même d'évaluer DMARC, et donc DKIM. L'organisation professionnelle M3AAWG demande pour cette raison aux destinataires de ne refuser sur SPF fail qu'après l'évaluation DMARC, sauf pour l'enregistrement v=spf1 -all.
• Microsoft, comme destinataire, indique dans sa documentation que la règle DMARC ne s'applique pratiquement pas en cas de softfail SPF si l'e-mail ne porte aucune signature DKIM. Les stratégies anti-spam de Microsoft 365 comportent en outre l'option « SPF record: hard fail ». Elle est désactivée par défaut. Si un destinataire l'active, Microsoft 365 classe les e-mails en SPF fail comme spam à haut niveau de confiance, indépendamment de DKIM.

Ce que recommandent les grands fournisseurs

Les recommandations divergent, et chaque camp a de bonnes raisons :

• Microsoft recommande -all pour les domaines Microsoft 365, parce qu'il recommande aussi DKIM et DMARC. Les rapports DMARC doivent montrer si tous les canaux d'envoi sont couverts.
• Google recommande ~all dans l'aide de Google Workspace.
• Le M3AAWG (Messaging, Malware and Mobile Anti-Abuse Working Group) écrit dans ses recommandations sur l'authentification des e-mails de 2020 que les enregistrements SPF « should end in ~all » (devraient se terminer par ~all). Les domaines qui n'envoient pas d'e-mails doivent publier v=spf1 -all.

Tous s'accordent sur deux points : SPF seul ne suffit pas, il faut DKIM et DMARC. Et un domaine sans envoi d'e-mails reçoit v=spf1 -all.

Le risque de -all avec les transferts

Si un destinataire transfère votre e-mail, par exemple de la boîte d'une association vers une adresse privée, c'est ensuite le serveur du transfert qui envoie. Il ne figure pas dans votre SPF. SPF échoue donc forcément, quelle que soit la terminaison.

La différence : avec -all, vous risquez qu'un destinataire qui évalue SPF tôt et strictement refuse l'e-mail immédiatement. Votre signature DKIM valide aurait fait réussir DMARC, mais elle n'est jamais examinée. Avec ~all, l'e-mail est en général accepté, DKIM est vérifié et sauve DMARC.

Important : ~all ne répare pas DMARC lors des transferts. Sans signature DKIM alignée, DMARC échoue de toute façon. La terminaison décide seulement si DKIM a une chance d'être examiné.

Comment fiabiliser malgré tout les transferts : Transfert d'e-mails : SPF fail et e-mails transférés en spam

Pourquoi +all est dangereux

+all autorise n'importe quel serveur à envoyer au nom de votre domaine. Avec DMARC, c'est particulièrement piégeux : un fraudeur met votre domaine dans l'enveloppe et dans l'expéditeur visible. SPF réussit et correspond au domaine de l'expéditeur, donc DMARC réussit aussi. Votre règle p=reject devient inutile.

+all naît le plus souvent de l'impatience : un e-mail n'arrive pas, quelqu'un « ouvre » l'enregistrement, et la faille reste en place pendant des années. Il en va de même pour un all sans qualificateur : sans signe, c'est + qui s'applique.

Recommandation pour les PME selon le niveau DMARC

1. Le domaine n'envoie pas d'e-mails (domaines secondaires, anciens noms d'entreprise) : v=spf1 -all et DMARC avec p=reject.
2. Pas encore de DMARC ou p=none : ~all. Tant que vous ne savez pas avec certitude qui envoie en votre nom (comptabilité, boutique en ligne, scanner, newsletter), -all bloque les canaux oubliés. Mettez d'abord en place DMARC avec rapports, voir DMARC de p=none à quarantine et reject : quand est-ce sûr ?.
3. p=quarantine ou p=reject, tous les canaux signent avec DKIM : -all est alors défendable et correspond à la recommandation de Microsoft. ~all reste tout aussi correct. Si beaucoup de destinataires transfèrent vos e-mails, par exemple dans des associations, des écoles ou des listes de membres, restez sur ~all.

Passer de ~all à -all ne remplace pas DMARC. La protection contre les expéditeurs falsifiés vient de p=reject.

Reconnaître les erreurs dans l'en-tête

Envoyez un e-mail de test vers une boîte externe et ouvrez les en-têtes complets, dans Gmail via « Afficher l'original ». Cherchez Authentication-Results. Exemples abrégés :

spf=softfail (domain of transitioning info@example.com does not designate 203.0.113.25 as permitted sender) smtp.mailfrom=info@example.com

spf=fail (sender IP is 203.0.113.25) smtp.mailfrom=example.com; dkim=none; dmarc=fail action=quarantine header.from=example.com

Comment les lire :

• spf=softfail ou spf=fail, mais dkim=pass et dmarc=pass : le plus souvent un transfert. L'e-mail est en ordre.
• spf=fail et dmarc=fail pour un vrai e-mail de votre part : le serveur d'envoi manque dans votre SPF. Ajoutez l'include du fournisseur. Attention à la limite de dix requêtes DNS : Erreur SPF «too many DNS lookups» : pourquoi dix requêtes doivent suffire.
• spf=permerror : l'enregistrement est invalide, souvent à cause de deux enregistrements SPF : Deux entrées SPF pour un domaine : pourquoi cela invalide tout.
• spf=neutral : l'enregistrement se termine par ?all ou n'a pas de terminaison.

Erreurs typiques

• all au milieu de l'enregistrement : tout ce qui suit all est ignoré. v=spf1 -all include:[fournisseur] n'autorise pas le fournisseur.
• -all trop tôt : la boutique en ligne ou la comptabilité manque dans l'enregistrement, les factures sont refusées.
• +all comme solution de secours : supprime la protection de SPF et de DMARC.
• Domaines parqués sans SPF : les fraudeurs se rabattent volontiers sur les domaines inutilisés.

Ce que DomainRadar prend en charge

DomainRadar vérifie chaque jour votre enregistrement SPF et signale une terminaison manquante, trop ouverte ou invalide. Les rapports DMARC vous montrent quelles sources échouent à SPF et s'il s'agit de vos propres canaux d'envoi, de transferts ou de falsifications. Vous décidez ainsi du passage à -all sur la base de données réelles.