Vérifier SPF : votre enregistrement SPF fonctionne-t-il ?
Vos e-mails finissent dans les spams, ou un service vous dit que votre SPF est invalide ? Saisissez votre domaine ci-dessous. Le vérificateur récupère l’enregistrement SPF, suit chaque include, compte les requêtes DNS face à la limite de 10 et liste en langage clair ce qu’il faut corriger.
Comment un serveur destinataire utilise votre enregistrement SPF
Quand un message arrive, le serveur destinataire regarde le domaine de l’expéditeur d’enveloppe et récupère l’enregistrement SPF de ce domaine : un enregistrement TXT qui commence par v=spf1. Il vérifie ensuite si l’adresse IP du serveur qui vient de se connecter figure dans la liste. Le résultat est pass, fail, softfail ou neutral, et le destinataire le pondère avec d’autres signaux pour décider si le message va dans la boîte de réception ou dans le dossier spam.
SPF vérifie l’expéditeur d’enveloppe, pas l’adresse From que les gens voient dans leur messagerie. Combler cet écart est le rôle de DMARC.
Les termes SPF en un coup d’œil
| Terme | Ce qu’il fait |
|---|---|
| ip4:192.0.2.0/24 | Autorise une adresse ou une plage IPv4 |
| ip6:2001:db8::/32 | Autorise une adresse ou une plage IPv6 |
| a | Autorise les adresses des enregistrements A et AAAA du domaine lui-même |
| mx | Autorise les adresses des serveurs de messagerie du domaine |
| include:_spf.example.net | Autorise aussi tout ce que l’enregistrement SPF de ce domaine autorise |
| exists:name | Autorise quand une recherche DNS du nom renvoie une adresse |
| ptr | Obsolète. Fait la correspondance par DNS inversé et ne doit pas être utilisé |
| all | Correspond à tout : il se place donc en dernier et définit le résultat par défaut |
Un qualificatif devant un terme définit le résultat en cas de correspondance : + pass (par défaut), - fail, ~ softfail, ? neutral. Les terminaisons habituelles sont ~all, qui marque les expéditeurs non listés comme suspects, et -all, qui demande aux destinataires de les rejeter.
Pourquoi SPF casse quand on ajoute un service de plus
SPF autorise au maximum 10 termes qui déclenchent une requête DNS pendant l’évaluation d’un enregistrement. include, a, mx, ptr et exists comptent, tout comme un modificateur redirect. ip4, ip6 et all ne comptent pas. Les requêtes à l’intérieur d’un enregistrement inclus sont comptées dans le même total.
C’est ainsi qu’un enregistrement sain se dégrade : vous ajoutez un outil de newsletter, un helpdesk, un CRM et un système de facturation, chacun avec son propre include, et certains de ces include contiennent eux-mêmes des include. Dépassez 10 et SPF renvoie une erreur permanente. Les destinataires peuvent alors traiter chaque message comme si le domaine n’avait aucun SPF, sans que personne ne vous prévienne.
- Supprimez les include des services que vous n’utilisez plus.
- Remplacez un include par des plages ip4 et ip6 quand les adresses d’un fournisseur sont stables.
- N’utilisez jamais ptr.
- Donnez à chaque service d’envoi son propre sous-domaine quand c’est possible. Chaque nom a sa propre limite de 10.
- Si vous aplatissez des include en adresses, n’oubliez pas que les fournisseurs changent leurs plages : un enregistrement aplati demande donc des mises à jour régulières.
Une façon sûre de définir votre politique SPF
- Publiez un seul enregistrement SPF par nom. Deux enregistrements constituent une erreur permanente.
- Commencez par ~all le temps de confirmer que tous les expéditeurs légitimes sont listés, puis passez à -all quand vous en êtes sûr.
- Rappelez-vous que SPF ne s’hérite pas. Un sous-domaine qui envoie des e-mails a besoin de son propre enregistrement, et un sous-domaine qui n’en envoie jamais peut publier v=spf1 -all.
- Associez SPF à DKIM et à une politique DMARC. Chacun compense les faiblesses des autres.