Configurer Microsoft 365 (SPF, DKIM, DMARC) chez OVH

Quatre enregistrements à créer dans ta zone DNS OVH : un TXT pour le SPF, deux CNAME pour le DKIM, un TXT pour le DMARC. Le principe : Microsoft génère les valeurs, tu les colles dans l'espace client OVHcloud, puis tu reviens chez Microsoft activer la signature. Le SPF et le DMARC sont des valeurs fixes que tu peux recopier ; les deux cibles DKIM, non — elles sont propres à ton compte Microsoft et il faut aller les chercher dans le portail Defender. Compte 30 minutes devant l'écran, et jusqu'à 24 h de propagation chez OVH. Vérifié sur la documentation officielle le 05/09/2026.

Ces enregistrements disent aux serveurs qui reçoivent tes emails que Microsoft a le droit d'envoyer en ton nom, et leur donnent une consigne quand quelqu'un d'autre essaie. Ça ne garantit pas l'arrivée en boîte de réception — le contenu de tes emails et ta réputation d'expéditeur comptent au moins autant — mais sans ça, n'importe qui peut écrire à ta place.

Le point qui rend cette page utile. Microsoft publie une page dédiée à OVH pour connecter ton domaine : elle pose la vérification, le MX, l'autodiscover, le SPF et les enregistrements Teams — et s'arrête là. Ni DKIM ni DMARC n'y figurent. OVH, de son côté, n'a aucun guide consacré à Microsoft 365, et n'est pas dans la liste des registrars où Microsoft peut poser les enregistrements à ta place. Si tu as suivi l'assistant « Ajouter un domaine » jusqu'à l'écran « La configuration du domaine est terminée », tes emails partent, mais ils ne sont signés par rien. Les deux CNAME DKIM et le TXT DMARC sont à ta charge, à 100 %.

Ce qu'on ne fait pas : on ne touche jamais à ta zone DNS. On lit, on prescrit, tu colles — dans ton espace client, avec tes accès.

Une précision : cette page concerne Microsoft 365 souscrit chez Microsoft (Exchange Online). Si tes boîtes sont une offre Hosted Exchange ou Email Pro d'OVH, ce n'est pas la même chose — OVH y active le DKIM en un clic et le SPF de référence est include:mx.ovh.com : c'est le guide OVH générique qu'il te faut (lien en bas de page).

Les valeurs à copier-coller

1. SPF — dire que Microsoft a le droit d'envoyer

Ce que tu dois remplacer : rien, si Microsoft 365 est ton seul outil d'envoi. C'est la valeur exacte que Microsoft prescrit, y compris sur sa page dédiée à OVH. Si tu envoies aussi depuis un autre service — une plateforme de campagnes, ton site, un logiciel de facturation — ajoute son include: dans la même ligne, par exemple v=spf1 include:spf.protection.outlook.com include:spf.brevo.com -all.

Sur le -all de la fin. Microsoft recommande le -all (rejet strict) parce qu'il recommande DKIM et DMARC dans la foulée. OVH, dans son guide SPF actuel, recommande aussi -all — avec la même réserve : ne le choisis qu'une fois certain d'avoir listé toutes tes sources d'envoi légitimes. Si tu as un doute, commence par ~all, lis tes rapports DMARC quelques semaines, puis durcis. Un détail que la plupart des guides ratent : du point de vue de DMARC, ~all et -all sont un échec SPF identique — la différence ne joue que pour les serveurs qui évaluent le SPF sans passer par DMARC.

⚠️ Un domaine ne doit avoir qu'une seule ligne SPF. Deux lignes v=spf1, et le SPF ne fonctionne plus du tout. Chez OVH, l'enregistrement peut apparaître sous deux types différents dans le tableau, TXT ou SPF : filtre sur les deux avant de conclure que tu n'en as pas. Si une ligne existe déjà, tu la modifies — voir l'erreur n°3.

2. DKIM — deux CNAME, et aucune valeur à recopier d'ici

Ce que tu dois remplacer : les deux cibles, intégralement. Les sous-domaines selector1._domainkey et selector2._domainkey sont les mêmes pour tout le monde ; les cibles, non — et elles ne se déduisent pas de ton nom de domaine.

Voici pourquoi. Depuis mai 2025, Microsoft utilise un nouveau format pour les domaines personnalisés ajoutés après cette date :

selector1-TON-DOMAINE-AVEC-DES-TIRETS._domainkey.TON-PREFIXE-ONMICROSOFT.X-v1.dkim.mail.microsoft

Le X au milieu est un caractère attribué par Microsoft (n, r, autre chose selon les cas). Sa documentation est explicite : il est « déterminé par la logique de routage interne de Microsoft et n'est pas configurable ». Il ne se devine pas. Les domaines ajoutés avant mai 2025 continuent d'utiliser l'ancien format :

selector1-TON-DOMAINE-AVEC-DES-TIRETS._domainkey.TON-PREFIXE-ONMICROSOFT.onmicrosoft.com

Et les deux formats « ne peuvent pas coexister pour le même sélecteur ». D'où la consigne unique : copie les deux valeurs affichées par ton portail, ne les reconstruis jamais à la main à partir d'un tutoriel — y compris celui-ci, qui te donne des modèles et pas des valeurs.

Le point final, chez OVH, n'est pas une coquetterie. La zone DNS OVH utilise la notation relative : sans point à la fin, OVH colle ton nom de domaine derrière la cible. OVH le dit dans son propre guide DKIM pour des CNAME de ce type : « il faut bien conserver le point à la fin pour ponctuer la valeur ». C'est l'erreur n°1 plus bas.

Si tu n'utilises que ton domaine en .onmicrosoft.com (celui créé à l'inscription), tu n'as rien à faire : Microsoft signe déjà ces messages tout seul. Dès que tu envoies depuis ton vrai domaine, la configuration manuelle est obligatoire.

3. DMARC — la consigne donnée aux boîtes de réception

Ce que tu dois remplacer : TON-ADRESSE@TON-DOMAINE.fr par une adresse que tu relèves vraiment. C'est là que tu recevras les rapports — un DMARC sans rua=, c'est un rapport que tu ne liras jamais.

Pourquoi p=none pour commencer : ça veut dire « observe et raconte-moi ». Personne n'est bloqué, et tu reçois les rapports. Tu regardes pendant 2 à 4 semaines, tu vérifies que tous tes outils légitimes sont bien reconnus, et seulement après tu durcis vers p=quarantine, puis p=reject. Microsoft et OVH disent la même chose, chacun à sa façon : « commencez par p=none et surveillez les résultats » côté Microsoft, « il est conseillé de configurer p=none et d'effectuer une analyse des rapports pendant plusieurs semaines » côté OVH.

Deux mauvais exemples à ne pas copier. La documentation Microsoft illustre le DMARC avec v=DMARC1; p=reject; pct=100; rua=…; ruf=…, et le guide OVH avec p=quarantine; pct=100; aspf=s. Les deux commencent en mode blocage, avant d'avoir lu un seul rapport. Et les deux utilisent pct=, un paramètre retiré de la norme DMARC par la RFC 9989, publiée en mai 2026 — les serveurs à jour l'ignorent, donc un pct= partiel ne te donne aucune montée en douceur, juste ta politique complète pendant que tu crois y aller progressivement. OVH propose un formulaire assisté de type DMARC qui contient un champ pct= : tu peux l'utiliser, mais laisse ce champ vide — ou passe par un TXT brut avec la valeur ci-dessus, c'est plus simple.

Si tu envoies plus de 5 000 messages par jour vers des adresses Outlook.com, Hotmail ou Live, ce n'est plus facultatif : Microsoft exige de ces expéditeurs SPF et DKIM qui passent, plus un DMARC publié avec au minimum p=none. Sans ça, les messages sont rejetés avec une erreur 550 5.7.515.

⚠️ Un domaine ne doit avoir qu'un seul enregistrement DMARC. Si tu en avais déjà un, tu le modifies, tu n'en ajoutes pas un second.

Le chemin de clics

Côté Microsoft — récupérer les deux valeurs DKIM

Prérequis : ton domaine doit déjà être ajouté et vérifié dans Microsoft 365 (centre d'administration → Paramètres → Domaines). Microsoft ne propose la signature DKIM qu'une fois le domaine « ajouté avec succès ».

1. Va sur le portail Microsoft Defender : security.microsoft.com/authentication. (Chemin complet dans le menu : Email & collaboration → Stratégies & règles → Stratégies de menace → Paramètres d'authentification Email.)
2. Ouvre l'onglet DKIM, repère la ligne de ton domaine et essaie de faire glisser la bascule de Désactivé vers Activé.
3. Une boîte de dialogue « Erreur client » s'affiche. C'est normal, et c'est même le but : elle contient les deux valeurs CNAME à créer, noyées dans beaucoup d'autre texte. Clique sur OK.
4. Le statut du domaine passe à CnameMissing. Clique n'importe où sur la ligne (sauf sur la case à cocher et la bascule) pour ouvrir le volet de détail.
5. Dans la section Publier les CNAMEs, clique sur Copier. Note aussi la date de dernière vérification. Laisse ce volet ouvert, tu vas y revenir.

Si le statut affiche « Aucune clé DKIM enregistrée pour ce domaine », le volet de détail propose un bouton Créer des clés DKIM en bas : clique dessus d'abord, les deux valeurs apparaissent ensuite.

Tu préfères la ligne de commande ? Dans Exchange Online PowerShell, cette commande donne directement les deux valeurs — remplace tondomaine.fr par le tien :

Get-DkimSigningConfig -Identity tondomaine.fr | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

Côté OVH — créer les entrées

1. Connecte-toi à ton espace client OVHcloud.
2. Web Cloud → Noms de domaine → sélectionne ton domaine → onglet Zone DNS.
3. Regarde d'abord le tableau. Utilise le filtre par type sur TXT et SPF : y a-t-il déjà une ligne v=spf1 ? Si oui, tu vas la modifier, pas en ajouter une.
4. Bouton Ajouter une entrée, au-dessus du tableau. Un formulaire s'ouvre.
5. Choisis le type : CNAME pour les deux DKIM, TXT pour le SPF et le DMARC.
6. Renseigne le champ Sous-domaine, puis le champ Cible (pour un CNAME) ou Valeur (pour un TXT). Laisse le TTL sur Par défaut.
7. Clique sur Ajouter. Une seule étape, pas de récapitulatif.

Si ton écran ouvre un assistant en plusieurs étapes (Suivant, puis Confirmer), c'est l'ancienne version de l'interface : mêmes champs, même résultat.

Le champ « Sous-domaine » attend la partie gauche uniquement. OVH ajoute ton nom de domaine à la fin : tape selector1._domainkey, pas selector1._domainkey.tondomaine.fr. Pour le SPF, laisse le champ vide. Pour le DMARC, _dmarc et rien d'autre.

Le champ « Cible » d'un CNAME veut un point à la fin. Colle la valeur Microsoft, puis ajoute un . final si elle n'en a pas. Sans lui, OVH enregistre …dkim.mail.microsoft.tondomaine.fr, qui n'existe pas.

Pour modifier ta ligne SPF existante plutôt qu'en créer une seconde : sur la ligne concernée, ouvre le menu d'actions ⋮ à droite, puis Modifier l'entrée. La ligne se déploie en formulaire ; ajoute include:spf.protection.outlook.com avant le ~all ou le -all, et confirme.

Une précaution spécifique à OVH : le formulaire assisté de type SPF propose une case Inclure les serveurs e-mail OVH, qui écrit include:mx.ovh.com. Elle sert aux boîtes OVH, pas à Microsoft 365. Ne la coche que si tu envoies aussi depuis un service e-mail OVH — et dans ce cas, mets spf.protection.outlook.com dans le champ Serveurs supplémentaires à autoriser (include) du même formulaire, pour n'avoir qu'une seule ligne.

Retour côté Microsoft — activer

Une fois les deux CNAME créés et propagés, reviens dans le volet de détail du domaine et active la bascule Signer les messages pour ce domaine avec des signatures DKIM. Une boîte de dialogue t'avertit que « la synchronisation du changement de statut peut prendre plusieurs minutes ». Si les CNAME sont vus, le statut passe à Signature des messages DKIM pour ce domaine et le bouton Faire pivoter les clés DKIM apparaît. Si Microsoft renvoie l'erreur client, ce n'est pas forcément raté : attends une heure et réessaie avant de tout défaire. Microsoft lui-même conseille de « vérifier les fautes de frappe chez le registrar (facile avec les tirets, les points et les tirets bas !) », d'attendre encore un peu, et de recommencer.

Pour vérifier de bout en bout : envoie un email vers une adresse Gmail ou Outlook.com, ouvre les en-têtes, et cherche dkim=pass avec header.d=tondomaine.fr dans la ligne Authentication-Results.

Les 3 erreurs qu'on voit le plus souvent sur cette configuration

1. Le point final oublié sur la cible des CNAME DKIM

C'est l'erreur reine de la combinaison Microsoft 365 + OVH, et elle est invisible à l'œil nu. La documentation OVH le dit : « lorsque la cible de votre enregistrement est une URL, pensez à ponctuer celle-ci. En effet, si vous ne le faites pas, votre nom de domaine sera automatiquement ajouté à la fin de votre cible. » Microsoft le sait aussi — sa page dédiée à OVH le rappelle pour le MX et l'autodiscover (« assurez-vous que cette entrée se termine par un point ») — mais sa documentation DKIM, générique, n'en parle pas. Résultat : tu copies la valeur Defender, elle n'a pas de point, tu la colles telle quelle, et OVH publie selector1-…dkim.mail.microsoft.tondomaine.fr.

Comment tu le reconnais : le portail Defender reste sur CnameMissing alors que tes deux CNAME sont bien dans la zone. Dans le tableau OVH, regarde la colonne de la cible : ton propre nom de domaine y est collé à la fin.

Le correctif : ⋮ → Modifier l'entrée, ajoute le point à la fin de la cible, confirme, attends une heure, réactive la bascule.

Dans la même famille, mais à l'envers : saisir selector1._domainkey.tondomaine.fr dans le champ Sous-domaine crée selector1._domainkey.tondomaine.fr.tondomaine.fr. Là, le correctif est de raccourcir. Même symptôme, deux corrections opposées selon le champ.

2. Reconstruire les cibles DKIM à partir d'un tutoriel

C'est l'erreur la plus coûteuse en temps, parce qu'elle a l'air de marcher. Tu trouves le schéma selector1-mondomaine-fr._domainkey.montenant.onmicrosoft.com, tu remplaces par tes valeurs, tu crées les CNAME — avec le point final, même — et Microsoft refuse indéfiniment d'activer DKIM.

Deux raisons possibles. Soit ton domaine a été ajouté après mai 2025 et utilise le nouveau format, avec ce caractère que tu ne peux pas deviner. Soit le tutoriel se trompe sur le préfixe .onmicrosoft.com, qui est celui de ton tenant, pas celui de ton domaine.

Comment tu le reconnais : les deux CNAME existent, ils sont parfaitement formés, le point final est là, et le portail Defender continue de refuser avec la même erreur.

Le correctif : supprime tes deux CNAME reconstruits (⋮ → Supprimer l'entrée), retourne dans le portail Defender ou lance la commande PowerShell, et copie les valeurs affichées. Ce sont les seules qui vaudront.

3. Une deuxième ligne SPF, parce qu'OVH en avait déjà une

Beaucoup de domaines OVH ont un SPF posé au moment de la commande d'une offre e-mail ou d'un hébergement : v=spf1 include:mx.ovh.com ~all. Tu suis la page Microsoft, tu ajoutes un TXT v=spf1 include:spf.protection.outlook.com -all, et te voilà avec deux lignes v=spf1. Le SPF ne fonctionne plus du tout, ni pour Microsoft, ni pour ce qui reste chez OVH.

Le piège en plus, propre à OVH : l'ancienne ligne est parfois stockée sous le type SPF et non TXT. Si tu filtres le tableau sur TXT, tu ne la vois pas, tu conclus qu'il n'y en a pas, et tu en crées une. La documentation OVH le dit elle-même : « comme l'enregistrement peut apparaître à deux endroits différents, filtrez sur les types TXT et SPF ».

Comment tu le reconnais : ton scan affiche « plusieurs SPF détectés », ou tes rapports montrent un SPF en permerror alors que chaque ligne, prise séparément, a l'air correcte. Certains destinataires t'acceptent, d'autres non.

Le correctif : une seule ligne, tous les include: dedans. Si tu n'as plus de boîte OVH, la ligne est celle de la section 1. Si tu envoies encore depuis un service OVH — un site sur un hébergement mutualisé, par exemple — la ligne fusionnée est v=spf1 include:spf.protection.outlook.com include:mx.ovh.com -all : une composition à partir des deux valeurs officielles, pas une ligne publiée telle quelle par l'un ou l'autre.

Combien de temps avant que ça prenne effet

• Dans l'espace client OVH : la modification est enregistrée immédiatement.
• Sur Internet : OVH annonce 24 heures maximum de propagation (« 4 à 24 heures » dans son guide SPF). Microsoft, sur sa page OVH, parle d'« environ 15 minutes » en général — les deux sont compatibles : c'est souvent rapide, mais ne conclus rien avant 24 h.
• Côté Microsoft : la détection des CNAME prend « quelques minutes (ou peut-être plus) » ; Microsoft ne publie aucun délai ferme pour l'activation DKIM. Après une rotation de clés, en revanche, il en donne un : 4 jours (96 heures) avant que la nouvelle clé signe.
• Pour les rapports DMARC : les premiers arrivent 24 à 72 h après la publication de l'enregistrement, puis environ une fois par jour.

Le conseil pratique : crée les quatre entrées d'un coup, va faire autre chose une heure, puis reviens activer la bascule DKIM. La repasser douze fois dans les cinq premières minutes ne fait qu'ajouter du doute.

Pour aller plus loin

• Configurer SPF, DKIM et DMARC chez OVH
• Configurer Microsoft 365 (SPF, DKIM, DMARC) chez IONOS
• Configurer Google Workspace (SPF, DKIM, DMARC) chez OVH
• Passer son DMARC en p=reject sans casser ses emails