Enregistrement SPF chez OVH : quoi mettre et comment le configurer pas à pas

Le SPF (Sender Policy Framework) est l'un des trois piliers de l'authentification e-mail, avec DKIM et DMARC. Cette page se concentre sur le SPF seul. Pour la configuration complète des trois enregistrements dans l'ordre, suivez notre tutoriel pilier SPF, DKIM et DMARC sur OVH ; pour la signature, voir activer DKIM chez OVH, et pour la politique, configurer DMARC chez OVH.

Pour OVH, que mettre dans le SPF ?

Réponse courte : la liste de tous les serveurs qui envoient des e-mails avec une adresse @votredomaine.fr, et rien d'autre. Pour une adresse OVHcloud seule (MX Plan, E-mail Pro, Hosted Exchange, Zimbra), c'est v=spf1 include:mx.ovh.com ~all.

Un SPF se lit toujours de la même façon : v=spf1 (la version), puis les sources autorisées (include:, ip4:, a, mx…), puis un qualificateur final (~all ou -all) qui dit quoi faire des e-mails venant d'ailleurs. La documentation OVHcloud précise que le SPF « est en réalité un enregistrement TXT dans la zone DNS ».

Avant d'écrire quoi que ce soit, faites l'inventaire. Les créateurs d'infoproduits oublient souvent une source : la messagerie (OVH, Microsoft 365 ou Google Workspace), l'outil d'emailing (Brevo, Systeme.io…), la plateforme de vente qui envoie les reçus, le formulaire du site. Chaque outil qui envoie avec votre domaine dans l'adresse d'enveloppe doit être couvert, soit par un include:, soit par son propre mécanisme d'authentification (voir plus bas le cas Systeme.io). Si vous construisez votre stack, notre guide plateformes et outils techniques aide à savoir qui envoie quoi.

Quelle est la valeur SPF par défaut chez OVH (include:mx.ovh.com) ?

Réponse courte : v=spf1 include:mx.ovh.com ~all. C'est la valeur publiée par OVHcloud pour MX Plan (seul ou inclus dans un hébergement), E-mail Pro et Hosted Exchange.

Lorsque vous créez ou réinitialisez une zone DNS sans choisir les « entrées minimales », OVH préconfigure la zone pour ses propres services : les MX pointent vers les serveurs OVH (du type mx1.mail.ovh.net) et un SPF OVHcloud est généralement présent. C'est pour cela que beaucoup d'utilisateurs trouvent un SPF « qu'ils n'ont jamais créé » dans leur zone. Il est utile tant que vous envoyez via OVH ; il devient incomplet dès que vous ajoutez un autre service.

Deux variantes officielles à connaître :

• Exchange Provider avec passerelle : v=spf1 include:mx.ovh.com a:gw.ex-mail.biz ~all.
• Private Exchange : on déclare les IP du serveur avec ip4: et ip6:, et l'on ajoute include:mx.ovh.com seulement si une offre mutualisée est aussi utilisée.

Type SPF ou TXT : que choisir dans l'interface de la zone DNS OVH ?

Réponse courte : les deux produisent un enregistrement TXT. Choisissez SPF si vous voulez l'assistant OVH, TXT si vous avez déjà la valeur complète (cas le plus fréquent dès que vous combinez plusieurs services).

Dans l'espace client OVHcloud : Web Cloud → Noms de domaine (ou Zones DNS) → votre domaine → onglet Zone DNS → Ajouter une entrée. La fenêtre propose trois chemins :

Dans l'assistant, les trois réponses finales correspondent aux qualificateurs : « Oui, je suis sûr » donne -all, « Oui, mais utiliser le safe mode » donne ~all, « Non » donne ?all (neutre, peu utile).

Comment configurer le SPF sur OVH : la procédure en 5 étapes

1. Inventaire. Listez chaque service qui envoie avec votre domaine.
2. Contrôle de l'existant. Zone DNS → filtre TXT puis SPF. Notez la valeur actuelle.
3. Composition. Écrivez une seule ligne : v=spf1, tous les include:, puis ~all.
4. Publication. S'il existe déjà un SPF, cliquez sur ... au bout de la ligne → Modifier l'entrée et remplacez la valeur. Sinon, Ajouter une entrée → TXT, sous-domaine vide (racine), TTL par défaut, valeur collée, Suivant → Confirmer.
5. Vérification. Après propagation (OVHcloud annonce 4 à 24 heures), contrôlez avec dig et un e-mail test.

Pour ajouter en même temps les entrées MX, DKIM et de vérification d'un fournisseur comme Microsoft 365 ou Google Workspace, suivez notre tutoriel dédié domaine OVH avec Microsoft 365 ou Google Workspace.

Sur un domaine chez OVH (ou ailleurs), ne peut-on avoir qu'un seul enregistrement SPF ?

Oui, un seul. La RFC 7208, qui définit SPF, indique qu'un nom de domaine ne doit publier qu'un enregistrement commençant par v=spf1. S'il y en a deux, le résultat est une erreur permanente (permerror) : aucune des deux lignes n'est appliquée.

Le cas typique chez OVH : le SPF par défaut include:mx.ovh.com reste en place, et l'on ajoute à côté une seconde entrée TXT pour Microsoft 365 ou Brevo. La bonne méthode consiste à fusionner :

Avant (incorrect, deux lignes) :
v=spf1 include:mx.ovh.com ~all
v=spf1 include:spf.protection.outlook.com -all

Après (correct, une ligne) :
v=spf1 include:mx.ovh.com include:spf.protection.outlook.com ~all
      

Microsoft le rappelle dans sa documentation : si un SPF existe déjà, n'en créez pas un nouveau, ajoutez la valeur Microsoft 365 à l'existant pour obtenir un enregistrement unique. Bien sûr, si vous avez quitté OVH pour vos e-mails, retirez include:mx.ovh.com au lieu de le garder « au cas où ».

Les autres enregistrements TXT (vérification Google google-site-verification=, Microsoft MS=ms…, code Brevo…) ne sont pas des SPF : ils peuvent cohabiter sans problème à la racine.

Exemples de valeurs SPF combinées

Les include: ci-dessous ont été relevés sur la documentation officielle de chaque éditeur en septembre 2026. Vérifiez toujours la valeur que votre outil affiche dans son propre écran d'authentification : elle fait foi.

OVH (MX Plan, E-mail Pro, Zimbra) + Brevo

v=spf1 include:mx.ovh.com include:spf.brevo.com ~all
      

Nuance importante : dans sa documentation actuelle, Brevo authentifie les domaines par un code de vérification TXT, deux CNAME DKIM et un DMARC, et présente l'include:spf.brevo.com comme nécessaire surtout en cas d'IP dédiée. L'ajouter ne nuit pas si vous restez sous la limite de lookups ; l'ancienne valeur spf.sendinblue.com est à remplacer par spf.brevo.com pour une nouvelle configuration.

OVH + Microsoft 365 (période de migration)

v=spf1 include:mx.ovh.com include:spf.protection.outlook.com ~all
      

Une fois la migration terminée et les boîtes OVH résiliées :

v=spf1 include:spf.protection.outlook.com -all
      

Google Workspace + Systeme.io

v=spf1 include:_spf.google.com ~all
      

Pas d'include Systeme.io : la documentation de Systeme.io ne demande aucune modification du SPF. L'authentification passe par trois CNAME (un sous-domaine pointant vers inbound.systeme.io et deux clés DKIM systemeio1._domainkey / systemeio2._domainkey) plus un DMARC. Le SPF est alors vérifié sur le sous-domaine d'envoi géré par Systeme.io, pas sur votre racine.

Google Workspace + Microsoft 365 (exemple cité par Google)

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all
      

Tableau des include vérifiés

~all ou -all : lequel choisir ?

Réponse courte : ~all tant que vous n'êtes pas certain d'avoir listé toutes vos sources, -all ensuite si vous le souhaitez. OVHcloud et Google utilisent ~all dans leurs valeurs types ; Microsoft propose -all.

• ~all (softfail) : les sources non listées sont suspectes, le destinataire décide (souvent : spam).
• -all (fail) : vous demandez le rejet des sources non listées.
• ?all (neutre) et +all (tout le monde autorisé) : à éviter, +all annule toute protection.

Dans la pratique, les grands fournisseurs combinent le résultat SPF avec DKIM et DMARC. C'est la politique DMARC (p=none, quarantine, reject) qui pilote réellement le sort des e-mails non conformes : voir configurer DMARC chez OVH.

La limite des 10 lookups DNS

Réponse courte : l'évaluation d'un SPF ne doit pas déclencher plus de 10 requêtes DNS, sous peine de permerror. Chaque include:, a, mx, ptr, exists et redirect= compte — y compris ceux contenus à l'intérieur des includes.

Les ip4: et ip6: ne comptent pas. Le piège est donc l'imbrication : un seul include: peut en appeler plusieurs autres. Plusieurs analyses tierces signalent par exemple que mx.ovh.com contient des mécanismes ptr, déconseillés par la RFC. Pour connaître votre total réel, utilisez un outil qui déplie l'arbre (MXToolbox affiche le nombre de lookups). Au-delà de 7 ou 8, faites le ménage : retirez les outils que vous n'utilisez plus plutôt que d'empiler.

Comment vérifier le SPF d'un domaine OVH ?

Réponse courte : dig TXT votredomaine.fr +short dans un terminal, ou le « SPF Record Lookup » de MXToolbox, puis un e-mail test dont vous lisez les en-têtes.

dig TXT votredomaine.fr +short
# Windows :
nslookup -type=TXT votredomaine.fr
      

Ce que vous devez constater :

• Une seule ligne commençant par "v=spf1.
• Tous vos services présents, un qualificateur final unique.
• Dans MXToolbox, aucun avertissement « Too many included lookups » ni « Multiple records ».

Enfin, envoyez un e-mail depuis chaque service vers une adresse Gmail, puis « Afficher l'original » : la ligne spf=pass doit apparaître. Le tutoriel pilier SPF, DKIM, DMARC sur OVH détaille la lecture de ces en-têtes.

OVH : comment « désactiver le contrôle SPF » ?

Réponse courte : il n'y a pas d'interrupteur, car le contrôle SPF est fait par les serveurs qui reçoivent vos e-mails, pas par OVH. Ce que vous pouvez faire, c'est modifier ou supprimer l'enregistrement SPF de votre zone — et il vaut presque toujours mieux le corriger que le supprimer.

Derrière cette recherche, on rencontre en général l'une de ces trois situations :

1. Le SPF OVH par défaut bloque un autre service. Vous envoyez avec Microsoft 365, Google Workspace ou un outil d'emailing, et le SPF ne contient que include:mx.ovh.com : vos e-mails échouent. Solution : éditez l'entrée (bouton ... → Modifier) et ajoutez l'include du nouveau service, ou remplacez mx.ovh.com si vous n'utilisez plus OVH pour l'envoi.
2. L'interface OVH réaffiche le SPF « tout seul ». C'est souvent une entrée créée avec le type SPF et masquée par le filtre TXT, ou une zone réinitialisée sans « entrées minimales », qui réintroduit la configuration OVHcloud. Vérifiez les deux filtres, et évitez de réinitialiser une zone qui porte des services actifs.
3. Des e-mails entrants sont refusés ou classés en spam parce que l'expéditeur a un SPF défaillant. Ce n'est pas votre zone DNS qui est en cause : c'est à l'expéditeur de corriger son SPF. Chez OVH, l'antispam des offres e-mail n'offre pas de réglage « ignorer le SPF » documenté ; ajoutez plutôt l'expéditeur en liste blanche dans votre messagerie si votre offre le permet.

Outlook et SPF chez OVH

Réponse courte : tout dépend de quel « Outlook » il s'agit. Si Outlook est seulement le logiciel qui lit votre boîte OVH (MX Plan, E-mail Pro), les e-mails partent par les serveurs OVH : include:mx.ovh.com suffit. Si vos adresses sont hébergées chez Microsoft 365, il faut include:spf.protection.outlook.com.

Côté réception, Outlook.com applique depuis 2025 des exigences SPF, DKIM et DMARC aux expéditeurs de gros volumes, sur le modèle de Gmail. Un SPF propre est donc aussi une condition pour que vos newsletters atteignent les boîtes Hotmail et Outlook.com.

DKIM, SPF et Gmail avec un domaine OVH

Réponse courte : Gmail vérifie à la fois SPF et DKIM, puis DMARC. Le SPF seul ne suffit plus pour une bonne délivrabilité : ajoutez la signature DKIM de chaque service d'envoi.

• Vous envoyez depuis Google Workspace : SPF include:_spf.google.com et clé DKIM google._domainkey générée dans la console d'administration Google.
• Vous lisez vos e-mails OVH dans l'application Gmail : les envois passent toujours par le SMTP OVH, le SPF reste include:mx.ovh.com. Activez le DKIM OVH (voir DKIM chez OVH).

Erreurs fréquentes avec le SPF chez OVH

• Deux SPF (un en type SPF, un en type TXT) : permerror. Fusionnez.
• Guillemets ou espaces parasites copiés depuis un PDF ou un e-mail : collez la valeur brute.
• Sous-domaine rempli par erreur (par exemple www ou le nom du domaine) : le SPF de la racine s'écrit avec le champ sous-domaine vide.
• Plus de 10 lookups : retirez les services abandonnés.
• Include d'un ancien fournisseur conservé après migration : il élargit inutilement la liste des serveurs autorisés.
• Zone modifiée au mauvais endroit : si votre domaine utilise d'autres serveurs DNS que ceux d'OVHcloud (Cloudflare, Wix…), OVH précise que le SPF doit être modifié chez le prestataire qui gère la zone. Vérifiez l'onglet Serveurs DNS.

Questions fréquentes