Microsoft 365 a une particularité qui surprend quand on vient d'une autre messagerie : DKIM se configure avec deux entrées CNAME, pas une entrée TXT. Et elles doivent être publiées avant d'activer la signature, sinon le portail refuse purement et simplement.
Le reste suit la logique habituelle. Si les trois enregistrements ne vous parlent pas encore, commencez par là.
Étape 1 : l'enregistrement SPF
Dans la zone DNS de votre domaine, chez votre registraire et pas dans le portail Microsoft, qui ne gère pas votre domaine sauf si vous l'y avez délégué.
Cherchez d'abord un enregistrement existant commençant par v=spf1 : il ne peut y en avoir qu'un. S'il existe, modifiez-le.
- Type : TXT
- Nom : vide ou
@(domaine racine) - Valeur :
v=spf1 include:spf.protection.outlook.com -all
Avec d'autres services d'envoi, on les ajoute au même enregistrement :
v=spf1 include:spf.protection.outlook.com include:le-service.example -all
Si vous n'êtes pas certain d'avoir recensé tous vos expéditeurs, utilisez ~all le temps de le confirmer par les rapports DMARC, puis passez à -all.
Étape 2 : DKIM, les deux CNAME
L'activation se fait depuis le portail de sécurité Microsoft, dans les réglages d'authentification du courrier, section DKIM. Sélectionnez votre domaine : le portail affiche deux entrées CNAME à créer, du type selector1._domainkey et selector2._domainkey, chacune pointant vers une valeur propre à votre organisation.
L'ordre est impératif :
- Créez les deux entrées CNAME dans votre zone DNS, en recopiant exactement les valeurs affichées.
- Attendez la propagation.
- Ensuite seulement, activez la signature dans le portail.
Si vous activez avant que les entrées soient visibles, Microsoft refuse. C'est la cause de la quasi-totalité des échecs sur cette étape ce n'est pas une erreur de votre part, juste un ordre à respecter.
Étape 3 : DMARC
- Type : TXT
- Nom :
_dmarc - Valeur :
v=DMARC1; p=none; rua=mailto:rapports@votredomaine.fr; fo=1
Mode observation d'abord, toujours. Vous recevez les rapports sans bloquer personne, ce qui vous permet de découvrir les services légitimes que vous auriez oubliés. La progression vers une politique restrictive est détaillée dans quelle politique DMARC choisir.
Vérifier
Testez votre domaine avec notre outil SPF et DMARC une fois la propagation faite.
Puis dans la pratique : envoyez un message depuis votre adresse Microsoft vers une adresse Gmail, ouvrez-le et affichez les détails. La signature doit mentionner votre domaine, pas celui de Microsoft. Si c'est le second, l'étape 2 n'est pas terminée.
Les pièges spécifiques à Microsoft 365
Les connecteurs d'envoi. Une application métier, une imprimante multifonction ou un serveur qui relaie ses e-mails via Microsoft 365 n'apparaît pas toujours dans votre inventaire mental. Ils envoient pourtant en votre nom, et les rapports DMARC les feront remonter c'est justement à ça qu'ils servent.
Les domaines multiples. Chaque domaine personnalisé accepté dans votre organisation a besoin de sa propre configuration complète, DKIM inclus. Un domaine authentifié ne couvre pas les autres.
Les groupes et listes de distribution. Ils réexpédient des messages, ce qui casse SPF au passage même mécanisme qu'une redirection. Là encore, c'est DKIM qui préserve l'authentification.
Ailleurs
Même démarche, autre inclusion SPF : voir les guides pour OVH et Google Workspace.
Et si le problème persiste malgré une configuration correcte, il est probablement ailleurs : mes e-mails arrivent dans les spams, les sept causes.
Publier les entrées, attendre, puis activer. Dans cet ordre, l'opération prend dix minutes. Dans l'autre, elle prend trois tentatives.