Déployer DMARC progressivement, après la fin de pct

La vraie granularité a toujours été les sources

Voici le point que pct masquait : on ne durcit jamais vraiment « 25 % d'un flux ». On rend conformes des sources, une par une. Le déploiement progressif réel consiste à parcourir l'inventaire — plateforme marketing, CRM, facturation, support — et à aligner chacune (signature DKIM à la marque de l'expéditeur, d=exemple.fr) jusqu'à ce que les rapports montrent un passage aligné pour toutes.

Tant que des sources légitimes échouent, la politique reste en none (ou en quarantine si le risque est acceptable) ; dès qu'elles sont toutes alignées, le durcissement se fait sans faux positif. C'est ça, le vrai curseur de progressivité — bien plus fin qu'un pourcentage, parce qu'il agit sur la cause (une source non alignée) et non sur un symptôme (un volume en échec). La méthode d'alignement source par source est détaillée dans atteindre p=reject sans casser ses emails.

Le mode test t=y : le remplaçant honnête de pct

DMARCbis introduit la balise t (pour testing). Publier t=y signale aux destinataires que la politique est en cours de test : ils l'appliquent tout en sachant qu'elle n'est pas encore définitive, ce qui les incite à être plus indulgents et permet d'en observer les effets sans conséquences brutales. C'est le vrai équivalent moderne d'un déploiement prudent : non plus « applique à 25 % », mais « voici la politique cible, à traiter comme un test le temps de la confirmer ».

Concrètement, t=y s'utilise pendant la fenêtre de montée en politique, quand un filet reste nécessaire. Une fois les rapports propres et la confiance établie, t=y se retire (ou passe à t=n) pour rendre la politique pleinement effective. Le fonctionnement précis de la balise est expliqué dans la balise t de DMARCbis.

La cadence de surveillance entre les paliers

Un déploiement progressif sans surveillance n'est pas progressif, c'est juste lent. Chaque changement de politique appelle une cadence explicite :

• Jour 1 : vérifier que rien n'a cassé immédiatement — aucune source légitime majeure ne bascule en échec.
• Jour 3 : les premiers rapports agrégés du nouveau palier arrivent (ils sont quotidiens, avec un décalage). Contrôler l'alignement source par source.
• Jour 7 : une semaine complète capte les variations hebdomadaires (campagnes du lundi, relevés). Si tout est propre, la marche suivante devient envisageable.

Cette cadence transforme « on a durci DMARC » d'un pari optimiste en un changement contrôlé, réversible à la moindre alerte. Ces points de contrôle méritent un responsable nommé ; un déploiement progressif que personne ne regarde n'a de progressif que le nom.

Combien de temps par palier ?

Il n'y a pas de durée universelle, mais un principe : rester à chaque palier le temps de capter un cycle d'envoi complet. Avec des relevés mensuels, une fenêtre de quelques jours ne les verra pas — il faut avoir observé au moins un cycle de facturation avant de conclure que « tout est propre ». Pour un flux simple et quotidien, quelques jours en quarantine suffisent avant reject. Pour un écosystème complexe, il faut compter plusieurs semaines. La question de la durée totale est traitée à part dans le calendrier de montée en politique.

Les sous-domaines : un palier à ne pas oublier

Le déploiement progressif ne concerne pas que le domaine racine. Les sous-domaines héritent de p par défaut, mais sp mérite un pilotage explicite, et surtout les sous-domaines inexistants un verrouillage par np. Bonne nouvelle : np=reject est un gain immédiat et sans risque, à poser tôt dans le déploiement — aucun courrier légitime ne part d'un sous-domaine qui n'existe pas, donc rien à observer avant de durcir. Détails dans la politique de sous-domaine (sp et np).

Plusieurs domaines : échelonner aussi le portefeuille

Sur un parc de plusieurs domaines, la progressivité a une troisième dimension : l'ordre de traitement. Le bon départ est un domaine secondaire — faible volume, flux d'envoi simple — sur lequel dérouler toute l'échelle en premier. L'exercice apprend à l'équipe à lire les rapports, tenir la cadence de surveillance et exécuter le geste de repli, dans un contexte où une erreur coûte peu. Le scénario éprouvé se rejoue ensuite sur le domaine phare, où l'enjeu est réel mais où le processus n'a plus rien de nouveau. Les domaines parqués, eux, n'ont besoin d'aucune progressivité : rien de légitime n'en part, ils peuvent recevoir la politique la plus stricte dès le premier jour. Séquencer ainsi le portefeuille transforme un premier déploiement en répétition générale plutôt qu'en pari.

Savoir reculer

Un bon déploiement progressif inclut un plan de repli. Quand un palier révèle une source légitime oubliée et dont les messages sont bloqués, il faut redescendre d'un cran (par exemple de reject à quarantine, ou en réactivant t=y), aligner la source, puis remonter. Reculer n'est pas un échec : c'est exactement ce que la progressivité est censée permettre. L'erreur serait de rester en reject en espérant que le problème se règle seul pendant que des emails légitimes disparaissent.

Pièges fréquents

• S'appuyer encore sur pct. Certains outils l'acceptent par rétrocompatibilité, d'autres l'ignorent. Un déploiement ne se bâtit pas dessus : DMARCbis l'a retirée, et son comportement était de toute façon inégal.
• Sauter des paliers. Passer directement de none à reject sans fenêtre en quarantine fonctionne si et seulement si les rapports sont irréprochables depuis des semaines. Dans le doute, le sas se garde.
• Durcir sans surveiller. Un changement de politique sans cadence de contrôle est un pari, pas un déploiement.
• Oublier de retirer t=y. Le mode test est une phase, pas une destination : laissé en place, il affaiblit la politique cible.

Un calendrier type, du premier jour à reject

Pour rendre tout cela concret, voici à quoi ressemble une progression sereine pour un domaine de taille moyenne, sans urgence particulière :

• Semaines 1 à 3 — p=none. Publier l'enregistrement avec une adresse rua, poser np=reject d'emblée, et laisser les rapports affluer. Rien n'est bloqué. C'est le moment de dresser l'inventaire des sources et d'aligner les plus évidentes.
• Semaines 4 à 6 — alignement. Le gros du travail calendaire. L'inventaire se parcourt source par source, avec l'ajout d'une signature DKIM à la bonne marque sur chaque plateforme, et une vérification dans les rapports que chacune passe en aligné. La politique reste en none tant qu'une source majeure échoue encore.
• Semaine 7 — p=quarantine; t=y. Premier palier d'application, en mode test. La surveillance suit la cadence jour 1 / 3 / 7. Le mode test signale aux destinataires que la politique est encore en confirmation, et laisse un filet.
• Semaine 8 — p=quarantine. t=y est retiré. La politique quarantine est pleinement effective. Une semaine d'observation pour capter un cycle hebdomadaire complet.
• Semaine 9 — p=reject. Les rapports sont propres depuis plusieurs semaines, les seules sources en échec sont inconnues (donc des usurpateurs). Le durcissement a lieu. La surveillance des rapports continue, car l'apparition d'une nouvelle source non alignée peut toujours survenir.

Ce calendrier n'est pas une règle — un flux simple ira deux fois plus vite, un écosystème complexe deux fois plus lentement. C'est un gabarit : chaque marche est franchie sur preuve, pas sur horloge. Les durées s'adaptent au cycle d'envoi réel, jamais l'inverse.

En résumé

La disparition de pct n'a pas rendu le déploiement DMARC plus risqué — elle l'a rendu plus honnête. La progressivité réelle a toujours reposé sur l'alignement des sources et sur le temps d'observation entre les paliers, pas sur un pourcentage que les destinataires appliquaient de façon inégale. Le trio none → quarantine → reject, cadencé par une surveillance sérieuse et sécurisé par le mode test t=y, reste la bonne méthode.

Pour situer un domaine et vérifier l'alignement réel de chaque source avant de monter d'un palier, un passage dans l'analyseur DMARC gratuit suffit ; il dit, du point de vue des destinataires, si le durcissement peut se faire sans rien casser.