DMARC pour Office 365 : Configuration pas à pas et meilleures pratiques

Microsoft soutient et encourage la mise en place du protocole DMARC pour les utilisateurs de Microsoft 365 (également appelé Office 365 ou M365), ce qui leur permet d'adopter des protocoles d'authentification des e-mails de manière uniforme sur tous leurs domaines enregistrés. Dans cet article, nous expliquons la procédure à suivre pour configurer DMARC pour Office 365 afin de valider tous les e-mails Office 365 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

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

DMARC est un protocole d'authentification des e-mails qui protège les domaines contre l'usurpation d'identité et le phishing. (Domain-based Message Authentication, Reporting, and Conformance) s'appuie sur les protocoles SPF DKIM, en alignant les résultats d'authentification sur la politique du domaine et en indiquant aux serveurs destinataires comment traiter les messages qui ne satisfont pas à ces vérifications.

Dans un environnement Microsoft 365, DMARC remplit une double fonction. Il protège votre domaine contre l'usurpation d'identité par des pirates et contribue également à garantir que vos e-mails légitimes soient considérés comme fiables par les destinataires externes.

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

L'une des idées fausses les plus répandues chez les administrateurs est que Microsoft 365 gère le protocole DMARC à votre place.

Microsoft 365 effectue bien une validation DMARC, mais uniquement pour les e-mails entrants. Exchange Online Protection (EOP) vérifie automatiquement SPF, DKIM et DMARC des messages reçus par votre organisation. Cela signifie que vos utilisateurs sont, dans une certaine mesure, protégés contre les e-mails frauduleux.

Cependant, pour les e-mails sortants, Microsoft n'intervient pas tant que vous ne l'avez pas configuré. Si vous souhaitez protéger votre domaine et respecter les exigences actuelles en matière de conformité, vous devez publier un enregistrement DMARC dans votre DNS.

Cette distinction est essentielle. Microsoft protège votre boîte de réception, mais DMARC protège la réputation de votre domaine ; c'est pourquoi Microsoft 365 a besoin de DMARC même si EOP est déjà en place. La configuration que vous vous apprêtez à mettre en place concerne la protection des e-mails sortants.

Conditions préalables : Configurer SPF DKIM pour Microsoft 365

Avant de publier un enregistrement DMARC, vous devez vous assurer que les protocoles SPF DKIM sont correctement configurés pour votre domaine. 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, 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. Dans une configuration Microsoft 365, cela inclut généralement les serveurs de messagerie de Microsoft ainsi que tous les services tiers que vous utilisez.

SPF manuelle SPF (méthode DNS)

Pour configurer SPF :

1. Accédez à votre fournisseur d'hébergement DNS (par exemple, GoDaddy, Cloudflare, etc.)
2. Créer ou mettre à jour un enregistrement TXT pour votre domaine racine

Utilisez SPF Microsoft 365 standard suivant :

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

Si vous utilisez des services supplémentaires (tels que Mailchimp ou Salesforce), vous devez également les inclure. Par exemple :

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

SPF automatisée SPF (avec PowerDMARC)

La création manuelle SPF peut s'avérer complexe, en particulier lorsque plusieurs services sont concernés. Des erreurs telles que le dépassement des limites de requêtes DNS ou des erreurs de configuration sont fréquentes.

L'utilisation SPF de PowerDMARC simplifie ce processus. Le SPF crée automatiquement un enregistrement valide en fonction de vos sources d'envoi.

É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.

Contrairement SPF, le protocole DKIM dans Microsoft 365 nécessite à la fois une configuration DNS et une activation dans le Centre d'administration.

Configuration manuelle de DKIM (DNS + Centre d'administration)

Pour activer DKIM manuellement :

1. Accéder au portail Microsoft 365 Defender
2. Accédez à Courrier électronique et collaboration → Politiques et règles → Politiques de sécurité → DKIM
3. Choisissez votre domaine

Source de l'image

Avant de pouvoir activer DKIM, Microsoft vous demandera d'ajouter deux enregistrements CNAME à votre DNS.

En général, cela ressemble à ceci :

selector1._domainkey.votredomaine.com → selector1-votredomaine-com._domainkey.votredomaine.onmicrosoft.com

selector2._domainkey.votredomaine.com → selector2-votredomaine-com._domainkey.votredomaine.onmicrosoft.com

Une fois ces enregistrements publiés, retournez sur le portail d'administration et cliquez sur « Activer » pour DKIM. Une fois cette option activée, Microsoft commencera à signer tous les e-mails sortants à l'aide de DKIM.

Configuration automatisée de DKIM (avec PowerDMARC)

La configuration de DKIM peut s'avérer complexe, en particulier pour les administrateurs qui ne sont pas familiarisés avec les enregistrements CNAME et les formats de sélecteurs.

PowerDMARC simplifie ce processus en générant automatiquement les enregistrements DKIM adaptés à votre domaine, en proposant la publication automatique via DNS pour éviter les erreurs de saisie manuelle, et en mettant à disposition un outil de vérification DKIM permettant de s'assurer que le protocole DKIM est correctement activé

Comment configurer DMARC pour Office 365 ?

Une fois que SPF DKIM sont correctement configurés, vous pouvez passer à la configuration de DMARC. Dans Microsoft 365, cette procédure s'effectue au niveau du DNS, mais pour la mener à bien, il est nécessaire de bien comprendre votre environnement de messagerie, de choisir la politique appropriée et de surveiller les résultats avant de la mettre en application.

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

Avant de publier un enregistrement DMARC, vous devez avoir une vue d'ensemble complète des expéditeurs qui envoient des e-mails au nom de votre domaine. Il s'agit d'une des étapes les plus importantes, car omettre un expéditeur légitime peut entraîner des problèmes de livraison par la suite.

Vos sources d'envoi comprennent généralement :

• Microsoft 365 (Exchange Online)
• Plateformes de marketing (Mailchimp, HubSpot, etc.)
• Systèmes CRM (Salesforce)
• Outils d'assistance (Zendesk, Freshdesk)
• Applications ou serveurs internes

Si l'un de ces éléments n'est pas correctement authentifié via SPF DKIM, il échouera au test DMARC une fois que l'application de cette politique sera activée.

Étape 2 : Créer votre enregistrement DMARC

Un enregistrement DMARC est un enregistrement TXT publié dans votre DNS. Il définit votre politique et indique aux serveurs destinataires comment traiter les e-mails dont l'authentification a échoué. Vous pouvez créer un enregistrement DMARC Office 365 unique pour votre domaine à l'aide de l'outil de génération instantanée d'enregistrements DMARC de PowerDMARC.

Un enregistrement DMARC de base se présente comme suit : v=DMARC1; p=none; rua=mailto:[email protected]; fo=1

Analysons cela :

v=DMARC1 – Spécifie la version DMARC
p=none – Mode de surveillance (pas d'application)
rua=mailto:[email protected] – Adresse à laquelle les rapports agrégés sont envoyés
fo=1 – Active la notification des échecs

C'est le point de départ recommandé, car cela vous permet de collecter des données sans nuire à la délivrabilité des e-mails.

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

Une fois votre enregistrement prêt, vous devez l'ajouter à votre DNS.

Utilisez les paramètres suivants :

Type d'enregistrement : TXT
Hôte/Nom : _dmarc
Valeur : Votre enregistrement DMARC
TTL : 1 heure (ou valeur par défaut)

Étape 4 : Surveiller les rapports DMARC

Une fois le protocole DMARC activé avec une politique p=none, vous commencerez à recevoir des rapports de la part 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 généralement envoyés au format XML et peuvent être difficiles à interpréter manuellement. Sans une analyse appropriée, il est facile de passer à côté de configurations erronées ou d'expéditeurs non autorisés.

Étape 5 : Passer progressivement à la mise en application

Une fois que vous aurez examiné vos rapports et vérifié que tous les expéditeurs légitimes sont correctement authentifiés, vous pourrez commencer à renforcer votre politique DMARC.

Voici à quoi ressemble généralement le déroulement :

Commencez par la surveillance : v=DMARC1; p=none; rua=mailto:[email protected]

↓

Envoyer en quarantine les e-mails suspects sont redirigés vers le dossier spam) : v=DMARC1;quarantine; rua=mailto:[email protected];

↓

Enfin, appliquer le rejet : v=DMARC1 ; p=reject ; rua=mailto:[email protected] ; adkim=r ; aspf=r

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

La procédure peut varier 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 qui va de la surveillance à quarantine au rejet. La durée de chaque phase dépend de la complexité de votre environnement de messagerie, mais sauter des étapes augmente le risque d'échecs de livraison involontaires.

Comment Exchange Online gère les messages DMARC entrants

Exchange Online Protection évalue automatiquement le protocole DMARC sur tous les messages entrants et, depuis juillet 2023, Microsoft applique 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 le paramètre «Respecter la politique d'enregistrement DMARC lorsque le message est détecté comme étant une usurpation »de la politique anti-hameçonnage, qui est activé par défaut.

Source de l'image

Explication du comportement « oreject »

Avant juillet 2023, Microsoft appliquait une dérogation 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 courrier au niveau de la passerelle, EOP le redirigeait vers le dossier Courrier indésirable du destinataire et ajoutait la mention « oreject » dans l'en-tête.

Microsoft a pris cette décision délibérément, car les e-mails transférés et le trafic des listes de diffusion enfreignent souvent SPF DKIM pendant leur acheminement. Cela signifie qu’un message légitime qui passe l’authentification chez l’expéditeur d’origine peut échouer à cette authentification au moment où un destinataire secondaire le reçoit. Un rejet catégorique avec le paramètre « p=reject » aurait entraîné la suppression d’un volume important de courriers légitimes en même temps que les messages usurpés. Le dossier « Courrier indésirable » constituait un compromis : les destinataires pouvaient toujours récupérer le message si nécessaire, et la politique de l’expéditeur était techniquement respectée.

En contrepartie, les messages falsifiés qui auraient dû être rejetés continuaient d'arriver dans les boîtes de réception des utilisateurs (dans le dossier des courriers indésirables), où un destinataire distrait pouvait les ouvrir. Pour les équipes de sécurité, cela signifiait que l'application de DMARC ne semblait jamais aussi stricte que le laissait entendre la politique.

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

Depuis que le comportement par défaut a changé, 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 trois cas de figure :

1. L'option « Honor DMARC » est désactivée dans votre politique anti-hameçonnage.

Pour résoudre ce problème : vérifiez le paramètre dans Microsoft 365 Defender → Courrier électronique et collaboration → Stratégies de protection contre les menaces → Anti-hameçonnage → Paramètres d'usurpation d'identité. L'option est activée par défaut, mais elle peut être désactivée pour les locataires ayant migré depuis des configurations antérieures.

2. Le courrier transite par une passerelle tierce avant d'atteindre Microsoft 365.

Si votre serveur MX pointe vers un dispositif de sécurité (Proofpoint, Mimecast, etc.) qui transfère ensuite les messages vers EOP, Microsoft ne peut pas réévaluer le DMARC, sauf si vous activez le filtrage avancé pour les connecteurs dans le portail Defender. Sans cette option, EOP se fie à la décision de la passerelle en amont et rejette par défaut les e-mails non conformes.

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 de transport attribuant un niveau de confiance anti-spam (SCL -1) ne seront pas soumis à l'application de la politique DMARC, et le message arrivera dans la boîte de réception, quelle que soit la politique en vigueur.

Pour un traitement plus strict, activez la fonctionnalité « Spoof Intelligence » dans le portail Defender, en plus de l’option « Honor DMARC ». Spoof Intelligence évalue la réputation de l’expéditeur indépendamment du protocole DMARC et met en quarantaine les messages qui semblent constituer des tentatives d’usurpation d’identité, même si l’authentification est techniquement validée.

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

Pour les organisations qui souhaitent garantir le rejet des e-mails non conformes à DMARC, une règle de transport Exchange Online constitue le mécanisme le plus fiable.

Comment créer la règle :

1. Accédez au Centre d'administration Exchange → Flux de messagerie → Règles, puis créez une nouvelle règle.
2. Définissez la condition suivante : l'en-tête d'un 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. Définissez l'action : rejeter le message en fournissant une explication — saisissez par exemple « Le message n'a pas passé l'authentification DMARC et a été rejeté conformément à la politique de l'organisation. »
4. (Facultatif) Ajoutez une exception pour les expéditeurs internes de confiance ou les expéditeurs légitimes connus afin d'éviter les faux positifs.
5. Définissez le mode de la règle sur « Test avec conseils de stratégie » pendant la première semaine. Vérifiez les messages concernés dans l'historique des messages avant de passer au mode « Application ».

Pour plus d'informations, vous pouvez consulter la documentation détaillée de Microsoft sur les règles de flux de messagerie.

Quand utiliser cette approche :

Les règles de transport s'avèrent utiles lorsque la réglementation ou la politique interne exige le rejet effectif des messages non conformes, lorsque votre organisation constitue une cible de choix pour l'usurpation d'identité (secteur financier, juridique, communications de la direction), ou lorsque vous souhaitez garantir une cohérence entre les flux via le serveur MX direct et ceux transitant par une passerelle tierce.

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.

D'une manière générale, les exigences de Microsoft en matière d'expéditeurs d'e-mails s'inscrivent dans la tendance générale du secteur vers une authentification plus stricte et une plus grande responsabilité des expéditeurs. Cette mise à jour définit des seuils clairs, des mesures coercitives et des attentes qui, auparavant, étaient appliquées de manière plus souple.

Principales modifications apportées par Microsoft

• Obligation de mise en place du protocole DMARC 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 désormais disposer d'un enregistrement DMARC valide.
• S'applique à Outlook.com, Hotmail.com et Live.com: cette mesure vise spécifiquement l'écosystème de messagerie grand public de Microsoft, et pas seulement les locataires d'entreprise.
• Exigence minimale: DMARC avec p=none : même une politique de surveillance est acceptable, mais l'absence totale d'enregistrement DMARC n'est plus tolérée à grande échelle.
• Accent accru sur l'alignement des domaines: l'authentification seule ne suffit pas ; SPF DKIM doivent correspondre au domaine « De » visible pour que le test DMARC soit réussi.
• Rejet définitif pour non-conformité: les e-mails qui ne répondent pas aux exigences peuvent être bloqués avec le message suivant : 550 5.7.515 Accès refusé, le domaine d'origine [SendingDomain] ne répond pas au niveau d'authentification requis.

Cette modification permet à Microsoft de s'aligner sur Google et Yahoo, qui ont mis en place des exigences similaires en février 2024, ce qui signifie que les trois plus grands fournisseurs de messagerie imposent désormais tous une authentification aux expéditeurs de courriers en masse.

Des plateformes telles que PowerDMARC comblent cette lacune en proposant des programmes de conformité spécifiques, conçus pour répondre aux exigences des fournisseurs de messagerie sur l'ensemble de vos sources d'envoi.

Pourquoi Microsoft 365 ne suffit pas à lui seul

Si Microsoft 365 offre une protection efficace contre les menaces entrantes, il ne dispose que de fonctionnalités limitées pour gérer et surveiller le protocole DMARC à grande échelle – des fonctionnalités que proposent les plateformes dédiées à l'authentification des e-mails.

Absence de rapports lisibles par l'homme

Bien que Microsoft envoie désormais des rapports DMARC aux utilisateurs professionnels, il n'existe pas de système intégré permettant de regrouper et d'interpréter ces rapports de manière pertinente. Ces rapports sont envoyés au format XML et peuvent être difficiles à analyser sans outils spécialisés. Par conséquent, les entreprises ne savent souvent pas qui envoie des e-mails en leur nom ni 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 à la gestion continue

Une solution DMARC dédiée transforme les 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 pas en standard.

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

1. Aucun enregistrement DMARC publié

C'est le problème le plus courant. La mention « Aucun enregistrement DMARC publié » signifie en substance que votre domaine ne dispose pas d'enregistrement TXT DMARC dans le DNS, de sorte que les destinataires ne disposent d'aucune politique à appliquer.

Pour résoudre ce problème, commencez par

• Vérifiez cela à l'aide d'un outil de vérification DMARC.
• Si l'outil renvoie une erreur « Enregistrement DMARC manquant », la solution consiste à publier un enregistrement commençant par v=DMARC1; p=none; rua=mailto:[email protected] afin de pouvoir commencer à collecter des rapports avant de renforcer la politique.
• Une fois que vous maîtrisez votre configuration, vous pouvez progressivement passer à la mise en application tout en surveillant vos rapports.

2. Le transfert de messages enfreint SPF DKIM

Le transfert d'e-mails est la principale cause d'échec des e-mails légitimes. Lorsqu'un intermédiaire (liste de diffusion, service de transfert ou dispositif de sécurité) modifie un en-tête inclus dans la signature DKIM, celle-ci ne passe plus la vérification et le contrôle DKIM échoue. SPF échoue SPF en même temps, car l'adresse IP du serveur de transfert ne figure pas dans votre enregistrement.

Voici trois bonnes pratiques possibles pour résoudre ce problème :

• Il est préférable d'utiliser une signature conforme à DKIM dès l'origine, car DKIM résiste mieux au transfert que SPF les en-têtes ne sont pas réécrits
• Évitez d'utiliser le « Sender Rewriting Scheme » (SRS) comme solution, car SPF il corrige SPF il ne rétablit pas l'alignement du domaine « From », ce qui fait que DMARC continue d'échouer
• Configurez des générateurs de scellés ARC (Authenticated Received Chain) de confiance dans Microsoft Defender pour tout service de transfert qui modifie légitimement votre courrier. Microsoft tiendra compte du résultat de l'authentification en amont via la chaîne ARC plutôt que de rejeter purement et simplement le message.

3. SPF due à un nombre trop élevé de requêtes DNS

Si SPF cesse SPF de fonctionner pour toutes les sources légitimes et renvoie une erreur permanente, la cause sous-jacente est généralement d'ordre structurel plutôt que liée à la configuration.

Il peut y avoir deux causes possibles à cela :

• Tout d'abord, vous avez dépassé la limite de 10 requêtes SPF pour les mécanismes include, a, mx, redirect, exists et ptr. Les requêtes imbriquées dans les en-têtes include des fournisseurs comptent également, de sorte qu'un enregistrement qui semble correct à première vue peut en réalité en compter 12 ou 13. Lorsque cette limite est dépassée, tous les destinataires renvoient une erreur permanente (permerror), et l'alignement DMARC SPF s'effondre d'un seul coup pour l'ensemble du domaine.

Que faire : commencez par vérifier votre fichier à l'aide d'un outil SPF et supprimez les fournisseurs que vous n'utilisez plus. Mais il ne s'agit là que d'une solution temporaire. Une solution à long terme consiste à utiliser une solution SPF hébergée telle que PowerSPF, dotée d'une optimisation SPF pour une gestion dynamique SPF .

• La deuxième cause, si vous constatez des erreurs « temperror » visant spécifiquement des destinations Microsoft, pourrait être liée à des délais d'attente DNS. Si ces délais d'attente surviennent sur une entrée spécifique, c'est ce fournisseur qu'il faut supprimer ou retirer de la liste.

4. Les politiques de « p=reject » ne sont pas respectées

Depuis juillet 2023, Microsoft applique par défaut la politique « p=reject », c'est-à-dire qu'un message présentant une erreur doit être rejeté d'emblée. Si ce n'est pas le cas, l'une des quatre situations suivantes est en cause :

• La prise en compte de DMARC peut être désactivée dans votre politique anti-hameçonnage: assurez-vous que l'option « Respecter la politique d'enregistrement DMARC lorsque le message est détecté comme étant usurpé » est activée, et que l'action pour p=reject est définie sur Rejeter (et non sur Quarantine).
• Une passerelle tierce est déployée en amont de Microsoft 365: si votre enregistrement MX pointe vers une passerelle de sécurité tierce, Microsoft n'appliquera pas le protocole DMARC, sauf si vous activez le filtrage avancé pour les connecteurs.
• L'authentification composite a pris le pas sur le résultat: Microsoft superpose des signaux de réputation au protocole DMARC. Un message peut échouer au test DMARC tout en étant livré si compauth=pass
  (Pour en savoir plus, consultez la communauté d'apprentissage de Microsoft).
• Une règle d'autorisation de locataire contourne le filtrage: un expéditeur figurant sur la liste blanche, un connecteur entrant de confiance ou une règle attribuant un niveau de confiance anti-spam (SCL) de 1 ne sera pas soumis à l'application de la politique DMARC.

Aller de l'avant avec DMARC sur Microsoft 365

Le protocole 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 modifications apportées à l'application de la norme en mai 2025 rendent cette responsabilité d'autant plus urgente pour tous ceux qui envoient des e-mails en grand nombre.

La méthode la plus sûre est celle qui prend du temps : commencez par définir p=none, surveillez vos rapports pendant deux à quatre semaines, corrigez les expéditeurs identifiés, puis passez àquarantine enfin à p=reject. Le fait de sauter des étapes est la cause la plus fréquente de dysfonctionnement du courrier légitime lors de la mise en place.

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 ; autant de changements susceptibles de compromettre discrètement l'alignement si personne ne surveille les rapports. C'est là qu'une plateforme DMARC dédiée prend tout son sens. Les outils de reporting et d'analyse de PowerDMARC transforment les données XML brutes en informations exploitables et signalent les écarts avant qu'ils ne se traduisent par un problème de délivrabilité.

Commencez par vérifier votre enregistrement DMARC actuel pour savoir où vous en êtes aujourd'hui.

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.

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

Oui, Microsoft impose l'utilisation de DMARC aux expéditeurs à fort volume. Il est également vivement recommandé à toutes les organisations d'y recourir pour garantir la délivrabilité et la sécurité.

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

Cette erreur indique que vos e-mails sont rejetés en raison de politiques DMARC manquantes ou non conformes aux règles d'application de Microsoft.

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

Microsoft a toujours utilisé une règle de contournement interne appelée « oreject » (rejet à la source), qui redirige les messages non conformes à la norme DMARC vers le dossier Courrier indésirable au lieu de les rejeter d'emblée au niveau de la passerelle. Cette mesure visait à protéger les expéditeurs légitimes contre toute perte accidentelle, mais elle rend les messages usurpés visibles pour les destinataires.

Deux choses à savoir :

1) Depuis les modifications apportées aux règles d'application en mai 2025, Microsoft s'oriente vers un rejet plus strict et définitif des expéditeurs à fort volume.

2) Si vous souhaitez garantir le rejet des messages au sein de votre propre tenant Microsoft 365, créez une règle de transport Exchange qui rejette systématiquement les messages.

Dois-je choisir « quarantine « Refuser » ?

Commencez par la surveillance (p = aucune) pour contrôler vos sources d'envoi et vos canaux de messagerie, passez ensuite à quarantine, et n'utilisez le rejet que lorsque vous êtes certain que toutes les sources légitimes sont bien identifiées.

• À propos de
• Derniers messages

Yunes Tarada

Expert en sécurité des domaines et des courriels 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)

• Windows Defender suffit-il pour assurer la sécurité des petites entreprises ? - 14 mai 2026
• DMARCbis expliqué : ce qui change et comment s'y préparer - 16 avril 2026
• Le format du numéro de série SOA n'est pas valide : causes et solutions - 13 avril 2026