Skip to content
Retour aux guides
Guide

Configurer SPF, DKIM et DMARC chez OVH : guide pas à pas

Guide technique pour configurer SPF, DKIM et DMARC sur votre domaine hébergé chez OVH. Protégez votre domaine contre l'usurpation d'identité et améliorez votre délivrabilité email.

Thomas Ferreira 14 min de lecture

Vous gérez votre domaine chez OVH — l’hébergeur numéro un en France avec plus de 3,5 millions de domaines enregistrés. Votre zone DNS est dans le Manager OVH. Et pourtant, si vous n’avez jamais touché à SPF, DKIM ou DMARC, n’importe qui peut aujourd’hui envoyer un email depuis @votredomaine.fr.

Pas besoin de pirater votre boîte mail. Pas besoin de votre mot de passe. Le protocole email SMTP, conçu en 1982, n’authentifie pas l’expéditeur. Un attaquant peut mettre votre adresse dans le champ « De : » aussi facilement qu’on écrit une fausse adresse sur une enveloppe postale. C’est ce qu’on appelle le spoofing.

OVH configure par défaut les enregistrements MX pour que vos emails arrivent. Mais les enregistrements qui protègent l’expéditeur — SPF, DKIM, DMARC — ne sont pas toujours activés, notamment si vous utilisez un service email tiers ou si votre compte date de quelques années.

Ce guide vous accompagne étape par étape dans la configuration de ces trois protocoles, avec les chemins exacts dans l’interface OVH Manager.

Avant de commencer, testez gratuitement la configuration email de votre domaine. Notre outil vérifie vos enregistrements SPF, DKIM et DMARC en quelques secondes et vous indique précisément ce qui manque.

Pourquoi configurer SPF, DKIM et DMARC chez OVH

OVH héberge une part massive des domaines d’entreprises françaises. C’est précisément pour cette raison que ses clients sont des cibles : un attaquant qui usurpe des domaines en @entreprise.fr bénéficie d’une reconnaissance immédiate auprès de ses victimes françaises.

La configuration email par défaut chez OVH varie selon l’ancienneté du compte et l’offre souscrite. Les comptes récents avec MX Plan nouvelle génération ont souvent SPF pré-configuré. Les comptes plus anciens, les configurations avec Microsoft 365 ou Google Workspace comme service email, et les domaines avec hébergement mutualisé sans email actif : dans ces cas, la configuration est fréquemment incomplète.

Les conséquences d’une absence de SPF, DKIM et DMARC sont de deux ordres :

Délivrabilité dégradée. Depuis février 2024, Google et Yahoo exigent SPF et DKIM pour tout expéditeur envoyant plus de 5 000 emails par jour. En dessous de ce seuil, l’absence de ces protocoles augmente significativement le risque que vos emails atterrissent en spam.

Usurpation d’identité. Sans politique DMARC active, votre domaine peut être utilisé pour envoyer des emails de phishing à vos clients, partenaires ou employés. Ces emails auront l’air de venir de vous, et vous n’en saurez rien.

Voici ce que fait chacun des trois protocoles :

  • SPF (Sender Policy Framework) : liste dans votre DNS les serveurs autorisés à envoyer des emails pour votre domaine. Un serveur non listé est signalé comme non autorisé.
  • DKIM (DomainKeys Identified Mail) : ajoute une signature cryptographique à chaque email sortant. Le serveur destinataire vérifie que le message n’a pas été altéré en transit.
  • DMARC (Domain-based Message Authentication, Reporting & Conformance) : s’appuie sur SPF et DKIM pour décider ce qu’il faut faire des emails qui échouent aux vérifications — et vous envoie des rapports sur ce qui se passe.

Pour une explication détaillée du fonctionnement technique de chaque protocole, consultez le guide complet SPF, DKIM et DMARC.

Tester votre configuration actuelle

Avant de modifier quoi que ce soit, vérifiez l’état de votre configuration. Vous éviterez ainsi d’écraser un enregistrement déjà correct.

Via notre outil gratuit : rendez-vous sur /outils/test-securite-email, entrez votre nom de domaine, et obtenez en quelques secondes le statut de vos enregistrements SPF, DKIM et DMARC avec des recommandations concrètes.

Via la ligne de commande : si vous préférez vérifier directement depuis votre terminal :

# Vérifier SPF
dig TXT votredomaine.fr | grep spf

# Vérifier DMARC
dig TXT _dmarc.votredomaine.fr

# Vérifier DKIM (remplacez "ovh" par le sélecteur de votre service email)
dig TXT ovh._domainkey.votredomaine.fr

Interpréter les résultats :

Ce que vous voyezCe que ça signifie
Aucun résultat pour SPFPas d’enregistrement SPF — à créer
v=spf1 include:mx.ovh.com sans ~all ni -allSPF incomplet — à corriger
Deux lignes commençant par v=spf1Double enregistrement SPF — à fusionner
Aucun résultat pour DMARCPas de politique DMARC — votre domaine peut être usurpé librement
p=none dans DMARCSurveillance uniquement, pas de protection active

Configurer SPF chez OVH

Accéder à la zone DNS

  1. Connectez-vous à votre espace client OVH (manager.ovh.com)
  2. Dans le menu de gauche, cliquez sur Noms de domaine
  3. Sélectionnez le domaine à configurer
  4. Cliquez sur l’onglet Zone DNS

Vous voyez la liste de tous vos enregistrements DNS. Cherchez si un enregistrement TXT à la racine (colonne « Sous-domaine » vide ou avec @) commence par v=spf1. Si c’est le cas, modifiez-le plutôt que d’en créer un nouveau.

Ajouter ou modifier l’enregistrement SPF

Si vous n’avez pas encore de SPF :

  1. Cliquez sur Ajouter une entrée
  2. Sélectionnez TXT
  3. Sous-domaine : laissez vide (ou entrez @ selon l’interface — les deux correspondent à la racine du domaine)
  4. TTL : laissez la valeur par défaut (3600)
  5. Valeur : entrez votre record SPF (voir les valeurs ci-dessous)
  6. Cliquez sur Suivant puis Valider

Si vous avez déjà un SPF :

  1. Cliquez sur le crayon (modifier) à côté de l’enregistrement TXT existant
  2. Modifiez la valeur en ajoutant les mécanismes manquants
  3. Validez

Quelle valeur SPF utiliser ?

Vous utilisez uniquement les emails OVH (MX Plan, Email Pro, Exchange OVH) :

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

Vous utilisez OVH + Microsoft 365 :

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

Vous utilisez OVH + Google Workspace :

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

Vous utilisez uniquement Microsoft 365 (domaine OVH, emails Microsoft) :

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

Vous utilisez uniquement Google Workspace (domaine OVH, emails Google) :

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

Sur le ~all vs -all : le softfail ~all indique que les serveurs non listés sont probablement frauduleux. Le hardfail -all demande explicitement leur rejet. Commencez par ~all le temps de valider que tous vos services d’envoi sont bien listés. Une fois que vos rapports DMARC confirment qu’aucun service légitime n’est manquant, passez à -all.

Erreurs fréquentes à éviter

Deux records SPF. C’est l’erreur la plus courante. Si vous ajoutez un second enregistrement TXT commençant par v=spf1, vous aurez deux records SPF en conflit. Le résultat est PermError : SPF est ignoré, comme si vous n’en aviez pas. Un seul record SPF par domaine, avec tous vos services dans ce record.

Trop de lookups DNS. SPF est limité à 10 résolutions DNS récursives. Chaque include: en consomme au moins une, et certains includes contiennent eux-mêmes d’autres includes. Si vous avez beaucoup de services d’envoi, vérifiez le nombre de lookups avec un outil comme MXToolbox SPF Record Checker. Au-delà de 10, le contrôle SPF renvoie PermError.

Oublier un service d’envoi. Chaque service qui envoie des emails depuis votre domaine doit figurer dans le SPF : votre messagerie principale, mais aussi votre CRM, votre outil marketing (Brevo, Mailchimp), vos emails transactionnels (Stripe, Pennylane), votre outil de support (Zendesk). Un service oublié verra ses emails échouer à SPF une fois que DMARC sera en politique stricte.

Configurer DKIM chez OVH

La procédure DKIM dépend de votre offre email chez OVH. Il existe trois cas principaux.

Cas 1 : MX Plan nouvelle génération ou Email Pro OVH

Depuis 2023, OVH permet d’activer DKIM directement depuis l’espace client pour ses offres MX Plan nouvelle génération et Email Pro.

  1. Dans l’espace client OVH, allez dans Emails → sélectionnez votre service email
  2. Cliquez sur l’onglet Informations générales puis Sécurité
  3. Dans la section DKIM, cliquez sur Configurer
  4. OVH génère une paire de clés et publie automatiquement l’enregistrement DKIM dans votre zone DNS

Vérifiez que l’enregistrement a bien été créé dans Noms de domaine → Zone DNS. Vous devez voir un enregistrement TXT dont le nom ressemble à ovh._domainkey.votredomaine.fr.

Vous avez l’ancienne formule MX Plan ? Elle ne supporte pas DKIM. OVH propose la migration gratuite vers la nouvelle formule MX Plan. Allez dans Emails → votre service MX Plan → Général et cherchez le bouton de migration. Cette migration ne cause pas d’interruption de service.

Cas 2 : Exchange OVH (Hosted Exchange ou Private Exchange)

  1. Dans l’espace client OVH, allez dans Microsoft → Exchange → votre service
  2. Allez dans l’onglet Domaines associés
  3. Cliquez sur le domaine à configurer → Configurer le DKIM
  4. OVH vous fournit deux enregistrements CNAME à ajouter dans votre zone DNS :
    • selector1._domainkey.votredomaine.fr → pointe vers un enregistrement géré par OVH
    • selector2._domainkey.votredomaine.fr → second sélecteur pour la rotation de clés
  5. Ajoutez ces deux enregistrements CNAME dans Noms de domaine → Zone DNS
  6. Revenez dans la configuration Exchange et activez la signature DKIM

Cas 3 : Domaine OVH avec Microsoft 365 ou Google Workspace

Si votre domaine est géré chez OVH mais que vos emails partent de Microsoft 365 ou Google Workspace, c’est ces services qui génèrent les clés DKIM. La zone DNS OVH sert juste à publier les enregistrements qu’ils vous donnent.

Microsoft 365 :

  1. Dans le portail Microsoft Defender (security.microsoft.com) : Stratégies & règles → Stratégies de menace → Email authentication settings → DKIM
  2. Sélectionnez votre domaine et cliquez sur Créer des clés DKIM
  3. Microsoft vous donne deux enregistrements CNAME
  4. Ajoutez-les dans la zone DNS OVH (type CNAME)
  5. Revenez dans Defender et cliquez Activer

Google Workspace :

  1. Dans la console Admin Google (admin.google.com) : Applications → Google Workspace → Gmail → Authentifier les emails
  2. Sélectionnez votre domaine, cliquez sur Générer un nouvel enregistrement
  3. Choisissez une longueur de clé de 2048 bits
  4. Google vous donne un enregistrement TXT (nom : google._domainkey)
  5. Ajoutez cet enregistrement TXT dans la zone DNS OVH
  6. Attendez 15 à 60 minutes, puis revenez dans la console Admin et cliquez Démarrer l’authentification

Vérifier que DKIM est actif

Envoyez un email depuis votre domaine vers une adresse Gmail personnelle. Ouvrez l’email reçu → menu ⋮ (les trois points) → Afficher l’original. Dans les résultats d’authentification en haut, vous devez voir dkim=pass. Si vous voyez dkim=none ou dkim=fail, la signature n’est pas encore active ou la clé n’a pas propagé.

Configurer DMARC chez OVH

DMARC se configure comme un simple enregistrement TXT dans votre zone DNS OVH. La subtilité : il faut démarrer avec une politique non bloquante, analyser les rapports, puis monter progressivement vers une politique stricte.

Ajouter l’enregistrement DMARC

  1. Dans l’espace client OVH : Noms de domaine → votredomaine.fr → Zone DNS
  2. Cliquez sur Ajouter une entréeTXT
  3. Sous-domaine : entrez _dmarc
  4. TTL : 3600
  5. Valeur : entrez votre record DMARC (voir ci-dessous)
  6. Validez

Progresser par étapes

Étape 1 — Surveillance (à déployer immédiatement) :

v=DMARC1; p=none; rua=mailto:dmarc-reports@votredomaine.fr; fo=1
  • p=none : pas de blocage, observation uniquement
  • rua= : adresse qui recevra les rapports quotidiens (utilisez une adresse que vous consultez)
  • fo=1 : générer des rapports pour chaque email en échec (utile pour le diagnostic)

Gardez cette configuration 2 à 4 semaines. Pendant cette période, analysez les rapports reçus pour identifier toutes vos sources d’envoi légitimes et vous assurer qu’elles passent SPF ou DKIM.

Étape 2 — Mise en quarantaine progressive :

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@votredomaine.fr; fo=1

pct=25 signifie que seulement 25 % des emails en échec seront mis en spam. Montez progressivement : 25 % → 50 % → 75 % → 100 %. Vérifiez après chaque palier qu’aucun email légitime n’est touché.

Étape 3 — Rejet total (objectif final) :

v=DMARC1; p=reject; rua=mailto:dmarc-reports@votredomaine.fr; fo=1

À ce stade, tout email prétendant venir de votre domaine mais échouant aux vérifications SPF et DKIM sera rejeté par les serveurs destinataires. C’est la protection maximale.

Pour une stratégie de migration détaillée vers p=reject, consultez le guide migration DMARC vers reject.

Que font les rapports DMARC ?

Chaque jour, les grands fournisseurs de messagerie (Gmail, Microsoft, Yahoo, OVH, etc.) vous envoient un fichier XML récapitulant tous les emails qui ont prétendu venir de votre domaine. Ces rapports contiennent l’IP du serveur expéditeur, le résultat SPF, le résultat DKIM, et l’alignement.

Les fichiers XML bruts sont difficiles à lire. Des outils gratuits comme Postmark DMARC ou dmarcian les transforment en tableaux de bord lisibles. En phase initiale, ce suivi est nécessaire pour détecter les services d’envoi légitimes qui échouent avant de passer en politique bloquante.

Vérifier votre configuration

Une fois vos enregistrements publiés, vérifiez qu’ils sont correctement interprétés.

Avec notre outil : /outils/test-securite-email vérifie SPF, DKIM et DMARC et vous donne un score. C’est le moyen le plus rapide.

Avec dig en ligne de commande :

# Vérifier SPF — doit retourner votre enregistrement v=spf1
dig TXT votredomaine.fr

# Vérifier DMARC — doit retourner votre enregistrement v=DMARC1
dig TXT _dmarc.votredomaine.fr

# Vérifier DKIM pour OVH Mail (sélecteur "ovh")
dig TXT ovh._domainkey.votredomaine.fr

# Vérifier DKIM pour Google Workspace (sélecteur "google")
dig TXT google._domainkey.votredomaine.fr

# Vérifier DKIM pour Microsoft 365 (sélecteur "selector1")
dig TXT selector1._domainkey.votredomaine.fr

Avec nslookup (Windows) :

nslookup -type=TXT _dmarc.votredomaine.fr
nslookup -type=TXT votredomaine.fr

Délai de propagation : OVH utilise un TTL de 3 600 secondes par défaut. Attendez au moins 1 heure après chaque modification avant de tester. Si les anciens enregistrements persistent, attendez jusqu’à 48 heures (rare, mais possible si un résolveur a mis en cache une valeur avec un TTL élevé).

Test d’envoi : envoyez un email depuis votre domaine vers une adresse Gmail. Ouvrez l’email → menu ⋮ → Afficher l’original. Cherchez la section Authentication-Results. Vous devez voir :

spf=pass
dkim=pass
dmarc=pass

Si l’un des trois affiche fail ou none, revenez à la section correspondante de ce guide.

Cas particuliers OVH

Plusieurs domaines chez OVH

Si vous gérez plusieurs domaines dans le même compte OVH, la configuration SPF, DKIM et DMARC doit être répétée pour chaque domaine. Il n’existe pas de configuration globale. Pensez aussi aux sous-domaines utilisés pour l’envoi (ex: newsletter.votredomaine.fr) : ils ont besoin de leurs propres enregistrements SPF et DKIM, ou doivent être couverts par la politique DMARC du domaine parent via le paramètre sp=.

Domaines redirigés ou parqués

Si vous avez des domaines qui ne servent qu’à rediriger vers un autre domaine (domaines défensifs, variantes orthographiques), ces domaines peuvent aussi être usurpés pour du phishing. La configuration recommandée pour un domaine qui n’envoie jamais d’email :

# SPF : aucun serveur autorisé
v=spf1 -all

# DMARC : rejet immédiat
v=DMARC1; p=reject

Pas besoin de DKIM pour un domaine qui n’envoie rien. SPF -all et DMARC p=reject suffisent à bloquer toute usurpation.

OVH + outil de marketing email (Mailchimp, Brevo, Sendinblue)

Si vous utilisez un outil de marketing email en plus de votre messagerie OVH, vous avez deux options pour DKIM :

Option 1 — Délégation de domaine. Certains outils (Brevo, Mailjet, Mailchimp) permettent d’authentifier votre domaine via des enregistrements CNAME. L’outil génère et gère les clés DKIM, vous publiez les CNAME dans la zone DNS OVH. C’est la méthode recommandée : elle garantit un alignement DMARC correct.

Option 2 — Sous-domaine spécifique. Pour les newsletters, vous pouvez utiliser un sous-domaine comme news.votredomaine.fr. Configurez SPF et DKIM spécifiquement pour ce sous-domaine. Cela évite que des problèmes de configuration sur l’outil marketing n’affectent la délivrabilité des emails de votre domaine principal.

Pour chacun de ces outils, ajoutez le mécanisme include: correspondant dans votre SPF :

ServiceMécanisme SPF à ajouter
Brevo / Sendinblueinclude:spf.brevo.com
Mailchimpinclude:servers.mcsv.net
Mailjetinclude:spf.mailjet.com
HubSpotinclude:hubspotemail.net
Klaviyoinclude:klaviyomail.com

Hébergement mutualisé OVH et emails PHP

Si votre site web envoie des emails depuis un script PHP (formulaire de contact, emails de confirmation de commande) sur un hébergement mutualisé OVH, ces emails utilisent le serveur de messagerie OVH interne. Ils ne seront pas signés DKIM sauf si vous configurez explicitement un relais SMTP.

Pour ces emails transactionnels, la pratique recommandée est d’utiliser un service d’envoi externe via SMTP (Brevo, Mailjet, Postmark, SendGrid). Ces services signent les emails en DKIM avec votre domaine et offrent un suivi de délivrabilité. La plupart proposent des formules gratuites jusqu’à quelques centaines d’emails par jour, suffisantes pour un site PME.

FAQ

Voir les questions fréquentes en tête de guide.


SPF, DKIM et DMARC bloquent l’usurpation exacte de votre domaine. Mais le phishing ne se résume pas à cette seule technique. Les domaines sosies (votre-entreprise.fr, votreentreprise-info.com), les comptes légitimes compromis, les services cloud détournés (Google Forms, SharePoint) : autant d’approches que la configuration DNS ne peut pas contrer.

C’est pourquoi la protection technique et la formation des équipes sont complémentaires. Un employé qui reconnaît une tentative de phishing, même quand l’email semble parfaitement légitime, reste la meilleure ligne de défense pour les attaques que les filtres techniques laissent passer.

Votre configuration SPF, DKIM et DMARC est en place. Pour compléter cette protection technique par la formation de vos équipes, découvrez comment nophi.sh simule des attaques de phishing réalistes pour mesurer et améliorer la vigilance de vos collaborateurs — sans avoir à gérer l’infrastructure vous-même.