Une recherche SPF est la requête DNS qu'un serveur de messagerie destinataire exécute pour découvrir quels serveurs vous avez autorisés à envoyer des e-mails au nom de votre domaine. Elle a lieu à chaque message entrant, si bien que savoir exécuter la même recherche vous-même est le moyen le plus rapide de voir ce que voient les destinataires. Associez cette recherche à un vérificateur d'enregistrement SPF pour valider l'enregistrement que vous trouvez.
Comment fonctionne une recherche SPF
Votre enregistrement SPF est publié comme un enregistrement DNS TXT à l'apex de votre domaine (par exemple, à example.com, et non _spf.example.com). Lorsqu'un message arrive, le destinataire lit le domaine de l'expéditeur d'enveloppe, interroge les enregistrements TXT de ce domaine, trouve celui commençant par v=spf1, et l'évalue au regard de l'adresse IP du serveur qui se connecte. Si l'IP est autorisée, SPF passe ; sinon, le qualificateur de l'enregistrement décide de la suite.
Lire l'enregistrement SPF brut
Une recherche renvoie une seule ligne comme celle-ci :
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.0/24 -all
Chaque token est un mécanisme : include: intègre les expéditeurs autorisés d'un autre fournisseur, ip4: autorise directement une adresse ou une plage, et le -all final indique aux destinataires de rejeter quiconque n'est pas correspondant ; notre guide sur a, mx, ip4 et include couvre chacun d'eux. La chaîne brute n'est cependant que la moitié du tableau - le vrai travail consiste à développer ce que contiennent ces include.
Expansion récursive des include et décompte des recherches
Chaque include: est lui-même un domaine avec son propre enregistrement SPF, qui peut contenir d'autres include. Cet outil suit cette chaîne jusqu'au bout, si bien qu'un enregistrement qui semble ne comporter que trois include peut en réalité se résoudre en une douzaine de recherches DNS. Cela compte car la RFC 7208 plafonne l'évaluation à dix mécanismes interrogeant le DNS (plus une limite de deux recherches à vide) ; franchissez l'une ou l'autre et les destinataires renvoient un PermError. Si votre enregistrement développé dépasse dix, AutoSPF aplatit les include en un enregistrement compact et le maintient à jour - voir trop de recherches DNS.
Rechercher un enregistrement SPF manuellement
Vous pouvez exécuter la requête sous-jacente vous-même depuis un terminal. Sur macOS ou Linux :
dig TXT example.com +short
Sur Windows :
nslookup -type=TXT example.com
Les deux renvoient les enregistrements TXT bruts, y compris la ligne SPF - mais ni l'un ni l'autre ne développe les include imbriqués ni ne compte le total des recherches, ce qui explique pourquoi un outil de recherche dédié est plus rapide pour tout ce qui dépasse un simple coup d'œil.
Quand une recherche ne renvoie rien (ou échoue)
- Aucun enregistrement trouvé. Le domaine ne publie aucun enregistrement TXT
v=spf1, si bien que les destinataires n'ont rien pour contrôler l'expéditeur. - Deux enregistrements trouvés. La RFC 7208 n'en autorise qu'un ; un second produit un PermError et les deux sont ignorés - fusionnez les enregistrements SPF en une seule entrée pour corriger cela.
- Le sous-domaine n'a pas d'enregistrement. Les sous-domaines n'héritent pas de l'enregistrement SPF du parent - chaque sous-domaine émetteur a besoin du sien.
- PermError sur le décompte. Syntaxe valide, mais les recherches développées dépassent dix.
Après la recherche : validez, corrigez et couvrez DKIM et DMARC
Une fois l'enregistrement obtenu, soumettez-le au validateur SPF pour le contrôler au regard de chaque règle RFC, ou reconstruisez-le proprement avec le générateur d'enregistrement SPF. Et comme SPF ne couvre que le serveur d'envoi, associez-le au vérificateur DMARC gratuit et à la recherche DKIM - DMARC est ce qui relie SPF et DKIM à votre adresse From visible. Recherchez votre enregistrement chaque fois que vous ajoutez un expéditeur, migrez de fournisseur ou constatez que du courrier atterrit en spam.