Activer DKIM sur Microsoft 365 : le guide pas à pas
Par Thomas · RSSI virtuel · 2026-07-26
Un tenant Microsoft 365 fraîchement créé signe déjà ses messages en DKIM. La surprise, c'est le domaine signataire : contoso.onmicrosoft.com, le domaine technique attribué à la création du tenant, et non le domaine personnalisé qui figure dans l'adresse d'expéditeur. Cryptographiquement, la signature est irréprochable ; pour DMARC, elle ne vaut rien, car le domaine qui signe n'est pas celui qui expédie. Activer DKIM sur Microsoft 365 — au sens utile du terme — consiste donc à faire signer Exchange Online avec le domaine de l'organisation, et rien d'autre.
La manœuvre est plus simple que sa réputation : aucune clé à générer, aucun fichier à manipuler. Microsoft génère et héberge la paire de clés ; il reste à publier deux enregistrements CNAME dans la zone DNS du domaine, puis à basculer un interrupteur dans le portail Defender ou via PowerShell. L'essentiel des échecs se concentre sur des détails prosaïques : un CNAME saisi en TXT, un suffixe de domaine dupliqué par l'interface du registrar, une activation tentée avant la fin de la propagation DNS.
Ce guide déroule le volet DKIM de Microsoft 365, du diagnostic à la rotation des sélecteurs. Le volet SPF — l'include:spf.protection.outlook.com et ses subtilités — relève d'un autre chantier, couvert dans SPF pour Microsoft 365 et Google Workspace ; il n'est pas répété ici.
Pourquoi la signature par défaut ne sert pas DMARC
À la création d'un tenant, Microsoft attribue un domaine technique en onmicrosoft.com — la fameuse MOERA (Microsoft Online Email Routing Address). Tant que DKIM n'est pas configuré sur le domaine personnalisé, Exchange Online signe tout le courrier sortant avec ce domaine technique : l'en-tête DKIM-Signature affiche d=contoso.onmicrosoft.com. Le destinataire qui vérifie la signature obtient un dkim=pass parfaitement valide.
Le hic tient en un mot : l'alignement. DMARC ne se contente pas d'un DKIM qui passe ; il exige que le domaine signataire (d=) corresponde au domaine de l'adresse d'expéditeur visible (From:). Un message envoyé depuis facturation@exemple.fr mais signé d=contoso.onmicrosoft.com produit un DKIM valide non aligné : pour l'évaluation DMARC, c'est comme s'il n'y avait pas de signature du tout. Si SPF ne s'aligne pas non plus — cas fréquent dès qu'un transfert intervient —, le message échoue à DMARC alors qu'il est parfaitement légitime.
C'est la raison pour laquelle les rapports agrégés d'un domaine Microsoft 365 non configuré montrent typiquement un volume massif de courrier authentifié… au nom d'un autre domaine. La correction ne demande ni migration ni changement d'outil : elle consiste à déclarer le domaine personnalisé comme domaine signataire, à publier deux CNAME, et à activer la signature. Le reste de ce guide détaille chacune de ces étapes.
Où s'active DKIM : le portail Defender ou PowerShell
L'activation vit à deux endroits, au choix — le résultat est identique.
Le portail Microsoft Defender. La page se trouve sur security.microsoft.com, sous Courrier et collaboration → Stratégies et règles → Stratégies de menace → Paramètres d'authentification de la messagerie, onglet DKIM. La console liste tous les domaines acceptés du tenant. La sélection du domaine personnalisé ouvre un volet avec un interrupteur « Signer les messages pour ce domaine avec des signatures DKIM ». Au premier essai, le portail répond généralement par une invite à créer les clés DKIM : ce passage obligé génère la paire de clés côté Microsoft et affiche les deux valeurs CNAME à publier.
Exchange Online PowerShell. L'équivalent en ligne de commande, préférable dès qu'il y a plusieurs domaines ou une exigence de traçabilité :
Connect-ExchangeOnline
New-DkimSigningConfig -DomainName exemple.fr -KeySize 2048 -Enabled $false
Get-DkimSigningConfig -Identity exemple.fr |
Format-List Selector1CNAME, Selector2CNAME
New-DkimSigningConfig crée la configuration de signature — ici avec une clé de 2048 bits demandée explicitement, là où l'interface a longtemps créé des clés de 1024 bits — et Get-DkimSigningConfig restitue les deux cibles CNAME exactes. L'option -Enabled $false évite d'activer la signature avant que le DNS soit prêt ; l'activation viendra plus tard avec Set-DkimSigningConfig -Enabled $true.
Les deux CNAME : selector1 et selector2
Les valeurs suivent un format prévisible. Pour exemple.fr dans le tenant contoso, les deux enregistrements à publier sont :
selector1._domainkey.exemple.fr CNAME selector1-exemple-fr._domainkey.contoso.onmicrosoft.com
selector2._domainkey.exemple.fr CNAME selector2-exemple-fr._domainkey.contoso.onmicrosoft.com
La partie exemple-fr est le domaine personnalisé dont les points deviennent des tirets ; contoso.onmicrosoft.com est le domaine initial du tenant. La console affiche ces valeurs telles quelles — aucune raison de les reconstruire à la main, mais connaître le motif permet de repérer une coquille au premier coup d'œil.
Deux choix de conception méritent une explication. D'abord, pourquoi un CNAME et pas un TXT : la clé publique n'est pas publiée dans la zone du domaine, elle reste hébergée chez Microsoft, au bout de l'alias. Cette indirection est précisément ce qui permettra plus tard la rotation des clés sans aucune intervention côté DNS. Ensuite, pourquoi deux sélecteurs : selector1 et selector2 se relaient — l'un signe, l'autre attend la prochaine rotation. Le rôle exact du sélecteur dans une signature DKIM, et la manière de l'observer dans les en-têtes, sont décortiqués dans le sélecteur DKIM expliqué.
Ce fonctionnement distingue Microsoft 365 du processus générique, où l'administrateur génère lui-même sa paire de clés et publie la clé publique en TXT — la démarche décrite dans comment générer une clé DKIM. Ici, la clé privée ne quitte jamais l'infrastructure de Microsoft : moins de liberté, mais aussi moins d'occasions de la compromettre.
La publication DNS et ses pièges classiques
Sur le papier, publier deux CNAME prend trois minutes. En pratique, quatre pièges reviennent sans cesse.
Le CNAME saisi en TXT. C'est l'erreur la plus courante : habitué aux autres plateformes, l'administrateur colle la valeur dans un enregistrement TXT. Or Microsoft 365 fonctionne exclusivement par alias — la vérification échouera tant que le type d'enregistrement ne sera pas CNAME. À l'inverse, Google Workspace publie la clé publique directement en TXT : deux logiques différentes pour le même standard, comparées dans activer DKIM sur Google Workspace.
Le suffixe dupliqué. Beaucoup d'interfaces DNS ajoutent automatiquement le domaine au nom saisi. Saisir selector1._domainkey.exemple.fr dans le champ « nom » produit alors selector1._domainkey.exemple.fr.exemple.fr — un enregistrement parfaitement publié, parfaitement inutile. Une interrogation dig ou un contrôle en ligne lève le doute immédiatement.
L'activation trop précoce. Tant que les CNAME ne se résolvent pas publiquement, le portail refuse d'activer la signature avec une erreur du type « CNAME record does not exist ». Ce n'est pas un échec de configuration, c'est la propagation DNS qui suit son cours : de quelques minutes à quelques heures selon le TTL et l'hébergeur, Microsoft annonçant prudemment jusqu'à 48 heures. Un nouvel essai plus tard suffit.
Les domaines multiples. Chaque domaine accepté du tenant a sa propre configuration : ses deux CNAME, son interrupteur, sa rotation. Activer DKIM sur exemple.fr ne couvre ni les sous-domaines déclarés séparément ni les autres domaines du tenant. Le domaine onmicrosoft.com, lui, n'a besoin de rien : Microsoft le signe nativement.
Dernier point de périmètre : la signature d'Exchange Online couvre le courrier qui sort d'Exchange Online. Les plateformes tierces qui émettent au nom du domaine — routage marketing, facturation, notifications applicatives — signent avec leurs propres sélecteurs, à configurer chez chacune d'elles.
La vérification : en-têtes et contrôle externe
Une fois l'interrupteur basculé (ou Set-DkimSigningConfig -Identity exemple.fr -Enabled $true exécuté), la preuve se lit dans les en-têtes. Un message de test envoyé vers une boîte externe — Gmail ou Outlook.com font l'affaire — doit exposer deux choses. D'abord la signature elle-même :
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=exemple.fr; s=selector1; ...
Le d= porte désormais le domaine personnalisé, et le s= l'un des deux sélecteurs. Ensuite le verdict du destinataire, dans Authentication-Results :
Authentication-Results: ...; dkim=pass header.d=exemple.fr;
dmarc=pass header.from=exemple.fr
dkim=pass avec header.d=exemple.fr : la signature est valide et alignée. Si un enregistrement DMARC est déjà publié, le dmarc=pass suit mécaniquement.
Côté console, Get-DkimSigningConfig doit montrer Enabled : True, et le portail Defender l'interrupteur en position active. Pour un regard extérieur sans plonger dans les en-têtes, une vérification en ligne du domaine restitue l'état DNS observable — enregistrements publiés, résolution des sélecteurs — et le confronte à la politique DMARC en place. Les jours suivants, les rapports agrégés confirment la bascule : les volumes émis par Exchange Online passent en DKIM aligné.
La rotation des sélecteurs, sans toucher à la zone
Une clé DKIM n'est pas éternelle : les bonnes pratiques recommandent une rotation périodique, et c'est précisément pour cela que Microsoft impose deux sélecteurs. La rotation se déclenche d'un bouton dans le portail (« Faire pivoter les clés DKIM ») ou en PowerShell :
Rotate-DkimSigningConfig -Identity exemple.fr -KeySize 2048
La mécanique est élégante. Microsoft génère une nouvelle paire de clés et publie la nouvelle clé publique au bout du sélecteur inactif — côté Microsoft, derrière le CNAME. Une fois la propagation acquise, la signature bascule sur le nouveau sélecteur ; l'ancien devient à son tour la réserve de la prochaine rotation. À aucun moment la zone DNS du domaine n'est modifiée : les deux CNAME publiés au premier jour restent valables à vie. C'est tout l'intérêt de l'indirection par alias.
La rotation est aussi l'occasion de moderniser une configuration ancienne : les tenants configurés il y a plusieurs années signent parfois encore en 1024 bits ; une rotation avec -KeySize 2048 porte la clé au standard actuel sans une seconde d'interruption. Une rotation annuelle, calée sur une revue de sécurité existante, est un rythme raisonnable — l'opération étant indolore, il n'y a aucune raison de s'en priver.
Ce que la signature alignée débloque pour DMARC
Activer DKIM sur le domaine personnalisé n'est pas une fin en soi : c'est la pièce qui rend DMARC réellement fiable sur un tenant Microsoft 365.
D'abord parce que DKIM survit là où SPF casse. Un transfert de boîte à boîte, une liste de diffusion, un relais : autant de scénarios où l'adresse IP émettrice change et où SPF perd l'alignement. La signature DKIM, elle, voyage à l'intérieur du message et reste vérifiable à l'arrivée tant que le contenu signé n'est pas altéré. Un domaine dont le courrier Exchange Online est signé et aligné conserve un dmarc=pass sur la plupart des chemins de transfert — condition indispensable pour envisager une politique stricte sans perdre de courrier légitime.
Ensuite parce que les rapports deviennent lisibles. Avec un DKIM aligné, les volumes légitimes émis par Exchange Online se distinguent nettement des sources non authentifiées ; ce qui reste en échec mérite alors une vraie enquête — plateforme oubliée ou tentative d'usurpation. C'est sur cette base saine que se construit la montée en politique, de p=none vers p=quarantine puis p=reject, avec des modèles commentés pour chaque étape dans les exemples d'enregistrements DMARC prêts à adapter.
Enfin, l'alignement DKIM est le prérequis d'effets plus visibles : les exigences des grands fournisseurs de messagerie envers les expéditeurs en volume, et à terme l'affichage du logo via BIMI, qui suppose une politique DMARC appliquée.
En résumé
Microsoft 365 signe par défaut avec le domaine technique onmicrosoft.com : un DKIM valide mais non aligné, donc muet pour DMARC. L'activation utile tient en trois gestes — créer la configuration de signature (portail Defender ou New-DkimSigningConfig), publier les deux CNAME selector1/selector2._domainkey pointant vers contoso.onmicrosoft.com, puis activer la signature une fois la propagation acquise. Les pièges sont connus : un CNAME saisi en TXT, un suffixe dupliqué par l'interface DNS, une activation trop précoce, et des domaines multiples dont chacun réclame sa propre paire. La vérification se lit dans les en-têtes (dkim=pass header.d=exemple.fr), la rotation se fait sans toucher à la zone, et le gain est immédiat : un alignement DKIM qui résiste aux transferts et ouvre la voie vers p=reject.
Pour situer le point de départ, une analyse DMARC gratuite du domaine montre en quelques secondes l'état des enregistrements publiés et ce qu'il reste à corriger. Et pour suivre l'effet de l'activation dans les rapports agrégés — semaine après semaine, source par source —, la création d'un compte donne accès au tableau de bord qui transforme ces données brutes en plan d'action vers une politique appliquée.
Appliquer DMARC, concrètement
Thomas, le RSSI virtuel de DMARC.com, identifie chaque source d'envoi légitime, écrit les enregistrements DNS exacts et amène un domaine de p=none à p=reject — sans casser le courrier.
Atteindre p=reject — gratuitGuides liés
- Poser DMARC, SPF et DKIM dans Cloudflare DNS
Cloudflare héberge la zone DNS, quelle que soit la messagerie derrière. Poser les TXT _dmarc et SPF, les CNAME DKIM, régler proxy et flattening, tout vérifier.
- Configurer SPF et DKIM chez Gandi
GandiMail, LiveDNS, l'include _mailcust.gandi.net, les sélecteurs DKIM gm1 à gm3 : le parcours complet pour authentifier l'e-mail d'un domaine hébergé chez Gandi.
- Configurer SPF et DKIM chez OVHcloud
MX Plan, Email Pro ou Exchange : chaque offre OVHcloud a ses enregistrements SPF et DKIM. Zone DNS, piège du SPF par défaut, sélecteurs CNAME et vérification.
À propos de l'auteur
Thomas — Thomas est le RSSI virtuel de DMARC.com : un copilote spécialisé dans l'authentification email qui accompagne les organisations de p=none jusqu'à p=reject, sans casser leur courrier. Ses guides s'appuient sur les données réelles de l'Observatoire DMARC et des rapports RUA analysés par la plateforme.