Qu'est-ce que le SPF (Sender Policy Framework) ?

Définition

Sender Policy Framework est l'une des trois normes fondamentales d'authentification d'e-mails, aux côtés de DKIM et DMARC. Elle s'attaque à une faiblesse de base de l'e-mail : par défaut, n'importe qui peut envoyer un message prétendant provenir de n'importe quel domaine, parce que les protocoles de messagerie d'origine n'ont jamais intégré de moyen de prouver qui est le véritable expéditeur. SPF comble une partie de cette faille en donnant au propriétaire d'un domaine un moyen de déclarer, publiquement et sous une forme lisible par machine, exactement quels serveurs sont autorisés à envoyer des e-mails au nom du domaine.

Cette déclaration réside dans le Domain Name System, le même annuaire mondial qui traduit les noms de domaine en adresses réseau. Le propriétaire du domaine publie un enregistrement DNS spécial qui nomme les expéditeurs autorisés. Quand un message arrive, le serveur de messagerie destinataire consulte cet enregistrement et le compare au serveur qui a réellement livré le message. Si le serveur d'envoi figure sur la liste, le message passe SPF. Sinon, le message échoue à SPF, ce qui est un indice fort que l'e-mail pourrait être falsifié. SPF ne chiffre rien et ne contrôle pas le contenu du message. Il répond à une seule question ciblée : ce message a-t-il été envoyé depuis un serveur approuvé par le propriétaire du domaine ?

Comment ça fonctionne

Une politique SPF est publiée sous la forme d'un unique enregistrement DNS TXT sur le domaine. L'enregistrement commence toujours par la balise de version v=spf1, suivie d'une série de mécanismes qui décrivent les expéditeurs autorisés, et il se termine normalement par un mécanisme all qui définit le résultat par défaut. Un enregistrement simple pourrait se lire v=spf1 include:_spf.google.com -all, qui autorise les serveurs de messagerie Google Workspace et rejette tout le reste.

Les mécanismes sont les briques de base. Les mécanismes ip4 et ip6 autorisent directement des adresses précises ou des plages d'adresses. Le mécanisme a autorise les serveurs trouvés dans les enregistrements d'adresse du domaine, et mx autorise les serveurs listés comme serveurs de messagerie du domaine. Le mécanisme include est le plus courant en pratique, puisqu'il intègre la politique SPF d'un autre fournisseur, ce qui est la façon dont un domaine délègue l'envoi à des services comme Google, Microsoft ou une plateforme d'e-mailing. Chaque mécanisme peut porter un qualificateur qui fixe le résultat lorsqu'il correspond. Un signe plus, qui est la valeur par défaut, signifie pass. Un signe moins signifie fail, un tilde signifie softfail, soit un avertissement léger, et un point d'interrogation signifie neutre. Le mécanisme all à la fin attrape tout serveur qui n'a pas correspondu : -all est donc un rejet strict de tout ce qui n'est pas listé, tandis que ~all est un signal plus souple.

Lorsqu'un serveur destinataire évalue SPF, il vérifie l'adresse envelope-from, c'est-à-dire le return-path déclaré pendant l'échange SMTP, et pour les messages de rebond dont le return-path est vide, il vérifie plutôt l'identité HELO. La norme impose une contrainte importante : l'évaluation d'un enregistrement ne peut pas utiliser plus de dix recherches DNS, et des mécanismes comme include, a, mx et exists en consomment chacun une. Si un enregistrement en nécessite plus de dix, il produit une PermError, que les destinataires peuvent traiter comme un échec : les enregistrements SPF doivent donc rester compacts. SPF a aussi des limites structurelles. Il se brise quand un e-mail est transféré, car le serveur de transfert ne figure pas sur la liste du domaine d'origine, et surtout il ne valide que l'adresse envelope-from, pas l'adresse From visible que le destinataire voit réellement.

Pourquoi c'est important pour la délivrabilité des e-mails

SPF est désormais une exigence de base plutôt qu'une option facultative. Les fournisseurs de messagerie traitent un contrôle SPF réussi comme un signal de confiance positif et un enregistrement absent ou en échec comme un motif de suspicion, ce qui influe directement sur le fait que l'e-mail atteigne la boîte de réception ou le dossier spam. Depuis les exigences pour expéditeurs de 2024 introduites par Google et Yahoo, les expéditeurs en masse sont censés s'authentifier avec SPF, et un domaine sans enregistrement SPF valide peut voir ses e-mails ralentis ou rejetés purement et simplement.

SPF compte aussi parce qu'il est un prérequis pour DMARC, la couche de politique qui relie l'authentification à l'adresse From visible. DMARC fonctionne en vérifiant si SPF ou DKIM a réussi et si le résultat s'aligne avec le domaine From. Sans enregistrement SPF correctement configuré, un domaine ne peut pas atteindre l'alignement DMARC via SPF, ce qui affaiblit sa protection globale. En même temps, il importe d'être réaliste sur ce que SPF ne peut pas faire. Parce qu'il ignore l'en-tête From visible et se brise lors d'un transfert, SPF seul ne peut pas arrêter un usurpateur déterminé. C'est une couche nécessaire d'une défense à trois couches, et il ne délivre toute sa valeur que lorsque DKIM et DMARC sont en place à ses côtés.

Comment VeriMails gère cela

SPF et la vérification d'e-mails résolvent deux moitiés différentes du même problème de délivrabilité. SPF authentifie les e-mails que vous envoyez pour que les serveurs destinataires aient confiance qu'ils viennent bien de vous. La vérification d'e-mails nettoie la liste à laquelle vous écrivez, pour que vous n'adressiez jamais que des adresses réelles et joignables. Un bon placement en boîte de réception a besoin des deux ensemble, et aucun ne se substitue à l'autre.

VeriMails se concentre sur le côté destinataire. Chaque adresse que vous soumettez est contrôlée via la validation de la syntaxe, une recherche MX et DNS, une négociation SMTP en direct, la détection des domaines catch-all, des adresses jetables et des adresses génériques, de sorte que les adresses invalides sont retirées avant de pouvoir rebondir et faire chuter une réputation que de bons enregistrements SPF, DKIM et DMARC existent justement pour protéger. Pour aider aussi du côté de l'authentification, VeriMails propose un générateur SPF gratuit qui construit un enregistrement syntaxiquement correct pour votre domaine et vos services d'envoi, en le maintenant dans la limite des dix recherches. Vous pouvez vérifier une liste via l'API REST ou un import CSV en masse, avec des catégories de délivrabilité claires pour vos décisions de campagne. La vérification démarre à $0.0019 par e-mail, avec 10,000 crédits pour $19 et des formules annuelles à partir de $12.50/month en facturation annuelle, et chaque compte démarre avec 100 crédits gratuits, sans carte bancaire, qui n'expirent jamais.

Questions fréquentes