Aller au contenu
DomainVigil
S'inscrire

Guide de référence

Qu'est-ce qu'un enregistrement SPF ?

SPF est la liste publique des serveurs autorisés à envoyer du courrier au nom de votre domaine. Elle tient dans un seul enregistrement TXT, elle se lit de gauche à droite, et elle casse toujours pour les mêmes raisons.

8 min de lectureMis à jour le 12 septembre 2026

En bref

Un enregistrement SPF est un enregistrement DNS de type TXT, publié à la racine de votre domaine, qui énumère les serveurs autorisés à envoyer du courrier en votre nom. Le serveur qui reçoit un message compare l'adresse IP de l'expéditeur à cette liste et en tire un verdict : autorisé, refusé ou sans avis.

À quoi sert SPF

Sans SPF, n'importe quelle machine sur Internet peut ouvrir une connexion et annoncer qu'elle écrit depuis votre domaine. Le protocole de courrier, tel qu'il a été conçu, ne demande aucune preuve. SPF ajoute cette preuve du côté du domaine : le propriétaire publie dans son DNS la liste des serveurs qu'il reconnaît, et le serveur qui reçoit peut la consulter avant d'accepter le message.

La vérification porte sur l'adresse d'enveloppe, celle que le serveur expéditeur annonce pendant la conversation SMTP. Ce n'est pas l'adresse que votre destinataire voit dans sa messagerie : les deux peuvent différer, et c'est précisément ce qu'exploitent les messages frauduleux. SPF seul ne protège donc pas l'adresse affichée ; c'est DMARC qui impose que les deux concordent.

L'enregistrement se publie en TXT, à la racine du domaine. Un type d'enregistrement dédié a existé, puis a été abandonné : aujourd'hui, un SPF publié ailleurs qu'en TXT n'est lu par personne.

Un enregistrement SPF, terme par terme

Voici un enregistrement complet, tel qu'il apparaît dans une zone DNS. Chaque terme se lit dans l'ordre, et le premier qui correspond à l'adresse IP de l'expéditeur décide du verdict.

example.com. 3600 IN TXT "v=spf1 include:_spf.example.net ip4:198.51.100.25 ip4:203.0.113.0/28 ~all"

  1. v=spf1La version

    Obligatoire, et toujours en premier. C'est ce qui distingue un SPF des autres enregistrements TXT du domaine, qui peuvent être nombreux.

  2. include:_spf.example.netReprendre la liste d'un prestataire

    Le serveur qui vérifie va lire l'enregistrement SPF de ce second domaine et l'évaluer à son tour. C'est ainsi qu'on autorise une plateforme d'envoi sans avoir à connaître ses adresses IP, qui changent.

  3. ip4:198.51.100.25Une adresse autorisée

    Une seule machine, désignée par son adresse IPv4. Aucune requête DNS supplémentaire : la réponse est déjà dans l'enregistrement.

  4. ip4:203.0.113.0/28Un bloc d'adresses autorisé

    La même chose pour une plage. Ici, les seize adresses de 203.0.113.0 à 203.0.113.15. La notation CIDR après la barre oblique indique la taille du bloc.

  5. ~allLe verdict par défaut, en dernier

    Tout ce qui n'a pas correspondu avant tombe ici. Le tilde demande un échec souple : le message est accepté mais signalé. Un tiret demanderait un rejet franc.

L'ordre compte : l'évaluation s'arrête au premier terme qui correspond. Un mécanisme placé après all ne sera jamais lu.

Les mécanismes SPF et ce qu'ils coûtent

Un enregistrement SPF est une suite de termes. Certains désignent directement des adresses, d'autres obligent le serveur qui vérifie à interroger le DNS — et ces requêtes sont comptées.

TermeCe qu'il désigneRequête DNS
v=spf1La version. Obligatoire, en tête de l'enregistrement.Non
ip4:Une adresse IPv4 ou un bloc CIDR autorisé.Non
ip6:Une adresse IPv6 ou un bloc CIDR autorisé.Non
aLes adresses A et AAAA du domaine, ou d'un domaine précisé après deux-points.Oui
mxLes adresses des serveurs de courrier entrant du domaine. Pratique quand la machine qui reçoit est aussi celle qui envoie.Oui
include:L'enregistrement SPF d'un autre domaine, évalué à son tour. Le terme des prestataires d'envoi.Oui
exists:Vrai si le nom construit répond en A. Sert aux règles conditionnelles avancées, rarement utile dans une agence.Oui
ptrL'inverse d'une adresse IP. Déconseillé par la norme elle-même : lent, peu fiable, à ne plus employer.Oui
redirect=Remplace entièrement l'enregistrement par celui d'un autre domaine. S'ignore si un all est présent.Oui
exp=Le texte d'explication renvoyé quand la vérification échoue. N'intervient qu'en cas d'échec.Non
allTout le reste. Toujours le dernier terme, précédé de son qualificateur.Non

Les quatre qualificateurs

Chaque mécanisme peut être précédé d'un signe qui dit quoi faire quand il correspond. Sans signe, c'est le plus permissif qui s'applique.

SigneRésultatCe que le destinataire en fait
+PassLe serveur est autorisé. C'est la valeur par défaut : un mécanisme sans signe vaut un plus.
-FailLe serveur n'est pas autorisé et le domaine l'assume. La plupart des destinataires rejettent le message.
~SoftFailLe serveur n'est pas autorisé, mais le domaine ne veut pas encore de rejet. Le message passe, généralement marqué.
?NeutralLe domaine ne se prononce pas. Équivaut, en pratique, à n'avoir rien publié du tout.

Terminer par ~all est le réglage de transition : on observe avant de fermer. Terminer par -all n'a de sens qu'une fois certain qu'aucun service légitime n'a été oublié.

Le budget de dix requêtes DNS

C'est la limite qui fait tomber la plupart des enregistrements SPF d'agence. Elle n'est pas indicative : au-delà, la vérification ne renvoie pas un échec, elle renvoie une erreur permanente, et le domaine se retrouve dans le même état que s'il n'avait rien publié.

Ce qui est comptéPlafondAu-delà
Mécanismes qui interrogent le DNS10Erreur permanente. L'évaluation s'arrête net et le résultat est inexploitable.
Noms rendus par un mécanisme mx10Erreur permanente, même si le budget global n'est pas atteint.
Noms rendus par un mécanisme ptr10Les noms suivants sont ignorés.
Réponses DNS vides2Erreur permanente. Un include qui pointe vers un domaine sans SPF compte double au classement des pièges.
Enregistrements v=spf1 sur un même nom1Erreur permanente. Deux enregistrements valent zéro enregistrement.
Longueur d'une chaîne TXT255L'enregistrement doit être découpé en plusieurs chaînes, recollées par le serveur qui lit.

Les termes ip4, ip6, all et exp ne consomment rien. Remplacer un include par les blocs d'adresses qu'il publie libère donc du budget — au prix d'une maintenance manuelle le jour où le prestataire change ses serveurs.

Vérifiez sur votre domaine, tout de suite

Entrez un nom de domaine : l'outil lit son enregistrement SPF, son DKIM et son DMARC, et vous dit ce que chacun autorise.

Sans inscription, sans e-mail à laisser. Vous pouvez coller une adresse complète : nous en extrayons le domaine.

Les quatre erreurs qu'on retrouve partout

  • Deux enregistrements SPF sur le même domaine

    Ce qui le provoque : On ajoute un prestataire en créant un second TXT qui commence par v=spf1, au lieu de modifier celui qui existe.

    Le geste qui corrige : Fusionner les deux en un seul enregistrement, en reprenant les include et les ip4 de chacun, et supprimer le doublon.

  • SPF passe, et le message part quand même en indésirable

    Ce qui le provoque : SPF valide l'adresse d'enveloppe, pas l'adresse affichée dans la messagerie. Les deux peuvent appartenir à des domaines différents sans que SPF s'en émeuve.

    Le geste qui corrige : Publier DMARC : c'est lui qui exige que l'adresse validée et l'adresse affichée relèvent du même domaine.

  • L'enregistrement dépasse dix requêtes

    Ce qui le provoque : Chaque outil branché sur le domaine apporte son include, et certains include en contiennent eux-mêmes plusieurs. Le compte monte sans qu'on le voie.

    Le geste qui corrige : Retirer les prestataires qui n'envoient plus rien, puis remplacer les include restants les plus stables par les blocs d'adresses qu'ils publient.

  • Le message réexpédié automatiquement échoue

    Ce qui le provoque : Une redirection de boîte conserve l'adresse affichée mais fait partir le message depuis un autre serveur, qui n'est évidemment pas dans la liste.

    Le geste qui corrige : Aucun réglage SPF ne couvre ce cas. C'est la signature DKIM qui survit au transfert, et c'est pour cela que les trois protocoles se posent ensemble.

Les questions qu'on se pose ensuite

SPF, DKIM, DMARC : dans quel ordre les installer ?

SPF d'abord, parce qu'il ne demande qu'un enregistrement TXT et qu'il n'a aucun effet de bord. DKIM ensuite, côté plateforme d'envoi. DMARC en dernier, en mode observation, une fois que les deux autres passent sur tous vos envois.

Un sous-domaine hérite-t-il du SPF du domaine ?

Non. La vérification se fait sur le nom exact annoncé par le serveur expéditeur. Un sous-domaine qui envoie du courrier doit publier son propre enregistrement, et un sous-domaine qui n'en envoie pas gagne à publier v=spf1 -all.

Faut-il terminer par -all ou par ~all ?

Commencez par ~all et lisez les rapports DMARC pendant quelques semaines. Passez à -all quand plus aucun envoi légitime n'apparaît en échec. L'ordre inverse coupe du courrier réel avant de vous en avertir.

Combien de temps un changement met-il à prendre effet ?

Le temps du TTL de l'enregistrement TXT, tel que vous l'avez publié. Les serveurs qui ont déjà lu l'ancienne valeur la garderont jusqu'à son expiration, pas une seconde de plus.

Un SPF juste aujourd'hui peut être faux dans six mois

Un prestataire ajouté, un include qui grossit, une migration de messagerie, et le budget de dix requêtes saute sans prévenir. DomainVigil relit l'enregistrement de chacun de vos domaines tous les jours et vous écrit quand il change ou quand il cesse d'être valide.

Commencer gratuitement

Cinq domaines gratuits, pour toujours. Sans carte bancaire.

Les autres guides de référence