Aller au contenu
DomainVigil
S'inscrire

Outil gratuit

Générateur d'enregistrement SPF

Cochez qui envoie des e-mails en votre nom, l'enregistrement s'écrit à droite. Le compteur de requêtes DNS suit la limite de dix fixée par la RFC 7208 : c'est elle qui casse les SPF des vraies entreprises, bien avant la syntaxe.

Qui envoie vos e-mails ?

Chaque valeur ci-dessous a été relevée dans le DNS du fournisseur. Cochez votre messagerie, puis les outils qui envoient en votre nom : facturation, infolettre, formulaire de contact.

Vos propres serveurs

Deux raccourcis qui évitent d'écrire des adresses à la main. Chacun coûte une requête DNS.

Que faire des messages venus d'ailleurs ?

Le dernier terme de l'enregistrement. C'est lui qui décide du sort d'un message envoyé depuis une adresse que vous n'avez pas listée.

Votre enregistrement

v=spf1 -all

0 requêtes DNS sur 1011 caractères
  • Cet enregistrement n'autorise personne. Publié tel quel sur un domaine qui envoie des e-mails, il les fait tous échouer. Cochez au moins votre messagerie — sauf si le domaine n'envoie rien du tout, cas dans lequel « v=spf1 -all » est la bonne réponse.

Où le poser

Type
TXT
Nom
@
Valeur
v=spf1 -all
Durée de vie
3600

Le SPF se pose à la racine du domaine, dans un enregistrement TXT. Il REMPLACE celui qui existe déjà : deux enregistrements SPF sur un même nom font échouer la vérification au lieu de s'additionner (RFC 7208 § 3.2). Si vous en avez déjà un, fusionnez les deux en un seul avant de publier.

Le mécanisme

Un include n'est pas une ligne, c'est une porte

Le compteur du générateur voit ce que vous écrivez. Le serveur qui reçoit votre message, lui, ouvre chaque include, puis les include qu'il trouve derrière, et recommence. Dépliez l'arbre : vous faites exactement son travail, et c'est ce total-là qui est comparé à la limite.

Ce que vous avez écrit

5

consultations DNS

Ce que le serveur doit résoudre

5

consultations DNS — limite : 10

v=spf1

  • include:_spf.example.comvotre messagerie
  • include:_spf.example.netvotre outil d'infolettre
  • include:_spf.example.orgvotre logiciel de facturation
  • mxles serveurs listés dans vos MX
  • al'adresse de votre domaine

-all

5 consultations sur dix. Il reste de la marge — tant qu'aucun de vos fournisseurs n'ajoute un include de son côté, ce qu'il fera sans vous prévenir.

La limite de dix termes consommant une requête DNS — include, a, mx, ptr, exists, redirect — est fixée par la RFC 7208, § 4.6.4 ; au-delà, le vérificateur doit rendre permerror. Les mécanismes ip4, ip6 et all ne coûtent aucune consultation. Les noms ci-dessus sont des exemples (RFC 2606) : la structure interne d'un fournisseur change sans préavis.

Un SPF juste ne suffit pas à protéger votre nom

SPF dit qui peut envoyer. Il ne dit pas au destinataire quoi faire quand la vérification échoue, et il ne survit pas à une redirection de message. C'est DMARC qui donne la consigne, et DKIM qui signe. Les trois vont ensemble, et le jour où un prestataire remplace votre enregistrement par le sien, aucun des trois ne vous prévient.

Ce qui se casse sans que personne regarde

Un SPF se publie une fois et on l'oublie. Puis un outil d'infolettre est ajouté sans passer par la zone, un hébergeur change ses plages d'adresses, un prestataire écrase l'enregistrement en installant son formulaire. Les messages partent toujours, ils arrivent simplement en indésirable — et ça ne se voit pas de l'intérieur. DomainVigil relit votre SPF, votre DMARC et vos clés DKIM en continu, et vous écrit quand l'un des trois bouge.

La limite

Dix requêtes. La onzième annule tout.

La RFC 7208 fixe dix requêtes DNS pour toute la vérification d'un SPF. Au-delà, le vérificateur rend une erreur permanente : ni succès, ni échec, et plus rien à opposer à une usurpation.

  • 10requêtes DNS pour toute la vérification
  • 0requête coûtée par ip4, ip6 et all
  • 2requêtes sans réponse suffisent à tout casser

Lire le résultat

Trois indicateurs à surveiller pendant que vous cochez.

Le compteur de requêtes, en vert
Six requêtes ou moins : vous avez de la marge, même si vos include en cachent d'autres. C'est la zone confortable.
Le compteur, en orange
Sept requêtes ou plus au premier niveau. Le compte réel est presque toujours supérieur, parce qu'un include évalue le SPF entier du fournisseur, include imbriqués compris. C'est le moment de remplacer un include par les plages d'adresses qu'il publie.
Le compteur, en rouge
Plus de dix requêtes. La vérification s'arrête sur une erreur permanente, et le résultat n'est ni un succès ni un échec : c'est comme si vous n'aviez pas de SPF, sauf que les rapports DMARC se remplissent d'erreurs.
La longueur
Sous 255 caractères, l'enregistrement tient dans une seule chaîne de TXT et passe partout. Au-dessus, il faut que votre hébergeur sache le découper — la plupart le font.
« Cet enregistrement n'autorise personne »
Vous avez choisi un verdict sans lister d'expéditeur. C'est la bonne réponse pour un domaine qui n'envoie rien, et une panne totale de messagerie pour tous les autres.
Le récapitulatif « où le poser »
Type TXT, nom à la racine, valeur telle quelle. Le point qui fait échouer la manœuvre est écrit dessous : un SPF remplace le précédent, il ne s'y ajoute pas.

Les erreurs qui font échouer un SPF

Toutes les cinq se voient dans les enregistrements réels, et aucune ne provoque d'erreur visible à la publication.

  1. Deux enregistrements SPF sur le même domaine

    Ce qui la provoque : Un prestataire a ajouté le sien à côté de celui qui existait, au lieu de fusionner. Les deux sont syntaxiquement corrects, et l'interface de la zone les accepte tous les deux.

    Le geste qui corrige : La RFC 7208 § 3.2 est explicite : plusieurs enregistrements donnent une erreur permanente, pas une union. Fusionnez les termes des deux dans un seul enregistrement et supprimez l'autre.

  2. La limite de dix requêtes DNS est dépassée sans qu'on le sache

    Ce qui la provoque : Chaque include évalue le SPF complet du fournisseur, y compris les include qu'il contient. Quatre include au premier niveau peuvent en coûter douze.

    Le geste qui corrige : Comptez le total réel, pas le nombre de lignes. Remplacez les include des services dont les plages d'adresses sont stables par des mécanismes ip4, qui ne coûtent rien.

  3. Le mécanisme « ptr » est encore là

    Ce qui la provoque : Il vient de vieux tutoriels. Il demande au récepteur de résoudre le nom inverse de l'adresse émettrice, opération lente et facile à tromper.

    Le geste qui corrige : La RFC 7208 § 5.5 écrit que ce mécanisme NE DEVRAIT PAS être publié. Retirez-le et remplacez-le par les adresses concernées.

  4. Le domaine qui n'envoie rien n'a pas de SPF

    Ce qui la provoque : On ne publie un SPF que sur les domaines qui envoient, ce qui laisse les autres — domaines de redirection, noms défensifs, anciennes marques — libres d'être usurpés.

    Le geste qui corrige : Publiez « v=spf1 -all » sur chacun, avec un DMARC en « p=reject ». Personne n'a le droit d'envoyer en leur nom, et c'est exactement ce que vous voulez dire.

  5. Le SPF est juste, et les messages arrivent quand même en indésirable

    Ce qui la provoque : SPF ne survit pas à une redirection : un message transféré arrive depuis le serveur qui l'a transféré, adresse que vous n'avez pas listée. Sans DKIM, il n'y a plus rien qui atteste l'origine.

    Le geste qui corrige : Signez vos messages avec DKIM et publiez un DMARC. DMARC accepte un message dont SPF OU DKIM passe : la signature survit au transfert, l'adresse non.

Les mécanismes SPF et ce que chacun coûte

La limite est de dix requêtes DNS pour toute la vérification (RFC 7208 § 4.6.4). Cette colonne est la seule qui compte quand un SPF cesse de fonctionner.

TermeCe qu'il autoriseRequêtes DNS
ip4:Une adresse IPv4 ou une plage, écrite avec sa longueur de préfixe.0
ip6:Une adresse IPv6 ou une plage.0
aL'adresse du domaine courant. « a:autre.example » vise un autre domaine.1
mxLes adresses des serveurs listés dans les MX du domaine. Pratique, et rarement juste : vos serveurs entrants ne sont pas forcément vos serveurs sortants.1, plus la résolution de chaque MX
include:Le SPF d'un autre domaine, évalué en entier. C'est ce que vous donne votre fournisseur.1 par include, plus le coût du SPF inclus
exists:Vrai si le nom construit à partir de l'adresse émettrice résout. Sert aux fournisseurs qui ont trop d'adresses pour les lister.1
ptrLe nom inverse de l'adresse émettrice. La RFC 7208 § 5.5 demande de ne pas le publier.1
redirect=Remplace entièrement cet enregistrement par celui d'un autre domaine. Un modificateur, pas un mécanisme : il ne sert qu'à centraliser un SPF pour plusieurs domaines.1
exp=Le nom qui porte le message d'explication renvoyé lors d'un refus.0, évalué seulement en cas d'échec

Deux limites de plus, rarement citées et tout aussi bloquantes : un mécanisme « mx » ne peut pas résoudre plus de dix serveurs, et deux requêtes qui ne rendent rien (« void lookups ») suffisent à provoquer une erreur permanente.

Les quatre qualificateurs

Un qualificateur se place devant n'importe quel mécanisme. Devant « all », il décide du sort de tout ce que vous n'avez pas listé.

QualificateurRésultatCe que le destinataire en fait
+PassAutorisé. C'est la valeur par défaut : un mécanisme sans qualificateur vaut « + ».
-FailRefusé. Le message est rejeté ou supprimé. La seule position qui protège un nom de l'usurpation.
~SoftFailAccepté, mais marqué. Le message arrive, souvent en indésirable, et l'échec apparaît dans les rapports DMARC. Le réglage de transition.
?NeutralAucune consigne. Traité comme s'il n'y avait pas de SPF.

Trois autres résultats ne s'écrivent pas dans l'enregistrement mais apparaissent dans les rapports : « None » quand aucun SPF n'existe, « TempError » quand une requête DNS a échoué temporairement, « PermError » quand l'enregistrement est cassé — deux SPF publiés, ou plus de dix requêtes.

Questions fréquentes

Comment créer un enregistrement SPF ?

Cochez ci-dessus qui envoie en votre nom, copiez la valeur produite, et publiez-la dans votre zone DNS en TXT, à la racine du domaine. Un seul SPF par domaine : s'il en existe déjà un, fusionnez-le avec le nouveau au lieu d'en ajouter un second. Comptez une heure avant que la nouvelle valeur soit visible partout.

Faut-il choisir « -all » ou « ~all » ?

« -all » si votre liste est complète, et c'est l'objectif. « ~all » le temps de vérifier qu'aucun expéditeur légitime n'a été oublié : vous verrez les échecs dans les rapports DMARC sans casser d'envoi. Le piège est de rester en « ~all » pour toujours, ce qui laisse votre nom usurpable.

Combien d'include peut-on mettre dans un SPF ?

Autant que vous voulez, tant que le total des requêtes DNS reste sous dix. Un include coûte au minimum une requête, et souvent davantage parce qu'il en contient lui-même. En pratique, quatre ou cinq include sont un plafond raisonnable. Au-delà, remplacez ceux dont les plages d'adresses sont stables par des mécanismes ip4.

Que se passe-t-il si le SPF dépasse dix requêtes DNS ?

La vérification s'arrête sur une erreur permanente, le résultat est « PermError ». Ce n'est ni un succès ni un échec : la plupart des destinataires traitent le message comme s'il n'y avait pas de SPF, et votre DMARC ne s'appuie plus que sur DKIM. La protection disparaît sans qu'aucun message ne soit rejeté, donc sans que personne le remarque.

Faut-il un SPF sur un domaine qui n'envoie pas d'e-mails ?

Oui, et c'est le plus vite fait : « v=spf1 -all ». Sans lui, n'importe qui peut écrire au nom de votre domaine de redirection ou de votre ancienne marque. Ajoutez un DMARC en « p=reject » sur le même domaine pour que la consigne soit complète.

Le SPF remplace-t-il DKIM et DMARC ?

Non, les trois font trois choses différentes. SPF autorise des adresses IP. DKIM signe le message, et la signature survit à une redirection. DMARC dit au destinataire quoi faire quand les deux échouent, et vous fait envoyer des rapports. Un SPF seul, sans DMARC, ne produit aucune consigne exploitable.

La question fermée

Peut-on publier deux enregistrements SPF sur un même domaine ?

Non.

La RFC 7208 § 3.2 ne laisse aucune marge : quand plusieurs enregistrements SPF répondent sur le même nom, la vérification rend une erreur permanente. Les deux ne s'additionnent pas, ils s'annulent. Votre interface DNS les acceptera pourtant tous les deux sans rien dire, et vos messages continueront de partir — c'est ce qui rend l'erreur si durable.

Ce qu'on fait à la place

Fusionner les termes

Un seul enregistrement reprend les mécanismes des deux : les include de l'un suivent ceux de l'autre, les plages d'adresses se rassemblent, et un seul qualificateur final tranche.

Recompter les requêtes

Fusionner additionne aussi les coûts. Si chacun des deux coûtait six requêtes DNS, le résultat en coûte douze, et la limite de dix est franchie.

Supprimer l'ancien

Le nouvel enregistrement publié, l'ancien reste une erreur permanente tant qu'il figure dans la zone. Vérifiez qu'il n'en reste qu'un avant de passer à autre chose.

Le compteur

Faire redescendre le compte

Trois gestes qui retirent des requêtes DNS, et un quatrième qui vérifie que le compte affiché dit vrai.

  1. Remplacer un include par les adresses qu'il publie

    Les mécanismes ip4 et ip6 ne coûtent aucune requête ; un include en coûte une, plus le coût du SPF inclus. Le geste vaut pour les services dont les plages sont stables et documentées, pas pour un fournisseur qui change les siennes sans prévenir.

  2. Retirer le mécanisme ptr

    La RFC 7208 § 5.5 écrit qu'il ne devrait pas être publié. Il coûte une requête, il est lent, et il se laisse tromper. Remplacez-le par les adresses qu'il servait à autoriser.

  3. Se passer de mx quand les serveurs sortants sont connus

    Le mécanisme mx coûte une requête, plus la résolution de chaque serveur listé. Il autorise en plus vos serveurs entrants, qui ne sont pas forcément ceux qui émettent.

  4. Vérifier le total réel avant de publier

    Le compteur du générateur ne voit que le premier niveau. Un include vers un fournisseur qui en contient trois en coûte quatre. L'outil d'authentification des e-mails interroge le DNS et rend le total complet.

Vingt contrôles, sans inscription