Comment fonctionne la vérification SPF
Notre serveur demande au résolveur public de Cloudflare les enregistrements TXT du domaine et retient celui qui commence par v=spf1. Il cherche ensuite l’enregistrement SPF de chaque domaine nommé dans un include ou un redirect, et des domaines que ceux-ci nomment, jusqu’à 20 enregistrements et six niveaux de profondeur, comme le ferait un serveur de messagerie destinataire. Il ne contacte jamais les serveurs de messagerie eux-mêmes.
Chaque terme est lu selon les règles de la RFC 7208. Un destinataire compare l’adresse du serveur qui a envoyé un message aux termes, de gauche à droite ; le premier qui correspond décide, et son qualificateur dit comment : + réussite, - échec, ~ échec léger, ? neutre. Un terme sans qualificateur réussit.
Les termes include, a, mx, ptr, exists et redirect coûtent chacun une requête DNS, de même que ceux de chaque enregistrement inclus. La RFC 7208 en autorise 10 par vérification : au-delà, le destinataire s’arrête et SPF échoue pour tous les e-mails du domaine. ip4, ip6 et all ne coûtent rien. En mode collé, l’enregistrement est lu dans votre navigateur : seules ses propres requêtes sont donc comptées.
Mécanismes et qualificateurs SPF
Les termes que peut contenir un enregistrement SPF, ce que chacun fait correspondre, et ce qu’il coûte sur les 10 requêtes :
| Terme | Correspond quand le serveur expéditeur… | Requêtes |
|---|---|---|
ip4 | a une adresse IPv4 dans l’adresse ou la plage, comme ip4:192.0.2.0/24. | 0 |
ip6 | a une adresse IPv6 dans l’adresse ou la plage, comme ip6:2001:db8::/32. | 0 |
a | a une adresse que nomme l’enregistrement A ou AAAA du domaine (ce domaine, ou a:other.example). | 1 |
mx | est l’un des serveurs de messagerie du domaine (ses enregistrements MX). | 1 |
include | réussit l’enregistrement SPF d’un autre domaine, en général celui d’un service de messagerie. | 1 + celles de son enregistrement |
exists | fait exister un nom que le destinataire construit à partir du message ; pour des configurations spéciales. | 1 |
ptr | a un nom DNS inverse dans le domaine. À ne pas utiliser : lent et peu fiable. | 1 |
all | est n’importe quoi. Toujours en dernier : il définit ce qui arrive à tous les serveurs non listés. | 0 |
redirect= | est autorisé par l’enregistrement d’un autre domaine, utilisé quand rien dans celui-ci n’a correspondu. | 1 + celles de son enregistrement |
exp= | jamais : il ne fait que nommer un texte qui explique un rejet. | 0 |
Qualificateurs
- + réussite (valeur par défaut quand rien n’est écrit) : le serveur peut envoyer.
- - échec : le serveur n’a pas le droit d’envoyer ; les destinataires peuvent refuser l’e-mail.
- ~ échec léger : probablement non autorisé ; l’e-mail est accepté mais traité comme suspect.
- ? neutre : pas de verdict, comme s’il n’y avait pas d’enregistrement SPF.
Exemple
example.com publie "v=spf1 ip4:192.0.2.10 mx include:spf.mailer.example ~all". Le terme ip4 ne coûte aucune requête, mx en coûte une, et l’include en coûte une plus ce dont a besoin l’enregistrement de spf.mailer.example. Cet enregistrement est "v=spf1 ip4:198.51.100.0/24 include:spf2.mailer.example -all" : une requête de plus, et spf2.mailer.example ne liste que des plages d’adresses. Cela fait 3 sur 10. Un message venant de 192.0.2.10 réussit au premier terme ; un message venant de 203.0.113.5, qu’aucun terme ne liste, arrive à ~all et subit un échec léger : il est donc en général accepté mais traité comme suspect.
Questions
Qu’est-ce qu’un enregistrement SPF et comment le vérifier ?
SPF (Sender Policy Framework) est un enregistrement TXT du DNS d’un domaine qui liste les serveurs autorisés à envoyer des e-mails pour lui, et commence par v=spf1. Pour le vérifier, saisissez le domaine ci-dessus : l’outil trouve l’enregistrement, suit ses include et montre ce que signifie chaque terme et ce qui ne va pas. Pour vérifier un enregistrement avant de le publier, passez en mode enregistrement collé.
Comment corriger l’erreur SPF « too many DNS lookups » ?
SPF autorise 10 requêtes DNS par vérification, en comptant chaque include, a, mx, ptr, exists et redirect, y compris dans les enregistrements inclus. Au-delà de 10, l’enregistrement échoue avec une erreur permanente (permerror). Supprimez les include de services que vous n’utilisez plus, remplacez a et mx par les adresses ip4 et ip6 qu’ils représentent, et envoyez les e-mails en masse depuis un sous-domaine qui a son propre enregistrement SPF. L’aplatissement (copier les adresses d’un service dans votre enregistrement) fonctionne aussi, mais devient obsolète quand le service les change.
Un domaine peut-il avoir deux enregistrements SPF ?
Non. Un domaine ne peut publier qu’un seul enregistrement TXT commençant par v=spf1. Avec deux, les destinataires renvoient une erreur permanente et SPF échoue pour tous les e-mails. Fusionnez-les : gardez un seul v=spf1, mettez-y les termes des deux, et terminez par un seul ~all ou -all. Les sous-domaines ont leurs propres enregistrements et ne comptent pas.
Quelle est la différence entre ~all et -all ?
-all (échec) indique aux destinataires que les e-mails de serveurs non listés ne sont pas autorisés et peuvent être refusés. ~all (échec léger) dit qu’ils ne sont probablement pas autorisés : ils sont en général acceptés et marqués comme suspects. Avec DMARC en place, les destinataires suivent de toute façon la politique DMARC : ~all est donc le choix courant ; -all convient à un domaine qui n’envoie aucun e-mail. Évitez ?all et +all : ils ne protègent rien.
SPF protège-t-il l’adresse From que voient les gens ?
Pas à lui seul. SPF vérifie le domaine de l’adresse de retour (Return-Path), que les gens ne voient jamais : un faussaire peut donc réussir SPF avec un domaine à lui et afficher quand même le vôtre dans From. DMARC comble cette lacune : il exige que SPF ou DKIM réussisse pour le domaine de la ligne From. Utilisez la vérification DMARC pour voir si c’est le cas du vôtre.