La politique DMARC détermine ce que les serveurs de messagerie sont invités à faire lorsqu'un email utilisant votre domaine échoue au contrôle DMARC. p=none sert principalement à observer, p=quarantine demande de traiter les messages en échec comme suspects et p=reject demande de les rejeter. Le bon choix n'est donc pas forcément de passer immédiatement à reject : il dépend surtout de votre niveau de maîtrise des sources qui envoient des emails pour votre domaine.
DMARC est particulièrement efficace pour limiter l'usurpation d'un nom de domaine dans les emails. Mais une politique trop stricte activée avant d'avoir identifié tous vos expéditeurs légitimes peut également provoquer des rejets indésirables.
Avant de modifier votre politique, il faut donc comprendre précisément la différence entre none, quarantine et reject, puis progresser par étapes.
Que signifie la politique DMARC ?
Un enregistrement DMARC est publié dans le DNS du domaine, généralement sous la forme d'un enregistrement TXT situé sur _dmarc.votredomaine.fr.
Le paramètre p= indique la politique que le propriétaire du domaine souhaite voir appliquer aux messages qui échouent à DMARC.
Il existe trois valeurs principales :
p=none: aucune action DMARC particulière n'est demandée ;p=quarantine: les messages en échec doivent être considérés comme suspects ;p=reject: les messages en échec doivent normalement être rejetés.
Pour qu'un message passe DMARC, il doit notamment obtenir un alignement valide avec SPF ou DKIM. Avant de renforcer votre politique, assurez-vous donc que les services autorisés à envoyer des emails avec votre domaine sont correctement authentifiés. Si vous souhaitez reprendre les bases, consultez notre guide complet SPF, DKIM et DMARC.
Il faut également garder à l'esprit que DMARC exprime une politique au serveur destinataire. Le RFC DMARC précise que la décision finale de distribution reste du ressort du système de messagerie qui reçoit le message. Un serveur peut donc appliquer ses propres mécanismes de sécurité en complément de DMARC.
p=none : observer avant d'agir
Avec p=none, le propriétaire du domaine ne demande aucune action particulière contre les messages qui échouent à DMARC.
Cette politique est particulièrement utile lors de la mise en place de DMARC. Elle permet d'observer l'utilisation du domaine sans demander immédiatement le placement en quarantaine ou le rejet des messages en échec.
Avec une adresse de rapport définie dans le paramètre rua, vous pouvez recevoir des rapports agrégés permettant d'identifier les serveurs qui envoient des emails en utilisant votre domaine.
Cela permet notamment de repérer un CRM, un logiciel de facturation, une plateforme d'emailing, un site Internet ou un service externe qui n'aurait pas encore été correctement configuré.
Cette valeur signifie seulement que votre domaine ne demande pas de traitement DMARC particulier en cas d'échec. Les filtres antispam, les systèmes anti-phishing et les autres règles du serveur destinataire continuent à s'appliquer.
p=quarantine : traiter les échecs comme suspects
Avec p=quarantine, vous demandez aux serveurs destinataires de considérer comme suspects les messages qui échouent au contrôle DMARC.
Selon le fournisseur de messagerie, le message peut par exemple être placé dans les courriers indésirables, mis en quarantaine ou soumis à des contrôles supplémentaires.
p=quarantine constitue donc souvent une étape intermédiaire entre l'observation avec p=none et une politique plus stricte avec p=reject.
Elle permet de commencer à agir contre l'usurpation du domaine tout en conservant une marge de surveillance avant de demander le rejet systématique des messages non conformes.
p=reject : demander un traitement strict des échecs DMARC
p=reject exprime la politique DMARC la plus stricte. Le propriétaire du domaine indique qu'il considère les messages qui échouent à DMARC comme une utilisation non valide de son domaine.
Dans de nombreux environnements, cette politique conduit au rejet des messages en échec. Le RFC 9989 précise toutefois que la décision finale appartient au serveur destinataire et qu'un message ne doit pas être rejeté sur le seul critère p=reject sans tenir compte d'autres éléments d'analyse.
Cette politique apporte une protection forte contre certaines formes d'usurpation du domaine, mais elle nécessite une configuration maîtrisée et une bonne connaissance des flux légitimes.
Si une plateforme autorisée, une redirection ou certains usages comme les listes de diffusion provoquent encore des échecs DMARC, une politique p=reject peut entraîner des problèmes de délivrabilité. Il faut donc mesurer son impact avant de la généraliser.
none, quarantine ou reject : le comparatif
| Politique | Action demandée | Usage principal | Risque si la configuration est incomplète |
|---|---|---|---|
p=none |
Aucune action DMARC spécifique | Observer et analyser les sources d'envoi | Faible impact sur les emails légitimes, mais aucune politique de quarantaine ou de rejet n'est demandée |
p=quarantine |
Traiter les échecs comme suspects | Renforcer progressivement la protection | Des emails légitimes mal authentifiés peuvent finir en indésirables ou en quarantaine |
p=reject |
Rejeter les échecs DMARC | Appliquer une politique stricte contre l'usurpation | Des emails légitimes peuvent être rejetés si toutes les sources d'envoi ne sont pas correctement configurées |
Quelle politique DMARC choisir ?
La meilleure politique n'est pas la même à toutes les étapes du déploiement.
Vous venez d'activer DMARC
Commencez généralement par p=none. L'objectif est d'identifier les différentes sources qui utilisent votre domaine et de vérifier leur authentification avant d'appliquer une politique plus restrictive.
Vos principaux expéditeurs sont identifiés
p=quarantine permet de franchir une étape supplémentaire. Vous commencez à demander un traitement particulier des emails qui échouent à DMARC tout en surveillant les conséquences.
Toutes vos sources légitimes sont maîtrisées
Lorsque les flux d'envoi sont inventoriés, que SPF et DKIM sont correctement configurés et que les rapports ne font plus apparaître de sources légitimes en échec, vous pouvez envisager une politique plus stricte. p=reject peut être pertinent pour certains domaines très maîtrisés, notamment lorsqu'ils sont utilisés dans un contexte d'envoi contrôlé. Pour un domaine de messagerie utilisé directement par des utilisateurs, il faut également tenir compte des redirections, des listes de diffusion et des autres situations susceptibles de provoquer des échecs DMARC légitimes.
Ne choisissez pas votre politique uniquement en fonction du niveau de protection affiché. Choisissez-la en fonction de votre capacité à identifier et authentifier correctement tous les services qui envoient des emails au nom de votre domaine.
Comment renforcer progressivement sa politique DMARC ?
Microsoft recommande notamment un déploiement progressif de DMARC : observer d'abord les rapports, corriger les sources d'envoi, puis passer progressivement de none à quarantine et enfin à reject.
Publiez DMARC en p=none
Activez les rapports agrégés avec rua afin d'identifier les serveurs qui utilisent votre domaine.
Inventoriez vos sources légitimes
Vérifiez vos serveurs de messagerie mais aussi les outils annexes : CRM, facturation, formulaires du site, newsletters, support client ou applications métier.
Corrigez SPF, DKIM et l'alignement DMARC
Un service autorisé à envoyer des emails pour votre entreprise doit être correctement authentifié. Contrôlez en particulier le domaine utilisé par SPF et celui de la signature DKIM.
Passez à quarantine et surveillez
Observez les effets du changement et continuez à analyser vos rapports. Si des sources légitimes échouent encore, corrigez-les avant de poursuivre.
Évaluez p=reject lorsque la configuration est maîtrisée
Une fois les flux légitimes identifiés et conformes, vous pouvez demander le rejet des messages qui échouent à DMARC.
Les erreurs à éviter avec une politique DMARC
La première erreur consiste à considérer p=reject comme un simple bouton de sécurité que l'on pourrait activer sans vérification préalable. Une entreprise utilise souvent davantage de sources d'envoi qu'elle ne l'imagine.
Un serveur Microsoft 365 ou Google Workspace peut être parfaitement configuré alors qu'un logiciel de facturation, une plateforme marketing ou un formulaire du site utilise une autre infrastructure.
La deuxième erreur consiste à publier DMARC puis à ne jamais consulter les rapports. Avec p=none, ces données constituent justement l'un des principaux outils permettant de préparer la suite du déploiement.
Enfin, ne considérez pas DMARC comme un filtre antispam. DMARC traite principalement de l'authentification et de l'utilisation de votre domaine dans le champ expéditeur. Il ne détermine pas à lui seul si le contenu d'un message est légitime, publicitaire, malveillant ou indésirable.
Ce que disent les standards et les grands fournisseurs
Depuis mai 2026, le RFC 9989 constitue le standard DMARC de référence et remplace notamment le RFC 7489. Il conserve les trois politiques none, quarantine et reject, tout en précisant que la politique publiée constitue une préférence du propriétaire du domaine et que la décision finale de traitement appartient au serveur destinataire.
Microsoft recommande toujours une mise en œuvre progressive, en commençant par l'observation des rapports avant de renforcer la politique. Google exige SPF ou DKIM pour les expéditeurs et SPF, DKIM ainsi que DMARC pour les expéditeurs de gros volumes. Yahoo impose également SPF et DKIM ainsi qu'une politique DMARC au minimum en p=none pour ses expéditeurs de gros volumes.
Questions fréquentes sur les politiques DMARC
Quelle politique DMARC choisir pour commencer ?
p=none permet généralement d'observer les flux et d'analyser les rapports DMARC sans demander le rejet des messages en échec. L'objectif est d'identifier toutes les sources légitimes avant de passer progressivement à quarantine, puis éventuellement à reject.Est-ce que p=none protège mon domaine contre l'usurpation ?
p=none permet de publier DMARC et de collecter des informations, mais ne demande pas au serveur destinataire de mettre en quarantaine ou de rejeter un message uniquement parce qu'il échoue à DMARC. Cette politique sert donc surtout à l'observation et à la préparation d'un déploiement plus strict.Quelle est la différence entre p=quarantine et p=reject ?
p=quarantine demande au serveur destinataire de traiter un message en échec DMARC comme suspect, par exemple en l'orientant vers les courriers indésirables. p=reject demande au contraire son rejet. Le traitement exact reste cependant dépendant de la politique appliquée par le serveur qui reçoit le message.Peut-on passer directement de p=none à p=reject ?
Faut-il configurer SPF et DKIM avant DMARC ?
Pour approfondir le fonctionnement de ces trois mécanismes et comprendre leur complémentarité, retrouvez notre guide complet SPF, DKIM et DMARC.
SPF, DKIM et DMARC contribuent à authentifier les expéditeurs et à limiter l'usurpation d'un domaine. Ils ne remplacent pas un filtrage capable d'analyser les spams, tentatives de phishing et messages malveillants reçus par vos utilisateurs. Une fois votre authentification correctement configurée, vous pouvez aussi tester la protection de votre messagerie.
Tester mon domaine gratuitement