Comment créer un enregistrement SPF pour un domaine personnalisé ?

Que contient un enregistrement SPF ?

Un enregistrement SPF est un enregistrement TXT qui commence par v=spf1 et se poursuit par des mécanismes, chacun avec un qualificateur facultatif. La RFC 7208 définit les mécanismes all, include, a, mx, ip4, ip6, exists et ptr, et le modificateur redirect. Le qualificateur décide du résultat quand un mécanisme correspond : + pass (par défaut), - fail, ~ softfail et ? neutral.

Pour un domaine qui utilise un fournisseur e-mail, un seul mécanisme fait presque tout le travail : include. Il indique au destinataire d'évaluer l'enregistrement SPF du domaine du fournisseur et de traiter une correspondance là-bas comme une correspondance pour le vôtre. Vous ne copiez jamais d'adresses IP à la main : le fournisseur peut donc changer ses serveurs sans toucher à votre DNS. Si vous envoyez depuis un serveur à vous, ip4 et ip6 listent ses adresses et ne coûtent aucune requête.

SPF est publié sous forme d'enregistrement TXT. Une chaîne TXT unique est limitée à 255 octets, et un enregistrement plus long est découpé en plusieurs chaînes que le destinataire assemble sans espace. La plupart des éditeurs DNS font ce découpage pour vous.

Pourquoi un domaine ne peut-il avoir qu'un seul enregistrement SPF ?

Si deux enregistrements TXT commencent tous deux par v=spf1, le destinataire ne peut pas choisir et renvoie une erreur permanente : chaque message échoue donc à SPF. La RFC 7208 indique qu'un domaine ne doit pas avoir plus d'un enregistrement SPF. Proton, Mailbox.org et Mailfence donnent tous le même conseil : quand vous ajoutez un service, mettez son include dans l'enregistrement qui existe.

La cause habituelle est une migration. Vous publiez l'enregistrement du nouveau fournisseur et oubliez l'ancien. Ouvrez la liste des TXT, fusionnez les deux lignes en une seule et supprimez le reste. Quand vous changez définitivement de fournisseur, remplacez l'ancien include au lieu d'en ajouter un. La migration elle-même est décrite dans comment migrer son e-mail vers un nouveau fournisseur sans perdre de messages.

Quelle est la limite de 10 requêtes dans SPF ?

L'évaluation SPF s'arrête avec une erreur permanente après 10 termes qui interrogent le DNS : un enregistrement qui en demande 11 échoue donc pour tous les expéditeurs. Les termes qui comptent sont include, a, mx, ptr, exists et le modificateur redirect. Les mécanismes all, ip4 et ip6 ne comptent pas. La RFC 7208 précise aussi que les implémentations devraient s'arrêter après deux requêtes vides (void lookups), qui ne renvoient rien ou un domaine inexistant.

Un include compte pour une requête plus toutes les requêtes à l'intérieur de l'enregistrement inclus. Un seul fournisseur de messagerie est donc peu coûteux, mais un empilement d'un hébergeur de messagerie, d'un service de newsletter, d'un outil de support et d'un formulaire de site web s'additionne. Retirez d'abord les services que vous n'utilisez plus. Quand un outil publie des adresses IP fixes, les plages ip4 et ip6 ne coûtent rien. Le décompte imbriqué exact de chaque fournisseur n'a pas été mesuré par Postelva : testez donc votre enregistrement final avec une requête avant de vous y fier, comme montré dans comment vérifier les enregistrements MX, SPF, DKIM et DMARC.

Dois-je terminer mon enregistrement SPF par ~all ou -all ?

Utilisez ~all sauf si vous contrôlez chaque expéditeur : il marque les autres serveurs comme suspects sans demander aux destinataires de refuser purement et simplement le message. Le qualificateur sur all est le verdict pour tout serveur qui n'a correspondu à rien avant. -all signifie fail, ~all signifie softfail, ?all signifie neutral.

Un -all strict est plus sévère, mais la RFC 9989 avertit qu'il peut amener un destinataire à rejeter un message avant même que DMARC ne s'exécute, ce qui masque un message transféré que DKIM aurait sauvé. Pour cette raison, l'enregistrement que montrent Proton et Mailbox.org se termine par ~all. Selon la comparaison de Postelva du 12 novembre 2026, les trois fournisseurs dont les pages d'aide donnent une valeur SPF complète (Proton Mail, Mailbox.org, Fastmail) utilisent chacun exactement 1 include : un enregistrement pour un seul fournisseur coûte donc 1 requête, et deux d'entre eux se terminent par ~all tandis que la valeur de Fastmail se termine par ?all.

Quelle que soit la terminaison, c'est DMARC qui applique la règle. Définissez la politique là, comme expliqué dans le guide pour configurer DMARC. Les trois enregistrements sont comparés dans SPF, DKIM et DMARC : les différences.

Que vérifie SPF, et que ne vérifie-t-il pas ?

SPF vérifie le serveur derrière l'expéditeur d'enveloppe et le nom HELO, pas l'adresse From du message que le lecteur voit. Un message peut réussir SPF pour un domaine que personne ne remarque et afficher quand même votre domaine dans la ligne From. DMARC comble cette lacune en exigeant l'alignement entre les deux.

SPF ne survit pas non plus à une simple redirection, car un transitaire livre depuis sa propre adresse IP. Une règle pratique citable : SPF autorise des serveurs, un enregistrement par domaine, 10 requêtes au maximum. Pour un domaine qui n'envoie rien, publiez v=spf1 -all et le modèle « no email » de Postelva ; pour un domaine qui envoie et reçoit, modèles DNS en un clic pour Proton Mail, Fastmail, Zoho Mail, Google Workspace et Microsoft 365, plus un modèle SPF + DMARC et un modèle « sans e-mail » pour un domaine qui n'envoie rien.