Générateur d'enregistrement SPF

Le formulaire ci-dessus assemble un enregistrement v=spf1 à partir des mécanismes choisis : une ou plusieurs entrées include: pour les prestataires de messagerie hébergés, des plages ip4/ip6 directes pour les serveurs que vous gérez vous-même, des options a et mx pour autoriser les hôtes résolus par le domaine, et un qualificateur all en clôture. Chaque champ correspond à un mécanisme SPF réel défini par la RFC 7208 - aucune syntaxe maison n'est utilisée.

Le champ include propose _spf.google.com par défaut car c'est l'entrée la plus courante pour les domaines sous Google Workspace, mais ce n'est qu'un point de départ - retirez-le et ajoutez ce que vos prestataires réels publient (Microsoft 365, SendGrid, Mailgun, une API transactionnelle, un outil de support). Chaque prestataire indique dans sa documentation la valeur include: exacte à utiliser.

L'enregistrement se construit en direct au fil des modifications du formulaire et devient prêt à copier dans un enregistrement TXT DNS à la racine du domaine (le domaine nu, pas un sous-domaine) dès qu'il reflète réellement votre infrastructure d'envoi.

include: importe l'enregistrement SPF d'un autre domaine et l'évalue comme s'il était inséré à cet endroit. C'est le bon choix pour tout prestataire hébergé qui gère et fait tourner ses propres IP d'envoi - vous pointez vers son enregistrement et il reste à jour de son côté. La plupart des plateformes d'emailing professionnel et marketing en publient un précisément dans ce but.

ip4: et ip6: autorisent directement une adresse ou une plage CIDR précise, sans recherche DNS nécessaire. Réservez-les aux infrastructures que vous contrôlez - un serveur de messagerie sur IP fixe, un relais sur site - puisque rien ne les met à jour automatiquement si cette adresse change.

a et mx autorisent ce que résolvent les propres enregistrements A/AAAA ou MX du domaine, au moment de l'évaluation. Ils sont surtout utiles quand le serveur qui envoie réellement le message est le même hôte que celui déjà pointé par l'enregistrement A ou MX du domaine ; un domaine qui envoie exclusivement via un prestataire tiers n'a généralement besoin d'aucun des deux.

Le mécanisme all doit être le dernier de l'enregistrement et détermine le sort des emails provenant d'un serveur non couvert par les mécanismes précédents. -all (hardfail) demande au serveur destinataire de rejeter directement ces emails. ~all (softfail) lui demande de les accepter mais de les traiter comme suspects, en général en pénalisant un score anti-spam plutôt qu'en les renvoyant. ?all (neutral) n'a pas plus de poids que l'absence totale d'enregistrement SPF, et +all autorise n'importe quel serveur sur internet - l'inverse de ce que SPF est censé garantir.

Le générateur propose -all par défaut, mais un enregistrement pas encore entièrement validé face aux sources d'envoi réelles devrait d'abord partir en ~all : observer le flux de mail et les journaux des prestataires pendant un certain temps, confirmer qu'aucun envoi légitime n'est signalé, puis basculer le qualificateur en -all une fois la liste d'include et d'ip4/ip6 complète. Publier -all avant d'avoir recensé tous les expéditeurs légitimes est la cause la plus fréquente d'un déploiement SPF qui bloque silencieusement de vrais emails.

La RFC 7208 plafonne l'évaluation SPF à 10 recherches DNS par contrôle. include, a, mx, ptr et exists consomment chacun au moins une recherche ; ip4 et ip6 n'en consomment aucune, puisqu'ils ne nécessitent pas de résolution. Le compte ne se limite pas aux mécanismes de votre propre enregistrement - un include: hérite de toutes les recherches que fait l'enregistrement du prestataire inclus, si bien que trois ou quatre prestataires chaînés peuvent dépasser la limite alors que votre propre enregistrement semble court.

Au-delà de 10 recherches, la RFC 7208 impose un résultat permerror, et la plupart des serveurs destinataires traitent alors l'ensemble du contrôle comme un échec, que l'IP d'envoi réelle ait été autorisée ou non. La solution consiste à retirer les include superflus, supprimer les mécanismes a ou mx inutiles, ou remplacer un include par les plages ip4/ip6 littérales qu'il résout - en acceptant qu'il faudra alors les mettre à jour manuellement à chaque changement d'IP côté prestataire.

L'enregistrement commence par v=spf1 et se lit de gauche à droite - le premier mécanisme qui correspond à l'IP du serveur émetteur détermine le résultat, mais l'ordre change rarement le résultat en pratique puisque ip4, ip6, include, a et mx ne correspondent chacun qu'à leurs propres expéditeurs, all ne pouvant par définition correspondre qu'en dernier.

Avant de publier, comparez le résultat du bouton de copie à ce que vous voulez réellement autoriser : chaque include: doit correspondre à un prestataire qui envoie effectivement des emails pour le domaine, chaque entrée ip4/ip6 doit être une adresse que vous contrôlez, et le qualificateur all doit refléter votre degré de confiance dans l'exhaustivité de la liste au-dessus. Une fois l'enregistrement publié, passez-le dans /spf-checker pour confirmer que le TXT DNS correspond bien à ce que vous avez publié et voir le nombre de recherches résolues face à la limite de la RFC 7208.

• Publier plus d'un enregistrement TXT SPF - la RFC 7208 impose exactement un enregistrement ; un domaine qui en a deux est traité comme n'en ayant aucun de valide
• Laisser +all en place, ce qui autorise n'importe quel serveur sur internet à envoyer au nom du domaine
• Oublier un prestataire ajouté plus tard (nouveau CRM, outil de facturation, plateforme marketing) dont les emails échouent alors au contrôle SPF
• Chaîner assez de mécanismes include: pour dépasser la limite de 10 recherches, provoquant un permerror sur chaque message
• Publier l'enregistrement sur un sous-domaine en espérant que le SPF du domaine parent s'applique - SPF s'évalue par nom d'hôte exact, sans héritage
• Basculer directement en -all sans avoir confirmé que tous les expéditeurs légitimes sont déjà listés