Valider un enregistrement SPF, c'est le contrôler au regard des règles que les serveurs de messagerie destinataires appliquent réellement - la spécification Sender Policy Framework (RFC 7208). Un enregistrement peut sembler correct et tout de même être rejeté, voici donc ce que « valide » signifie et comment corriger les défauts que ce validateur repère.
Ce que « valide » signifie selon la RFC 7208
Un enregistrement SPF valide satisfait chacune de ces conditions à la fois : il est le seul enregistrement TXT v=spf1 du domaine, il commence par la balise v=spf1, il n'utilise que des mécanismes et qualificateurs reconnus, il se résout en dix recherches DNS ou moins, il ne produit pas plus de deux recherches à vide, et il se termine par un qualificateur all. Manquez-en une seule et les destinataires peuvent renvoyer un PermError et traiter l'enregistrement comme s'il n'avait jamais été publié.
Les règles de syntaxe que le validateur applique
- Un seul enregistrement. La RFC 7208 n'autorise qu'un seul enregistrement
v=spf1par domaine. Un second est un PermError automatique - les deux sont ignorés. - Ordre correct. La balise de version
v=spf1doit venir en premier et le mécanismealldoit venir en dernier. - Mécanismes et qualificateurs valides uniquement. Les mécanismes autorisés sont
include,a,mx,ip4,ip6,existsetall; chacun peut porter un qualificateur+,-,~ou?. Des fautes de frappe commeip:ouincludes:échouent. - Longueur des chaînes. Toute chaîne de caractères unique dans l'enregistrement TXT doit rester dans les 255 caractères, et l'enregistrement entier dans les 512 octets, sinon le DNS le tronque.
Les limites de 10 recherches et 2 recherches à vide
Deux limites numériques attrapent la plupart des enregistrements « syntaxe valide, mais qui échoue tout de même ». La première est le plafond bien connu de dix mécanismes interrogeant le DNS par évaluation - chaque include, a, mx, ptr et exists compte, et les include imbriqués comptent de façon récursive. La seconde, moins familière, concerne les recherches à vide : pas plus de deux mécanismes ne peuvent se résoudre en une réponse DNS vide. Dépassez l'une ou l'autre et le résultat est un PermError. Si votre enregistrement dépasse la limite de dix recherches, AutoSPF aplatit les include en un enregistrement compact qui se valide proprement et rescanne toutes les 15 minutes - voir trop de recherches DNS pour les détails.
Mécanismes obsolètes et risqués
Le validateur avertit sur deux choses techniquement analysables mais à éviter. Le mécanisme ptr est rendu obsolète par la RFC 7208 (§5.5) parce qu'il est lent et peu fiable - remplacez-le par ip4/ip6 ou un include. Et +all autorise l'intégralité d'Internet à envoyer au nom de votre domaine, anéantissant totalement l'objectif de SPF ; un enregistrement valide devrait se terminer par -all ou ~all.
Comment corriger un enregistrement SPF invalide
La plupart des échecs de validation correspondent à l'une de quatre corrections - et notre guide sur comment résoudre les échecs de validation SPF traite chacune en profondeur :
- Deux enregistrements SPF ? Fusionnez tous les expéditeurs dans un unique enregistrement
v=spf1. - Plus de 10 recherches ? Remplacez les include gourmands en recherches par des entrées
ip4/ip6, ou aplatissez l'enregistrement automatiquement avec AutoSPF. ptrobsolète ? Supprimez-le et autorisez ces hôtes par IP ou include à la place.- Qualificateur manquant ou incorrect ? Assurez-vous que l'enregistrement commence par
v=spf1et se termine par-all(ou~allpendant vos tests).
Reconstruire à partir de zéro est souvent plus facile que rapiécer - le générateur d'enregistrement SPF gratuit produit un enregistrement syntaxiquement propre que vous pouvez valider ici en une seule étape.
Où se situe SPF aux côtés de DKIM et DMARC
Un enregistrement SPF valide est nécessaire mais pas suffisant. DKIM signe le corps du message et DMARC relie SPF et DKIM au domaine From visible et fixe la politique d'application. Après avoir vérifié votre enregistrement SPF et sa validation, confirmez les deux autres avec le vérificateur DMARC gratuit et la recherche DKIM. Revalidez SPF chaque fois que vous ajoutez ou supprimez un service d'envoi, et auditez-le au moins une fois par trimestre - et rappelez-vous que chaque sous-domaine émetteur a besoin de son propre enregistrement valide.