Comment vérifier un enregistrement SPF pour les e-mails applicatifs ?

Partez de l’identité que SPF vérifie réellement

Une vérification SPF nécessite trois entrées : l’adresse IP du client SMTP, le domaine dont la politique d’autorisation est évaluée et l’identité de l’expéditeur. Pour un e-mail applicatif ordinaire, ce domaine est tiré de l’adresse SMTP MAIL FROM, aussi appelée expéditeur d’enveloppe ou return path. Il peut différer de l’adresse que les gens voient dans l’en-tête From du message. Si MAIL FROM est vide, comme c’est normalement le cas pour une notification d’état de livraison, SPF utilise l’identité HELO pour la vérification MAIL FROM. Relevez la vraie IP de connexion et l’identité d’enveloppe à partir d’un message de test reçu ou de la configuration du fournisseur d’envoi avant d’interroger le DNS. Vérifier example.test parce qu’il apparaît dans From n’est pas concluant si l’application envoie en réalité avec un MAIL FROM sur bounce.provider.test ou bounces.example.test.

Interrogez les TXT sur le domaine MAIL FROM exact

Interrogez les enregistrements DNS TXT sur le domaine exact identifié à la première étape. La RFC 7208 exige que les politiques SPF version 1 soient publiées sous forme d’enregistrements TXT au nom de propriétaire qu’elles régissent. Ignorez les valeurs TXT sans rapport et sélectionnez les enregistrements dont la section de version est exactement v=spf1. Si aucun enregistrement n’est sélectionné, le résultat SPF est none. Si plus d’un enregistrement SPF est sélectionné, le résultat est permerror ; publier des enregistrements distincts pour différents fournisseurs n’est pas une façon valide de les combiner. Un même enregistrement de ressource TXT peut être découpé en chaînes de caractères entre guillemets par l’outillage DNS, mais ces chaînes sont concaténées sans espace ajouté avant l’analyse SPF. Conservez la réponse complète, le résolveur, l’heure de la requête et le TTL pour pouvoir répéter la vérification après un changement.

Validez la syntaxe et évaluez les termes de gauche à droite

Un enregistrement SPF est une politique ordonnée, pas une liste non ordonnée de fournisseurs. Après v=spf1, les mécanismes sont évalués de gauche à droite jusqu’à ce que l’un d’eux corresponde. Un qualificateur en tête détermine le résultat : + signifie pass et c’est la valeur par défaut, - signifie fail, ~ signifie softfail et ? signifie neutral. Les mécanismes ip4 et ip6 comparent l’adresse du client à une adresse ou à un réseau. Les mécanismes a et mx effectuent une résolution DNS, tandis qu’include évalue la politique SPF d’un autre domaine et ne correspond que selon les règles d’include. exists effectue un test fondé sur le DNS. all correspond toujours et termine généralement l’enregistrement. Une erreur de syntaxe, où qu’elle se trouve, provoque un permerror avant l’évaluation normale. Un bon vérificateur doit indiquer quel mécanisme a correspondu, son qualificateur et chaque domaine développé, plutôt que de renvoyer seulement un badge coloré.

Suivez include et redirect sans les traiter comme des alias

Suivez chaque include et redirect dans le même contexte d’évaluation. Include est un mécanisme : il demande si la politique incluse renvoie pass pour le client et l’expéditeur courants, puis poursuit dans l’enregistrement d’origine s’il n’y a pas de correspondance. Redirect est un modificateur pris en compte après qu’aucun mécanisme de l’enregistrement courant n’a correspondu ; il transfère l’évaluation à une autre politique en conservant l’IP du client et l’expéditeur. Un redirect est ignoré si all apparaît n’importe où dans l’enregistrement. Ces différences comptent lors des migrations. Remplacer include:vendor.test par redirect=vendor.test peut remplacer toute la politique de repli du propriétaire du domaine au lieu de simplement ajouter un fournisseur. Détectez les cycles, les cibles manquantes, les cibles invalides et les erreurs permanentes ou transitoires imbriquées, et conservez la chaîne de dépendances dans le résultat pour qu’un changement de politique côté fournisseur soit visible.

Comptez l’intégralité du budget de requêtes DNS

Comptez les termes qui déclenchent des requêtes DNS sur l’ensemble de l’évaluation récursive, pas seulement dans l’enregistrement de premier niveau. La RFC 7208 limite à dix les termes include, a, mx, ptr, exists et redirect au cours d’une même évaluation SPF ; le dépassement de cette limite impose un permerror. Les mécanismes all, ip4 et ip6 ne consomment pas ce budget. Le traitement de MX et de PTR comporte des limites supplémentaires de requêtes d’adresses. La RFC recommande aussi de limiter à deux les requêtes vides (void lookups), c’est-à-dire les réponses vides réussies ou les erreurs de nom, et de produire un permerror au-delà. Le mécanisme ptr est déconseillé car il est lent et peu fiable. Un enregistrement peut sembler court alors que les include des fournisseurs se développent en suffisamment de termes imbriqués pour échouer : indiquez donc le total, chaque terme qui y contribue, les requêtes vides et la branche exacte empruntée pour l’IP testée.

Interprétez le résultat SPF sans l’exagérer

Utilisez le vocabulaire de résultats standard. Pass signifie que le client testé est autorisé à utiliser l’identité SMTP vérifiée. Fail signifie qu’une autorisation négative correspondante a été trouvée. Softfail est une affirmation négative faible, tandis que neutral indique que le domaine ne se prononce pas sur ce client. None signifie qu’aucun enregistrement SPF n’a été sélectionné. Temperror traduit un problème d’évaluation transitoire, souvent lié au DNS ; permerror traduit une politique qui ne peut pas être évaluée correctement. Si aucun mécanisme ne correspond et qu’aucun redirect ne s’applique, le résultat est neutral, ce qui équivaut à un ?all implicite. Rapportez le résultat avec l’identité, l’IP du client, le terme correspondant, la trace DNS et l’heure. Ne traduisez pas pass par message sûr, courrier souhaité, acceptation par le fournisseur, livraison dans la boîte aux lettres ou arrivée en boîte de réception, car SPF ne décide d’aucun de ces résultats.

Vérifiez un vrai message, pas seulement l’enregistrement publié

Une vérification statique de l’enregistrement indique si une politique peut être découverte et analysée. Elle ne prouve pas que l’application a utilisé le domaine MAIL FROM ou l’IP sortante attendus. Envoyez un message contrôlé par chaque chemin de production réel vers un compte destinataire que vous administrez, puis inspectez les en-têtes reçus. Comparez l’IP de connexion, l’expéditeur d’enveloppe et l’entrée Authentication-Results du destinataire avec l’évaluation DNS. Répétez l’opération pour chaque fournisseur, région, pool dédié ou partagé, chemin de repli et catégorie de message susceptible de modifier le return path. Conservez les en-têtes dans un stockage à accès restreint, car les adresses et les détails de routage peuvent être sensibles. Si le tableau de bord d’un fournisseur et le message reçu divergent, le message est la preuve la plus solide du chemin réellement emprunté, mais le résultat d’un seul destinataire ne doit toujours pas être généralisé à tous les comportements de livraison.

Évaluez l’alignement DMARC comme une étape distincte

SPF peut donner pass pour un domaine de return path appartenant au fournisseur alors que DMARC ne peut toujours pas utiliser ce résultat. Les règles DMARC actuelles comparent le domaine RFC5321.MailFrom authentifié avec succès par SPF au domaine de l’auteur dans le champ RFC5322.From visible. L’alignement strict exige le même domaine DNS. L’alignement relaxed accepte des domaines qui se ramènent au même domaine organisationnel selon les règles de découverte de DMARC. Par exemple, bounces.example.test et example.test peuvent être alignés en mode relaxed, alors que bounce.provider.test et example.test ne le sont pas. Un résultat DMARC peut aussi s’appuyer sur une signature DKIM alignée et vérifiée : un résultat SPF non aligné ne signifie donc pas à lui seul que DMARC échoue. Rapportez l’authentification et l’alignement séparément, et utilisez la procédure actuelle de découverte de domaine plutôt qu’une comparaison figée des deux derniers labels.

Testez la configuration MAIL FROM propre au fournisseur

La configuration du fournisseur détermine quelle identité SPF apparaît réellement dans l’échange. Amazon SES, par exemple, documente un domaine MAIL FROM personnalisé qui nécessite son propre enregistrement MX et son propre enregistrement TXT SPF. SES peut se rabattre sur un domaine MAIL FROM amazonses.com dépendant de la région lorsque le MX du domaine personnalisé est mal configuré, ou rejeter l’envoi, selon le comportement configuré. Ce repli peut modifier l’alignement DMARC même si l’adresse From visible ne change pas. Pour tout fournisseur, consignez le domaine de return path configuré, les valeurs DNS requises, le comportement de repli, les régions d’envoi et le propriétaire. Après un changement de DNS ou de fournisseur, attendez l’expiration des réponses en cache concernées, puis répétez l’évaluation DNS et les envois contrôlés. Ne copiez pas l’include d’un fournisseur dans le domaine From visible sauf s’il s’agit de l’identité réelle et que l’inventaire complet des expéditeurs du domaine le justifie.

Menez un audit SPF reproductible pendant les changements

Tenez une ligne par chemin d’envoi avec un propriétaire, l’application, la catégorie de message, le domaine From visible, le domaine MAIL FROM, le domaine HELO, les plages sources attendues, la dépendance fournisseur et la date du dernier test contrôlé. Enregistrez chaque vérification SPF avec l’enregistrement sélectionné, la trace récursive, le nombre de requêtes DNS, le mécanisme correspondant, le résultat, la décision d’alignement et un identifiant de test non sensible. Pendant une migration, n’autorisez les anciennes et nouvelles sources légitimes que pendant la fenêtre de transition nécessaire, vérifiez le nouveau chemin, puis retirez délibérément les autorisations obsolètes. Surveillez les erreurs d’authentification permanentes et transitoires plutôt que de réagir uniquement aux rejets. Relancez l’audit après un changement de fournisseur, un déplacement de pool d’IP, un changement de domaine, une modification DNS ou l’arrivée d’une nouvelle application. Ce workflow détecte à la fois les politiques trop étroites qui bloquent des chemins légitimes et les politiques trop larges qui conservent des autorisations inutilisées.

Vérifiez SendHQ avec le même niveau d’exigence en matière de preuves

SendHQ indique qu’un envoi direct doit utiliser une adresse appartenant à un domaine d’espace de travail vérifié. Cela vérifie l’identité de l’expéditeur, mais ne remplace pas une évaluation SPF. Un message SendHQ contrôlé exige toujours la même trace DNS, l’inspection des en-têtes reçus, le résultat SPF et la vérification de l’alignement DMARC décrits ci-dessus.

Questions fréquentes

Sources

• RFC 7208 : Sender Policy Framework — IETF
• RFC 5321 : Simple Mail Transfer Protocol — IETF
• RFC 9989 : Domain-Based Message Authentication, Reporting, and Conformance — RFC Editor
• Utiliser un domaine MAIL FROM personnalisé dans Amazon SES — Amazon Web Services
• Contrat OpenAPI de SendHQ — SendHQ