SPF, DKIM et DMARC sur Microsoft 365 : configurer sans bloquer vos mails

Pour protéger un domaine utilisé avec Microsoft 365, il faut identifier tous ses expéditeurs, configurer SPF et DKIM, puis vérifier leur alignement avec l’adresse visible avant de durcir DMARC. Outlook n’est souvent qu’un des chemins d’envoi. Le logiciel de facturation, le formulaire du site ou le CRM peuvent utiliser d’autres serveurs.

Une facture peut partir avec votre adresse visible tout en étant envoyée et signée par le domaine de votre logiciel de gestion. Tant que cet écart reste invisible, une politique DMARC plus stricte peut faire apparaître le problème au mauvais moment : lorsque le client attend sa facture. Le test doit suivre chaque chemin d’envoi jusqu’au message reçu.

SPF, DKIM et DMARC ne vérifient pas la même chose

SPF indique quels serveurs sont autorisés à envoyer pour un domaine utilisé dans l’enveloppe du message. DKIM permet de vérifier une signature associée à un domaine et l’intégrité des parties signées. DMARC relie cette authentification au domaine de l’adresse From, celle que le destinataire voit, et publie une politique de traitement des échecs.

Les détails de SPF relèvent de la RFC 7208. Dans la pratique, gardez trois domaines distincts dans votre relevé : celui de l’adresse visible, celui évalué par SPF et celui de la signature DKIM. La confusion entre ces trois valeurs explique de nombreux messages « authentifiés » qui échouent pourtant à DMARC.

1. Recenser les expéditeurs avant de modifier le DNS

Demandez aux équipes ce qui envoie des messages avec votre domaine. La comptabilité peut utiliser un outil que l’administrateur Microsoft 365 n’a jamais configuré. Un formulaire peut envoyer un message de confirmation, et un prestataire une campagne occasionnelle. Chaque flux légitime doit avoir un propriétaire capable de fournir un message de test.

Voici un inventaire fictif, à adapter à votre entreprise :

Ajoutez le domaine visible, le domaine d’enveloppe et le domaine DKIM réellement observés. Le nom du logiciel ne suffit pas : son mode d’envoi peut changer selon sa configuration.

Conservez la zone DNS actuelle, les valeurs concernées et la procédure de retour. Vérifiez également qui possède le compte du fournisseur DNS et comment y accéder si la messagerie est indisponible. La réversibilité du prestataire inclut ce type d’accès critique.

2. Vérifier SPF sans écraser les autres services

Un même nom de domaine ne doit pas publier plusieurs enregistrements SPF concurrents. Si plusieurs services utilisent ce domaine d’enveloppe, leurs autorisations doivent être organisées dans un SPF cohérent. Microsoft donne, pour un cas où Microsoft 365 est le seul expéditeur concerné, cet exemple :

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

Ne remplacez pas votre SPF existant par cette ligne sans inventaire. Un relais, un outil métier ou un autre service légitime pourrait être oublié. La documentation SPF Microsoft distingue ces configurations.

SPF limite à dix certains mécanismes et modificateurs déclenchant des recherches DNS lors de son évaluation. Les inclusions imbriquées comptent aussi : neuf include visibles ne prouvent pas que vous respectez la limite. Un résultat permerror doit être diagnostiqué, pas corrigé en autorisant arbitrairement tous les serveurs.

Une séparation par sous-domaines peut clarifier les usages, à condition de configurer également les adresses, signatures et politiques de ces flux. Elle demande un choix d’architecture ; ajouter un sous-domaine dans le DNS ne reconfigure pas le CRM.

3. Récupérer les valeurs DKIM de votre propre domaine

Pour un domaine personnalisé Microsoft 365, récupérez les CNAME demandés par votre environnement, publiez-les chez votre fournisseur DNS, puis activez la signature lorsque les enregistrements sont reconnus. Vérifiez ensuite un message réellement émis. La présence des CNAME seule ne prouve pas qu’il est signé comme prévu.

Microsoft a fait évoluer le format des valeurs pour les nouveaux domaines personnalisés à partir de mai 2025. Les anciens exemples ne sont donc pas des valeurs universelles à reconstruire de mémoire. Utilisez les valeurs affichées pour votre domaine dans le portail ou retournées par les outils d’administration appropriés. Configuration DKIM Microsoft.

Pour le logiciel de facturation et le CRM, suivez leur procédure de signature avec votre domaine. Activer DKIM dans Microsoft 365 ne signe pas automatiquement les messages envoyés par une plateforme indépendante.

4. Comprendre l’alignement avec un exemple

Imaginons un CRM qui affiche commercial@example.com, mais utilise bounce.example.net dans l’enveloppe et signe avec example.net. Même si SPF et DKIM réussissent pour example.net, cela ne prouve pas que le message est autorisé à se présenter comme example.com.

Voici des en-têtes fictifs et simplifiés, tels qu’un système de réception de confiance pourrait rendre compte de ce cas. Les domaines example.com et example.net servent uniquement à l’illustration.

From: commercial@example.com
Authentication-Results: mx.destinataire.example;
  spf=pass smtp.mailfrom=bounce.example.net;
  dkim=pass header.d=example.net;
  dmarc=fail header.from=example.com

Les deux pass concernent example.net, alors que l’adresse visible présente example.com. La correction consiste ici à faire signer le CRM avec le domaine personnalisé autorisé. Après configuration et envoi d’un nouveau message, le résultat attendu serait :

From: commercial@example.com
Authentication-Results: mx.destinataire.example;
  spf=pass smtp.mailfrom=bounce.example.net;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

SPF peut donc rester non aligné dans cet exemple : la signature DKIM valide et alignée suffit. DMARC n’exige pas que les deux voies réussissent. L’alignement peut être strict ou souple selon les paramètres publiés. La documentation DMARC Microsoft décrit ces contrôles.

L’alignement souple et l’alignement strict changent aussi le diagnostic. Dans un exemple où example.com est le domaine organisationnel commun, une signature valide d=mail.example.com peut être alignée avec un From en example.com en mode souple ; ces domaines différents ne sont pas alignés en mode strict. Les paramètres adkim et aspf règlent ces modes. La RFC DMARC les distingue de la politique p. Passer à p=reject et passer à un alignement strict sont donc deux changements séparés à tester.

Pour vérifier votre message, utilisez les résultats ajoutés par votre système de réception de confiance. Une ligne arbitraire insérée par l’expéditeur ne constitue pas une preuve indépendante. Ne partagez pas des en-têtes complets publiquement : ils peuvent contenir des adresses, des identifiants et des informations de routage.

Lors d’un transfert, le serveur qui réémet peut faire échouer SPF pour le domaine initial. Une signature DKIM alignée peut préserver la réussite de DMARC si les parties signées restent intactes. Testez les transferts réellement utilisés : ils ne sont pas tous équivalents.

5. Passer de l’observation à une politique plus stricte

Rapprochez les rapports de l’inventaire des expéditeurs. Un échec sur une source inconnue et un échec sur le logiciel de facturation n’appellent pas la même action. La source inconnue doit être qualifiée ; le flux métier légitime doit être corrigé. N’ajoutez pas une IP dans SPF au seul motif qu’elle apparaît dans un rapport.

L’exemple suivant est illustratif, pour le domaine réservé example.com. Il suppose que l’adresse de réception a été préparée. Ce n’est pas un enregistrement à copier tel quel dans votre zone :

Nom : _dmarc.example.com
Type : TXT
Valeur : v=DMARC1; p=none; rua=mailto:dmarc@example.com

Les rapports agrégés sont définis par la RFC 9990. Ils servent notamment à observer des sources et des résultats d’authentification. Ils ne constituent pas un relevé exhaustif de chaque message envoyé : tous les destinataires ne fournissent pas nécessairement les mêmes rapports. Une destination de rapports extérieure au domaine peut aussi nécessiter une autorisation DNS spécifique.

La RFC 9989, publiée en mai 2026, remplace l’ancienne RFC 7489 et retire le paramètre pct. Les récepteurs et les guides peuvent évoluer à des rythmes différents. Ne fondez donc pas votre transition sur l’idée qu’un pct=10 garantira partout le traitement strict d’exactement 10 % des échecs. Pilotez la progression par les flux identifiés, leurs tests et les rapports reçus.

Il n’existe pas un nombre universel de jours à attendre. Une entreprise qui envoie ses factures en fin de mois doit inclure ce cycle dans son observation ou organiser un essai représentatif. Si la politique du domaine couvre des sous-domaines, ceux-ci doivent également être inventoriés avant de la renforcer.

Le but n’est pas de faire disparaître tous les échecs des rapports : des messages non autorisés peuvent continuer à échouer, et c’est attendu. Il faut savoir les distinguer des envois légitimes encore mal configurés. Les destinataires conservent leurs règles locales ; même p=none n’oblige pas à accepter un message jugé indésirable pour une autre raison.

La recette avant de considérer le travail terminé

Faites envoyer un message par chacun des flux retenus, vers des boîtes de test autorisées. Conservez l’heure, le service d’origine, les en-têtes utiles et le résultat. Vérifiez aussi les réponses, les transferts réellement utilisés et les messages avec pièces jointes métier représentatives.

Les contrôles DNS suivants sont en lecture seule. Ils utilisent example.com ; remplacez-le par le domaine que vous êtes autorisé à administrer :

Resolve-DnsName -Type TXT example.com
Resolve-DnsName -Type TXT _dmarc.example.com
Resolve-DnsName -Type CNAME selector1._domainkey.example.com
Resolve-DnsName -Type CNAME selector2._domainkey.example.com

Ces commandes montrent des enregistrements DNS. Elles ne vérifient pas à elles seules la signature, l’alignement ou la réception d’un message. Associez chaque constat à un test d’envoi, et tenez compte des caches DNS avant d’interpréter des résultats différents.

Deux limites à expliquer aux équipes

Pourquoi un message authentifié arrive-t-il encore en spam ?

L’authentification n’est qu’une partie du traitement. La réputation, le comportement d’envoi et les politiques du destinataire interviennent aussi. Les consignes Gmail aux expéditeurs distinguent plusieurs exigences. Un résultat DMARC réussi n’est pas une garantie de placement en boîte principale.

DMARC empêche-t-il toutes les usurpations ?

Non. Un attaquant peut utiliser un domaine ressemblant au vôtre, un nom d’affichage trompeur ou un compte réellement compromis. La protection du domaine complète le MFA des comptes, les contrôles de paiement et la sécurité des données.

Le résultat à remettre aux équipes

Conservez un relevé par flux : responsable, adresse visible, domaine SPF, domaine DKIM, résultat DMARC, destinataire de test et date. Ajoutez la politique publiée et la personne autorisée à la modifier. Ce relevé permet de contrôler l’ajout du prochain CRM ou outil de facturation sans reprendre l’enquête à zéro.

Si un flux reste inexpliqué, un diagnostic Initial Infra peut partir de ses en-têtes et de sa configuration d’envoi. La messagerie sera alors examinée à partir d’un message précis, pas seulement d’un score affiché par un vérificateur DNS.

Sources vérifiées le 9 octobre 2026. Les domaines, flux et en-têtes des exemples sont fictifs.