Microsoft 365 / Enregistrements DNS e-mail : vérifier MX, SPF, DKIM et DMARC

Pour les emails Microsoft 365, les enregistrements DNS (Domain Name System) dirigent les messages entrants et prennent en charge l'authentification des messages sortants. Un enregistrement de serveur de messagerie (MX) identifie le serveur récepteur ; Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), et Domain-based Message Authentication, Reporting, and Conformance (DMARC) fournissent différentes vérifications d'authentification et des informations de politique. Vérifiez la propriété du domaine et inventoriez les services d'envoi Microsoft 365 et externes avant de modifier ces enregistrements.

Rôles des quatre enregistrements

Le guide Microsoft de déploiement de l’authentification des e-mails explique comment configurer SPF, DKIM et DMARC pour les domaines personnalisés. La réussite de SPF ou de DKIM ne suffit pas toujours pour réussir DMARC : le domaine authentifié doit aussi être aligné avec le domaine visible de l’expéditeur.

SPF déclare quelles sources d'envoi sont autorisées. Avec DKIM, l'expéditeur utilise une clé privée pour signer des parties du message, et le destinataire utilise une clé publique publiée via DNS pour vérifier la signature. DMARC vérifie l'alignement avec le domaine visible dans le champ From et publie la politique de traitement des échecs demandée ainsi que la destination des rapports. Ces capacités d'authentification sont incluses dans la protection intégrée pour les boîtes aux lettres cloud ; d'autres fonctionnalités de Defender peuvent nécessiter des licences supplémentaires.

SPF vérifie le domaine utilisé dans MAIL FROM, l'adresse de l'expéditeur de l'enveloppe utilisée entre les serveurs de messagerie. Cela peut différer de l'adresse From affichée au lecteur. Un domaine de signature DKIM peut également appartenir au fournisseur de services. Un service de gestion de la relation client (CRM) pourrait donc passer SPF et DKIM avec le domaine de son fournisseur mais tout de même échouer à DMARC pour le domaine de l'entreprise affiché dans From. L'exigence clé est qu'au moins un résultat SPF aligné ou DKIM aligné soit réussi.

L'alignement peut être relâché (le même domaine organisationnel, en autorisant les sous-domaines) ou strict (une correspondance exacte du nom de domaine). Les balises optionnelles aspf et adkim contrôlent l'alignement SPF et DKIM séparément ; toutes deux sont par défaut relâchées (r). Vérifiez ces modes lorsqu'un service d'envoi utilise un sous-domaine.

Enquêter sur le chemin d'envoi avant la configuration

• E-mails envoyés par les employés depuis Exchange Online
• E-mails envoyés par des systèmes externes tels que les formulaires de contact sur le site Web, les CRM, les services marketing et les périphériques multifonctions
• Services d'envoi qui utilisent des sous-domaines séparément
• Le chemin à travers une passerelle de sécurité des e-mails ou un serveur relais

Si la source d'envoi est omise, les e-mails légitimes peuvent être rejetés après le renforcement de SPF, DKIM et DMARC. Supprimez les sources d'envoi qui ne sont pas utilisées et authentifiez les services requis selon les directives officielles du fournisseur respectif.

Ordre de vérification dans Microsoft 365

1. Dans le centre d'administration Microsoft 365, ouvrez le domaine cible dans [Paramètres] → [Domaines] et vérifiez l'état de la configuration DNS. Utilisez les valeurs MX indiquées dans l'assistant de domaine pour ce domaine.

2. Vérifiez les enregistrements SPF TXT actuels auprès de votre fournisseur d'hébergement DNS. Si des sources d'envoi en dehors de Microsoft 365 doivent être incluses, intégrez-les aux valeurs existantes.
3. Dans les paramètres d'authentification du courrier du portail Microsoft Defender, vérifiez l'état DKIM du domaine personnalisé et les enregistrements DNS requis. Après avoir ajouté les valeurs suggérées au DNS, vérifiez que la signature est activée.

4. Introduisez DMARC progressivement. Analysez les expéditeurs réels et les échecs d'authentification via les rapports, puis décidez du renforcement de la politique. Si vous n'ajoutez que la déclaration de politique sans lire les rapports, il est difficile de détecter les problèmes.
5. Envoyez un e-mail test à une adresse externe en dehors de l'organisation et vérifiez les résultats et l'alignement SPF, DKIM et DMARC dans les en-têtes reçus. Même si le statut DNS est normal, vous devez tester le chemin d'envoi réel.

Conditions dans lesquelles l'exemple SPF peut être utilisé tel quel

Pour un domaine personnalisé dont vous gérez le DNS public, la valeur TXT suivante est un exemple de base lorsque Microsoft 365 est le seul service d’envoi. Cet exemple s’applique au service commercial mondial de Microsoft ; les clouds spéciaux pour le gouvernement ou opérés en Chine peuvent nécessiter des domaines inclus différents. Utilisez les valeurs spécifiques au service dans votre centre d’administration et la documentation. Si un site web ou un service marketing envoie également directement en utilisant le même domaine, ne remplacez pas votre politique actuelle par cet exemple seul. Comparez l’assistant de domaine et les directives de configuration officielles de chaque expéditeur.

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

include fait référence au périmètre d'envoi de Microsoft 365 et -all déclare que les sources d’envoi non autorisées par les mécanismes SPF doivent être considérés comme des échecs SPF. Créer deux enregistrements TXT SPF avec le même nom pour inclure séparément Microsoft 365 et des services externes est une configuration incorrecte. Regroupez les sources d’envoi nécessaires dans une seule politique SPF et supprimez les expéditeurs inutiles. Les enregistrements TXT pour la vérification de propriété autres que SPF ont un objectif différent et ne sont pas soumis à suppression. Sélectionnez en fonction des scénarios d'envoi dans Guide de configuration SPF Microsoft.

Lors de la combinaison de services, vérifiez également la limite de SPF de 10 recherches DNS pendant l'évaluation. Les mécanismes d'inclusion imbriqués comptent également : moins de 10 fournisseurs ou entrées d'inclusion ne garantit pas que l'évaluation reste dans la limite.

Valeurs à sélectionner lors de la configuration de DKIM et DMARC

Dans le portail Defender, ouvrez le domaine personnalisé sous Courrier et collaboration → Stratégies et règles → Stratégies de protection → Paramètres d’authentification du courrier → DKIM. Générez les clés si nécessaire, puis saisissez les noms et cibles des deux enregistrements CNAME (nom canonique) indiqués dans les détails du domaine chez votre fournisseur DNS. Un enregistrement CNAME pointe un nom DNS vers un autre ; dans cette configuration, il relie la recherche DKIM aux enregistrements de clés de Microsoft. Copiez les noms et cibles des sélecteurs fournis pour votre locataire au lieu de les construire à partir d’un ancien blog. Microsoft a introduit un nouveau format de cibles pour les nouveaux domaines personnalisés en mai 2025, tandis que les domaines existants peuvent conserver l’ancien format.

Après la propagation DNS, activez le bouton de signature DKIM pour le domaine et vérifiez s'il signe. Si le CNAME est manquant, vérifiez à nouveau le nom saisi, le fournisseur DNS réel et le temps de détection. Ne supposez pas que la signature est activée simplement parce que les deux enregistrements sont enregistrés. Vous pouvez consulter la procédure pour procéder selon l'état actuel dans Procédure officielle de configuration DKIM .

La politique DMARC initiale peut être définie comme une configuration axée sur les rapports qui peut analyser les expéditeurs légitimes. Voici un exemple utilisant example.com comme domaine d'exemple. Publiez l'enregistrement TXT à _dmarc pour votre propre domaine, et remplacez dmarc@example.com dans la valeur rua=mailto: par une boîte mail de rapport réelle contrôlée par votre organisation. L'adresse d'exemple n'est pas une destination à utiliser telle quelle.

v=DMARC1; p=none; rua=mailto:dmarc@example.com

p=none est une politique de départ qui ne demande pas de quarantaine ni de rejet pour les échecs DMARC eux-mêmes, et elle ne désactive pas d'autres filtres anti-spam ou de sécurité. Le paramètre rua indique la destination des rapports agrégés. Vous devez être prêt à recevoir et analyser effectivement à cette adresse, et si vous utilisez une adresse de service de rapport externe, vous devez également vérifier les conditions supplémentaires d'approbation DNS. Après avoir vérifié l'alignement des expéditeurs légitimes et le chemin de livraison, vous renforcez la politique en suivant les étapes quarantine et reject. Les conditions détaillées suivent les directives de mise en œuvre guide de mise en œuvre de DMARC.

Vérifiez les enregistrements DNS et l'authentification sur les mails nouvellement envoyés

Envoyez de nouveaux e-mails à une adresse de test pour chaque chemin d'envoi, tels que la messagerie des employés, les formulaires de demande sur le web, le CRM, etc. Du côté de la réception, ouvrez le message original et les en-têtes Internet pour vérifier les résultats SPF, DKIM et DMARC dans le Authentication-Results du système de réception, et comparez également le domaine de signature DKIM avec le champ From affiché. Vous avez besoin des résultats des messages nouvellement envoyés après les modifications plutôt que de « les anciens e-mails étaient normaux ».

Si le DNS est normal mais qu'un CRM spécifique échoue, vérifiez d'abord le domaine d'envoi et les paramètres de signature pour ce chemin. Si le corps signé change ou si le serveur d'envoi diffère pendant le processus de livraison, les résultats peuvent varier. Le passage de l'authentification ne garantit pas la livraison dans la boîte de réception, et la réputation, le spam et les politiques de contenu ont également un impact.

Les valeurs des enregistrements varient en fonction du domaine et du moment de la configuration. Le but de cet article n'est pas de mémoriser les valeurs, mais de comparer les valeurs fournies par le centre de gestion , les valeurs réelles dans le DNS, et les résultats d'authentification côté récepteur. En cas de problèmes de réception ou d'envoi d'e-mails, identifiez l'étendue de l'impact en fonction des enregistrements DNS avant les modifications. Si des e-mails légitimes sont affectés, comparez la politique précédente et la configuration de l'expéditeur pour ne restaurer que les modifications problématiques et testez à nouveau. Ne supprimez pas tous les enregistrements SPF, DKIM et DMARC et ne maintenez pas une politique DMARC stricte sans en connaître la cause. Dans le rapport, distinguez les échecs des expéditeurs légitimes et les envois frauduleux suspects, et déterminez les actions de suivi en conséquence.