De p=none à p=reject : critères de sortie par étape pour DMARC

La question derrière la plupart des projets DMARC n'est pas de savoir comment écrire l'enregistrement, mais combien de temps rester à p=none et ce qui doit être vrai avant de passer à l'étape suivante. Attendre indéfiniment laisse votre domaine exposé à l'usurpation, et avancer trop tôt envoie vos propres factures en spam. Ce guide vous donne des critères de sortie étape par étape, un plan pour les sous-domaines, ce qui casse d'habitude, et comment revenir en arrière. Les seuils sont nos conseils, pas une partie d'une norme, et nous les présentons comme tels.

La réponse en bref#

Restez à p=none pendant au moins un cycle d'envoi complet, généralement deux à quatre semaines, plus si vous avez du courrier mensuel ou trimestriel comme des relevés. Passez à quarantine quand chaque source légitime que vous connaissez réussit DMARC par un contrôle SPF ou DKIM aligné. Passez à reject après une nouvelle période à quarantine sans mauvaise surprise. Ne bâtissez pas la montée en charge sur pct= : la norme DMARC actuelle, la RFC 9989, supprime cette balise. Elle a été publiée en mai 2026 et remplace la RFC 7489, la spécification DMARC d'origine. Les bases de l'enregistrement lui-même figurent dans le guide de configuration de DMARC, que cet article ne répète pas.

Les étapes et quand quitter chacune#

Chaque étape ci-dessous a un test de sortie. Tous les chiffres du tableau sont des règles empiriques que nous suggérons, car votre volume et votre mélange d'expéditeurs déterminent ce qui est réaliste.

Une étape est terminée quand les échecs inexpliqués sont minimes et sans intérêt : quelques messages de transmetteurs, de listes de diffusion ou de sources que vous pouvez identifier comme n'étant pas les vôtres. Si une source au volume réel reste non identifiée, vous n'avez pas fini l'étape 2. La méthode pour les identifier se trouve dans le guide comment lire les rapports DMARC.

Un exemple de calendrier#

Pour rendre le tableau concret, voici un calendrier plausible pour une entreprise qui a un ESP, un CRM et un outil de facturation. C'est une illustration, pas une promesse.

• Semaines 1 à 4 : publiez p=none, collectez les rapports, et dressez la liste de chaque source avec son responsable. Incluez celle qui n'envoie qu'en fin de mois.
• Semaines 5 à 8 : corrigez l'alignement source par source, en commençant par la plus grosse en volume. Revérifiez les rapports après chaque changement, pas à la fin.
• Semaine 9 : appliquez la politique sur les domaines parqués et ceux qui n'envoient pas.
• Semaines 10 à 13 : passez le domaine principal à quarantine et surveillez chaque semaine l'apparition de nouvelles sources en échec.
• À partir de la semaine 14 : passez à reject si le dernier mois a été calme, et ajoutez une règle permanente : les nouveaux expéditeurs sont authentifiés avant leur lancement.

Si une source tarde à être corrigée, le calendrier l'attend. La date est un plan, le test de sortie est la règle.

Que faire de pct#

Si vous avez vu d'anciens conseils comme pct=10, puis 25, 50, 100, c'était une façon d'appliquer une politique plus stricte à une part du courrier en échec. La RFC 9989 supprime la balise. Sa propre justification dit que la balise n'était généralement pas appliquée avec exactitude, sauf si la valeur était 0 ou 100. Elle ajoute à sa place une balise t, avec y pour « testing » et n (la valeur par défaut) pour un traitement normal.

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com"

Avec t=y, un destinataire qui la prend en charge devrait traiter un message en échec avec un cran de moins que ce que dit la politique : quarantine devient none, reject devient quarantine. Cela n'a aucun effet sur p=none. Deux mises en garde honnêtes. Premièrement, la prise en charge de la nouvelle balise mettra du temps à se répandre : ne comptez pas dessus pour vous protéger. Deuxièmement, une montée en pourcentage n'a jamais été un filet de sécurité fiable, même avant ce changement.

Une façon plus sûre de limiter le risque est de procéder par périmètre plutôt que par pourcentage : appliquez d'abord sur les sous-domaines et les domaines qui n'envoient pas, puis sur le domaine principal, et restez quelques semaines à quarantine avant reject. Si votre enregistrement actuel contient encore pct=, inutile de vous presser de le retirer, mais n'ajoutez pas de nouvelle montée en charge qui en dépend.

Sous-domaines et domaines qui n'envoient rien#

Le gain le plus rapide vient des domaines qui n'envoient jamais de courrier. Les domaines parqués et les marques abandonnées sont des cibles favorites de l'usurpation, et ils n'ont aucune source légitime à casser. Publiez tout de suite une politique d'application, plus un enregistrement SPF qui n'autorise rien :

parked.example.com.         TXT  "v=spf1 -all"
_dmarc.parked.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
parked.example.com._report._dmarc.example.com.  TXT  "v=DMARC1;"

La troisième ligne est l'enregistrement d'autorisation. Comme l'adresse rua= se trouve dans un domaine différent de celui que la politique protège, les destinataires n'envoient des rapports que si cet autre domaine publie un enregistrement TXT nommé <protected-domain>._report._dmarc.<report-domain>. Omettez-le, ou placez l'adresse rua= sur le domaine parqué lui-même, et les rapports de ce domaine n'arriveront jamais. Le guide des rapports non reçus couvre cette vérification.

Pour les sous-domaines d'un domaine qui envoie, la politique du parent s'applique sauf si le sous-domaine publie son propre enregistrement. La balise sp= fixe une politique différente pour les sous-domaines qui n'en ont pas. La RFC 9989 définit aussi une balise np pour les sous-domaines qui n'existent pas dans le DNS, utile contre les noms d'hôte inventés. Si vous comptez définir sp=reject sur le parent, confirmez d'abord que chaque sous-domaine d'envoi réussit, ou donnez-lui son propre enregistrement. Le guide du sous-domaine d'envoi explique pourquoi chaque flux de courrier est de toute façon mieux placé sur son propre sous-domaine.

Ce qui casse d'habitude quand on applique la politique#

Presque tous les incidents d'application remontent à l'une de ces causes. Cherchez-les aux étapes 1 et 2, pas après le changement de politique.

• L'expéditeur que personne n'avait en tête. Un outil de facturation, une plateforme d'enquêtes ou un système de recrutement qui envoie une fois par mois. Un cycle complet de rapports en attrape la plupart, et c'est pourquoi l'étape 1 n'est pas facultative.
• Aligné en test, pas en production. Un service réussit depuis un pool d'IP d'envoi et échoue depuis un autre. Jugez chaque source sur son volume réel dans la durée.
• Transmetteurs et listes de diffusion. Le transfert casse SPF, et les listes qui modifient un message cassent DKIM. Vous ne pouvez pas l'empêcher complètement. Attendez-vous à un petit taux d'échec résiduel et décidez à l'avance qu'il est acceptable. La RFC 9989 est explicite à ce sujet : un domaine qui publie p=reject ne doit pas compter sur SPF seul et doit signer son courrier en DKIM, et un domaine dont les utilisateurs écrivent à des listes de diffusion ne devrait pas du tout publier p=reject. Pour ce type de domaine, elle suggère au moins un mois à p=none, puis une période aussi longue à p=quarantine, avant de comparer les résultats. Nos fenêtres plus courtes ci-dessus conviennent aux domaines qui envoient surtout du courrier système : allongez-les si votre personnel écrit à des listes publiques.
• Un nouvel outil ajouté après l'application. L'équipe marketing s'inscrit à une plateforme un mardi et son courrier se met à rebondir. C'est un problème de processus : convenez que les nouveaux expéditeurs ont leur authentification en place avant la première utilisation.
• Alignement strict laissé actif. adkim=s ou aspf=s transforment une configuration relaxed qui marchait en échecs. Le guide de dépannage de l'alignement passe en revue chaque cause.

Suivre le passage avec des chiffres réels#

Pendant les étapes 2 à 4, vous voulez une seule vue : pour chaque source, quelle part de son courrier réussit DMARC, et quelles sources sont nouvelles cette semaine. Les rapports DMARC de Qualisend l'affichent par domaine, sur 7, 30 ou 90 jours, et vous envoient un e-mail le lendemain du jour où un domaine a au moins 10 messages en échec à la fois à SPF et à DKIM, ou une nouvelle source avec au moins 5 messages en échec. Il n'y a pas de score « prêt pour reject », le jugement vous revient donc : regardez chaque source légitime atteindre 100 % et s'y maintenir. Les données agrégées ont aussi un jour ou deux de retard et ne couvrent que les destinataires qui envoient des rapports : une semaine calme n'est donc pas la preuve que rien n'a échoué.

La surveillance de la santé du domaine de Qualisend classe p=none comme un avertissement dans les problèmes d'un domaine, et avertit pour un pct inférieur à 100, ce qui aide si vous gérez plusieurs domaines et voulez voir lesquels n'ont pas encore avancé.

Retour en arrière#

Prévoyez le chemin du retour avant d'avancer. Trois habitudes rendent un retour en arrière rapide.

1. Conservez le texte de l'enregistrement précédent dans vos notes de changement, pour que le retour se fasse par copier-coller.
2. Baissez le TTL de l'enregistrement _dmarc à quelques minutes environ un jour avant un changement de politique, puis remontez-le une fois la situation stable. Les destinataires mettent le DNS en cache, et un TTL long ralentit votre propre retour en arrière.
3. Reculez d'un cran, pas jusqu'au bout. Si une source légitime se met à échouer à reject, revenez à quarantine le temps de la corriger. Les messages déjà rejetés pendant cette fenêtre sont en général renvoyés à l'expéditeur et ne sont pas récupérables côté destinataire : il vaut donc mieux que la première fenêtre d'application soit courte et surveillée.

Où l'application de la politique rejoint tout le reste#

Atteindre quarantine ou reject sur le domaine organisationnel est aussi la condition préalable aux logos BIMI, et le guide BIMI liste ce que la norme demande. Cela ne supprime pas le besoin des autres bases décrites dans les exigences de Google et Yahoo. Le tableau complet de l'articulation entre authentification et réputation se trouve dans le guide de la délivrabilité.

Une politique DMARC appliquée prouve que le courrier est bien le vôtre, mais elle ne peut pas rendre bonne une mauvaise liste. L'offre gratuite de la page des tarifs inclut 100 crédits qui lancent la vérification complète sur une liste. Un domaine protégé a quand même besoin d'une liste saine pour mériter la boîte de réception.