Comment créer un enregistrement SPF sécurisé

Un enregistrement SPF (Sender Policy Framework) sécurisé répertorie tous les serveurs autorisés à envoyer des e-mails pour votre domaine, reste sous la limite des 10 requêtes DNS et se termine par -all, afin que les expéditeurs non autorisés soient rejetés plutôt que simplement signalés. Si l'un de ces points est mal configuré, les serveurs de réception rejettent vos e-mails légitimes ou laissent passer silencieusement des e-mails usurpés.

SPF est défini par la RFC 7208 (qui rend obsolète l'ancienne RFC 4408) et se publie sous la forme d'un simple enregistrement TXT DNS : il n'existe plus de type d'enregistrement SPF dédié réellement utilisé. Ce guide vous montre comment en construire un qui soit à la fois correct et difficile à casser.

Qu'est-ce qu'un enregistrement SPF, exactement ?

Un enregistrement SPF est un enregistrement TXT de votre domaine qui indique aux serveurs de réception quelles adresses IP et quels hôtes sont autorisés à envoyer des e-mails en utilisant votre domaine dans l'adresse d'expédition de l'enveloppe (Return-Path). Lorsque quelqu'un vous envoie un e-mail en prétendant être you@yourdomain.com, le serveur de réception consulte l'enregistrement SPF de votre domaine pour vérifier si l'IP d'envoi figure sur la liste autorisée.

Un enregistrement simple ressemble à ceci :

v=spf1 ip4:203.0.113.10 include:_spf.google.com -all

Chaque élément est un mécanisme, évalué de gauche à droite :

Vous pouvez vérifier ce qu'un domaine publie actuellement avec notre outil de recherche DNS gratuit, et créer de zéro un enregistrement syntaxiquement valide avec le générateur SPF.

Quels mécanismes et qualificateurs SPF utiliser ?

Les mécanismes SPF décrivent ce qu'il faut vérifier ; les qualificateurs décrivent ce qu'il faut faire lorsqu'une vérification correspond.

Mécanismes :

• ip4 / ip6 : correspondent à une adresse précise ou à un bloc CIDR, sans coût en requêtes
• a : correspond à l'enregistrement A/AAAA du domaine lui-même
• mx : correspond aux hôtes listés dans les enregistrements MX du domaine
• include : intègre la politique SPF d'un autre domaine (courant pour Google Workspace, Microsoft 365 et les ESP)
• exists : correspond si une requête DNS renvoie un enregistrement A quelconque
• ptr : correspond sur la base de requêtes DNS inverses

Qualificateurs, placés devant un mécanisme :

• + Pass (par défaut, rarement écrit explicitement)
• - Fail (échec strict : rejet)
• ~ SoftFail (accepté mais marqué, souvent classé en spam)
• ? Neutral (aucun avis réel : à éviter)

WarningÉvitez complètement ptr. La RFC 7208 le désigne explicitement comme non recommandé, car les requêtes DNS inverses sont lentes, peu fiables et coûteuses au regard de la limite de requêtes.

Pour le mécanisme final, utilisez -all dès que vous êtes certain que toutes les sources légitimes sont répertoriées. ~all est une étape intermédiaire raisonnable tant que vous identifiez encore vos expéditeurs, mais le conserver comme politique permanente affaiblit tout l'intérêt de SPF ; quant à un +all égaré, il autorise littéralement n'importe qui à usurper votre domaine. Considérez +all comme une erreur de configuration critique, et non comme un réglage permissif.

La limite des 10 requêtes DNS : le piège qui casse la plupart des enregistrements SPF

C'est sur ce point que la plupart des équipes se trompent. La RFC 7208 §4.6.4 plafonne l'évaluation SPF à 10 requêtes DNS par vérification. Chaque include, a, mx, ptr, exists et redirect est comptabilisé dans cette limite ; ip4 et ip6 ne le sont pas, puisqu'ils ne nécessitent aucune requête.

Au-delà de 10, le résultat est une PermError, que les serveurs de réception traitent comme une vérification défaillante ou échouée, et non comme un succès. C'est une panne très courante : un domaine ajoute Google Workspace, puis Microsoft 365 pour une boîte partagée, puis une plateforme marketing, un CRM et un outil de support, chacun apportant sa propre chaîne imbriquée de include:, et personne ne remarque que le nombre total de requêtes dépasse 10 jusqu'à ce que la délivrabilité baisse discrètement.

Deux facteurs aggravent la situation :

• mx est un multiplicateur caché. Utiliser mx dans votre enregistrement SPF coûte une requête pour l'interrogation MX elle-même, plus une requête supplémentaire pour chaque hôte MX renvoyé.
• Les requêtes vides sont limitées à 2. Une requête vide (void lookup) est un mécanisme qui ne renvoie rien : un include: pointant vers un hôte sans enregistrement SPF, ou un a/mx pour un nom qui n'existe plus. Au-delà de deux, une PermError est également renvoyée ; un seul expéditeur désaffecté que vous avez oublié de retirer peut donc casser silencieusement tout l'enregistrement.

Rester sous les dix requêtes, avec un enregistrement épuré

Vous ne disposez pas de plus de 10 requêtes : l'enregistrement doit donc être entretenu, et pas simplement complété au fil de l'eau :

• Auditez vos chaînes include:. Chaque fournisseur ajouté imbrique ses propres requêtes. Répertoriez chaque expéditeur qui envoie réellement des e-mails en votre nom et supprimez les autres : l'ancien CRM, l'outil marketing testé à l'essai, la plateforme de newsletter abandonnée l'an dernier.
• Préférez ip4:/ip6: à mx et a. Les mécanismes à IP statique ne coûtent aucune requête. Lorsqu'un expéditeur publie des IP stables, listez-les directement au lieu de vous appuyer sur mx, qui se multiplie avec chaque hôte MX renvoyé.
• Aplatissez avec prudence. L'« aplatissement SPF » (SPF flattening) résout vos includes en adresses IP brutes pour rester sous la limite, mais ces IP appartiennent à vos fournisseurs et changent sans préavis : un enregistrement aplati doit donc être surveillé, sinon il se met silencieusement à rejeter des e-mails légitimes.

Terminer par un échec strict, une fois sûr de vous

Le dernier mécanisme définit la politique pour tout ce qui n'est pas explicitement autorisé :

• ~all (softfail) indique aux destinataires « probablement pas nous, mais acceptez-le » : c'est le choix par défaut prudent tant que vous identifiez encore vos expéditeurs.
• -all (hardfail) leur indique « si ce n'est pas sur cette liste, rejetez-le ». C'est l'état final sécurisé, mais ne basculez dessus qu'une fois certain que l'enregistrement est complet, sinon vos propres e-mails seront rejetés.

Et SPF n'est qu'un pilier parmi d'autres : publiez DKIM pour que vos e-mails soient signés cryptographiquement, ainsi qu'une politique DMARC pour que les destinataires sachent quoi faire en cas d'échec d'une vérification, et pour recevoir des rapports lorsque quelqu'un usurpe votre domaine.

Ne pas le configurer puis l'oublier

Un enregistrement SPF sécurisé n'est pas une tâche ponctuelle. Les expéditeurs vont et viennent, les fournisseurs changent leurs IP et le nombre de requêtes augmente de lui-même ; rien de tout cela ne se signale, et vous ne le découvrez que lorsque la délivrabilité chute. Le DNS Security Advisor d'InfraNest surveille SPF, DKIM et DMARC sur tous les domaines que vous gérez, compte vos requêtes en temps réel et vous avertit avant que vous ne dépassiez dix requêtes ou qu'une requête vide ne casse l'enregistrement, pour que « sécurisé » le reste.