Qu'est-ce qu'une politique DMARC ? Aucune, Quarantine et Rejet

La fraude par e-mail est l'une des cybermenaces les plus persistantes et les plus préjudiciables auxquelles les entreprises sont confrontées aujourd'hui. Selon le rapport de Verizon sur les enquêtes relatives aux violations de données, le phishing reste l'une des principales causes de fuites de données, et la plupart des attaques commencent par l'utilisation d'un domaine de messagerie usurpé.

Une politique DMARC constitue votre première ligne de défense. Définie dans la RFC 7489, le DMARC (Domain-based Message Authentication, Reporting, and Conformance) est un protocole d'authentification des e-mails qui indique aux serveurs de messagerie destinataires comment réagir lorsqu'un e-mail échoue aux contrôles d'authentification. Sans lui, les pirates peuvent librement usurper l'identité de votre domaine pour cibler vos clients, vos employés et vos partenaires.

Ce guide explique en détail ce qu'est une politique DMARC, présente les trois options disponibles, décrit comment la mettre en œuvre et l'appliquer correctement, et indique comment éviter les pièges courants qui laissent la plupart des entreprises sans protection.

Qu'est-ce qu'une politique DMARC ?

Une politique DMARC est un ensemble d'instructions publiées dans votre DNS qui indique aux serveurs de messagerie destinataires comment traiter les e-mails qui échouent à l'authentification DMARC. En termes simples, il s'agit de la couche d'application du protocole DMARC qui détermine le sort de chaque message non authentifié prétendant provenir de votre domaine.

Sans politique DMARC, votre domaine de messagerie est pratiquement une porte ouverte. Les cybercriminels peuvent envoyer des e-mails frauduleux qui semblent provenir de votre organisation, ciblant vos clients et vos employés avec des attaques de phishing.

Comment fonctionne une politique DMARC ?

Une politique DMARC fonctionne en fournissant aux serveurs de messagerie destinataires un ensemble de règles claires à suivre chaque fois qu'un e-mail échoue à l'authentification DMARC. Voici exactement comment ce processus se déroule, de l'envoi jusqu'à la boîte de réception.

Le processus d'authentification, étape par étape :

1. Un expéditeur envoie un e-mail prétendant provenir de votre domaine.
2. Le serveur de messagerie destinataire effectue des contrôles d'authentification SPF DKIM sur le message.
3. Si le message satisfait à l'une ou l'autre de ces vérifications et que le domaine correspond à l'en-tête « From », il passe l'authentification DMARC et arrive dans la boîte de réception du destinataire.
4. Si le message échoue aux vérifications DMARC, le serveur lit votre enregistrement DMARC à partir de vos enregistrements DNS.
5. En fonction de votre politique DMARC publiée, le serveur achemine, met en quarantaine ou rejette le message non authentifié.
6. Le serveur destinataire renvoie les rapports agrégés DMARC à l'adresse indiquée dans votre enregistrement DMARC.

DMARC vérifie également que le domaine authentifié correspond bien au domaine indiqué dans l'en-tête « From ». C'est ce qu'on appelle l'alignement des identifiants, et c'est ce qui comble la faille permettant aux attaquants d'utiliser un domaine similaire pour contourner les contrôles d'authentification de base des e-mails.

Sans alignement, un acteur malveillant pourrait faire passer SPF un domaine tout en usurpant l'identité d'un tout autre domaine dans l'adresse d'expéditeur que vos destinataires voient réellement.

Avant de configurer DMARC

Vous devez avoir déployé et activé SPF DKIM depuis au moins 48 heures avant de configurer votre enregistrement DMARC. Si ces protocoles ne sont pas en place, votre politique DMARC n'aura aucun élément sur lequel s'appuyer pour effectuer la validation.

Il est également utile de comprendre le fonctionnement du DNS avant de commencer à publier des enregistrements, car des enregistrements DNS TXT mal configurés constituent l'une des causes les plus courantes d'échecs DMARC.

Lecture recommandée : Statistiques sur le phishing par e-mail et le DMARC : tendances en matière de sécurité pour 2026

Les 3 options de la politique DMARC

Il existe trois options de politique : p=none,quarantine et p=reject. Chacune correspond à un niveau différent d' application de DMARC. C'est le choix de la bonne option au bon moment qui distingue les organisations véritablement protégées de celles qui pensent simplement l'être.

1. p = aucun

L'option « p=none » est la politique DMARC la plus souple. Elle indique aux serveurs destinataires de ne prendre aucune mesure concernant les e-mails qui échouent à l'authentification DMARC. Chaque message, qu'il réussisse ou échoue l'authentification, est remis normalement dans la boîte de réception du destinataire. Aucun message n'est bloqué, aucun n'est signalé comme suspect.

Sa seule fonction est de générer des rapports agrégés DMARC, afin que vous puissiez voir qui envoie des e-mails au nom de votre domaine, combien de messages passent ou échouent à l'authentification, et quelles adresses IP pourraient usurper votre domaine.

La valeur « p=none » n'offre aucune protection contre l'usurpation d'adresse e-mail, car :

• Les e-mails non autorisés continuent d'être transmis
• Les messages frauduleux continuent d'arriver dans les boîtes de réception
• Les pirates peuvent utiliser votre domaine à leur guise

C'est un bon point de départ, mais ce n'est pas une fin en soi. La plupart des entreprises ne vont jamais plus loin que « p=none », se laissant ainsi totalement sans protection. Si votre politique DMARC n'est pas activée au-delà du mode de surveillance, votre domaine reste grand ouvert.

2. p =quarantine

quarantine la politique d'application transitoire. Elle demande au serveur de messagerie destinataire de traiter avec méfiance les messages dont l'authentification a échoué et de les rediriger vers le dossier « spam » ou « courrier indésirable » du destinataire plutôt que vers la boîte de réception.

Les e-mails qui passent l'authentification DMARC ne sont absolument pas affectés. Seuls les messages non authentifiés sont considérés comme suspects et sont retirés de la boîte de réception.

La quarantine vous permet une application stricte tout en offrant une marge de sécurité. Si une source d'e-mails légitime a été mal configurée et commence à échouer aux vérifications DMARC, elle est redirigée vers le dossier spam plutôt que d'être rejetée d'emblée. Vous pouvez ainsi la récupérer, résoudre le problème et éviter de perturber votre flux d'e-mails.

Vous ne devriez passer àquarantine avoir analysé en détail vos rapports DMARC et vérifié que tous les expéditeurs légitimes connus sont correctement authentifiés.

3. p = rejet

La politique « p=reject » est la plus stricte des politiques DMARC et la référence en matière de sécurité des e-mails. Elle ordonne aux serveurs destinataires de rejeter systématiquement les messages non authentifiés. Les e-mails frauduleux n'atteignent jamais la boîte de réception, le dossier spam ni aucun autre emplacement.

Arrêts complets (p=reject) l'usurpation de domaine , protège la réputation de votre marque et indique aux fournisseurs de messagerie que votre domaine est fiable, ce qui peut améliorer le placement de vos e-mails légitimes dans la boîte de réception.

Cependant, le paramètre « p=reject » est impitoyable. Tout expéditeur légitime qui n'aura pas été correctement authentifié avant que vous n'adoptiez cette politique verra ses e-mails rejetés. Vous devez vous assurer que tous les expéditeurs légitimes figurent sur la liste blanche et passent l'authentification DMARC avant de mettre cette mesure en place.

Autres balises de politique DMARC à connaître

Si l'attribut « p= » retient généralement toute l'attention, un enregistrement DMARC contient plusieurs autres paramètres de politique qui influent directement sur le fonctionnement de votre politique. Le fait de les négliger est l'une des raisons pour lesquelles les organisations se retrouvent avec des failles dans leur protection, même après avoir publié un enregistrement DMARC.

sp= (Politique de sous-domaine)

La balise sp= détermine comment votre politique DMARC s'applique aux sous-domaines. Si vous avez défini une politique sur votre domaine racine mais que vous laissez sp= , vos sous-domaines héritent par défaut de la politique du domaine racine. Cela convient dans la plupart des cas, mais si vous souhaitez appliquer un niveau d'application différent aux sous-domaines, vous devez le définir explicitement.

Par exemple, si votre domaine racine est défini sur p=reject mais qu'un sous-domaine n'est pas encore prêt pour une application stricte de la politique, vous pouvez définirquarantine y appliquer une politique plus souple.

pct = (balise de pourcentage)

La balise pct= indique aux serveurs destinataires à quel pourcentage des messages rejetés votre politique doit s'appliquer. Si elle n'est pas spécifiée, la valeur par défaut est 100. Cette balise est particulièrement utile lors du passage dequarantine p=reject.

Au lieu d'activer le commutateur pour l'ensemble du trafic d'un seul coup, vous pouvez commencer par pct=10 ou pct=25, puis augmenter progressivement ce pourcentage tout en surveillant vos rapports.

adkim= et aspf= (modes d'alignement)

Ces deux balises déterminent le niveau de rigueur avec lequel DMARC vérifie la cohérence du domaine pour DKIM et SPF respectivement. Les deux options sont r (assoupli) et s (strict). L'alignement assoupli autorise une correspondance de sous-domaine, ce qui signifie que mail.votredomaine.com passerait l'alignement pour votredomaine.com.

L'alignement strict exige une correspondance exacte. La plupart des organisations devraient opter pour l'alignement souple, qui est le réglage par défaut lorsque ces balises sont omises.

fo= (Options de signalement des défaillances)

La balise fo= détermine quand les rapports d'analyse DMARC sont générés. La valeur par défaut est 0, ce qui signifie qu'un rapport n'est envoyé que lorsque SPF DKIM échouent tous les deux. En définissant fo=1, un rapport est envoyé dès que SPF DKIM échoue.

Le paramètre fo=s ou fo=d génère respectivement des rapports spécifiques aux échecs SPF DKIM. Pour une meilleure visibilité lors du dépannage, le paramètre fo=1 est le plus utile.

Comparaison des politiques DMARC : p=none,quarantine p=reject

Il est plus facile de choisir entre les trois options de politique DMARC lorsque vous pouvez les comparer côte à côte. Utilisez ce document comme référence rapide pour déterminer quelle politique correspond à votre stade actuel de mise en œuvre de DMARC.

La plupart des organisations devraient considérer cela comme un processus progressif : commencer par p=none, analyser leurs rapports DMARC, corriger les erreurs de configuration, passer àquarantine, puis passer à p=reject une fois que toutes les sources d'e-mails légitimes ont été vérifiées.

Comment passer de p=none à p=reject

Le passage d'une configuration « p=none » à une application stricte de la politique DMARC est un processus progressif qui nécessite une analyse minutieuse de vos rapports à chaque étape. Une transition précipitée est la cause la plus fréquente du blocage d'e-mails légitimes.

Étape 1 : Publiez une entrée p=none et commencez à collecter des données

Commencez par publier un enregistrement DMARC avec p=none et une adresse rua= valide. Cela vous place en mode surveillance.

Tous les e-mails continuent d'être transmis normalement, mais vous commencez à recevoir des rapports agrégés DMARC indiquant qui envoie des messages depuis votre domaine, quels messages passent ou échouent à l'authentification, et quelles adresses IP sont concernées.

Étape 2 : Analysez vos rapports agrégés DMARC

Les rapports bruts agrégés sont fournis sous forme de fichiers XML et ne sont pas faciles à lire manuellement. Utilisez un analyseur de rapports DMARC pour les analyser et les transformer en tableaux de bord lisibles.

Recherchez tous les expéditeurs légitimes envoyant depuis votre domaine, les adresses IP qui échouent de manière inattendue aux vérifications DMARC, les problèmes d'alignement SPF DKIM chez des expéditeurs légitimes connus, ainsi que les expéditeurs non autorisés qui tentent d'usurper votre domaine.

Surveillez ces résultats d'authentification DMARC pendant au moins deux à quatre semaines avant de modifier vos politiques. Les rapports agrégés de PowerDMARC vous permettent de suivre facilement ces tendances au fil du temps.

Étape 3 : Corriger les problèmes de compatibilité SPF DKIM

Pour chaque source de courrier légitime qui échoue aux vérifications DMARC, identifiez la cause profonde et corrigez-la. Les solutions courantes consistent notamment à ajouter les adresses IP manquantes à votre SPF , à configurer la signature DKIM pour les services de messagerie tiers et à corriger les erreurs de configuration dans les flux de messagerie transférés.

Des vérifications régulières des rapports DMARC vous permettent de détecter ces problèmes avant qu'ils n'entraînent des difficultés de livraison.

Étape 4 : Ajouter tous les expéditeurs légitimes à la liste blanche

Avant de mettre en place toute politique d'application, toutes les sources d'e-mails légitimes doivent passer l'authentification DMARC de manière systématique. Si un seul expéditeur fait défaut à ce stade, ces e-mails risquent d'être rejetés dès que vous appliquerez le paramètre p=reject.

Étape 5 : Passer àquarantine 10 et 25 %

Utilisez la balise pct= pour appliquer d'abord votre nouvelle politique à un pourcentage des messages rejetés. Commencez parquarantine pct=25 et surveillez attentivement vos rapports.

Si des e-mails légitimes se retrouvent dans le dossier des spams, cela signifie qu'il y a un problème avec l'expéditeur qu'il faut résoudre avant de continuer.

Étape 6 : Régler le paramètre p (quarantine 100 %

Une fois que vous êtes certain que les messages rejetés représentant 25 % sont bel et bien non autorisés, augmentez ce pourcentage jusqu'à 100 % et poursuivez la surveillance.

Étape 7 : Passer à p=reject

Une fois quequarantine correctement à 100 % sans bloquer aucun message légitime, vous êtes prêt à passer à une application stricte. Tous les messages non authentifiés seront désormais bloqués avant leur remise.

Le service DMARC hébergé de PowerDMARC service DMARC hébergé peut gérer l'intégralité de cette transition pour vous, en automatisant les mises à jour des politiques sans nécessiter de modifications manuelles du DNS à chaque étape.

Rapports DMARC : rapports agrégés vs rapports d'analyse approfondie

Les rapports DMARC vous permettent de transformer votre politique en un outil de veille opérationnel. Si vous ne les consultez pas, vous ne saurez pas qui utilise votre domaine, ce qui ne fonctionne pas, ni si votre politique est efficace.

Il existe deux types de rapports, qui ont des objectifs très différents.

Erreurs courantes dans les politiques DMARC et comment les corriger

La mise en œuvre du protocole DMARC peut s'avérer complexe, et de petites erreurs de configuration ont souvent des conséquences disproportionnées. Voici les erreurs les plus courantes et comment y remédier rapidement.

Enregistrement TXT DMARC manquant ou incorrect

Si vous publiez sous un nom d'hôte incorrect, si la balise v=DMARC1 est manquante ou si vous créez des enregistrements en double, les serveurs destinataires ignoreront complètement votre politique. Parmi les erreurs courantes concernant le nom d'hôte, on peut citer l'utilisation de dmarc.votredomaine.com au lieu de _dmarc.votredomaine.com.

Solution : Vérifiez votre enregistrement à l'aide de l'outil DMARC Record Checker de PowerDMARC avant et après toute modification du DNS.

SPF DKIM ne sont pas synchronisés

Vos vérifications SPF DKIM peuvent toutes deux aboutir, mais vos messages échoueront tout de même au test DMARC si le domaine authentifié ne correspond pas à l'en-tête « From ». Il s'agit là d'un des points de défaillance les plus souvent mal compris dans la mise en œuvre de DMARC.

Solution : Vérifiez vos paramètres d'alignement adkim= et aspf= dans votre enregistrement DMARC. L'alignement assoupli est le paramètre par défaut approprié pour la plupart des organisations et permet des correspondances de sous-domaines sans exiger une correspondance exacte du domaine.

Les e-mails légitimes ne parviennent plus à l'adresse de destination après le passage au mode de validation

Cela signifie presque toujours qu'un expéditeur légitime a échappé au contrôle lors de la phase de surveillance et qu'il est désormais bloqué par votre politique plus stricte.

Solution : Revenez au niveauquarantine une valeur pct= faible pendant que vous menez votre enquête. Identifiez l'expéditeur défaillant dans vos rapports agrégés, corrigez sa configuration SPF DKIM, vérifiez qu'il passe systématiquement les contrôles, puis remontez progressivement le niveau.

Dépassement des limites de recherche SPF

SPF nombreSPF est limité à 10 recherches DNS. Si vous acheminez suffisamment de messages via des plateformes tierces, vous dépasserez cette limite, ce qui entraînera SPF et provoquera directement des échecs DMARC pour les e-mails légitimes.

Solution : Vérifiez votre SPF et utilisez SPF automatisée SPF pour simplifier votre enregistrement et rester dans les limites de recherche.

Aucune adresse de rapport n'est configurée

Sans adresse rua= valide, vous disposez certes d'une politique déployée, mais vous ne pouvez pas savoir si elle fonctionne, ce qui ne fonctionne pas, ni si des activités d'usurpation d'identité ont lieu sur votre domaine.

Solution : Veillez à toujours inclure une adresse rua= valide dès le premier jour. Si vous gérez plusieurs domaines, utilisez une plateforme de reporting centralisée pour regrouper vos rapports DMARC agrégés en un seul endroit.

Protégez votre domaine avec PowerDMARC

L'efficacité d'une politique DMARC dépend entièrement de la manière dont elle est mise en œuvre. Les étapes techniques sont simples. Mais c'est dans le travail continu consistant à analyser les rapports, à corriger les erreurs de configuration, à ajouter les expéditeurs légitimes à la liste blanche et à passer en toute sécurité à la phase d'application que la plupart des organisations peinent à s'en sortir.

PowerDMARC a été conçu pour faciliter la gestion de l'ensemble de ce processus. De la création de votre premier enregistrement DMARC à la mise en œuvre complète de la politique « p=reject », la plateforme prend en charge chaque étape. Elle inclut la gestion hébergée des politiques, des tableaux de bord de reporting automatisés, des alertes de menaces en temps réel, ainsi que la surveillance SPF DKIM sur l'ensemble de vos domaines.

Les entreprises qui utilisent PowerDMARC passent plus rapidement de « p=none » à « p=reject », tout en perturbant moins le trafic de courriels légitimes et en bénéficiant d'une visibilité totale sur chaque expéditeur utilisant leur domaine.

Votre nom de domaine, c'est votre marque. Ne le laissez pas sans protection.

Réservez une démonstration pour faire dès aujourd'hui le premier pas vers une authentification et une mise en œuvre complètes des e-mails.

FAQ

1. Quelle est la politique DMARC par défaut ?

Il n'y a pas de politique DMARC par défaut. En l'absence d'enregistrement DMARC, les serveurs destinataires n'effectueront pas de vérifications DMARC. Lorsque vous créez un enregistrement DMARC pour la première fois, il est recommandé de commencer par p=none à des fins de surveillance.

2. Les politiques DMARC peuvent-elles avoir une incidence sur la délivrabilité des e-mails ?

Oui, les politiques DMARC peuvent améliorer le taux de délivrabilité de 10 à 15 % lorsqu'elles sont correctement mises en œuvre, car les fournisseurs de messagerie accordent davantage de confiance aux domaines authentifiés. Cependant, une mise en œuvre incorrecte peut entraîner la mise en quarantaine ou le rejet d'e-mails légitimes.

3. Quelle est la différence entre SPF, DKIM et DMARC ?

SPF le serveur expéditeur est autorisé, le protocole DKIM garantit l'intégrité des messages grâce à des signatures cryptographiques, tandis que le protocole DMARC assure l'application des politiques et la génération de rapports en s'appuyant sur les résultats des protocoles SPF DKIM.

4. Combien de temps dois-je rester sur le niveau « p=none » avant de passer à des règles plus strictes ?

Conservez la valeur « p=none » pendant au moins 30 jours afin de recueillir des rapports DMARC complets. Pour les organisations complexes disposant de plusieurs sources de messagerie, prévoyez une période de 60 à 90 jours afin de garantir que tous les expéditeurs légitimes soient identifiés et correctement authentifiés.

5. Quelle est la meilleure politique DMARC ?

La politique p=reject est la plus stricte, car elle empêche la livraison de tous les e-mails non autorisés. Cela dit, passer directement à p=reject comporte des risques. Il est recommandé de commencer par p=none pour surveiller votre trafic de messagerie, de passer àquarantine vous avez identifié tous vos expéditeurs légitimes, et de n'appliquer p=reject que lorsque vous êtes certain que tous les messages légitimes sont correctement authentifiés.

6. Comment puis-je corriger ma politique DMARC ?

Vous pouvez mettre à jour votre politique DMARC en modifiant directement votre enregistrement TXT DMARC dans votre console de gestion DNS et en modifiant la valeur de la balise « p= ». Si vous préférez une solution plus simple, le service DMARC hébergé de PowerDMARC vous permet de mettre à jour votre politique en un seul clic.

7. Quelle politique DMARC utiliseriez-vous pour rejeter les e-mails qui ne passent pas les vérifications DMARC ?

Utilisez p=reject. Cela indique aux serveurs de messagerie destinataires de bloquer immédiatement tout message qui échoue à l'authentification DMARC. L'e-mail n'arrivera ni dans la boîte de réception ni dans le dossier des spams du destinataire. Si vous souhaitez que les e-mails non conformes soient redirigés vers le dossier des spams plutôt que d'être bloqués, utilisezquarantine .

• À propos de
• Derniers messages

Maitham Al Lawati

Expert en cybersécurité, PDG de PowerDMARC

Maitham est un entrepreneur technologique, expert en cybersécurité, PDG et fondateur de PowerDMARC avec plus de 15 ans d'expérience dans l'industrie. Maitham est titulaire d'un Global MBA de l'Université de Manchester et de diverses certifications professionnelles, notamment CISSP, CISM, CRISC et ISC2 CCSP.

Derniers messages de Maitham Al Lawati (voir tous)

• Statistiques sur le phishing et le DMARC : tendances 2026 en matière de sécurité des e-mails - 6 janvier 2026
• Comment corriger « Aucun SPF trouvé » en 2026 - 3 janvier 2026
• SPF : comment corriger un nombre trop élevé de requêtes DNS - 24 décembre 2025