Configurer DMARC avec Microsoft 365

Microsoft 365 authentifie vos emails avec les mêmes trois briques que partout ailleurs, mais son DKIM ne fonctionne pas comme celui des autres : il repose sur deux enregistrements CNAME pointant vers votre tenant, et non sur une clé publiée directement dans votre zone.

SPF

Un seul enregistrement TXT SPF par domaine, incluant Exchange Online :

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

Si d’autres services envoient pour ce domaine — un outil de facturation, une plateforme d’emailing, un serveur applicatif — ajoutez leurs mécanismes dans ce même enregistrement. Deux enregistrements SPF sur un domaine est une erreur de configuration qui les invalide tous les deux.

DKIM

Publiez deux CNAME — Microsoft fait tourner les clés entre les deux sélecteurs, il en faut donc bien deux dès le départ :

selector1._domainkey  CNAME  selector1-<domaine-avec-tirets>._domainkey.<tenant>.onmicrosoft.com
selector2._domainkey  CNAME  selector2-<domaine-avec-tirets>._domainkey.<tenant>.onmicrosoft.com

Deux substitutions à faire correctement : <tenant> est le préfixe de votre domaine initial .onmicrosoft.com, et <domaine-avec-tirets> est votre domaine dont les points ont été remplacés par des tirets — exemple.fr devient exemple-fr.

Une fois les CNAME propagés, activez la signature dans le portail Microsoft Defender (Email et collaboration → Stratégies et règles → Stratégies contre les menaces → Paramètres d’authentification de messagerie → DKIM), domaine par domaine. Tant que l’interrupteur est sur « Désactivé », les enregistrements existent et rien n’est signé.

DMARC

Publiez la politique en observation sur _dmarc.votredomaine.com :

v=DMARC1; p=none; rua=mailto:votre-adresse@votredomaine.com

Puis durcissez progressivement, une fois vos expéditeurs légitimes tous identifiés. La méthode, étape par étape.

Erreurs fréquentes avec Microsoft 365

• Les CNAME publiés mais DKIM jamais activé dans le portail : le cas le plus courant, et rien ne le signale côté DNS.
• Le domaine initial onmicrosoft.com n’a pas besoin d’être configuré : il est signé d’office. C’est votre domaine personnalisé qui demande ces enregistrements.
• Les connecteurs sortants et les applications qui relaient par Exchange Online (SMTP authentifié, relais applicatif) n’alignent pas toujours le domaine visible avec celui qui authentifie — un point à vérifier dans les rapports plutôt qu’à supposer.
• Le partage de domaine avec un autre tenant ou une migration en cours produit des échecs d’alignement transitoires qui n’ont rien d’une usurpation : raison de plus pour rester en p=none au début.

Une fois en place, Clarsend lit vos rapports et distingue pour vous les échecs qui viennent de vos propres outils mal configurés de ceux qui viennent d’ailleurs — la seule question qui compte avant de passer en reject.