Guide de configuration de DMARC pour Office 365 (2026)

Suivez ce guide étape par étape pour configurer DMARC sur Office 365. Découvrez les changements pertinents en matière de conformité, les méthodes courantes de dépannage et pourquoi Microsoft 365 ne suffit pas à lui seul à garantir la sécurité des e-mails.

Microsoft prend en charge et encourage la mise en place du protocole DMARC pour Office 365, également appelé Microsoft 365 ou M365. Cela permet aux utilisateurs d’adopter de manière uniforme les protocoles d’authentification des e-mails sur l’ensemble de leurs domaines enregistrés. En tant qu’experts en protocoles d’authentification, nous profitons de cet article de blog pour expliquer les étapes de configuration du protocole DMARC pour Office 365 afin de valider tous les e-mails qui :

• Adresses de routage d'e-mails en ligne avec Microsoft
• Domaines personnalisés ajoutés dans le centre d'administration
• Domaines parqués ou inactifs, mais enregistrés

Consultez ce guide pour comprendre le protocole DMARC pour Microsoft 365, les étapes de sa configuration, la modification des exigences d'authentification, ainsi que l'importance d'outils tels que PowerDMARC pour mettre en œuvre progressivement ces mesures.

Réponse rapide

Si vous souhaitez une version succincte, voici les grandes lignes de la procédure de configuration DMARC pour Microsoft 365 :

1. Configurer SPF: ajoutez « v=spf1 include:spf.protection.outlook.com -all » à votre DNS
2. Activer DKIM : accédez à Microsoft 365 Defender → Messagerie et collaboration → Stratégies et règles → Stratégies de protection contre les menaces → DKIM → sélectionnez le domaine → Activer (nécessite deux enregistrements CNAME)
3. Publier DMARC : créez un enregistrement TXT sur _dmarc.votredomaine.com commençant par v=DMARC1; p=none; rua=mailto:[email protected]
4. Surveillez les rapports pendant 2 à 4 semaines, puis passez progressivement dequarantine p=rejet

Pour un guide plus détaillé à suivre, lisez cet article de blog jusqu'à la fin.
Remarque : cette procédure rapide ne fonctionne que si toutes les sources d'envoi légitimes de Microsoft 365 et de tiers sont correctement authentifiées et configurées. Si vous utilisez des plateformes telles que des CRM, des outils d'automatisation du marketing, des systèmes d'assistance ou des outils de facturation, identifiez-les avant de passer à la mise en application.

Qu'est-ce que le DMARC et pourquoi est-ce important pour Microsoft 365 ?

DMARC signifie « Domain-based Message Authentication, Reporting, and Conformance » (authentification, rapport et conformité des messages basés sur le domaine). Il s'agit d'un protocole d'authentification des e-mails qui contribue à protéger les domaines contre l'usurpation d'identité, le hameçonnage et l'utilisation non autorisée.

DMARC s'appuie sur les protocoles SPF DKIM. Il vérifie si un message est conforme SPF DKIM et si le domaine conforme correspond bien au domaine « De » affiché. Il indique ensuite aux serveurs de messagerie destinataires comment traiter les messages qui échouent à l'authentification.

Pour les utilisateurs de Microsoft 365, le protocole DMARC revêt une importance particulière pour deux raisons :

• Cela permet d'empêcher les pirates de se faire passer pour votre domaine.
• Cela permet d'améliorer la confiance et le taux de délivrabilité des e-mails sortants légitimes.

Exchange Online Protection vérifie la conformité DMARC des e-mails entrants, mais cela ne protège pas automatiquement votre domaine contre l'usurpation d'identité par des tiers. Pour protéger votre identité lors de l'envoi d'e-mails, vous devez publier des enregistrements SPF, DKIM et DMARC pour votre domaine.

Pour obtenir des informations plus complètes sur la mise en œuvre, consultez le guide DMARC de PowerDMARC.

DMARC 2026 : mise à jour des RFC 9989, 9990 et 9991

En mai 2026, le protocole DMARC a été mis à jour par le biais de trois RFC de l'IETF :

La RFC 9989 remplace les RFC 7489 et 9091 et fait passer DMARC au statut de « norme proposée ». Pour les propriétaires de domaines, le changement pratique le plus important réside dans le passage d'une méthode de découverte des domaines organisationnels basée sur la liste des suffixes publics (Public Suffix List) à une méthode de parcours de l'arborescence DNS (DNS Tree Walk).

Les enregistrements DMARC existants commencent toujours par :

txt

v=DMARC1

La plupart des administrateurs Microsoft 365 ne le font donc pas pas ont pas besoin de reconfigurer leurs enregistrements DNS immédiatement. Cependant, vous devriez vérifier :

• sp= comportement de la politique de sous-domaine
• Toute structure complexe de sous-domaines délégués
• Domaines et sous-domaines qui envoient des e-mails via Microsoft 365 ou des plateformes tierces
• Domaines inactifs et ne générant aucun envoi qui devraient être verrouillés

Si votre organisation utilise une hiérarchie de domaines complexe, publiez des enregistrements DMARC explicites pour chaque domaine et sous-domaine qui envoie des e-mails. Cela permet de réduire les ambiguïtés lorsque les destinataires passent d'un traitement DMARC plus ancien au comportement défini par la norme RFC 9989.

Pour plus d'informations, consultez le guide de PowerDMARC consacré aux mise à jour des RFC 9989, 9990 et 9991 de DMARC.

Microsoft 365 gère-t-il le protocole DMARC pour vous ?

Microsoft 365 effectue la validation DMARC pour les e-mails entrants, mais ne configure pas entièrement la protection du domaine sortant pour votre domaine personnalisé.

Exchange Online Protection évalue automatiquement SPF, DKIM et DMARC des messages reçus par votre organisation. Cela permet de protéger les utilisateurs contre les e-mails entrants usurpés.

En ce qui concerne les e-mails sortants, les responsabilités sont différentes. Vous devez configurer SPF, activer le DKIM et publier un enregistrement DMARC dans le DNS pour chaque domaine émetteur.

Pour comprendre cette distinction de la manière la plus simple qui soit, disons que Microsoft protège votre boîte de réception Microsoft 365, tandis que DMARC protège l'identité de votre domaine dans l'ensemble de l'écosystème de messagerie.

Si vous vous fiez uniquement aux contrôles natifs de Microsoft 365, il se peut que vous ne disposiez toujours pas :

• Rapports DMARC lisibles par l'utilisateur
• Visibilité sur les expéditeurs tiers
• Consignes pour passer de « p=none » à « enforcement »
• Surveillance centralisée sur l'ensemble des domaines
• Gestion SPF
• Envoie des alertes lorsque les fournisseurs ou les enregistrements DNS ne sont plus synchronisés

Pour une analyse détaillée, consultez pourquoi les utilisateurs de Microsoft 365 ont toujours besoin de DMARC.

Conditions préalables : Configurer SPF DKIM pour Microsoft 365

Avant de publier un enregistrement DMARC, assurez-vous que les protocoles SPF DKIM sont correctement configurés pour votre domaine. Le protocole DMARC n'authentifie pas les e-mails de manière autonome ; il s'appuie entièrement sur les résultats SPF DKIM. Si ceux-ci font défaut ou ne sont pas correctement configurés, le protocole DMARC échouera, et les e-mails légitimes risquent d'être affectés une fois que l'application de la politique sera activée.

Étape 1 : Configurer SPF Microsoft 365

SPF(Sender Policy Framework) définit quels serveurs de messagerie sont autorisés à envoyer des e-mails au nom de votre domaine.

Pour un domaine exclusivement Microsoft 365, SPF standard est le suivant :

v=spf1 includespf.protection.outlook.com -all

Si vous utilisez des expéditeurs tiers, ajoutez-les dans le même SPF :

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

Important : Il ne peut y avoir qu'un seul enregistrement SPF par domaine. La présence de plusieurs SPF entraîne SPF et peut empêcher l'authentification.

SPF imposeSPF une limite stricte de 10 requêtes DNS. Le dépassement de cette limite entraîne SPF , que DMARC interprète comme un échec. Si vous utilisez plusieurs services SaaS, utilisez SPF hébergé de PowerSPF SPF macros pour rester en permanence en dessous de cette limite sans avoir à modifier manuellement les paramètres DNS. Vous pouvez également vérifier votre SPF actuel ou utiliser ce SPF gratuitement.

Étape 2 : Activer DKIM pour Microsoft 365

Le protocole DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique à vos e-mails. Cela permet aux serveurs destinataires de vérifier que le message n'a pas été altéré et qu'il provient bien de votre domaine.

⚠️  DKIM dans Microsoft 365 n'est pas activé par défaut pour les domaines personnalisés. Vous devez l'activer explicitement dans le centre d'administration.

Configuration manuelle de DKIM : DNS + Centre d'administration

1. Accéder au portail Microsoft 365 Defender
2. Accédez à « Messagerie et collaboration » → « Politiques et règles » → « Politiques de menaces » → « Paramètres d'authentification des e-mails » → « DKIM »
3. Sélectionnez votre nom de domaine.

Avant de pouvoir activer cette fonctionnalité, Microsoft vous demandera d'ajouter deux enregistrements CNAME :

selector1._domainkey
selector1-<CustomDomainWithDashes>._domainkey.<InitialDomainPrefix>.<DynamicPartitionCharacter>-v1.dkim.mail.microsoft

selector2._domainkey
selector2-<CustomDomainWithDashes>._domainkey.<InitialDomainPrefix>.<DynamicPartitionCharacter>-v1.dkim.mail.microsoft

1. Une fois ces enregistrements CNAME publiés, retournez sur le portail Defender et activez l'option « Activer » pour DKIM.

Une fois cette fonctionnalité activée, Microsoft commence à signer tous les e-mails sortants à l'aide de DKIM. Vérifiez votre configuration à l'aide de l'outil de vérification DKIM gratuit de PowerDMARC vérificateur DKIM gratuit.

Comment configurer DMARC pour Office 365

Une fois SPF DKIM configurés, vous pouvez publier DMARC. Pour la plupart des domaines personnalisés, la configuration de DMARC dans Microsoft 365 s'effectue via le DNS, et non dans le Centre d'administration Microsoft 365.

Étape 1 : Identifier toutes les sources d'envoi d'e-mails

Avant de publier un enregistrement DMARC, vous devez disposer d’une vue d’ensemble complète des expéditeurs qui envoient des e-mails au nom de votre domaine. Si un expéditeur légitime n’est pas répertorié, cela peut entraîner des échecs de livraison une fois que l’application de la politique sera activée.

Les sources d'envoi courantes de Microsoft 365 sont notamment :

• Microsoft 365 (Exchange Online)
• Plateformes de marketing (Mailchimp, HubSpot, Klaviyo)
• Systèmes CRM (Salesforce, HubSpot CRM)
• Outils d'assistance (Zendesk, Freshdesk, Intercom)
• Applications internes ou serveurs de messagerie sur site
• Passerelles de messagerie ou appareils de sécurité tiers

C'est là que de nombreux déploiements de DMARC échouent. Un domaine peut sembler être « exclusivement réservé à Microsoft 365 », mais les factures, les lettres d'information, les réinitialisations de mot de passe, les mises à jour de tickets et les notifications des RH proviennent souvent de sources extérieures à Microsoft 365.

Si vous ne savez pas quels systèmes envoient des e-mails en votre nom, commencez par définir p=none et utilisez les rapports agrégés DMARC pour les identifier.

Étape 2 : Créer votre enregistrement DMARC

Un enregistrement DMARC est un enregistrement TXT publié dans votre DNS à l'adresse _dmarc.votredomaine.com. Utilisez le générateur d'enregistrements DMARC de PowerDMARC pour créer en quelques secondes un enregistrement valide et sans erreur.

Voici à quoi ressemble un enregistrement de départ recommandé :

v=DMARC1 ; p=none ; rua=mailto:[email protected] ;

Voyons cela plus en détail :

• v=DMARC1 — indique la version de DMARC
• p=none — mode de surveillance (pas d'application ; collecte de données uniquement)
• rua=mailto:… — adresse à laquelle sont envoyés les rapports agrégés (RUA)

Étape 3 : Publier l'enregistrement DMARC dans le DNS

Ajoutez l'enregistrement TXT suivant chez votre hébergeur DNS :

Remarque : après la publication, la propagation de l'enregistrement à l'échelle mondiale peut prendre un certain temps (généralement de quelques minutes à quelques heures).

Une fois la publication effectuée, vérifiez votre enregistrement à l'aide d'un outil de vérification DMARC afin de vous assurer qu'il ne contient aucune erreur de syntaxe et qu'il se résout correctement.

Étape 4 : Surveiller les rapports DMARC

Une fois le protocole DMARC activé avec une politique « p=none », vous commencerez à recevoir des rapports agrégés DMARC (RUA) provenant des serveurs destinataires. Ces rapports vous permettent de savoir : qui envoie des e-mails en utilisant votre domaine, quels messages réussissent ou échouent à l’authentification, ainsi que l’état de conformité des politiques SPF DKIM.

Les rapports DMARC sont fournis au format XML brut, ce qui les rend difficiles à interpréter sans outils adaptés. L'analyseur de rapports de PowerDMARC les convertit en tableaux de bord lisibles par l'utilisateur, ce qui vous permet d'identifier les problèmes et de progresser en toute sécurité vers la mise en œuvre des mesures correctives.

Étape 5 : Passer progressivement à la mise en application

Une fois que vous vous êtes assuré que tous les expéditeurs légitimes sont correctement authentifiés, renforcez progressivement votre politique DMARC :

Étape 1 — Suivi (p = aucun) :

v=DMARC1 ; p=none ; rua=mailto:[email protected]

Étape 2 — Quarantine les e-mails suspects sont envoyés dans le dossier « Spam ») :

v=DMARC1 ;quarantine; rua=mailto:[email protected] ; pct=25 ; t=y

Étape 3 — Application (rejet des e-mails non authentifiés) :

v=DMARC1 ; p=reject ; rua=mailto:[email protected] ; adkim=r ; aspf=r

Conseil : ne vous précipitez pas pour rejeter un message. Une application prématurée des règles est la cause la plus fréquente du blocage d'e-mails légitimes lors de la mise en place du système.

Étape 6 : Configurer DMARC pour différents types de domaines

La marche à suivre varie en fonction du domaine que vous configurez.

Étape 7 : Valider et gérer votre configuration DMARC pour Microsoft 365

La configuration DMARC ne se fait pas une fois pour toutes. À mesure que votre environnement de messagerie évolue, votre configuration doit s'adapter. Même après avoir atteint le niveau « p=reject », une surveillance continue est indispensable pour garantir la délivrabilité et la sécurité.

Vous devriez régulièrement :

• Consulter les rapports DMARC
• Mettre à jour SPF l'ajout de nouveaux expéditeurs
• Assurez-vous que DKIM reste activé et correctement configuré
• Surveiller les activités non autorisées

Mise en place de la politique DMARC : pourquoi une application progressive est importante

Le passage direct à une politique de rejet est l'une des erreurs les plus courantes lors de la mise en œuvre du protocole DMARC. Sans une bonne visibilité sur vos flux de messagerie, l'application de cette politique peut perturber les communications légitimes.

Un déploiement progressif vous permet de surveiller et de corriger les problèmes avant d'appliquer des règles strictes. La plupart des entreprises suivent un processus allant de la surveillance à quarantine au rejet. La durée de chaque phase dépend de la complexité de votre environnement de messagerie, et le fait de sauter des étapes ne fait qu'augmenter le risque d'échecs de livraison involontaires.

Comment Exchange Online gère les messages DMARC entrants

Exchange Online Protection analyse automatiquement les en-têtes DMARC de tous les messages entrants. Depuis juillet 2023, Microsoft respecte par défaut la politique publiée par l’expéditeur. Lorsque l’enregistrement MX du domaine destinataire pointe directement vers Microsoft 365, les messages qui échouent au contrôle DMARC selon une politique p=reject sont rejetés au niveau de la passerelle. De même,quarantine sont envoyés en quarantine. Ce comportement est contrôlé par la politique «Respecter la politique de l’enregistrement DMARC lorsque le message est détecté comme étant usurpé» de la politique anti-hameçonnage, activé par défaut.

Pour obtenir des instructions détaillées sur la configuration de ce paramètre et de toutes les options associées, consultez le guide de PowerDMARC consacré à la politique anti-hameçonnage d'Office 365.

Source : Microsoft

Explication du comportement « oreject »

Auparavant, Microsoft appliquait une règle de contournement interne appelée « action=oreject » (rejet à la source) aux messages entrants qui ne respectaient pas la politique « p=reject » de l'expéditeur. Au lieu de rejeter purement et simplement le message au niveau de la passerelle, EOP l'acheminait vers le dossier « Courrier indésirable » du destinataire et ajoutait la mention « oreject » à l'en-tête.

Microsoft a agi ainsi délibérément ; les e-mails transférés et le trafic des listes de diffusion enfreignent souvent SPF DKIM lors de leur transit, et un rejet catégorique (p=reject) aurait entraîné la suppression d'un volume important d'e-mails légitimes. Le dossier « Courrier indésirable » constituait un compromis : les destinataires pouvaient récupérer les e-mails si nécessaire, et la politique de l'expéditeur était techniquement respectée.

Quand verrez-vous encore « oreject » aujourd'hui ?

Depuis la modification du comportement par défaut, EOP considère désormais « p=reject » comme un véritable rejet pour les flux MX directs. Cependant, l'ancien comportement n'a pas complètement disparu. Vous verrez toujours « oreject » dans les trois cas suivants :

1. L'option « Honor DMARC » est désactivée dans votre stratégie anti-hameçonnage : vérifiez dans Microsoft 365 Defender → Messagerie et collaboration → Stratégies de protection contre les menaces → Anti-hameçonnage → Paramètres d'usurpation d'identité
2. Les e-mails transitent par une passerelle tierce (Proofpoint, Mimecast) avant d'atteindre Microsoft 365 : activez le « filtrage avancé pour les connecteurs » dans le portail Defender
3. Une règle d'autorisation au niveau du locataire contourne le filtrage : les expéditeurs figurant sur la liste blanche, les connecteurs entrants de confiance ou les règles SCL -1 échappent totalement à l'application de la norme DMARC.

Comprendre compauth et l'authentification composite

Microsoft superpose des indicateurs de réputation aux résultats DMARC grâce à un système appelé « authentification composite » (compauth). Cela signifie qu’un message peut techniquement échouer au test DMARC tout en étant quand même remis si les indicateurs de réputation de Microsoft indiquent que l’expéditeur est légitime (compauth=pass). À l’inverse, un message peut réussir le test DMARC et être tout de même classé comme courrier indésirable si l’authentification composite échoue. Lors du dépannage des problèmes de livraison DMARC dans M365, vérifiez toujours l’en-tête « Authentication-Results » pour le code « reason= ». Consultez ce guide complet sur les l'échec de compauth et l'authentification composite pour plus d’informations.

Renforcement des contrôles à l'entrée grâce aux règles de transport

Pour les organisations qui souhaitent s'assurer que les e-mails non conformes à DMARC soient systématiquement rejetés, une règle de transport Exchange Online constitue le mécanisme le plus fiable :

1. Accéder à Centre d'administration Exchange → Flux de messagerie → Règles → Créer une nouvelle règle
2. Condition définie : un en-tête de message contient l'un de ces mots. Nom de l'en-tête : Authentication-Results. Valeur de l'en-tête : dmarc=fail action=oreject
3. Action à définir : rejeter le message avec l'explication suivante : « Le message n'a pas passé l'authentification DMARC et a été rejeté conformément à la politique de l'organisation. »

1. (Facultatif) Ajouter une exception pour les expéditeurs internes de confiance ou les expéditeurs légitimes connus
2. Réglez le mode de règle sur « Test sans politique » ou « Test avec conseils de politique » (si disponible) pendant la première semaine ; examinez les messages correspondants dans l'historique des messages avant de passer au mode « Appliquer ».

Adoptez cette approche lorsque la réglementation ou la politique interne exige le rejet effectif des e-mails non conformes, lorsque votre organisation constitue une cible de choix pour l'usurpation d'identité (communications financières, juridiques ou de direction), ou lorsque vous souhaitez garantir un comportement cohérent entre les flux MX directs et ceux transitant par des passerelles tierces.

Application de la norme DMARC par Microsoft en mai 2025 : ce qui a changé

En mai 2025, Microsoft a introduit un changement majeur dans la manière dont il traite les e-mails non authentifiés provenant d'expéditeurs externes. Ce changement concerne principalement les expéditeurs à fort volume, mais a des implications plus larges pour toutes les organisations.

Comparaison des mesures d'application des fournisseurs de messagerie

Principales exigences introduites par Microsoft

• DMARC obligatoire pour les expéditeurs en masse : les domaines envoyant plus de 5 000 e-mails par jour vers les services grand public de Microsoft doivent disposer d'un enregistrement DMARC valide
• S'applique à l'écosystème de messagerie grand public de Microsoft : Outlook.com, Hotmail.com et Live.com
• Exigence minimale : DMARC avec p=none — même une politique de surveillance est acceptable, mais l'absence d'enregistrement DMARC n'est plus tolérée à grande échelle
• L'accent est mis sur l'alignement des domaines : l'authentification seule ne suffit pas, les en-têtes SPF DKIM doivent correspondre au domaine « De » visible
• Refus catégorique pour non-conformité : 550 5.7.515 Accès refusé, le domaine d'origine ne répond pas au niveau d'authentification requis

Ce changement permet à Microsoft de s'aligner sur Apple, Google et Yahoo en matière d’authentification des e-mails, ce qui signifie que les plus grands fournisseurs de messagerie imposent désormais tous une authentification aux expéditeurs de courriers en masse. Voir les exigences DMARC de Microsoft pour Outlook pour obtenir une liste de contrôle complète de conformité.

Pourquoi Microsoft 365 ne suffit pas à lui seul

Si Microsoft 365 offre une protection efficace contre les menaces entrantes, il ne dispose toutefois que de fonctionnalités limitées pour gérer et surveiller le protocole DMARC à grande échelle.

Pas de rapports lisibles par l'utilisateur

Microsoft envoie désormais des rapports DMARC aux utilisateurs professionnels lorsque le record MX pointe directement vers Office 365. Cependant, ces fichiers XML bruts sont difficiles à interpréter sans outils spécialisés. Sans analyse appropriée, les entreprises ne disposent pas d'une visibilité suffisante pour savoir qui envoie des e-mails en leur nom et si ces expéditeurs sont correctement authentifiés.

Absence de directives d'application

Microsoft ne propose pas de processus automatisé pour passer de la surveillance à l'application des mesures. Les administrateurs doivent donc interpréter manuellement les données et prendre des décisions susceptibles d'avoir une incidence sur la distribution des e-mails.

Ne convient pas à une gestion à long terme

Une solution DMARC dédiée ne se contente pas de transformer des rapports bruts en informations exploitables. Elle permet une surveillance continue, simplifie la gestion des politiques et aide les organisations à progresser en toute sécurité vers une mise en œuvre complète, à une échelle que Microsoft 365 n'offre tout simplement pas.

Résolution des problèmes courants liés à DMARC dans Office 365

Vous pouvez également rejoindre la communauté d'apprentissage de Microsoft pour vous tenir informé des dernières actualités concernant Office 365 et ses exigences en matière de protocole d'authentification.

Aller de l'avant avec DMARC sur Microsoft 365

Le DMARC sur Microsoft 365 pose un double problème. Exchange Online Protection se charge automatiquement de la validation des e-mails entrants, mais la protection des e-mails sortants relève entièrement de votre responsabilité. Les changements d’application prévus pour mai 2025 rendent cette responsabilité urgente pour toute personne envoyant des e-mails en grand volume, la publication de DMARCbis en mai 2026 indiquant que le secteur de la messagerie électronique considère désormais DMARC comme une infrastructure permanente et officielle.

La méthode la plus sûre est plus lente, mais efficace : définissez p=none, surveillez vos rapports pendant deux à quatre semaines, corrigez les expéditeurs qui apparaissent, puis passez àquarantine , enfin, à p=reject. C'est en sautant ces étapes que les e-mails professionnels légitimes sont bloqués lors du déploiement.

Une fois la mise en application effective, le travail passe de la configuration à la surveillance. De nouveaux expéditeurs sont ajoutés et les fournisseurs tiers modifient leur infrastructure, ce qui peut discrètement compromettre l'alignement si personne ne surveille les rapports. Donnez la priorité à la sécurité des e-mails en vérifiant votre enregistrement DMARC actuel pour évaluer votre situation actuelle.

Pour une liste complète de toutes les balises, politiques et options de mise en œuvre DMARC, consultez le guide DMARCde PowerDMARC.

Foire aux questions

Microsoft 365 configure-t-il automatiquement DMARC ?

Microsoft valide le protocole DMARC pour les e-mails entrants, mais ne le configure pas pour votre domaine personnalisé. Vous devez publier vous-même manuellement l'enregistrement TXT DMARC sortant. La protection du domaine nécessite que vous publiiez vous-même les enregistrements SPF, DKIM et DMARC dans le DNS.

Microsoft impose-t-il l'utilisation de DMARC ?

Oui. Microsoft a rendu obligatoire l'utilisation de DMARC (au minimum avec p=none) pour les domaines envoyant plus de 5 000 e-mails par jour vers Outlook.com, Hotmail.com et Live.com à partir de 2025. Les expéditeurs non conformes sont rejetés au niveau du serveur, sans que leurs messages n'atteignent la boîte de réception. Microsoft recommande également vivement à tous les expéditeurs de mettre en œuvre DMARC, quel que soit leur volume d'envoi.

Qu'est-ce que l'erreur 550 5.7.515 ?

Cette erreur Microsoft 365 signifie que vos e-mails sont rejetés car votre domaine d'envoi ne répond pas aux exigences d'authentification. Pour y remédier, vous devez publier un enregistrement DMARC valide (au minimum p=none) et vous assurer que SPF DKIM sont tous deux configurés et alignés sur votre domaine d'expédition.

Pourquoi les e-mails sont-ils toujours envoyés avec le paramètre « p=reject » ?

Il existe quatre raisons courantes : (1) l’option « Honor DMARC » est désactivée dans votre politique anti-hameçonnage ; (2) une passerelle tierce est déployée en amont de Microsoft 365 ; (3) le filtrage amélioré pour les connecteurs n’est pas activé ; (4) l’authentification composite de Microsoft (compauth) remplace le résultat d’échec DMARC ; (5) une règle d’autorisation du locataire contourne entièrement le filtrage. Bien que Microsoft se soit orienté vers un rejet définitif plus strict pour les expéditeurs à fort volume, ces remplacements restent actifs dans les environnements mal configurés.

Dois-je choisir « quarantine « Refuser » ?

Commencez par la surveillance (p=none) pour identifier vos sources d'envoi, puis passez à quarantine, et n'utilisez le rejet qu'une fois que vous êtes certain que toutes les sources légitimes sont correctement identifiées. Passer directement au rejet sans passer par la surveillance est la principale cause de perte d'e-mails légitimes lors du déploiement de DMARC.

Que signifie DMARCbis pour les administrateurs de Microsoft 365 ?

DMARCbis (RFC 9989, publiée en mai 2026) fait officiellement passer DMARC au statut de « norme proposée ». Pour la plupart des administrateurs M365, aucune modification immédiate du DNS n’est requise ; les enregistrements DMARC existants restent valides. Le principal changement à prendre en compte est l’approche dite « DNS Tree Walk » (parcours de l’arborescence DNS) pour déterminer les domaines organisationnels, qui remplace la liste des suffixes publics (Public Suffix List). Vérifiez votre balise sp= (politique de sous-domaine) pour vous assurer qu’elle s’applique toujours correctement selon la nouvelle logique.

Le protocole DMARC s'applique-t-il aux domaines onmicrosoft.com ?

Oui. Le domaine onmicrosoft.com (MOERA) est souvent négligé, mais les pirates l'utilisent activement à des fins d'usurpation d'identité. Microsoft SPF pour les domaines MOERA, mais les politiques DKIM et DMARC doivent être publiées manuellement. Appliquez une politique stricte « p=reject » sur ces domaines, car ils ne sont généralement pas utilisés pour l'envoi légitime de courriers électroniques.

Le protocole DMARC est-il obligatoire pour la conformité à la norme PCI DSS ?

À compter du 31 mars 2025, la section 5.4.1 de la norme PCI DSS v4.0 rend obligatoire l'utilisation de contrôles anti-hameçonnage, notamment DMARC, SPF et DKIM, pour toutes les organisations traitant des données de cartes de paiement. Toutes les évaluations de 2026 seront menées conformément à la norme PCI DSS v4.0.1, sans période de grâce. Si votre organisation traite des paiements par carte et utilise Microsoft 365, DMARC constitue une exigence de conformité stricte.

• À propos de
• Derniers messages

Yunes Tarada

Expert en sécurité des domaines et des e-mails chez PowerDMARC

Yunes est chef d'équipe des opérations chez PowerDMARC et possède des connaissances approfondies en matière d'authentification et de sécurité des courriels. Yunes est certifié Microsoft Azure Administrator Associate et possède des certifications CompTIA A+ et bien d'autres encore.

Derniers messages de Yunes Tarada (voir tous)

• Guide de configuration de Happyfox DKIM, DMARC et « SPF » - 13 août 2026
• Guide de configuration de Twikey SPF, DKIM et DMARC - 11 août 2026
• Qu'est-ce que le « whaling » dans le domaine de la cybersécurité ? - 7 août 2026