SPF fonctionne en ajoutant une entrée DNS (Domain Name System) spécifique pour un domaine, qui décrit les serveurs autorisés à envoyer des e-mails pour ce domaine. Les serveurs de messagerie qui reçoivent un e-mail vérifient alors que l'adresse IP de l'expéditeur est sur la liste des serveurs autorisés dans l’enregistrement SPF de ce domaine.
Au lieu d’indiquer une adresse IP ou un « include » d’adresses IPs dans l’enregistrement SPF, un administrateur de domaine peut décider d’utiliser le mécanisme PTR (DNS pointer record) comme présenté dans l’exemple ci-dessous :
- Hostname : DomaineA
- Type : TXT
- Value : v=spf1 ptr include:spf.mailjet.com include:spf.protection.outlook.com ip4:212.234.xxx.xxx ip4:212.51.xxx.xxx include:servers.mcsv.net -all
L’antispam recevant un e-mail avec un champs SMTP FROM / Enveloppe FROM / Return PATH faisant références à une adresse e-mail présente dans le domaine « DomaineA » par exemple ici :
Authentication-Results: spf=pass (sender IP is 208.117.XXX.XXX)
smtp.mailfrom=DomaineA; dkim=pass (signature was verified)
header.d=DomaineA ;dmarc=pass action=none
header.from= DomaineA ;compauth=pass reason=100
vérifiera si l’IP émettrice 208.117.XXX.XXX est présente dans l’enregistrement SPF suivant :
- Hostname : DomaineA
- Type : TXT
- Value : v=spf1 ptr include:spf.mailjet.com include:spf.protection.outlook.com ip4:212.234.xxx.xxx ip4:212.51.xxx.xxx include:servers.mcsv.net -all
Si cette IP n’est pas présente dans l’enregistrement SPF ci-dessus, l’antispam vérifiera l’adresse DNS associée à l’IP émettrice 208.117.XXX.XXX
(Peut être obtenu en faisant une commande « ping -a 208.117.XXX.XXX » dans un terminal Windows :
)
Et si cette adresse DNS fait partie du domaine « DomaineA » alors la vérification SPF réussira.
Pourquoi certains grands récepteurs ignoreront le mécanisme PTR - ou pire - ils ignoreront tout l'enregistrement SPF ?
- Temps de traitement : Effectuer une vérification PTR pour chaque IPs ayant émis un e-mail peut prendre beaucoup de temps, surtout pour les grands récepteurs qui reçoivent des millions de courriels par jour. Cela peut ralentir considérablement leur capacité à traiter les courriels.
- Taille du cache : utiliser le mécanisme PTR peut entraîner une augmentation importante de la taille du cache local. Les grands récepteurs doivent gérer un grand nombre de connexions et de requêtes DNS différentes, ce qui rend difficile de stocker toutes les informations DNS liées à ces IPs dans un cache.
- Problème de mise à jour : Les domaines et les adresses IP peuvent changer fréquemment, ce qui signifie que les informations d'enregistrement SPF et PTR peuvent devenir obsolètes rapidement. Les grands récepteurs doivent donc souvent mettre à jour leurs informations de cache, ce qui peut être fastidieux.
En raison de ces problèmes, certains grands récepteurs peuvent choisir de ne pas utiliser PTR ou d’ignorer les enregistrement SPF faisant référence à un mécanisme PTR. C’est pour cette raison que le mécanisme PTR est maintenant déprécié dans la RFC de SPF et ne doit donc pas être utilisé.
