Qu’est-ce que la syntaxe de l’enregistrement SPF, et quel est son effet sur les e-mails applicatifs ?

Un enregistrement SPF est une expression de politique ordonnée

La RFC 7208 définit un enregistrement SPF comme une chaîne DNS TXT dont le premier terme est v=spf1. Les autres termes, séparés par des espaces, sont des mécanismes, qui peuvent correspondre, et des modificateurs, qui changent le traitement. L’évaluation se fait de gauche à droite et s’arrête au premier mécanisme correspondant : l’ordre exprime donc la politique. Un enregistrement typique peut autoriser deux plages d’adresses fixes, inclure la politique d’un fournisseur, puis se terminer par -all. Ne collez pas ce modèle tel quel : l’enregistrement correct dépend des identités SMTP MAIL FROM ou HELO exactes et des sources d’envoi réelles. Inventoriez d’abord les fournisseurs applicatifs, les serveurs de messagerie, les outils de support, les plateformes d’identité, les systèmes marketing, les chemins de transfert et les expéditeurs de reprise après sinistre. Publiez la politique sur le domaine évalué, et non automatiquement sur le domaine From visible. Un enregistrement syntaxiquement valide peut malgré tout autoriser les mauvaises sources, omettre un flux de production ou dépasser les limites d’évaluation DNS.

Les qualificateurs associent une correspondance de mécanisme à un résultat SPF

Un mécanisme peut commencer par un qualificateur : + pour pass, - pour fail, ~ pour softfail ou ? pour neutral. En l’absence de qualificateur, + est implicite. Le qualificateur ne s’applique que lorsque ce mécanisme correspond. Il ne change pas le fait que les termes suivants sont évalués lorsque le mécanisme ne correspond pas. Les équipes se concentrent souvent sur le terme all final, mais chaque mécanisme include, d’adresse, a, mx ou exists qui le précède possède aussi un qualificateur et peut mettre fin à l’évaluation. Procédez à une revue explicite plutôt que de supposer que ~all signifie « mode test » ou que -all prouve que toutes les sources sont connues. Un résultat fail est une preuve, pour le destinataire, concernant l’identité SMTP et l’IP évaluées, et non un ordre universel de supprimer l’e-mail. Les destinataires appliquent leur politique locale. Neutral et softfail ne sont pas des autorisations. Consignez le résultat attendu pour les sources autorisées, non autorisées et temporairement non résolues, et vérifiez-le avec des jeux d’IP et d’identités contrôlés.

Les mécanismes d’adresse sont directs mais exigent une responsabilité claire

Les mécanismes ip4 et ip6 autorisent les plages réseau correspondantes, exprimées dans la syntaxe propre à chaque protocole avec une longueur de préfixe facultative. Ils évitent des requêtes d’adresse supplémentaires lors de l’évaluation, mais peuvent devenir obsolètes à mesure que les réseaux de sortie évoluent. Utilisez des adresses d’envoi publiques, jamais les adresses privées de l’environnement d’exécution, et gardez les plages aussi étroites que le basculement opérationnel le permet. Chaque plage doit avoir un responsable, un système source, un environnement, une procédure de changement et une date de révision. Le mécanisme a résout un nom A ou AAAA, par défaut le domaine SPF courant sauf si un autre domain-spec est fourni. Le mécanisme mx résout les hôtes MX et leurs adresses. Ces mécanismes ajoutent du travail DNS et peuvent autoriser une infrastructure qui change en dehors des mises en production de l’application. N’utilisez pas a ou mx comme raccourci, sauf si toutes les adresses résolues sont délibérément autorisées à envoyer avec cette identité SMTP exacte. Surveillez les changements et testez les chemins IPv4 comme IPv6.

Include évalue une autre politique, ce n’est pas un fragment de texte

Le mécanisme include évalue la politique SPF du domaine référencé et correspond lorsque cette évaluation imbriquée renvoie pass. Il ne recopie pas mécaniquement des termes dans la chaîne courante, et les autres résultats imbriqués ont des effets définis. N’utilisez include que lorsque l’organisation référencée documente explicitement ce domaine pour votre relation d’envoi. Le domaine du site web d’un fournisseur, son domaine MX ou le domaine From visible ne sont pas automatiquement son include SPF. Les include créent des dépendances opérationnelles : une modification de l’enregistrement du fournisseur peut changer l’autorisation, ajouter des requêtes DNS imbriquées ou produire des erreurs temporaires et définitives. Consignez le fournisseur, le service, le domaine include exact, la source contractuelle, le responsable et le plan de retrait. Testez la politique obtenue depuis l’IP d’envoi réelle du fournisseur et votre domaine d’enveloppe. N’aplatissez jamais les include des fournisseurs en listes d’IP copiées, sauf si vous acceptez aussi la responsabilité de suivre chaque changement d’adresse du fournisseur et de préserver la sémantique d’origine.

All, redirect et l’explication jouent des rôles différents

Le mécanisme all correspond toujours et se place normalement en dernier ; les termes qui le suivent ne peuvent pas influer sur l’évaluation. Son qualificateur détermine le résultat pour les sources qui n’ont pas correspondu plus tôt. Le modificateur redirect indique à SPF d’utiliser la politique d’un autre domaine lorsqu’aucun mécanisme de l’enregistrement courant n’a correspondu. Redirect n’est pas l’équivalent de include : include est un mécanisme parmi d’autres dans l’ordre, tandis que redirect remplace la décision finale de la politique dans les conditions définies. Un enregistrement ne doit pas contenir plusieurs modificateurs redirect. Le modificateur exp peut référencer une explication pour un résultat fail, mais il n’autorise aucun e-mail et soulève des questions opérationnelles et de confidentialité supplémentaires. Gardez des explications génériques et évitez toute donnée sur l’expéditeur ou le destinataire. Choisissez redirect lorsque des domaines partagent délibérément une politique entière et ont des responsables coordonnés. Choisissez include pour ajouter les sources autorisées d’un fournisseur au sein d’une politique locale plus large. Testez les chemins sans correspondance, pas seulement les pass attendus.

Éviter ptr et réserver exists et les macros aux usages avancés

La RFC 7208 indique que le mécanisme ptr ne doit pas être utilisé, car il est lent, peu fiable et lourd pour les serveurs de noms. N’ajoutez pas ptr pour faire passer une IP inconnue. Le mécanisme exists peut effectuer un test d’existence DNS à l’aide d’un domain-spec, et les macros SPF peuvent développer des éléments de l’identité et de la connexion dans les champs qui les acceptent. Ces outils permettent d’exprimer une autorisation déléguée ou par client, mais augmentent la complexité, le travail DNS, l’exposition des données et les modes de défaillance. La syntaxe des macros n’est pas un système de gabarits libre : seules les lettres, transformateurs, délimiteurs et contextes définis sont valides. Ne placez jamais d’adresses de destinataires complètes, de secrets ou de données non bornées fournies par les tenants dans des requêtes DNS. Si un simple ensemble de plages d’IP détenues et d’include de fournisseurs documentés suffit à exprimer la politique, préférez-le. Pour les politiques avancées, construisez avant la production des jeux de test déterministes couvrant plusieurs domaines, expéditeurs, familles d’IP, chemins de retour nuls, l’échappement des macros, NXDOMAIN, les timeouts et les réponses DNS inattendues.

Respecter la limite de dix termes générant des requêtes DNS

La RFC 7208 limite les implémentations SPF à dix termes provoquant des requêtes DNS lors d’une même vérification, y compris le traitement de include, a, mx, ptr, exists et redirect. Les include imbriqués comptent. La spécification recommande aussi de limiter à deux les requêtes vides (void lookups), pour lesquelles le DNS renvoie une réponse vide ou une erreur de nom. Dépasser les limites de traitement peut produire une erreur permanente au lieu d’un pass. Comptez le graphe d’évaluation développé, pas seulement les termes visibles dans la chaîne TXT de premier niveau. Un seul include de fournisseur peut entraîner plusieurs dépendances imbriquées, et un mécanisme mx peut déclencher des requêtes d’adresse pour plusieurs hôtes. Utilisez un évaluateur conforme aux normes avec des instantanés DNS, mais inspectez aussi vous-même l’arbre de dépendances. Supprimez les fournisseurs inutilisés et les mécanismes redondants. Évitez l’aplatissement risqué qui perd silencieusement les mises à jour des fournisseurs. Surveillez les changements de politique et gardez de la marge pour l’évolution des fournisseurs plutôt que de déployer exactement au maximum.

Publier exactement une politique SPF par domaine

La RFC 7208 utilise des enregistrements DNS TXT pour SPF et exige de sélectionner l’enregistrement commençant par v=spf1. Plusieurs enregistrements SPF pour le même nom exact provoquent une erreur permanente au lieu de cumuler les autorisations. Modifiez la politique existante avec une coordination entre responsables ; n’ajoutez pas de second enregistrement TXT parce qu’une autre application a besoin d’un accès. D’autres enregistrements TXT sans rapport peuvent coexister sous ce nom, mais une seule politique SPF sélectionnée doit exister. Vérifiez comment votre outil de gestion DNS gère les guillemets et le découpage des chaînes, interrogez les serveurs faisant autorité, puis des résolveurs récursifs indépendants. Conservez la valeur et le TTL précédents pour le retour arrière. La propagation DNS n’est pas instantanée, et les caches négatifs peuvent persister. Une coche verte dans un tableau de bord ne prouve que la requête observée et le comportement de son analyseur. Vérifiez le domaine d’enveloppe exact de production à partir des en-têtes bruts reçus et des logs du fournisseur, y compris les sous-domaines et les adresses de bounce qui peuvent publier des politiques distinctes.

Relier la syntaxe SPF à DMARC sans les confondre

SPF évalue normalement le domaine MAIL FROM ou l’identité HELO selon les règles du protocole. DMARC utilise le domaine From RFC 5322 visible et n’accepte SPF comme chemin de réussite que lorsque le domaine authentifié par SPF est aligné sur ce domaine visible. Le return path d’un fournisseur peut donc réussir SPF tout en restant non aligné pour DMARC. À l’inverse, un pass DKIM aligné peut satisfaire DMARC lorsque SPF échoue ou n’est pas aligné. Consignez séparément le résultat SPF, le domaine évalué, l’IP de connexion, le From visible, les résultats DKIM, l’alignement et le résultat DMARC. Le transfert modifie souvent l’IP de connexion et peut casser SPF même lorsque l’expéditeur d’origine était autorisé. N’élargissez pas SPF pour inclure des services de transfert arbitraires. Utilisez DKIM et, le cas échéant, des mécanismes de chaîne authentifiée et les preuves des destinataires. Un pass SPF ne prouve ni l’intégrité du message, ni la sûreté du contenu, ni le consentement du destinataire, ni l’acceptation par le serveur, ni l’arrivée en boîte de réception.

Valider les changements avec un workflow déterministe

Avant de modifier le DNS, exportez l’enregistrement actuel et listez chaque mécanisme ou modificateur avec son responsable et sa finalité. Analysez l’enregistrement candidat selon la grammaire de la RFC 7208, développez les dépendances DNS à partir d’instantanés contrôlés, comptez les termes générant des requêtes et testez des jeux d’adresses IPv4 et IPv6 autorisées et non autorisées. Vérifiez le comportement des include imbriqués en cas de pass, fail, neutral, softfail, erreur temporaire et erreur permanente. Testez la gestion du chemin de retour nul via HELO, les sous-domaines, les return paths des fournisseurs et une source qui doit aboutir à all. Publiez via les contrôles de changement habituels, interrogez le DNS faisant autorité et récursif, puis envoyez des messages contrôlés par chaque flux réel. Conservez les en-têtes Authentication-Results bruts de destinataires de confiance et comparez-les aux identités attendues. Revenez en arrière en cas de sources de production manquantes, de sélection de plusieurs enregistrements, d’erreurs de limite de requêtes, de temperror généralisé ou d’autorisation non voulue. Ne testez jamais en envoyant des e-mails non sollicités.

Configurez SPF avec SendHQ

SendHQ provisionne une politique SPF TXT dans le cadre de la configuration de l’identité d’expéditeur. Il arrête la configuration en cas de politiques SPF conflictuelles et indique une valeur SPF fusionnée recommandée plutôt que d’écraser silencieusement une politique sans rapport. Conservez exactement une politique SPF sélectionnable ; consultez la documentation Domains and DNS pour les détails de configuration et de correction.

Questions fréquentes

Sources

• RFC 7208 : Sender Policy Framework — RFC Editor
• RFC 7489 : Domain-based Message Authentication, Reporting, and Conformance — RFC Editor
• RFC 5321 : Simple Mail Transfer Protocol — RFC Editor