Un contrôle SPF renvoie l'un des sept résultats définis par la RFC 7208 : none, neutral, pass, fail, softfail, temperror ou permerror. neutral et softfail signifient que le serveur d'envoi n'est pas clairement autorisé par votre enregistrement. permerror signifie que votre SPF est illisible et doit être corrigé, temperror signale un incident DNS temporaire. Le résultat apparaît dans l'en-tête Authentication-Results des emails reçus. Voici ce que veut dire chacun, ses causes habituelles et la correction à appliquer.
Les 7 résultats SPF de la RFC 7208
| Résultat | Ce que dit la norme | Cause typique | Que faire |
|---|
pass | Le serveur est autorisé à envoyer pour ce domaine | Configuration correcte | Rien |
none | Aucun enregistrement SPF trouvé, ou domaine inexploitable | SPF jamais publié | Publier un SPF |
neutral | Le domaine déclare ne pas se prononcer sur ce serveur | Enregistrement terminé par ?all | Lister les serveurs et passer à ~all ou -all |
softfail | Le serveur n'est probablement pas autorisé | Serveur absent d'un SPF terminé par ~all | Ajouter le service s'il est légitime |
fail | Le serveur n'est pas autorisé | Serveur absent d'un SPF terminé par -all | Ajouter le service s'il est légitime |
temperror | Erreur transitoire, généralement DNS | Serveurs DNS lents ou injoignables | Vérifier la disponibilité des DNS |
permerror | L'enregistrement ne peut pas être interprété | Syntaxe, doublon, plus de 10 requêtes DNS | Corriger l'enregistrement |
Le résultat dépend du mécanisme qui correspond en premier, puis du qualificatif final all : +all (tout autoriser, à proscrire), ?all (neutral), ~all (softfail), -all (fail).
SPF neutral : que faire
Un résultat neutral vient presque toujours d'un enregistrement qui se termine par ?all :
"v=spf1 include:_spf.google.com ?all"
La RFC 7208 impose de traiter un neutral exactement comme un none, c'est-à-dire comme si vous n'aviez pas de SPF pour les serveurs non listés. Votre SPF n'apporte alors aucune protection contre l'usurpation.
Correction :
- Listez tous les services qui envoient des emails avec votre domaine (messagerie, outil d'emailing, site e-commerce, CRM). Les rapports DMARC aident à n'en oublier aucun.
- Ajoutez-les au SPF.
- Remplacez
?all par ~all, puis par -all quand vous êtes sûr de la liste.
Le générateur SPF construit l'enregistrement à partir des services que vous cochez.
SPF softfail : grave ou pas ?
~all est un réglage très répandu, proposé par défaut par plusieurs fournisseurs, dont OVHcloud (v=spf1 include:mx.ovh.com ~all). Un softfail sur un email légitime veut dire qu'un de vos services d'envoi manque à l'enregistrement.
Selon la RFC 7208, un récepteur ne devrait pas rejeter un message sur la seule base d'un softfail, mais peut l'examiner de plus près. En pratique, le message est plus exposé au dossier spam, surtout s'il échoue aussi à DKIM et donc à DMARC. Si le softfail concerne un serveur que vous ne connaissez pas, c'est probablement une tentative d'usurpation : votre SPF fait son travail.
SPF permerror : les causes et les corrections
Un permerror est le résultat le plus dangereux, car il invalide tout votre SPF. Pour DMARC, un SPF en permerror ne compte pas comme validé. Avec une politique DMARC restrictive, vos emails légitimes peuvent finir en spam ou être rejetés si DKIM ne compense pas.
Cause 1 : plus de 10 requêtes DNS
La RFC 7208 limite à 10 le nombre de mécanismes qui déclenchent une requête DNS : include, a, mx, ptr, exists et le modificateur redirect. Les include imbriqués comptent aussi. Au-delà, le résultat est permerror. Les mécanismes ip4, ip6 et all ne comptent pas.
Exemple d'enregistrement à risque :
"v=spf1 a mx include:_spf.google.com include:spf.protection.outlook.com include:mx.ovh.com include:servers.mcsv.net include:sendgrid.net include:_spf.salesforce.com ~all"
Chaque include peut en contenir d'autres. Le total réel se calcule en suivant toute la chaîne.
Corrections possibles :
- supprimez les services que vous n'utilisez plus ;
- retirez
a et mx si ces serveurs n'envoient pas d'emails ;
- déplacez un flux d'envoi sur un sous-domaine (
news.votre-domaine.fr) qui a son propre SPF ;
- remplacez un
include par des plages ip4 fixes, seulement si le fournisseur garantit leur stabilité.
La norme limite aussi à deux les « void lookups », c'est-à-dire les requêtes qui ne renvoient aucune réponse. Un include vers un domaine qui n'a plus de SPF peut donc aussi provoquer un permerror.
Cause 2 : deux enregistrements SPF
Un domaine ne doit publier qu'un seul enregistrement commençant par v=spf1. S'il y en a deux, le résultat est permerror. C'est l'erreur classique après l'ajout d'un nouveau service, quand le prestataire crée son propre SPF au lieu de compléter l'existant. Nous l'avons détaillée dans deux enregistrements SPF : la panne que personne ne voit. Fusionnez-les en un seul :
# Avant (permerror)
"v=spf1 include:mx.ovh.com ~all"
"v=spf1 include:_spf.google.com ~all"
# Après
"v=spf1 include:mx.ovh.com include:_spf.google.com ~all"
Cause 3 : erreur de syntaxe
Fautes courantes :
v=spf1 mal écrit (v=spf, v=spf2) ;- mécanisme inconnu ou mal orthographié (
inlcude:, ipv4: au lieu de ip4:) ;
- adresse IP ou plage CIDR invalide ;
- guillemets ajoutés en double par l'interface DNS.
SPF temperror : un problème DNS, pas de syntaxe
Un temperror indique que la vérification n'a pas pu aboutir à cause d'une erreur transitoire, le plus souvent DNS. Une nouvelle tentative plus tard peut réussir. La RFC 7208 prévoit que le serveur de réception puisse répondre par un refus temporaire (code SMTP 4xx) : l'expéditeur réessaie alors plus tard.
Causes à vérifier :
- serveurs DNS faisant autorité lents ou en panne ;
- un des domaines inclus (
include:) dont les DNS ne répondent pas ;
- réponse DNS trop volumineuse mal gérée par un pare-feu.
Si le temperror revient régulièrement, testez vos serveurs de noms un par un :
dig +short NS votre-domaine.fr
dig @ns1.exemple-dns.fr TXT votre-domaine.fr
Vérifier votre SPF avec dig
Lisez l'enregistrement publié :
dig +short TXT votre-domaine.fr
Ne retenez que les lignes qui commencent par "v=spf1. S'il y en a deux, vous avez trouvé votre permerror.
Suivez ensuite chaque include pour compter les requêtes :
dig +short TXT _spf.google.com
dig +short TXT mx.ovh.com
Pour savoir quel résultat SPF un email a obtenu, ouvrez ses en-têtes complets et cherchez Received-SPF ou la mention spf= dans Authentication-Results :
Authentication-Results: mx.google.com;
spf=softfail (google.com: domain of transitioning contact@votre-domaine.fr does not designate 198.51.100.7 as permitted sender) smtp.mailfrom=contact@votre-domaine.fr
L'IP indiquée (198.51.100.7) est celle du serveur qui a envoyé le message. Si c'est l'un de vos services, ajoutez-le. L'outil sécurité email affiche votre SPF, le nombre de requêtes DNS et les erreurs détectées.
SPF ne suffit pas seul
SPF vérifie le domaine de l'enveloppe (MAIL FROM), pas l'adresse affichée au destinataire. Il échoue aussi lors des transferts automatiques. C'est pour cela qu'il faut l'associer à DKIM et DMARC. Une fois votre SPF propre, passez à DMARC avec la méthode pour passer de p=none à reject, et revoyez les bases dans SPF, DKIM, DMARC : protéger ses emails de l'usurpation.
Un SPF correct peut se casser du jour au lendemain, par exemple quand un prestataire ajoute un second enregistrement. Domains Defender surveille la configuration email de vos domaines (SPF, DKIM, DMARC) et vous alerte quand elle se dégrade. Pour contrôler un domaine maintenant, lancez l'audit gratuit.
Questions fréquentes
SPF neutral : que faire ?
Votre enregistrement se termine probablement par ?all. Listez tous vos services d'envoi dans le SPF, puis remplacez ?all par ~all ou -all. Tant qu'il reste en ?all, il ne protège pas contre l'usurpation.
Comment corriger un SPF permerror ?
Vérifiez trois choses dans l'ordre : un seul enregistrement v=spf1 sur le domaine, pas plus de 10 mécanismes qui déclenchent une requête DNS (includes imbriqués compris), et une syntaxe valide. Fusionnez les doublons et supprimez les includes inutiles.
SPF temperror : est-ce que mes emails sont perdus ?
Généralement non. Le serveur de réception peut répondre par un refus temporaire, et le serveur d'envoi réessaie plus tard. Si l'erreur persiste, vos serveurs DNS ou ceux d'un domaine inclus ont un problème de disponibilité.
Faut-il utiliser ~all ou -all ?
~all est plus tolérant pendant que vous recensez vos services d'envoi. -all est plus strict. Avec un DMARC en p=reject, c'est surtout la politique DMARC qui décide du sort des emails non authentifiés.