Définition
Un enregistrement SPF (Sender Policy Framework) est une ressource DNS TXT publiée dans la zone DNS publique d’un domaine qui énumère les adresses IP, préfixes IPv6 et noms de serveurs autorisés à envoyer des e-mails au nom de ce domaine. Quand un serveur de réception accepte un message entrant, il interroge le DNS de l’expéditeur pour récupérer l’enregistrement SPF et compare l’IP qui se connecte à la politique. Si l’IP n’est pas listée, le serveur peut marquer le message comme softfail, le rejeter d’emblée ou le signaler pour évaluation supplémentaire — selon le qualificateur de politique défini par le propriétaire.
SPF a été d’abord formalisé comme standard IETF dans la RFC 4408 (2006) puis mis à jour dans la spécification de référence actuelle, RFC 7208, publiée par l’IETF en avril 2014. C’est l’un des trois standards complémentaires d’authentification e-mail, aux côtés de DKIM (DomainKeys Identified Mail) et DMARC (Domain-based Message Authentication, Reporting, and Conformance).
Comment cela fonctionne
L’évaluation SPF implique plusieurs étapes séquentielles effectuées par le moteur SMTP du serveur de réception lors de la phase MAIL FROM du dialogue SMTP.
Le propriétaire du domaine publie un enregistrement SPF TXT dans le DNS. Un enregistrement typique suit la syntaxe : v=spf1 include:_spf.google.com ip4:203.0.113.5 ~all. Les composants sont : v=spf1 (identifiant de version), un ou plusieurs mécanismes (include, ip4, ip6, a, mx, exists), et un qualificateur final (+all, -all, ~all, ?all). Le qualificateur -all signifie un échec dur — tout serveur non explicitement listé n’est pas autorisé. Le qualificateur ~all (softfail) laisse passer le message tout en notant la divergence, couramment utilisé en période de migration.
Quand un message arrive, le MTA récepteur extrait le domaine de l’expéditeur d’enveloppe (l’adresse MAIL FROM, aussi appelée RFC5321.MailFrom) et effectue une recherche DNS TXT pour _spf.<domaine> ou directement sur la racine. La bibliothèque SPF évalue chaque mécanisme dans l’ordre jusqu’à ce qu’un corresponde ou que la limite de dix recherches DNS soit atteinte (limite « SPF PermError » définie en RFC 7208 §4.6.4). Le résultat — Pass, Fail, SoftFail, Neutral, TempError ou PermError — est inséré dans l’en-tête Received-SPF et transmis au filtre antispam et au moteur de politique DMARC.
Il est crucial de noter que SPF authentifie l’expéditeur d’enveloppe (MAIL FROM), pas l’en-tête From visible dans le corps du message. Cette distinction signifie que SPF seul ne prévient pas l’usurpation de nom d’affichage dans les clients e-mail, c’est pourquoi l’alignement DMARC — exigeant que les résultats SPF et/ou DKIM correspondent au domaine RFC5322.From — est nécessaire pour une protection complète.
Où vous le rencontrez
Les enregistrements SPF apparaissent partout où la délivrabilité et la réputation expéditeur comptent. Les infrastructures de messagerie transactionnelle exploitées par Amazon SES, SendGrid, Mailgun, Postmark et SparkPost exigent que vous ajoutiez un mécanisme include SPF pointant vers leur infrastructure d’envoi avant que les messages ne passent les contrôles d’authentification.
Les plateformes de concours qui envoient des votes par confirmation d’e-mail — y compris Woobox, ShortStack, et les systèmes sur mesure utilisant Mailchimp Transactional (Mandrill) — dépendent du fait que le domaine d’envoi possède un enregistrement SPF valide. Les fournisseurs de boîtes Google (Gmail), Microsoft (Outlook / Exchange Online Protection) et Yahoo Mail évaluent SPF comme entrée de leurs algorithmes de délivrabilité. Un SPF manquant ou mal configuré augmente substantiellement la probabilité que les e-mails de confirmation soient livrés silencieusement en spam ou rejetés totalement, faisant échouer la confirmation des votes.
Les panneaux DNS de Cloudflare, AWS Route 53, GoDaddy et Namecheap exposent l’édition d’enregistrements TXT SPF via leurs interfaces. Des outils de diagnostic comme MXToolbox SPF Lookup, Google Admin Toolbox et le SPF Surveyor de DMARCIAN permettent d’inspecter et valider les enregistrements publiés.
Exemples concrets
Une plateforme de concours envoie des e-mails de confirmation depuis [email protected]. Le domaine votes.example.com a l’enregistrement SPF v=spf1 include:sendgrid.net -all. Quand Gmail reçoit un message de confirmation, son serveur SMTP entrant interroge le DNS pour le SPF de votes.example.com, déploie le mécanisme include:sendgrid.net, et compare l’IP de connexion à la liste autorisée par SendGrid. Si l’IP correspond, le résultat SPF est Pass et le message progresse vers la boîte de réception. Sans enregistrement SPF, le filtre Gmail traiterait le message comme non authentifié, réduisant la probabilité d’aboutir en boîte de réception.
Le concours d’un journal régional change de fournisseur transactionnel — de Mailchimp à Amazon SES — sans mettre à jour son enregistrement SPF. Les e-mails de confirmation commencent à échouer aux contrôles SPF chez Microsoft Outlook et sont classés en masse en spam, faisant rater la fenêtre de confirmation aux votants. L’administrateur diagnostique avec MXToolbox, ajoute include:amazonses.com à l’enregistrement SPF, et la délivrabilité se rétablit dans la fenêtre de propagation DNS (typiquement 0–48 heures selon le TTL).
Concepts liés
SPF est un pilier du triptyque d’authentification e-mail : voir DKIM pour la vérification de signature cryptographique et DMARC pour la couche de politique qui agit sur les résultats SPF et DKIM. L’impact pratique sur les opérations de concours est décrit dans Vote par confirmation d’e-mail, où la délivrabilité du message de confirmation est la dépendance opérationnelle critique. BIMI (Brand Indicators for Message Identification), standard plus récent s’appuyant sur DMARC, permet aux expéditeurs vérifiés d’afficher un logo de marque chez les fournisseurs compatibles — signal de confiance émergent qui n’est pas couvert ici.
