Passer DMARC de p=none à p=quarantine sans perdre de courrier légitime

Un enregistrement DMARC avec p=none demande aux fournisseurs de messagerie de signaler le courrier qui échoue à l’authentification, mais de le remettre comme d’habitude. C’est le bon point de départ, et le mauvais endroit où rester : n’importe qui peut toujours envoyer du courrier avec votre domaine dans le champ From, et les destinataires n’ont reçu de votre part aucune consigne pour le traiter comme suspect.

Passer à p=quarantine indique aux destinataires que le courrier en échec doit être traité comme suspect, ce qui signifie en pratique le plus souvent le dossier spam. Le risque n’est pas le changement lui-même. Le risque, c’est un service légitime (facturation, support client, CRM, newsletter) qui échoue encore à DMARC le jour du changement, et vos propres messages finissent en spam.

La réponse courte : lisez vos rapports agrégés jusqu’à ce que chaque expéditeur légitime réussisse avec un DKIM aligné, passez à p=quarantine d’abord en mode test, comparez les rapports, puis retirez le mode test. Les détails suivent. Pour un rappel sur les 3 enregistrements, consultez SPF, DKIM et DMARC expliqués.

Ce que fait réellement p=none

DMARC est désormais défini par la RFC 9989, publiée en mai 2026, qui a remplacé la RFC 7489. Elle appelle p=none le Monitoring Mode (mode de surveillance) et explique pourquoi il existe : sauf dans les configurations les plus simples, le propriétaire d’un domaine peut oublier un serveur ou un accord d’envoi avec un tiers, et les rapports le révèlent.

La valeur quarantine signifie que le propriétaire du domaine considère le courrier en échec comme suspect. La décision finale reste au destinataire, mais pour la plupart des fournisseurs de messagerie, cela veut dire le dossier spam. Google le dit clairement dans son déploiement DMARC recommandé : les messages qui ne passent pas DMARC vont dans le dossier spam du destinataire.

Étape 1 : faire réussir chaque expéditeur légitime

La RFC 9989 est claire sur l’ordre. Les flux de courrier légitimes qui échouent parce que leurs identifiants ne sont pas alignés ou sont absents MUST be fixed before (doivent être corrigés avant) la publication d’une politique appliquée.

Parcourez vos rapports agrégés (notre guide comment lire un rapport agrégé DMARC détaille le XML) et dressez la liste de chaque source :

• Votre fournisseur de messagerie principal : il doit réussir avec DKIM et SPF alignés.
• Chaque outil tiers qui envoie au nom de votre domaine : activez dans ses paramètres la signature DKIM avec votre propre domaine. Un outil qui ne réussit SPF que sur son propre domaine d’enveloppe n’est pas aligné et échouera à DMARC.
• Les transferts et les listes de diffusion : ils cassent souvent SPF. Les signatures DKIM restent en général valides quand le courrier est relayé, une raison de plus de s’appuyer sur DKIM et pas seulement sur SPF.
• Les sources inconnues en échec : c’est précisément ce que la nouvelle politique doit arrêter.

La durée d’observation vous appartient. Google conseille au moins 1 semaine en p=none, car c’est en général suffisant pour que les rapports couvrent tous vos flux de courrier. La RFC 9989 précise que, selon la fréquence de vos envois, cela peut prendre de nombreux mois. Pensez au courrier que vous envoyez une fois par trimestre ou une fois par an : avis de paie, factures annuelles, rappels de renouvellement. S’ils ne sont pas encore apparus dans vos rapports, vous ne les avez pas vus réussir.

Étape 2 : changer d’abord en mode test

Sous la RFC 7489, la méthode habituelle pour avancer progressivement était la balise pct (appliquer la politique à un pourcentage du courrier en échec). La RFC 9989 a supprimé pct, car les destinataires appliquaient les valeurs autres que 0 et 100 de façon incohérente. Elle est remplacée par une balise de mode test, t :

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

Avec t=y, vous demandez aux destinataires d'appliquer 1 niveau en dessous de la politique indiquée : p=quarantine; t=y est donc traité comme none, tandis que les intermédiaires comme les listes de diffusion peuvent déjà adapter leur traitement de votre courrier. La balise ne change rien aux rapports. Comparez vos rapports avant et après : ils montrent quelle part de votre courrier passe par des relais qui échoueraient une fois la politique appliquée.

Certains fournisseurs documentent encore l’ancienne approche par pourcentage ; le guide de déploiement de Google, par exemple, indique pct=5 comme valeur de départ. Les destinataires qui ne prennent pas encore en charge t l’ignorent simplement : voyez le mode test comme un démarrage en douceur, pas comme un filet de sécurité.

Étape 3 : appliquer et continuer à surveiller

Quand les rapports en mode test sont propres, retirez la balise :

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

Pendant les premières semaines après le changement :

• Lisez les rapports chaque jour et repérez les valeurs disposition égales à quarantine pour des sources que vous connaissez.
• Demandez aux équipes qui écrivent aux clients (comptabilité, ventes, support) de vous prévenir si les réponses baissent ou si des clients disent que le courrier est arrivé en spam.
• Traitez chaque nouvel outil qui envoie au nom de votre domaine comme une demande de changement : DKIM avec votre domaine avant sa mise en service.
• Gardez les accès DNS bien en ordre. Un enregistrement DMARC remis discrètement en p=none par un prestataire bien intentionné annule tout le travail.

Sous-domaines et domaines qui n’envoient rien

Sans balise sp, la politique p s’applique aussi aux sous-domaines. Si un sous-domaine envoie du courrier marketing depuis une plateforme séparée, vérifiez-le dans les rapports avant le changement, ou donnez-lui son propre enregistrement _dmarc. La balise np fixe une politique pour les sous-domaines qui n’existent pas du tout, un choix courant pour des noms depuis lesquels personne ne devrait jamais envoyer.

Les domaines que vous possédez mais n’utilisez jamais pour le courrier (anciens noms de marque, enregistrements défensifs) sont le cas simple : sans expéditeur légitime, ils peuvent passer directement à une politique appliquée. Ce sont justement les domaines intéressants pour les arnaques aux fausses factures, parce que personne ne les surveille.

Avant d’aller plus loin vers p=reject

p=reject est l’étape suivante, mais la RFC 9989 reste prudente pour les domaines dont les utilisateurs écrivent sur des listes de diffusion. Elle recommande de rester en p=none au moins un mois, puis en p=quarantine pendant une durée équivalente, et de comparer d’abord les résultats. Les grands fournisseurs de messagerie attendent déjà DMARC des expéditeurs en masse, comme expliqué dans les exigences de Gmail et Yahoo pour les expéditeurs : une politique p=quarantine stable est donc déjà une position solide en soi.

Une courte liste de contrôle

• Des rapports agrégés collectés assez longtemps pour inclure les flux de courrier rares.
• Chaque expéditeur légitime réussit DMARC avec un DKIM aligné.
• p=quarantine; t=y publié et rapports comparés avant et après.
• Mode test retiré, rapports lus chaque jour pendant les premières semaines.
• Sous-domaines et domaines inutilisés couverts par sp, np ou leurs propres enregistrements.

La place de Guarding

Une fois votre politique appliquée, le principal risque est qu’elle revienne discrètement en arrière. Nous surveillons chaque jour, depuis l’extérieur et sans entrer dans vos systèmes, vos enregistrements SPF, DKIM et DMARC ainsi que le reste de ce que nous protégeons. Si un enregistrement est affaibli ou qu’un sélecteur DKIM disparaît, une personne l’examine et vous recevez la modification exacte à apporter, comme décrit dans ce qui se passe quand nous trouvons quelque chose. Le tableau de bord d’exemple montre à quoi cela ressemble.