Configurer DKIM dans Office 365 (Microsoft 365)

Que vérifier avant d’activer DKIM ?

Confirmez que le domaine personnalisé est ajouté et accepté dans Microsoft 365, que vous pouvez modifier sa zone DNS faisant autorité et que vous pouvez gérer l’authentification des e-mails dans Microsoft Defender. Recensez chaque service qui envoie avec ce domaine dans l’adresse From visible : Microsoft 365, plateformes marketing, outils de tickets, scanners et relais sur site.

Si un appareil ou une application s’authentifie sur Exchange Online, configurez et testez le chemin de soumission avec le guide des réglages SMTP d’Office 365 avant de voir le statut DKIM comme preuve que l’application peut envoyer.

Les consignes SPF actuelles de Microsoft exigent un seul enregistrement TXT SPF par domaine, sous la limite de dix requêtes DNS du protocole. Ne publiez pas de seconde politique SPF pour Microsoft 365. Fusionnez les sources autorisées dans la politique existante et ne retirez une source qu’après avoir confirmé qu’elle n’envoie plus.

Ce guide couvre un domaine personnalisé qui envoie via le cloud commercial Microsoft 365. Les environnements gouvernementaux, opérés en Chine, hybrides et sur site peuvent utiliser d’autres routes ou valeurs. Suivez les consignes officielles pour le tenant et le chemin réel.

Copiez les deux cibles CNAME DKIM du portail Microsoft Defender ou Exchange Online PowerShell pour le domaine configuré. Noms de tenant, identifiants de partition et formats de cible peuvent varier. Ne collez jamais dans le DNS de production des valeurs d’un tutoriel ou d’un autre tenant.

Quelle méthode choisir ?

Utilisez le portail Microsoft Defender pour une configuration interactive et un affichage clair du statut. Le chemin documenté est Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM. Sélectionnez le domaine pour voir son état de signature et les deux CNAME attendus.

Utilisez Exchange Online PowerShell pour une administration répétable sur plusieurs domaines, ou si le portail n’affiche pas clairement les valeurs. Les cibles DNS viennent toujours du tenant. PowerShell ne rend pas les cibles d’exemple réutilisables.

Configurer DKIM dans Office 365

1. Confirmez le domaine et les sources d’envoi

Vérifiez que les utilisateurs envoient depuis le domaine personnalisé et listez chaque service sortant autorisé. Déterminez si Microsoft 365 envoie directement, reçoit les e-mails d’un système sur site ou relaie via une autre passerelle. Cela fixe ce que la politique SPF doit autoriser et le chemin à tester.

2. Une seule politique SPF

À la racine du domaine, créez ou modifiez un unique enregistrement TXT commençant par v=spf1. Pour une configuration simple du cloud commercial Microsoft 365, autorisez Microsoft avec include:spf.protection.outlook.com, gardez les autres expéditeurs légitimes et terminez par le comportement d’échec choisi pour le domaine.

N’aplatissez pas l’include de Microsoft en adresses IP copiées. Microsoft peut changer les adresses derrière l’include. Vérifiez le résultat avec le test SPF de Palisade, nombre de requêtes DNS compris.

3. Ouvrez la page DKIM de Microsoft Defender

Dans Microsoft Defender, allez dans Email & collaboration > Policies & rules > Threat policies > Email authentication settings, puis ouvrez l’onglet DKIM. Sélectionnez le domaine. Le guide DKIM actuel de Microsoft décrit ce chemin et le flux de statut du domaine.

4. Copiez les deux CNAME propres au tenant

Si le domaine n’a pas de clés, créez-les dans le portail quand il le propose. Copiez les deux paires propriétaire et cible CNAME affichées. Les noms commencent en général par selector1._domainkey et selector2._domainkey, mais les cibles sont propres au tenant.

Microsoft a changé en 2025 le format de cible des nouveaux domaines personnalisés. Raison de plus pour utiliser les valeurs affichées par le tenant actuel plutôt que reconstruire une cible d’après un ancien exemple.

Pour récupérer les valeurs et l’état actuels dans Exchange Online PowerShell, remplacez example.com par le domaine :

Get-DkimSigningConfig -Identity example.com | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

Utilisez les valeurs Selector1CNAME et Selector2CNAME renvoyées pour ce domaine. Le guide de configuration DKIM de Microsoft décrit la commande et le flux actuel du portail.

5. Publiez les deux CNAME et attendez la résolution

Créez les deux CNAME dans la zone DNS faisant autorité. Certains fournisseurs DNS ajoutent le domaine racine d’office : saisissez le nom relatif si l’interface l’attend. Résolvez publiquement chaque nom complet et comparez la cible renvoyée, caractère par caractère, avec Microsoft Defender.

Utilisez le test DKIM de Palisade pour chaque sélecteur. N’activez pas la signature si un seul sélecteur se résout. Microsoft utilise deux sélecteurs pour alterner les clés sans couper l’authentification.

6. Activez la signature DKIM et testez en externe

Revenez au volet du domaine et activez Sign messages for this domain with DKIM signatures. Si Microsoft signale encore un CNAME manquant, revérifiez les deux CNAME publics et attendez les caches DNS avant de changer des valeurs correctes.

Une fois l’état de signature valide, envoyez un nouveau message par la route de production vers une boîte hors du tenant Microsoft 365. Inspectez les en-têtes ajoutés par le destinataire plutôt qu’un message livré en interne. Le test de délivrabilité e-mail gratuit fournit une adresse externe pour cela : envoyez-y un message, il analyse les en-têtes du destinataire et indique le résultat DKIM, le domaine et le sélecteur de signature, et si la signature est alignée avec votre domaine From.

Statuts DKIM de Microsoft Defender

Quel effet sur DMARC ?

DMARC vérifie si un identifiant SPF ou DKIM authentifié est aligné avec le domaine From visible. Selon la norme DMARC actuelle, l’une ou l’autre voie alignée peut réussir. La signature DKIM de Microsoft 365 donne aux e-mails du domaine une voie alignée stable si la signature utilise ce domaine.

Pour publier la politique, suivez le guide de configuration DMARC pour Microsoft 365 : recensez les expéditeurs, configurez les rapports et avancez vers l’application sans perturber les e-mails légitimes.

SPF peut aussi s’aligner, mais le transfert casse souvent SPF et des relais complexes peuvent changer l’identité MAIL FROM. Configurez et validez DKIM même si SPF réussit déjà. Les consignes de déploiement DMARC de Microsoft recommandent d’identifier les expéditeurs légitimes avant de renforcer la politique.

Vérifiez la politique publiée via le test DMARC de Palisade. Gardez un seul enregistrement à _dmarc et les adresses de rapport lors des changements prévus, et attendez les données agrégées pour durcir l’application.

Valider la configuration

Testez le DNS public

Résolvez le TXT SPF racine et les deux CNAME de sélecteur DKIM depuis l’extérieur du fournisseur DNS. La recherche d’enregistrement TXT lit la valeur SPF racine, et le test DKIM interroge selector1 et selector2 quand vous les saisissez. Confirmez une seule politique SPF, le bon include Microsoft pour l’environnement, un nombre de requêtes sûr, et deux sélecteurs pointant vers les valeurs exactes du tenant.

Vérifiez le statut Microsoft 365

Ouvrez le domaine dans l’onglet DKIM de Defender. Il doit afficher un état valide avec la signature activée. Des statuts comme NoDKIMKeys ou CnameMissing signalent un prérequis du tenant ou du DNS, sans prouver le comportement d’un message ultérieur.

Inspectez un message livré

Envoyez un nouveau message vers une boîte externe et inspectez le champ Authentication-Results ajouté par le destinataire. La RFC 8601 définit ce champ et sa frontière de confiance. Confirmez dkim=pass, notez le domaine DKIM d= et comparez-le au domaine From visible. Notez aussi les résultats SPF, MAIL FROM et DMARC.

Testez chaque chemin vraiment différent : boîtes cloud directes, applications, relais et transport hybride. Un message Outlook réussi ne valide pas chaque service qui utilise le domaine.

Lisez les rapports DMARC

Examinez les rapports agrégés une fois le trafic normal visible. Confirmez le volume de Microsoft 365, le domaine DKIM observé, l’identité SPF, l’alignement et le traitement. Séparez le trafic Microsoft des expéditeurs tiers pour qu’un tenant bien configuré ne masque pas les échecs d’une autre plateforme.

Dépannage

Le domaine a plusieurs enregistrements SPF

Fusionnez les mécanismes autorisés dans une seule politique à la racine. Ne supprimez un enregistrement qu’après avoir identifié son service. Plusieurs politiques SPF peuvent produire une erreur permanente au lieu d’autoriser les deux services.

SPF excède la limite de requêtes DNS

Recensez les include, redirect, mécanismes MX et autres termes qui génèrent des requêtes. Retirez les expéditeurs retraités et repensez la politique avec les responsables des services. N’aplatissez pas l’include de Microsoft en adresses fixes : elles peuvent changer.

Microsoft Defender affiche CnameMissing

Résolvez publiquement les deux noms de sélecteur et comparez leurs cibles aux valeurs actuelles du tenant. Cherchez un suffixe de domaine répété, une coquille, un proxy ou un CNAME créé dans la mauvaise zone DNS. Attendez les caches avant de remplacer encore des valeurs correctes.

Seul selector1 se résout

Publiez aussi selector2. Les deux CNAME sont requis pour la rotation des clés gérée par Microsoft. Vérifiez que le second nom n’a pas écrasé le premier et qu’aucun enregistrement en conflit n’existe au même nom.

DKIM réussit mais DMARC échoue

Comparez le d= DKIM au domaine From visible. Le message peut utiliser le domaine par défaut du tenant, un autre domaine personnalisé ou une autre route. Corrigez l’identité d’envoi ou le périmètre d’authentification sans affaiblir la politique DMARC.

Vérifiez le domaine Microsoft 365 au-delà du portail

Lancez le test de conformité Microsoft de Palisade une fois le statut Defender valide. Il évalue les exigences d’authentification publiques, mais ne peut voir les paramètres privés du tenant, prouver que chaque route Microsoft ou tierce a utilisé l’identité voulue, ni garantir les livraisons futures.

Microsoft 365 n’est souvent qu’un expéditeur parmi d’autres pour un domaine. L’agent DMARC de Palisade transforme les rapports agrégés en liste priorisée de problèmes d’expéditeurs, SPF, DKIM et DMARC. Il détecte quand l’authentification et l’alignement indiquent qu’un domaine est prêt pour l’étape de politique suivante, puis propose le passage à votre équipe, qui l’examine et l’applique. Ce flux avec humain dans la boucle vous aide à avancer vers p=reject en gardant la main sur la politique. Une authentification plus forte protège vos domaines et soutient la délivrabilité.

Palisade n’administre pas Microsoft 365, ne touche pas seul au DNS, ne contrôle pas les destinataires, ne garantit pas la boîte de réception et ne change aucune politique DMARC sans accord humain.

Commencez avec Palisade