SPF, DKIM, DMARC pour Microsoft 365 : la checklist

Pour empêcher qu'un tiers envoie des e-mails au nom de votre domaine Microsoft 365, il faut trois enregistrements DNS qui fonctionnent ensemble : un SPF unique qui autorise Microsoft 365 et vos autres expéditeurs légitimes, la signature DKIM activée pour chaque domaine personnalisé, et une politique DMARC publiée d'abord en observation (p=none), puis durcie progressivement jusqu'à p=reject à l'aide des rapports. Les domaines qui n'envoient jamais d'e-mails se verrouillent, eux, en une seule fois.

L'usurpation du nom de domaine reste l'un des leviers les plus simples de la fraude au virement et de l'hameçonnage ciblé. Microsoft 365 fournit les briques nécessaires, mais SPF et DMARC se publient chez votre hébergeur DNS, et DKIM doit être activé domaine par domaine. Voici la checklist que nous suivons lors d'un audit de sécurité Microsoft 365. Les exemples utilisent des domaines fictifs réservés (entreprise.example).

1. Ce que fait chaque mécanisme

• SPF déclare quels serveurs ont le droit d'envoyer des e-mails pour votre domaine.
• DKIM ajoute à chaque message une signature cryptographique, vérifiable grâce à une clé publique publiée dans votre DNS.
• DMARC indique au serveur destinataire quoi faire d'un message qui échoue (le laisser passer, le mettre en quarantaine ou le rejeter) et vous envoie des rapports.

Le point clé est l'alignement : un message passe DMARC si SPF ou DKIM réussit et si le domaine contrôlé correspond au domaine affiché dans le champ « De ». Un SPF ou un DKIM valide sur un autre domaine ne suffit pas.

2. Avant de toucher au DNS : l'inventaire

• Tous vos domaines : ceux qui envoient des e-mails, les sous-domaines utilisés par des outils tiers, et les domaines parqués qui n'envoient rien (anciennes marques, variantes, domaines défensifs).
• Tous les expéditeurs légitimes : Microsoft 365, outil d'e-mailing, CRM, logiciel de facturation ou de paie, support client, applications métier, imprimantes et scanners.
• Qui administre le DNS, en interne ou chez un prestataire : il n'existe pas d'écran Microsoft 365 qui crée SPF ou DMARC pour vos domaines personnalisés.
• Une boîte ou un service dédié pour recevoir les rapports DMARC.

3. Étape 1 : SPF

• Un seul enregistrement SPF (TXT) par domaine ou sous-domaine. Deux enregistrements SPF sur le même nom provoquent une erreur permanente : SPF échoue.
• Inclure Microsoft 365 avec include:spf.protection.outlook.com, puis vos autres expéditeurs légitimes (include du fournisseur, ou ip4 / ip6 pour vos propres serveurs).
• Rester sous la limite de 10 requêtes DNS. Les mécanismes include, a, mx, exists et redirect comptent, y compris les include imbriqués chez vos fournisseurs ; ip4, ip6 et all ne comptent pas. Au-delà, SPF renvoie une erreur permanente.
• Terminer par -all (échec strict) lorsque DKIM et DMARC sont aussi en place, comme le recommande Microsoft. Ne pas utiliser ?all en production.
• Confier les envois de masse des outils tiers à un sous-domaine dédié (par exemple newsletter.entreprise.example), avec son propre SPF : chaque sous-domaine qui envoie des e-mails a besoin de son propre enregistrement.
• Ne pas « aplatir » l'include de Microsoft 365 en adresses IP : ces adresses changent.

Exemple fictif pour un domaine qui n'envoie que via Microsoft 365 :

entreprise.example.  TXT  "v=spf1 include:spf.protection.outlook.com -all"

4. Étape 2 : DKIM

• Microsoft 365 signe automatiquement les messages avec le domaine initial en onmicrosoft.com, mais pas avec vos domaines personnalisés tant que vous n'avez pas activé DKIM pour chacun d'eux. Sans cela, la signature ne s'aligne pas sur votre domaine.
• Récupérer les valeurs des deux enregistrements dans le portail Microsoft Defender (paramètres d'authentification des e-mails, onglet DKIM) ou avec la commande PowerShell Get-DkimSigningConfig.
• Créer les deux CNAME, selector1._domainkey et selector2._domainkey. Le second sert à la rotation des clés : il est obligatoire. Pour Microsoft 365, ce sont bien des CNAME, pas des TXT.
• Activer la signature une fois les CNAME propagés.
• Depuis mai 2025, les nouveaux domaines reçoivent des cibles CNAME au format dkim.mail.microsoft : recopiez toujours les valeurs affichées par votre portail plutôt qu'un exemple trouvé en ligne.
• Préférer une clé de 2048 bits (1024 bits par défaut). Une rotation peut prendre jusqu'à 96 heures pour s'appliquer.
• Activer DKIM aussi pour chaque sous-domaine qui envoie des e-mails, et demander à chaque outil tiers de signer avec votre domaine.

5. Étape 3 : DMARC, du mode observation au rejet

L'enregistrement se publie en TXT sur _dmarc.<votre-domaine>. Version de départ (fictive) :

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

Le déploiement se fait par paliers :

1. Inventorier les domaines et les expéditeurs légitimes.
2. Publier un SPF unique, sous la limite de 10 requêtes DNS.
3. Activer DKIM sur chaque domaine qui envoie des e-mails.
4. Publier DMARC en p=none avec une adresse rua : aucun impact sur la distribution, mais vous recevez les rapports agrégés. Laissez tourner au moins un cycle d'activité complet (paie, facturation, campagnes marketing) pour voir passer tous les expéditeurs.
5. Corriger chaque expéditeur légitime qui échoue ou n'est pas aligné, ou le déplacer sur un sous-domaine. Tant qu'un flux légitime échoue, revenir à cette étape.
6. Passer en p=quarantine : les messages en échec vont en courrier indésirable. La montée peut être progressive avec pct (par exemple 10, 25, 50, 75 puis 100). Si un e-mail légitime est bloqué, corriger et revenir au palier précédent.
7. Passer en p=reject : les messages en échec sont refusés. C'est l'objectif final.
8. Surveiller les rapports en continu : un nouvel outil SaaS non déclaré se repère immédiatement.

Bon réflexe : commencer par les sous-domaines à faible volume et traiter le domaine principal en dernier. Un sous-domaine sans enregistrement propre hérite de la politique DMARC du domaine parent.

6. Les domaines qui n'envoient pas d'e-mails

Un domaine parqué est une cible facile, précisément parce que personne ne le surveille. Verrouillez-le en une fois, sans enregistrement DKIM :

ancienne-marque.example.          TXT  "v=spf1 -all"
_dmarc.ancienne-marque.example.   TXT  "v=DMARC1; p=reject;"

Le domaine initial en onmicrosoft.com mérite le même traitement s'il ne sert pas à envoyer des e-mails : son DNS étant géré par Microsoft, son enregistrement DMARC s'ajoute depuis le centre d'administration Microsoft 365.

7. Lire les rapports DMARC

• Les rapports agrégés (rua) sont des fichiers XML quotidiens envoyés par les fournisseurs de messagerie. Utilisez une boîte ou un groupe dédié, ou un service d'analyse DMARC : les fichiers bruts sont illisibles à la main.
• Microsoft 365 envoie des rapports agrégés mais pas de rapports forensiques (ruf), et seulement pour les domaines dont le MX pointe directement vers Microsoft 365.
• Si l'adresse rua se trouve sur un autre domaine que celui protégé, ce domaine doit publier un enregistrement d'autorisation (<domaine-protégé>._report._dmarc.<domaine-destinataire>).

8. Côté réception : appliquer la politique DMARC des autres

Votre propre DMARC protège votre marque à l'extérieur. Pour les e-mails entrants, vérifiez dans les stratégies anti-hameçonnage d'Exchange Online Protection et de Microsoft Defender pour Office 365 que Microsoft 365 respecte la politique DMARC des expéditeurs (quarantaine ou rejet) lorsqu'un message est détecté comme usurpé. Dans les en-têtes, dmarc=bestguesspass signifie que le domaine expéditeur ne publie aucun DMARC.

9. Les erreurs fréquentes

• Deux enregistrements SPF sur le même domaine, après l'ajout d'un outil.
• Un SPF qui dépasse 10 requêtes DNS à cause des include imbriqués des fournisseurs.
• DKIM jamais activé sur le domaine personnalisé : les messages restent signés avec le domaine onmicrosoft.com, sans alignement.
• Un seul CNAME DKIM publié au lieu de deux, ou des TXT à la place des CNAME.
• DMARC laissé indéfiniment en p=none, sans personne pour lire les rapports.
• Un passage direct à p=reject sans inventaire : factures ou fiches de paie bloquées.
• Des domaines parqués et des sous-domaines oubliés.
• Un outil d'e-mailing qui envoie depuis le domaine principal au lieu d'un sous-domaine dédié.

10. Checklist récapitulative

Ce que vérifie un audit

L'authentification des e-mails n'est qu'une partie de la protection de la messagerie : règles de transfert automatique vers l'extérieur, protections anti-hameçonnage, MFA des comptes et journalisation complètent le dispositif. Notre audit de sécurité Microsoft 365 contrôle SPF, DKIM et DMARC domaine par domaine, en lecture seule, et livre un plan de correction priorisé, accompagné d'une journée de transfert de compétences pour vos équipes. Pour les autres erreurs de configuration fréquentes, lisez sécurité Microsoft 365 : les erreurs qui reviennent le plus souvent. Pour entraîner vos équipes à repérer les e-mails frauduleux, voir notre sensibilisation au phishing. En cas de compte compromis ou de fraude en cours, contactez notre réponse à incident.

Questions fréquentes

Sources

• Microsoft Learn, configurer SPF pour Microsoft 365.
• Microsoft Learn, configurer DKIM pour Microsoft 365.
• Microsoft Learn, configurer DMARC pour Microsoft 365.

Pages consultées le 7 octobre 2026. Les menus des portails Microsoft évoluent souvent : en cas d'écart, la documentation Microsoft fait foi.