Configurer DMARC avec SPF et DKIM dans Microsoft 365 sans bloquer les courriels légitimes

DMARC protège le domaine, pas seulement la boîte aux lettres

Une politique DMARC indique aux systèmes destinataires quoi faire lorsqu’un message utilisant votre domaine visible dans From ne réussit pas une authentification alignée. Elle rend l’usurpation du domaine beaucoup moins rentable, mais une politique trop stricte publiée avant l’inventaire peut aussi placer en quarantaine ou rejeter des factures, alertes, formulaires Web et campagnes légitimes.

La séquence sûre est simple : trouver toutes les sources, corriger SPF, activer DKIM pour chaque domaine d’envoi, publier DMARC en observation, traiter les écarts, puis renforcer la politique. L’objectif final est p=reject, pas un p=none laissé indéfiniment.

• Microsoft — Configurer DMARC dans Microsoft 365 ↗
• Guide connexe — Fin de SMTP AUTH Basic →

Comprendre l’alignement SPF, DKIM et DMARC

Un message n’a pas besoin de réussir SPF et DKIM pour réussir DMARC : un seul mécanisme réussi et aligné suffit. En alignement relaxé, le mode par défaut, un sous-domaine partageant le même domaine organisationnel peut s’aligner. Le mode strict exige une correspondance exacte et doit être adopté seulement si tous les flux le justifient.

Cette nuance explique pourquoi ajouter l’adresse IP d’un fournisseur dans SPF ne règle pas toujours DMARC. Si son Return-Path utilise son propre domaine, SPF peut réussir sans s’aligner; une signature DKIM avec votre domaine devient alors le meilleur chemin.

• RFC 7489 — DMARC ↗

1. Inventorier toutes les sources avant de toucher à p=reject

Ne limitez pas l’inventaire aux boîtes Exchange Online. Cherchez les imprimantes, applications métiers, systèmes de surveillance, sites Web, CRM, RH, billetterie, campagnes marketing, fournisseurs de signature, relais locaux et plateformes infonuagiques qui utilisent le domaine dans From.

Pour chaque source, notez le domaine From, le MAIL FROM, la signature DKIM, l’adresse IP, le propriétaire, le volume et le scénario de test. Un flux sans propriétaire ne devrait pas retarder indéfiniment le projet : isolez-le, confirmez sa nécessité et décidez de le corriger ou de le retirer.

Connect-ExchangeOnline

Get-AcceptedDomain |
  Select-Object DomainName,DomainType,Default |
  Sort-Object DomainName

Get-DkimSigningConfig |
  Select-Object Domain,Enabled,Status,Selector1CNAME,Selector2CNAME

Get-OutboundConnector |
  Select-Object Name,Enabled,RecipientDomains,SmartHosts,TlsSettings

Get-InboundConnector |
  Select-Object Name,Enabled,SenderDomains,SenderIPAddresses,ConnectorType

2. Construire un SPF lisible et complet

Un domaine doit publier un seul enregistrement SPF TXT. Si Exchange Online est l’unique source, la base habituelle est v=spf1 include:spf.protection.outlook.com -all. Ajoutez seulement les sources réellement autorisées et fusionnez les mécanismes dans ce même enregistrement; deux enregistrements SPF causent une erreur permanente.

SPF autorise au maximum dix recherches DNS pendant l’évaluation. Les include peuvent eux-mêmes en déclencher plusieurs. Ne copiez pas une longue liste d’include sans calculer le chemin complet et ne remplacez pas mécaniquement ~all par -all avant d’avoir testé chaque expéditeur.

# Microsoft 365 seulement
@  TXT  "v=spf1 include:spf.protection.outlook.com -all"

# Domaine qui ne doit jamais envoyer de courriel
@  TXT  "v=spf1 -all"

• Microsoft — Configurer SPF pour un domaine personnalisé ↗

3. Activer DKIM sur chaque domaine d’envoi Microsoft 365

Microsoft 365 signe automatiquement le domaine initial onmicrosoft.com, mais un domaine personnalisé doit être configuré. Récupérez les deux valeurs CNAME depuis le portail Defender ou Exchange Online PowerShell; ne fabriquez pas les cibles à partir d’un ancien exemple, car Microsoft utilise aussi un format dynamique pour les nouveaux domaines.

Publiez selector1 et selector2 dans le DNS, attendez leur résolution, puis activez la signature. Un seul sélecteur signe à la fois; l’autre permet la rotation. Envoyez ensuite un message à un système externe et confirmez dans les en-têtes que d= correspond au domaine From et que Authentication-Results indique dkim=pass.

$domain = 'contoso.com'

$config = Get-DkimSigningConfig -Identity $domain -ErrorAction SilentlyContinue
if (-not $config) {
  New-DkimSigningConfig -DomainName $domain -Enabled $false
}

Get-DkimSigningConfig -Identity $domain |
  Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

# Après publication et résolution des deux CNAME
Set-DkimSigningConfig -Identity $domain -Enabled $true

# Rotation planifiée des clés
Rotate-DkimSigningConfig -Identity $domain -KeySize 2048

• Microsoft — Configurer DKIM dans Microsoft 365 ↗

4. Donner un sous-domaine aux fournisseurs externes

Une plateforme de marketing ou une application SaaS que vous ne contrôlez pas directement ne devrait pas utiliser le domaine principal si un sous-domaine est possible. marketing.contoso.com ou notifications.contoso.com sépare la réputation, simplifie SPF et permet une politique DMARC adaptée.

Demandez au fournisseur un Return-Path personnalisé et une signature DKIM avec ce sous-domaine. Publiez uniquement les clés et mécanismes documentés par le fournisseur. Un simple SPF au domaine principal laisse souvent l’alignement dépendre d’un détail que le client ne maîtrise pas.

• Un sous-domaine et un propriétaire par grande plateforme d’envoi.
• DKIM avec d= aligné sur le domaine From.
• Return-Path personnalisé lorsque le fournisseur le prend en charge.
• Aucune délégation DNS plus large que nécessaire.
• Procédure de retrait lorsque le contrat prend fin.

5. Commencer DMARC en observation

Publiez un TXT à _dmarc.contoso.com avec p=none et une adresse rua capable de recevoir les rapports agrégés XML. Utilisez une boîte ou un service réservé à ces rapports; une boîte d’utilisateur devient rapidement inutilisable. Les rapports montrent les IP observées, les volumes et les résultats SPF, DKIM et d’alignement.

p=none n’empêche pas chaque destinataire d’appliquer ses propres filtres. Il indique seulement la politique DMARC demandée par le propriétaire du domaine. Gardez cette phase assez longtemps pour couvrir les envois mensuels, mais associez-lui une date de sortie et un responsable.

_dmarc  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@contoso.com; adkim=r; aspf=r; fo=1"

6. Lire les rapports et corriger les écarts

L’objectif n’est pas d’obtenir 100 % de réussite en autorisant tout ce qui apparaît. Distinguez les sources légitimes, les anciens services à retirer et les tentatives d’usurpation. Validez un échantillon d’en-têtes réels, car un rapport agrégé ne raconte pas tout le trajet du message.

7. Passer progressivement à quarantine puis reject

Quand les sources légitimes importantes réussissent DMARC, appliquez p=quarantine à une partie limitée du trafic, augmentez graduellement pct, puis passez à p=reject. Commencez par un domaine ou sous-domaine peu risqué. Surveillez les plaintes, les rapports et les messages tests à chaque palier.

Une politique finale courante utilise p=reject et sp=reject pour les sous-domaines non configurés. Conservez l’alignement relaxé sauf besoin démontré. La valeur pct est une demande au destinataire et son comportement peut varier; elle aide au déploiement, mais ne remplace pas les tests.

# Étape 1 — observation
v=DMARC1; p=none; rua=mailto:dmarc-reports@contoso.com

# Étape 2 — quarantaine limitée
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@contoso.com

# Étape 3 — protection complète
v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:dmarc-reports@contoso.com; adkim=r; aspf=r

8. Protéger aussi les domaines qui n’envoient pas

Les domaines enregistrés pour protéger une marque, mais qui n’envoient aucun courriel, devraient annoncer clairement cette intention. Publiez SPF -all et DMARC p=reject; n’ajoutez pas de clé DKIM. Faites de même pour les sous-domaines inutilisés avec sp=reject sur le domaine parent lorsque l’architecture le permet.

N’oubliez pas les domaines secondaires acceptés dans Microsoft 365. Un domaine sans boîte active peut quand même être très convaincant dans une campagne d’hameçonnage s’il ressemble à votre marque.

@       TXT  "v=spf1 -all"
_dmarc  TXT  "v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:dmarc-reports@contoso.com"

Checklist de mise en production

DMARC ne se résume pas à copier un enregistrement DNS. C’est un projet d’inventaire et de gouvernance du courriel. Lorsqu’on sépare les fournisseurs, qu’on exige DKIM aligné et qu’on utilise les rapports pour décider, p=reject devient une protection prévisible plutôt qu’un pari sur la livraison.

• Tous les domaines From et toutes les sources d’envoi ont un propriétaire.
• Chaque domaine possède un seul SPF et reste sous la limite de dix recherches DNS.
• DKIM est actif et aligné pour Microsoft 365 et chaque fournisseur externe.
• Les sous-domaines séparent les plateformes non contrôlées du domaine principal.
• Les rapports rua sont reçus, analysés et conservés selon une politique claire.
• Les échecs connus ont une décision : corriger, retirer ou accepter temporairement.
• La progression none, quarantine et reject possède des critères de sortie.
• Les domaines sans envoi publient SPF -all et DMARC reject.
• Un test externe confirme SPF, DKIM, DMARC et l’alignement après chaque changement.

• Service — Audit de sécurité Microsoft 365 et Entra ID →
• Guide connexe — Vol de jetons et attaques AiTM →