« DMARC policy not enabled » : ce que veulent dire les vérificateurs, et l'honnête première étape de 5 minutes (2026)

Publié 2026-07-08

Chiffres au 2026-06-29 · méthodologie v7. Données de recensement agrégées sur 261 millions de domaines évalués. Voir comment nous notons.

« DMARC policy not enabled » signifie l’une de deux choses différentes : votre domaine n’a aucun enregistrement DMARC, ou il en a un réglé sur p=none. Seuls 10,59 % des domaines — 27 640 987 sur 261 086 232 — appliquent une politique DMARC, selon le recensement Defaults.Exposed. Publier un enregistrement de surveillance prend cinq minutes ; l’application, c’est un projet.

Ce guide décode l’avertissement, vous donne l’enregistrement TXT exact à publier et l’endroit exact où le mettre, passe en revue les erreurs de syntaxe qui font échouer les premières tentatives, et fixe une attente honnête de ce à quoi ressemble votre première semaine de rapports DMARC. Ce n’est délibérément pas un guide « réparez DMARC en 5 minutes » — les cinq minutes vous donnent la visibilité, pas la protection.

Que signifie réellement « DMARC policy not enabled » ?

Les vérificateurs comme MXToolbox fusionnent deux constats différents en un seul avertissement orange, et le chemin de correction dépend de celui qui vous concerne :

Ce que montre le vérificateur	Ce que cela signifie vraiment	Domaines concernés (sur 261 086 232 évalués)
“No DMARC record found”	Rien n’est publié à `_dmarc.votredomaine`. Les serveurs de réception n’appliquent aucune politique et ne vous envoient aucun rapport. Vous êtes aveugle à vos propres problèmes d’e-mail.	196 105 162 (75,11 %)
« DMARC policy not enabled » / “policy is none”	Un enregistrement existe mais dit `p=none` : les rapports sont activés, la protection est désactivée. Les serveurs de réception distribuent le courrier usurpé exactement comme avant.	37 312 637 (14,29 %)
“Policy: quarantine” ou “reject”	Une politique appliquée. Les serveurs de réception agissent sur les échecs.	27 640 987 (10,59 %)

Données au 2026-06-29.

La première ligne est celle où vit l’essentiel d’Internet : 75,11 % des domaines évalués ne publient aucun enregistrement DMARC, et 14,29 % de plus stationnent à p=none. L’inverse de la dernière ligne est le chiffre qui compte : 89,41 % des domaines n’ont aucune politique DMARC appliquée — sur 261 086 232 domaines évalués dans le recensement. Si votre vérificateur affiche l’avertissement, vous êtes dans l’écrasante majorité. Ce n’est pas rassurant ; c’est la raison pour laquelle l’usurpation reste bon marché.

Une clarification qui évite de la confusion plus tard : DMARC est la couche de politique au-dessus de SPF et DKIM, vérifiée contre l’en-tête From que votre destinataire voit réellement. « Not enabled » signifie que vous n’avez encore rien demandé aux serveurs de réception. Si les trois valeurs de politique sont nouvelles pour vous, l’explication en langage clair est qu’est-ce que DMARC : none, quarantine, reject.

Que pouvez-vous honnêtement corriger en cinq minutes ?

Publier un enregistrement. C’est toute l’affirmation honnête.

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

Cinq minutes après la mise en ligne de cet enregistrement TXT, les serveurs de réception qui vérifient DMARC commencent à compiler des rapports quotidiens sur qui envoie du courrier au nom de votre domaine — serveurs légitimes comme imposteurs. Cette visibilité est réellement précieuse et réellement immédiate.

Ce que cela ne fait pas : p=none ne protège rien. Le courrier usurpé est distribué exactement comme hier, et un vérificateur qui re-scanne demain peut encore dire « policy not enabled » — à juste titre, car la coche verte est réservée à quarantine ou reject. Nous avons expliqué pourquoi dans p=none n’est pas une protection ; le chemin par paliers vers une politique qui bloque réellement l’usurpation est de p=none à p=reject. L’étape de cinq minutes ci-dessous est le point de départ ; ce guide-là est la ligne d’arrivée.

Comment publier votre premier enregistrement DMARC ?

Lancez le scan gratuit avant de toucher au DNS. Il vous dit lequel des deux constats vous concerne réellement — aucun enregistrement ou p=none — et si SPF et DKIM sont en place en dessous, ce qui détermine la vitesse à laquelle vous pourrez passer à l’application plus tard.
Choisissez une adresse pour recevoir les rapports. Une boîte dédiée comme dmarc-reports@votredomaine suffit pour commencer. Si vous utilisez plutôt un service d’analyse de rapports, voyez la FAQ ci-dessous — les adresses tierces ont un piège silencieux.
Ajoutez un enregistrement TXT à l’hôte _dmarc. Dans la plupart des panneaux DNS (voir le guide de configuration DMARC chez IONOS pour un exemple concret), vous saisissez _dmarc dans le champ hôte/nom — le panneau ajoute votre domaine automatiquement, produisant _dmarc.votredomaine.com. Valeur : v=DMARC1; p=none; rua=mailto:[email protected]
Vérifiez qu’il résout. dig TXT _dmarc.yourdomain.com (ou n’importe quel vérificateur en ligne) doit renvoyer exactement un enregistrement commençant par v=DMARC1. La plupart des changements DNS sont visibles en quelques minutes ; un TTL bas aide.
Relancez le scan. Votre rapport montrera DMARC présent en mode surveillance — un reflet honnête d’où vous en êtes : rapports activés, application en attente.

Un seul enregistrement couvre aussi vos sous-domaines : les serveurs de réception qui ne trouvent aucun enregistrement sur mail.votredomaine.com se rabattent sur la politique du domaine organisationnel, vous n’avez donc pas besoin d’un enregistrement par sous-domaine pour commencer la surveillance.

Quelles sont les erreurs les plus fréquentes en ajoutant l’enregistrement ?

Presque chaque première tentative ratée est l’une de celles-ci — et elles comptent, car un enregistrement non analysable est traité comme aucun enregistrement. Le recensement compte 48 648 enregistrements DMARC publiés qui échouent à l’analyse ; les fautes de frappe que les gens publient réellement sont cataloguées dans le recensement des coquilles DMARC.

Mauvais hôte. L’enregistrement doit vivre à _dmarc.votredomaine.com, pas à l’apex. Sur le domaine nu, il ne fait rien, et les vérificateurs continuent de signaler “No DMARC record found”.
Domaine ajouté deux fois. Saisir _dmarc.votredomaine.com dans un panneau qui l’ajoute automatiquement donne _dmarc.votredomaine.com.votredomaine.com. Saisissez juste _dmarc.
Des virgules au lieu de points-virgules. Les balises sont séparées par ;. Un enregistrement non analysable est traité comme aucun enregistrement.
v=DMARC1 absent ou mal placé. Il doit être la première balise, orthographiée exactement ; les enregistrements commençant par p= échouent à l’analyse.
mailto: absent du rua. rua=dmarc@yourdomain est invalide ; il faut rua=mailto:[email protected].
Deux enregistrements DMARC. Les serveurs de réception qui trouvent plus d’un enregistrement v=DMARC1 les ignorent tous — même famille d’échec que le SPF multi-enregistrements.
Guillemets typographiques issus du copier-coller. Des guillemets courbes ou des espaces insécables importés d’un document cassent l’analyse. Retapez l’enregistrement si un vérificateur le dit malformé alors qu’il semble correct.

À quoi ressembleront les rapports rua la première semaine ?

Fixez les attentes maintenant pour ne pas conclure que c’est cassé :

Ils arrivent à peu près quotidiennement, par serveur de réception. Google envoie typiquement un rapport agrégé toutes les 24 heures ; Microsoft, Yahoo et les autres suivent leurs propres cycles. Pour un petit domaine, la première semaine se résume généralement à une poignée d’e-mails, surtout de [email protected].
Ce sont des pièces jointes XML compressées, pas un tableau de bord. Bruts, ils sont quasi illisibles ; un analyseur gratuit les transforme en tableau d’expéditeurs.
Le volume suit votre volume de courrier. Si vous envoyez peu de courrier, ou surtout vers des fournisseurs qui ne rapportent pas, attendez-vous à des données clairsemées. Deux semaines calmes sont normales pour un domaine à faible volume — vérifiez l’enregistrement avec dig plutôt que de supposer qu’il a échoué.
Attendez-vous à des surprises. La plupart des domaines découvrent des expéditeurs oubliés — le CRM, l’outil de facturation, le formulaire de contact. Chacun a besoin d’un SPF ou DKIM aligné avant que vous puissiez appliquer. Si les rapports montrent DMARC en échec alors que SPF et DKIM passent individuellement, c’est un problème d’alignement — voir DMARC échoue mais SPF et DKIM passent.

Et demandez bien les rapports : 64,3 % des domaines avec un enregistrement DMARC ne publient aucune adresse rua=, donc n’en reçoivent aucun rapport — la coupe du recensement là-dessus est dans DMARC publié à l’aveugle. Tout ce que vous apprenez ici alimente le déploiement de l’application — la surveillance est la première semaine de ce projet, pas une destination. Stationner à p=none indéfiniment est la façon la plus courante pour un domaine de finir dans les 89,41 %.

Foire aux questions

Publier p=none va-t-il nuire à la délivrabilité de mes e-mails ? Non. p=none ne change rien à la façon dont les serveurs de réception traitent votre courrier — il ne fait que demander des rapports. Cela peut même aider : les exigences de Google et Yahoo pour les expéditeurs en masse imposent au minimum un enregistrement DMARC p=none aux gros expéditeurs, donc en publier un est un plancher de conformité, pas un risque.

J’ai publié l’enregistrement — pourquoi le vérificateur dit-il encore « policy not enabled » ? Parce qu’il vous dit la vérité : votre politique est none, et les vérificateurs réservent le succès à quarantine ou reject. Vous avez rejoint les domaines qui surveillent sans appliquer — au 2026-06-29, seuls 10,59 % des 261 086 232 domaines évalués appliquent. L’avertissement disparaît quand vous terminez le déploiement vers l’application.

Dois-je configurer SPF et DKIM avant d’ajouter DMARC ? Il vous en faut au moins un, aligné, pour que votre courrier passe DMARC — mais ils n’ont pas besoin d’être parfaits avant de publier p=none. La surveillance est précisément la façon de trouver ce qui est cassé : 70 368 600 des 261 086 232 domaines évalués (au 2026-06-29) ont un SPF souple et aucune application DMARC, et les rapports sont ce qui leur apprendrait ce qui les bloque.

Puis-je envoyer les rapports à un analyseur tiers plutôt qu’à ma propre boîte ? Oui — mais une adresse rua sur un autre domaine exige que le prestataire publie un enregistrement d’autorisation (yourdomain._report._dmarc.vendor.com), sinon les serveurs de réception retiennent silencieusement les rapports. Les services sérieux le font automatiquement ; si les rapports n’arrivent jamais, vérifiez cela en premier.

Envoyez le rapport au propriétaire

Si vous corrigez cela pour un client ou un employeur, ne laissez pas le travail rester invisible. Relancez le scan gratuit une fois l’enregistrement résolu et transférez le rapport noté : il montre DMARC passant d’absent à surveillé, horodaté et en langage clair — et il montre la suite du chemin vers l’application. Les propriétaires ont de plus en plus besoin exactement de cette preuve pour les renouvellements de cyber-assurance et les questionnaires de sécurité fournisseurs, et un rapport noté d’une page répond à ces questions bien mieux qu’une capture d’écran d’un panneau DNS.

Vérifiez votre domaine gratuitement

Voyez lequel des deux constats vous concerne — aucun enregistrement ou p=none — et ce qu’il y a en dessous, en privé et réservé au propriétaire.

Vérifiez votre domaine → · Réparer DMARC → · De p=none à p=reject → · Comment nous notons → · Données agrégées uniquement. Données stockées et traitées dans l’UE.