DKIM, SPF et DMARC pour Microsoft 365 : la mise en place complète

Microsoft 365 signe le courrier sortant dès le premier jour, mais avec son domaine onmicrosoft.com, pas avec le vôtre. DMARC ne compte qu’une signature faite au nom du domaine affiché dans l’adresse d’expédition : un domaine personnalisé sans DKIM ne repose donc que sur SPF, et échoue dès qu’un message est transféré. Ce guide suit la documentation de Microsoft, relue le 14 novembre 2026.

1. SPF

Un enregistrement TXT sur le domaine :

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

Si d’autres services envoient en votre nom, ajoutez leur include: au même enregistrement : un seul enregistrement SPF par domaine, dix requêtes DNS au plus. Le vérificateur SPF gratuit les compte.

2. Trouver vos deux valeurs CNAME

DKIM dans Microsoft 365 utilise deux enregistrements CNAME, pas un enregistrement TXT contenant une clé. Microsoft garde les clés et les renouvelle ; votre DNS ne fait que pointer vers elles.

Dans le portail Microsoft Defender, allez dans E-mail et collaboration → Stratégies et règles → Stratégies de menace → Paramètres d’authentification des e-mails (Email authentication settings), ouvrez l’onglet DKIM et sélectionnez votre domaine. Le détail affiche les deux enregistrements à publier. Ou bien, dans Exchange Online PowerShell :

Get-DkimSigningConfig -Identity votredomaine.example | Format-List Selector1CNAME,Selector2CNAME

Les noms d’hôte sont les mêmes pour tout le monde : selector1._domainkey et selector2._domainkey. Les cibles, non. Les domaines anciens pointent vers un nom qui finit par .onmicrosoft.com ; les plus récents vers un nom qui finit par -v1.dkim.mail.microsoft, avec un caractère attribué par Microsoft. Copiez les valeurs affichées pour votre domaine ; ne les construisez pas à la main d’après un exemple.

3. Publier les deux enregistrements

Créez les deux CNAME chez votre hébergeur DNS. Les deux sont nécessaires, même si un seul sélecteur signe à la fois : l’autre sert au renouvellement des clés. Publier la clé dans un enregistrement TXT à la place ne fonctionne pas.

Certains hébergeurs DNS ajoutent d’eux-mêmes le nom de domaine à l’hôte : saisissez alors selector1._domainkey, et non selector1._domainkey.votredomaine.example.

4. Activer la signature

De retour sur l’onglet DKIM, basculez l’interrupteur de votre domaine sur Activé. Si Microsoft ne voit pas encore les CNAME, il le dit et les affiche de nouveau : attendez que la modification DNS se propage, puis réessayez. Une fois en place, l’état indique que les signatures DKIM sont apposées pour ce domaine.

5. Vérifier un vrai message

Envoyez un message à une boîte extérieure à votre organisation et lisez ses en-têtes : dkim=pass avec header.d= égal à votre domaine, pas à onmicrosoft.com. L’analyseur d’en-têtes d’e-mail les lit pour vous, et le vérificateur DKIM interroge selector1 et selector2.

6. DMARC

Commencez par observer :

_dmarc  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@votredomaine.example"

Lisez les rapports pendant deux semaines : ils montrent chaque service qui envoie en votre nom, et ceux qui échouent. Puis suivez De p=none à p=reject.

Ce qui se passe mal

L’interrupteur ne reste pas activé : les CNAME sont absents, mal saisis ou pas encore visibles. L’état CnameMissing dit la même chose.
Seul selector1 a été publié : la signature fonctionne aujourd’hui et casse au prochain renouvellement de clé. Publiez les deux.
Un CNAME construit d’après un ancien exemple : le format a changé pour les domaines récents. Utilisez les valeurs du portail.
DKIM passe avec onmicrosoft.com : la signature avec le domaine personnalisé n’est pas activée, donc DMARC échoue encore sur le courrier transféré.
Un autre service envoie en votre nom : un outil de lettres d’information ou de facturation a besoin de son propre DKIM avec votre domaine ; les enregistrements de Microsoft ne le couvrent pas.

Une fois tout publié, la vérification complète de l’e-mail lit SPF, DKIM et DMARC d’un coup.