Écrire le SPF d'un domaine sans bloquer son propre courrier

Un enregistrement SPF en DNS est une ligne de type TXT, publiée dans la zone du nom de domaine, qui liste les serveurs autorisés à envoyer du mail pour ce domaine. Le serveur qui reçoit un message compare l'adresse IP de l'expéditeur à cette liste, puis accepte, marque ou refuse le courrier. Sans cette ligne, la sécurité du domaine et la réputation de sa messagerie reposent sur la seule confiance du destinataire.

Qu'est-ce qu'un enregistrement SPF et à quoi sert-il ?

Le SPF, pour Sender Policy Framework, est un protocole d'authentification du courrier électronique défini par la RFC 7208, publiée par l'IETF en avril 2014. Il répond à une question simple : ce serveur a-t-il le droit d'envoyer un message au nom de ce domaine ? Le propriétaire du domaine publie la réponse sous forme d'enregistrement DNS, et chaque serveur de messagerie destinataire la consulte à la réception.

Le protocole SMTP, conçu dans les années 1980, ne contrôle pas l'identité de l'expéditeur : n'importe quelle machine peut annoncer une adresse en @votre-domaine.fr. Cette faiblesse alimente l'usurpation d'identité (le spoofing) et l'hameçonnage. L'enregistrement SPF ne supprime pas le problème, mais il donne au destinataire un moyen technique d'identifier un envoi qui ne vient pas d'une source autorisée.

Une précision change la manière de lire les résultats : le SPF vérifie l'adresse d'enveloppe, celle de la commande MAIL FROM que l'on retrouve dans l'en-tête Return-Path, et l'identité annoncée par la commande HELO. Il ne contrôle pas l'adresse visible dans le champ « De » que l'utilisateur lit dans son client de messagerie. C'est DMARC qui fait le lien entre les deux, grâce à l'alignement des domaines.

La différence avec DKIM tient à l'objet contrôlé : le SPF authentifie le serveur d'origine, DKIM signe le contenu du message avec une clé dont la partie publique est également utilisée depuis le DNS. Les deux systèmes se complètent, aucun ne remplace l'autre.

Pour une entreprise, une association ou un particulier qui possède un nom de domaine, le SPF sert donc à trois choses : protéger la marque contre l'usurpation, améliorer la délivrabilité des envois légitimes et répondre aux exigences de conformité des grands fournisseurs de messagerie. Un domaine sans SPF n'est pas bloqué partout, mais ses messages finissent plus souvent en indésirables.

Comment le serveur destinataire vérifie l'enregistrement SPF

La vérification SPF se déroule pendant la session SMTP, avant même que le corps du message soit accepté. Le serveur de réception suit toujours la même chaîne d'opérations :

1. il lit le domaine de l'adresse d'enveloppe (par exemple bounce@exemple.fr donne exemple.fr) ;
2. il lance une requête DNS de type TXT sur ce nom et cherche la ligne qui commence par v=spf1 ;
3. il évalue les mécanismes de gauche à droite et s'arrête au premier qui correspond à l'adresse IP du client SMTP ;
4. il applique le qualificatif de ce mécanisme et produit un résultat ;
5. il décide de la suite selon sa propre politique de sécurité et, si le domaine en publie une, selon la politique DMARC.

La RFC 7208 nomme sept résultats possibles. Leur sens détermine ce que l'administrateur doit corriger quand un rapport ou un en-tête signale un échec.

Le serveur reste libre de son traitement : un fail n'entraîne pas un rejet chez tous les fournisseurs. Gmail, par exemple, combine le résultat SPF avec la signature DKIM, la réputation de l'IP et l'historique de l'expéditeur avant de classer un message.

La syntaxe d'une ligne v=spf1, élément par élément

Un enregistrement SPF se publie toujours en enregistrement TXT : l'ancien type DNS nommé SPF (code 99), prévu par la première version expérimentale, n'est plus utilisé depuis la RFC 7208. Voici un exemple complet de ligne, telle qu'elle apparaît dans une zone DNS :

exemple.fr.  3600  IN  TXT  "v=spf1 mx a include:_spf.messagerie.example ip4:198.51.100.25 ~all"

La ligne commence obligatoirement par v=spf1, la version du protocole. Suivent les mécanismes, éventuellement précédés d'un qualificatif, puis un terme final qui dit quoi faire de tout le reste.

Les mécanismes : qui a le droit d'envoyer

Les qualificatifs : quel verdict rendre

Le qualificatif placé devant un mécanisme fixe le résultat quand ce mécanisme correspond : + pour pass (valeur par défaut, rarement écrite), - pour fail, ~ pour softfail et ? pour neutral. Une ligne terminée par ~all reste la plus répandue pendant la mise en place ; le -all s'impose une fois tous les services d'envoi recensés et vérifiés. Une ligne sans all ni redirect aboutit à un résultat neutre, qui ne protège rien.

Les modificateurs redirect et exp

Le modificateur redirect= confie toute l'évaluation au SPF d'un autre domaine : pratique pour une entreprise qui gère dix noms de domaine avec une seule politique, à condition qu'il n'y ait pas de all dans la ligne. Le modificateur exp= désigne un texte d'explication renvoyé en cas d'échec ; peu de serveurs l'affichent, il reste facultatif.

Créer et ajouter un enregistrement SPF dans la zone DNS : les étapes

Créer un enregistrement SPF prend dix minutes à écrire, mais la phase de recensement qui précède décide de sa justesse. Un oubli à cette étape suffit à faire rejeter les factures, les notifications du site ou la lettre d'information.

Étape 1 : recenser tout ce qui envoie au nom du domaine

Le recensement des services d'envoi est l'étape que les guides survolent et que les erreurs de production révèlent. La liste type d'une petite entreprise comprend :

• la messagerie principale (Google Workspace, Microsoft 365, la messagerie de l'hébergeur) ;
• le serveur web, si le site envoie des formulaires de contact ou des confirmations de commande ;
• l'outil d'emailing pour les newsletters ;
• le logiciel de facturation, le CRM, la billetterie ou la plateforme de support client ;
• les imprimantes et scanners qui envoient des courriels par un relais interne.

Les rapports DMARC agrégés aident beaucoup ici : publiés quelques semaines avec une politique p=none, ils montrent toutes les sources réelles d'envoi, y compris celles que personne n'avait signalées.

Dans une entreprise, la gestion du SPF revient à la personne qui administre les paramètres DNS, mais chaque équipe qui met en service un nouveau produit d'envoi (outil marketing, logiciel métier, application mobile) doit la prévenir : c'est l'essentiel de la prévention des pannes. Un fichier partagé ou une ressource interne qui liste chaque service, son include et sa date de mise en service aide à effectuer le ménage lors d'une résiliation, quand l'offre d'un prestataire change ou quand un outil configuré par une ancienne équipe n'a plus d'activité.

Les fournisseurs de cloud public méritent une attention à part : Google Cloud bloque les connexions sortantes sur le port 25 et AWS les limite par défaut sur EC2. Une application hébergée dans le cloud passe donc par un service d'envoi dédié, dont il faut utiliser l'include plutôt que l'IP, changeante, de l'instance.

Étape 2 : rédiger la ligne

Pour chaque service, la valeur exacte de l'include se trouve dans le centre d'aide ou la documentation du fournisseur ; elle ne se devine pas. On assemble ensuite les éléments dans une seule chaîne, de la plus précise (ip4:) à la plus large (include:), et on termine par ~all pendant la phase de test.

Étape 3 : ajouter l'enregistrement TXT chez le gestionnaire DNS

L'ajout se fait dans l'espace client du registrar ou de l'hébergeur qui gère la zone DNS, dans le tableau de bord de Cloudflare si les serveurs de noms y pointent. La démarche est la même partout : ajouter un enregistrement de type TXT, laisser le champ du nom vide ou mettre @ pour le nom de votre domaine, coller la valeur, choisir une durée de vie (TTL). Certains panneaux de gestion, dont celui d'OVHcloud, proposent aussi un assistant SPF qui génère la ligne. Si un enregistrement v=spf1 existe déjà, il faut le modifier, jamais en créer un second.

Étape 4 : attendre la propagation puis tester

La nouvelle valeur devient visible partout une fois écoulé le TTL de l'ancienne, de quelques minutes à plusieurs heures selon le réglage précédent : le mécanisme est détaillé dans la page sur la propagation DNS et ses délais. Les tests décrits plus bas confirment ensuite que chaque service passe.

Exemples d'enregistrements SPF selon les services d'envoi

Les exemples d'enregistrement SPF qui suivent reprennent les valeurs documentées par chaque fournisseur à la date de rédaction (octobre 2026). Elles évoluent rarement, mais un contrôle dans l'aide du fournisseur reste indispensable avant publication.

Domaine sur Google Workspace uniquement

v=spf1 include:_spf.google.com ~all : Google recommande cette valeur dans l'aide administrateur de Google Workspace.

Domaine sur Microsoft 365

v=spf1 include:spf.protection.outlook.com -all : la valeur que Microsoft indique pour les clients Exchange Online.

Messagerie de l'hébergement OVHcloud

v=spf1 include:mx.ovh.com ~all : la ligne proposée par défaut par l'assistant de la zone DNS d'OVHcloud.

Messagerie, site web et newsletter

v=spf1 include:_spf.google.com ip4:198.51.100.25 include:spf.newsletter.example ~all : la messagerie Google, l'IP du serveur web et l'include d'un service d'emailing réunis sur une seule ligne.

Domaine qui n'envoie jamais de courrier

v=spf1 -all : un nom réservé pour protéger une marque se défend contre l'usurpation avec cette règle très courte, à compléter par un DMARC en p=reject.

Sous-domaine dédié aux envois en masse

Chaque sous-domaine porte son propre SPF : news.exemple.fr n'hérite pas de la ligne de exemple.fr. Séparer les campagnes marketing sur un sous-domaine protège la réputation de la messagerie principale.

Le cas du serveur web se règle souvent mal. Un formulaire qui envoie par la fonction mail() de PHP part de l'IP du serveur web, qui n'est pas toujours celle de la messagerie : le symptôme et les correctifs sont décrits pour un mail envoyé par script PHP et bloqué par Gmail. Passer par un relais SMTP authentifié évite d'inclure l'IP du serveur.

Peut-on avoir plusieurs enregistrements SPF sur un même domaine ?

Un domaine ne peut publier qu'un seul enregistrement SPF. La RFC 7208 (section 4.5) est explicite : si la recherche DNS renvoie plus d'une ligne commençant par v=spf1, le résultat est permerror, et le domaine perd son authentification SPF pour tous ses envois, y compris ceux qui passaient la veille.

Le problème avec plusieurs SPF apparaît presque toujours de la même façon : un nouvel outil demande d'ajouter « son » enregistrement TXT, l'utilisateur crée une seconde ligne au lieu de compléter la première. La correction consiste à fusionner les deux en une seule ligne, avec un seul v=spf1 au début et un seul all à la fin :

Avant (erreur) :
"v=spf1 include:_spf.google.com ~all"
"v=spf1 include:spf.newsletter.example ~all"

Après fusion :
"v=spf1 include:_spf.google.com include:spf.newsletter.example ~all"

Les autres enregistrements TXT du domaine (vérification Google Search Console, clé DKIM sur son sélecteur, DMARC sur _dmarc) ne gênent pas : seule compte la présence de deux chaînes v=spf1 sur le même nom. Une ligne qui dépasse 255 caractères doit, en revanche, être découpée en plusieurs chaînes entre guillemets dans le même enregistrement, que le serveur recolle sans espace.

La limite de 10 requêtes DNS et l'aplatissement SPF

La limite de requêtes DNS est la cause la plus fréquente de permerror SPF sur les domaines qui utilisent plusieurs services en ligne. La RFC 7208 (section 4.6.4) plafonne à 10 le nombre de mécanismes et modificateurs qui demandent une recherche DNS : include, a, mx, ptr, exists et redirect. Le compte inclut les include imbriqués : l'include d'un fournisseur qui appelle lui-même trois autres include consomme quatre requêtes. La même section limite à deux les recherches « vides » (qui ne renvoient aucune réponse) avant de déclarer une erreur.

Un domaine qui cumule Google Workspace, Microsoft 365 pour une filiale, un CRM, un outil d'emailing et une plateforme de support dépasse vite le plafond. Trois réponses existent :

• supprimer l'inutile : un service résilié laisse souvent son include dans la ligne, et le mécanisme ptr n'a plus sa place ;
• déplacer des envois sur un sous-domaine, qui dispose de son propre budget de 10 requêtes ;
• aplatir la ligne : l'aplatissement SPF (flattening) remplace les include par les plages ip4: et ip6: qu'ils désignent, qui ne coûtent aucune requête.

L'aplatissement manuel a un défaut sérieux : quand le fournisseur change ses adresses, la ligne figée devient fausse sans alerte. Les services d'aplatissement automatique recalculent la liste et mettent la zone à jour, contre une dépendance de plus. Pour un petit domaine, le tri des include suffit dans la grande majorité des cas.

Comment valider un enregistrement SPF après publication ?

La validation d'un enregistrement SPF se fait en deux temps : lire la ligne publiée, puis observer le résultat sur un vrai message. La ligne se lit depuis n'importe quel poste :

dig +short TXT exemple.fr
nslookup -type=TXT exemple.fr

Un vérificateur SPF en ligne complète ce contrôle : MxToolbox, dmarcian ou le Check MX de la Google Admin Toolbox, gratuits pour un test ponctuel, comptent les requêtes DNS, détectent les doublons et signalent les erreurs de syntaxe. Ces checkers SPF ne connaissent pas les services réellement utilisés par le domaine : ils valident la forme, pas l'exhaustivité.

La bonne pratique consiste à utiliser un vérificateur SPF après chaque modification, puis à surveiller les rapports pendant deux semaines d'activité normale avant de configurer le -all : certains envois (relances trimestrielles, campagnes saisonnières, alertes d'un paramètre de sauvegarde) n'apparaissent qu'à intervalle long. L'utilisation d'un second vérificateur sert aussi de contrôle croisé, car leurs règles de comptage des requêtes diffèrent parfois.

Le vrai test reste un message envoyé depuis chaque service vers une boîte Gmail : la commande « Afficher l'original » indique SPF PASS, FAIL ou SOFTFAIL avec l'adresse IP évaluée, et le même affichage donne le résultat DKIM et DMARC. Dans Outlook ou Thunderbird, l'en-tête Authentication-Results porte la même information. Sur la durée, les rapports DMARC agrégés, envoyés chaque jour par les grands fournisseurs, restent le meilleur outil de suivi : ils montrent chaque source qui échoue, avec son volume.

SPF, DKIM et DMARC : pourquoi le SPF seul ne suffit pas

Le SPF a une faiblesse connue : il casse dès qu'un message est transféré. Une redirection automatique renvoie le courrier depuis le serveur intermédiaire, dont l'IP ne figure pas dans le SPF du domaine d'origine ; le problème touche aussi les boîtes rapatriées, comme l'explique la page sur la réception des boîtes mails dans Gmail ou Yahoo. La signature DKIM, attachée au contenu du message, survit en général au transfert : publier la clé DKIM dans les DNS du domaine donne ce second appui.

DMARC relie SPF et DKIM au domaine visible par le lecteur et dit au destinataire quoi faire en cas d'échec : rien (p=none), mise en quarantaine ou rejet. Il fournit aussi les rapports qui permettent de traiter les sources oubliées. La construction pas à pas d'un enregistrement DMARC suit naturellement la mise en place du SPF.

Les grands fournisseurs ont rendu le trio quasi obligatoire. Depuis février 2024, Google et Yahoo exigent de tout expéditeur un SPF ou un DKIM valide, et des expéditeurs en masse (environ 5 000 messages par jour vers Gmail) les trois protocoles, avec un DMARC au minimum en p=none. Microsoft applique des exigences comparables aux gros expéditeurs vers Outlook.com depuis mai 2025. Pour un domaine professionnel, l'authentification SPF et DKIM et une politique DMARC forment désormais la base de la délivrabilité.

Le SPF ne suffit pas non plus à empêcher toute attaque : un spam envoyé depuis un nom approchant (lettre doublée, chiffre à la place d'une lettre) passe le SPF de son propre domaine. Le protocole bloque l'usurpation exacte du nom, ce qui renforce la confiance des destinataires et la sécurité de la marque ; la surveillance des noms proches relève d'une autre utilisation, celle des outils de veille de marque.

SPF en pratique : include, TTL, sous-domaines et transferts

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

Le ~all convient pendant la mise en place, quand un service oublié risque encore d'envoyer : ses messages passent, marqués suspects. Le -all se pose quand les rapports DMARC ne montrent plus aucune source légitime en échec. Avec DMARC en place, l'écart entre les deux pèse moins, car c'est la politique DMARC qui décide.

Comment ajouter une adresse IP à un enregistrement SPF ?

Pour ajouter une adresse IP à un enregistrement SPF, on modifie la ligne existante en insérant ip4:203.0.113.10 (ou ip6: suivi de l'adresse) avant le terme all. Une plage s'écrit en notation CIDR, par exemple ip4:203.0.113.0/28. Ce mécanisme ne consomme aucune requête DNS.

Quel TTL choisir pour l'enregistrement SPF ?

Un TTL court (300 secondes) pendant les modifications permet de corriger vite une erreur ; une valeur de 3600 secondes ou plus convient une fois la ligne stable, et réduit le nombre de requêtes sur les serveurs de noms.

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

Non : le SPF s'évalue sur le nom exact de l'adresse d'enveloppe. Un sous-domaine qui envoie du courrier doit porter son propre enregistrement TXT v=spf1, et un sous-domaine qui n'envoie rien gagne à publier v=spf1 -all.

Sources : RFC 7208, Sender Policy Framework (sections 3, 4.5, 4.6 et 5) ; aide administrateur Google Workspace, consignes pour les expéditeurs d'e-mails ; documentation Microsoft 365 sur la configuration SPF ; guides OVHcloud sur la zone DNS.