Que faire face à l'alerte « DMARC policy not enabled »

L'alerte dmarc policy not enabled apparaît souvent dans un outil de spf dkim dmarc check ou dans un rapport de sécurité, et elle inquiète à tort : elle ne signifie pas forcément une absence totale de DMARC, mais le plus souvent une politique en p=none, qui observe sans jamais bloquer. Pour une prospection B2B ciblée où la réputation du domaine compte à chaque envoi, corriger ce point est un des gestes techniques à plus fort effet sur la délivrabilité.

Ce que dit vraiment l'alerte

Quand un outil de vérification signale « DMARC policy not enabled », il fait référence à la valeur du tag p= dans l'enregistrement DMARC. Trois valeurs sont possibles : none (aucune action, on observe seulement), quarantine (mise en spam) et reject (rejet pur et simple). L'alerte se déclenche presque toujours quand la politique est en none, ou quand aucun enregistrement DMARC n'existe du tout sur le domaine.

Dans le premier cas, un enregistrement existe déjà : v=DMARC1; p=none; rua=mailto:dmarc-reports@votre-entreprise.fr par exemple. Techniquement, DMARC est présent et fonctionne pour la collecte de rapports, mais aucune action n'est prise en cas d'échec d'authentification — d'où l'alerte, puisque la protection reste théorique.

Dans le second cas, plus problématique, aucun enregistrement _dmarc n'existe sur le DNS du domaine. Le domaine n'a alors aucune politique déclarée, ce qui le rend plus vulnérable à l'usurpation et peut peser sur la façon dont les grands fournisseurs de messagerie évaluent la fiabilité générale du domaine.

Pourquoi p=none n'est pas une erreur, mais une étape

Passer directement à reject sans étape d'observation est risqué : si un service légitime (un outil de facturation, une plateforme de prospection, un CRM) n'est pas correctement inclus dans le SPF ou signé en DKIM, ses emails seront purement et simplement rejetés par les serveurs receveurs, sans avertissement visible côté expéditeur.

p=none sert précisément à éviter ce scénario : la politique est déclarée, les rapports agrégés commencent à arriver, mais aucun email n'est bloqué pendant cette phase. C'est le comportement recommandé pendant les deux à trois premières semaines après la mise en place initiale de SPF et DKIM.

L'alerte « policy not enabled » a donc de la valeur comme rappel — elle signale qu'il reste une étape à franchir — mais elle ne doit pas pousser à sauter directement à reject sans avoir d'abord lu les rapports.

Comment corriger, étape par étape

Première étape : confirmer que SPF et DKIM sont tous deux fonctionnels et alignés avec le domaine d'envoi (le concept d'alignement DMARC exige que le domaine visible dans l'en-tête From corresponde au domaine authentifié par SPF ou DKIM). Sans cet alignement, resserrer DMARC ne fera que bloquer des emails légitimes.

Deuxième étape : si aucun enregistrement DMARC n'existe, le poser en p=none avec une adresse rua valide, par exemple v=DMARC1; p=none; rua=mailto:dmarc-reports@votre-entreprise.fr; pct=100. Laisser tourner deux à trois semaines minimum.

Troisième étape : lire les rapports agrégés reçus (idéalement via un outil comme dmarcian qui les rend lisibles, le format brut XML étant illisible à l'œil nu) et vérifier qu'aucun envoi légitime n'échoue à SPF ou DKIM.

Quatrième étape : passer à p=quarantine, avec éventuellement un pct=25 ou pct=50 pour ne resserrer que sur une partie du trafic dans un premier temps, puis monter progressivement vers pct=100 et enfin p=reject une fois la confiance établie.

• Vérifier l'alignement SPF/DKIM avec le domaine From avant tout changement de politique
• Démarrer ou confirmer p=none avec une adresse de rapport surveillée
• Lire les rapports agrégés pendant au moins deux à trois semaines
• Passer à p=quarantine avec un pct progressif avant d'atteindre p=reject

Impact concret sur une campagne de prospection B2B

Un domaine en p=none reste globalement délivrable au jour le jour, mais il envoie un signal de confiance plus faible aux algorithmes de filtrage des grands fournisseurs, qui pondèrent de plus en plus la maturité de l'authentification dans leur score de réputation. Sur une prospection adressée où chaque email compte, ce delta peut se traduire par quelques points de délivrabilité en moins, invisibles individuellement mais mesurables sur un batch de campagnes.

Erreurs fréquentes en corrigeant cette alerte

Passer de none à reject en une seule fois, sans étape intermédiaire ni lecture de rapports, est l'erreur la plus coûteuse : elle peut bloquer silencieusement des emails de prospection légitimes pendant des jours avant que quelqu'un ne s'en aperçoive via une chute anormale du taux de réponse.

Autre piège : oublier qu'un sous-domaine d'envoi hérite de la politique DMARC du domaine racine sauf déclaration contraire. Resserrer la politique du domaine principal peut donc affecter un sous-domaine de prospection sans qu'on l'ait anticipé.

Ce qu'on vérifie chez LDM

Avant de considérer un domaine « prêt » pour une campagne de prospection B2B, on exige au minimum p=none avec rapports actifs, et on pousse systématiquement vers p=quarantine ou p=reject dès que les rapports confirment l'absence d'échec sur les services légitimes. Un domaine encore signalé « policy not enabled » sans rapports lus est traité comme un domaine à finaliser, pas comme un domaine bloquant l'envoi — la nuance compte pour ne pas retarder inutilement une campagne déjà prête sur le fond.

Questions fréquentes