SPF softfail (~all) ou hard fail (-all) : lequel choisir

Softfail ou hard fail : que font les serveurs ?

SPF produit un signal, et le serveur de réception décide de l’issue. La RFC 7208 définit ainsi les résultats :

• Fail (-all) déclare explicitement que le client n’est pas autorisé à utiliser l’identité. Les destinataires ont le droit de rejeter le message d’emblée pendant la transaction SMTP.
• Softfail (~all) se situe entre neutral et fail : le domaine pense que l’e-mail n’est probablement pas autorisé, sans certitude. La RFC dit que le logiciel de réception SHOULD NOT rejeter un message sur la seule base d’un softfail, mais MAY l’examiner de plus près que d’habitude, ce qui veut souvent dire, en pratique, le dossier spam.

Notez ce que SPF évalue : une identité SMTP, normalement l’expéditeur d’enveloppe, pas l’adresse que l’on voit dans son client de messagerie. La présentation de SPF explique le choix de cette identité. Le domaine From visible est protégé par l’alignement DMARC, souvent avec DKIM comme second chemin d’authentification.

Et ?all et +all ?

SPF définit deux autres qualificateurs finaux, ?all et +all. Aucun ne convient à un domaine d’envoi en production :

• ?all (neutre) n’affirme rien. Les expéditeurs non listés ne sont ni autorisés ni interdits, donc les destinataires le traitent à peu près comme une absence de politique SPF. Son seul usage légitime : un test bref pendant l’inventaire des expéditeurs.
• +all (pass) déclare que tout serveur d’internet peut envoyer au nom de votre domaine. Il aide activement les usurpateurs, et de nombreux filtres le traitent comme un signal de spam en soi. Rien ne justifie de le publier.

Pourquoi le transfert casse le hard fail ?

Le transfert casse le hard fail SPF car le serveur de transfert relaie votre message depuis sa propre IP, absente de votre enregistrement SPF. SPF ne distingue pas ce saut d’une usurpation : il échoue donc sur un e-mail que vous avez légitimement envoyé. Voici la séquence :

1. Si un destinataire transfère d’office votre e-mail, disons d’une adresse pro vers Gmail, son serveur de transfert devient le serveur d’envoi.
2. Ce serveur de transfert n’est pas dans votre SPF, donc SPF échoue.
3. Avec -all, le destinataire peut rejeter le message transféré sur le seul résultat SPF. Un e-mail légitime est perdu.
4. Avec ~all, le message est accepté avec suspicion, ce qui laisse à DKIM et DMARC la chance de l’authentifier correctement.

Avec DMARC, ~all est-il moins sûr que -all ?

Non. Avec une politique DMARC appliquée, softfail et hard fail protègent autant contre l’usurpation. La RFC 9989, la spécification DMARC actuelle qui rend obsolète la RFC 7489, évalue SPF comme réussi ou non, plus l’alignement avec le domaine From visible. Elle ne distingue pas un échec léger d’un échec strict :

• Si SPF ou DKIM réussit et s’aligne, le message réussit DMARC.
• Sinon, votre politique DMARC, p=quarantine ou p=reject, s’applique.

Que recommande le secteur ?

Pour un domaine qui envoie des e-mails, le secteur recommande ~all. Le monde de DMARC et de la délivrabilité penche de ce côté, et le dit publiquement :

• Google Workspace recommande clairement le softfail. Sa documentation SPF donne v=spf1 include:_spf.google.com ~all pour un domaine uniquement Workspace, et prévient qu’avec un hard fail, « les messages qui échouent au contrôle SPF risquent davantage d’être rejetés par le serveur de réception, et vous ne pouvez pas les utiliser pour dépanner votre SPF ».
• Al Iverson, de Spam Resource, a répondu directement. Sa réponse générale était -all, mais il a ajouté une mise à jour pour qui utilise DMARC : dès que votre politique est à p=quarantine ou p=reject, « ~all (tilde all) est probablement la meilleure option », car les échecs SPF évalués avant DMARC peuvent causer des rejets absents de vos rapports DMARC.
• La RFC 7208 explique pourquoi les deux résultats se comportent différemment : elle demande aux destinataires de ne pas rejeter sur un simple softfail.

La dissidence notable vient de Microsoft. Ses consignes SPF pour Microsoft 365 recommandent -all, au motif que « la politique DMARC est en pratique ignorée pour les échecs SPF ~all si les messages ne contiennent pas aussi de signature DKIM ». Lisez bien cette condition, car tout l’argument est là : elle vise les messages sans aucune signature DKIM. La spécification DMARC ne distingue pas softfail et fail : cela décrit le comportement d’un destinataire, pas la norme. Signez chaque service d’envoi avec DKIM, ce qu’il faut faire de toute façon, et l’objection ne vise plus vos e-mails.

Lequel utiliser : ~all ou -all ?

Le choix entre ~all et -all dépend du rôle du domaine, pas du qualificateur qui semble le plus strict. Décidez selon ce que fait le domaine :

• Le domaine envoie des e-mails (votre domaine principal) : utilisez ~all, activez DKIM sur chaque service d’envoi, et appliquez DMARC à p=quarantine puis p=reject. Cela bloque l’usurpation sans perdre les e-mails transférés.
• Le domaine n’envoie aucun e-mail (domaines parqués ou web seuls) : publiez l’enregistrement nu v=spf1 -all avec DMARC p=reject. Rien de légitime ne peut se perdre, et l’usurpation est totalement bloquée.
• Vous inventoriez encore vos expéditeurs : utilisez ~all, où un domaine d’envoi finit de toute façon. L’inventaire change les expéditeurs autorisés, pas le qualificateur final.

Aucune date de migration de ~all vers -all n’existe dans le secteur, ni bonus de délivrabilité à la clé. Sur un domaine qui envoie, ~all est l’état final, pas un tremplin : ce que vous durcissez avec le temps, c’est la politique DMARC, pas le qualificateur SPF. Si vous modifiez l’enregistrement pour une raison quelconque, gardez l’ancienne valeur et son TTL pour pouvoir revenir en arrière.

Comment déployer ~all et DMARC sans risque ?

Pour déployer ~all et DMARC sans risque, publiez d’abord le softfail et signez chaque expéditeur avec DKIM, avant de durcir la politique DMARC. Suivez les six étapes dans l’ordre :

1. Publiez SPF en softfail, avec chaque service d’envoi légitime :

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Cet enregistrement est un exemple. Publiez les mécanismes documentés pour vos propres expéditeurs, pas ces valeurs.

2. Activez la signature DKIM pour chaque service qui envoie au nom du domaine. C’est ce qui rend le softfail sûr et répond à l’objection de Microsoft ci-dessus.
3. Publiez un DMARC à p=none pour commencer. Le générateur DMARC le construit correctement.
4. Surveillez les rapports agrégés jusqu’à ce que chaque source légitime réussisse avec alignement. Ces rapports mettent un jour ou plus à arriver. Pour un avis immédiat sur un flux, le test de délivrabilité note un message que vous envoyez et montre si SPF et DKIM sont alignés.
5. Passez DMARC à p=quarantine, puis p=reject. C’est là que se joue la vraie protection contre l’usurpation.
6. Tenez l’enregistrement à jour à chaque nouvel outil, sous la limite SPF de 10 termes à requête DNS.

Validez la configuration finale à tout moment avec le test SPF : un seul enregistrement SPF, une syntaxe valide, all en dernier et une évaluation sous la limite de 10 termes.

Vérifiez d’abord le SPF publié

Passez le domaine dans le test SPF de Palisade avant de changer le qualificateur, puis comparez son résultat DNS avec l’identité évaluée et l’IP de connexion d’un message livré. Le test lit l’enregistrement public ; il ne peut pas reproduire la décision privée d’un destinataire.

Si les changements fréquents d’expéditeurs compliquent l’inventaire, le guide de remédiation de l’agent DMARC de Palisade montre comment les constats des rapports deviennent des tâches SPF, DKIM et d’alignement par source. Commencez s’il ne reste qu’à suivre les expéditeurs par les rapports.