Fin de la balise pct : le mode test t= de DMARCbis

_dmarc.exemple.fr.  IN TXT
  "v=DMARC1; p=quarantine; t=y; rua=mailto:rapports@exemple.fr"

Comment déployer DMARC progressivement, sans pct

La disparition de pct ne change pas la méthode de déploiement — elle la rend même plus claire. La séquence reste celle décrite dans atteindre p=reject sans casser ses emails :

1. p=none — observation pure. Les rapports arrivent et l'inventaire des sources se construit.
2. Aligner chaque source légitime (SPF/DKIM), jusqu'à ce que les rapports soient propres.
3. p=quarantine avec t=y — la quarantaine est déclarée en mode test : la vérification qu'aucune source légitime oubliée ne tomberait se fait sans risque réel.
4. Retirer t=y — la quarantaine s'applique vraiment.
5. p=reject (éventuellement avec t=y d'abord, puis sans) — l'application complète.

Au lieu d'un curseur de pourcentage imprécis, le standard offre un interrupteur net : test ou réel. La granularité ne vient plus du « combien » (le pourcentage) mais du « quoi » (quelle politique, sur quel périmètre — racine, sous-domaines via sp, inexistants via np).

Et si pct reste dans l'enregistrement ?

Rien de grave. Les implémentations à jour de DMARCbis ignorent simplement pct. Le laisser ne casse rien, mais il ne sert plus à rien — autant le retirer pour garder un enregistrement propre. C'est l'un des petits gestes de la la migration vers ce nouveau standard, avec l'ajout de np.

Une nuance pendant la transition

Comme toujours avec DMARCbis, l'écosystème se met à jour progressivement. Pendant un temps, deux populations coexisteront :

• des destinataires à jour, qui comprennent t et ignorent pct ;
• des destinataires anciens, qui ignorent t (et appliquent donc la politique pleinement, même avec t=y).

Conséquence pratique : t=y n'est pas un filet de sécurité absolu côté destinataires anciens — certains appliqueront p=quarantine pour de vrai. C'est pourquoi la vraie sécurité reste de monter par étapes en surveillant les rapports : t=y aide à observer, mais c'est la propreté des rapports qui signale que le domaine est prêt, pas la balise. Pour lire ces rapports, voir comment lire les rapports agrégés.

Un déploiement réel, semaine par semaine

Pour rendre la séquence concrète, voici à quoi pourrait ressembler la montée d'un domaine de taille moyenne, avec les enregistrements à chaque étape.

Semaine 1 — observation. L'enregistrement publié est le suivant :

v=DMARC1; p=none; rua=mailto:rapports@exemple.fr

Rien d'autre ne bouge. Les rapports commencent à arriver ; les sources se révèlent une à une (plateforme mail, CRM, facturation, un outil oublié).

Semaines 2 à 4 — alignement. SPF et DKIM sont configurés et alignés pour chaque source légitime, jusqu'à ce que les rapports les montrent toutes au vert. L'enregistrement ne change pas encore : tout le travail se fait « sous le capot ».

Semaine 5 — quarantaine en test. La quarantaine est déclarée, mais en mode test :

v=DMARC1; p=quarantine; t=y; rua=mailto:rapports@exemple.fr

Avec t=y, ce qui serait mis en indésirable s'observe sans risquer d'y envoyer une source légitime oubliée. La surveillance dure quelques jours.

Semaine 6 — quarantaine réelle. Les rapports sont propres ? t=y disparaît :

v=DMARC1; p=quarantine; rua=mailto:rapports@exemple.fr

Semaine 7 — reject. Même logique : éventuellement p=reject; t=y quelques jours, puis retrait de t=y et ajout de np=reject pour verrouiller les sous-domaines inexistants. L'application est atteinte.

Ce calendrier est indicatif — un petit domaine ira plus vite, un grand parc plus lentement (voir atteindre p=reject). Le point clé : c'est l'état des rapports, pas le calendrier, qui autorise chaque passage.

Quoi chercher pendant une fenêtre t=y

La fenêtre de test n'est utile que si l'on sait ce qu'on y cherche. Pendant une phase t=y, le trafic en échec relevé dans les rapports se sépare en deux piles. D'abord, les sources reconnues — une plateforme, un outil, un partenaire qui émet pour le compte du domaine — et qui échouent encore à l'alignement : chacune est une tâche à terminer avant de retirer le drapeau, car sous la politique réelle elle aurait été attrapée. Ensuite, les sources inconnues : ces échecs-là sont la politique qui fait exactement ce qu'on attend d'elle, la preuve qu'elle mordra le bon trafic. La fenêtre a rempli son rôle quand la première pile est vide et qu'il ne reste que la seconde. Sa durée se dimensionne aussi sur les rythmes d'envoi — une semaine calme peut masquer un expéditeur rare mais important.

Trois erreurs à éviter avec t

• Confondre t=y et pct=100. t=y ne « réduit » pas l'application à un échantillon : il signale un mode test que seuls les destinataires à jour respectent. Ce n'est pas un substitut au pourcentage, c'est autre chose — un drapeau d'expérimentation.
• Rester en t=y pour toujours. Le mode test est une étape de transition, pas une destination. Tant que t=y est là, les destinataires à jour n'appliquent pas vraiment la politique : le domaine n'est pas réellement protégé. Le drapeau se retire dès que les rapports sont propres.
• Croire que t=y protège chez tout le monde. Les destinataires anciens ignorent t et appliquent la politique pleinement. Donc même avec t=y, un p=reject peut mordre chez certains. Une politique stricte ne se déclare que quand on est prêt à l'assumer partout.

Questions fréquentes sur t

Dois-je obligatoirement utiliser t=y ? Non. C'est un outil d'observation utile lors d'un durcissement, mais la montée p=none → quarantine → reject se mène très bien en surveillant simplement les rapports à chaque étape, sans jamais toucher à t.

t=y remplace-t-il l'étape p=none ? Non, ce sont deux choses différentes. p=none ne demande aucune action aux destinataires ; t=y avec p=quarantine ou p=reject leur dit « voici ma vraie cible, mais je teste encore ». t=y est utile après p=none, pour franchir un cran avec un filet.

Mon ancien pct=50 va-t-il poser problème ? Non — il sera simplement ignoré par les implémentations à jour. Le prochain changement d'enregistrement est l'occasion de le retirer.

t, délivrabilité et ce que font vraiment les destinataires

Une confusion fréquente mérite d'être levée : t=y n'est pas un réglage de délivrabilité. Il ne dit pas aux fournisseurs « soyez plus gentils avec mon courrier » ; il dit « cette politique est en test, ne l'appliquez pas encore strictement ». La délivrabilité dépend d'autres facteurs — réputation d'IP, taux de plaintes, alignement réel — pas de la présence de t.

Ce que font les destinataires avec t=y varie. Les implémentations à jour de DMARCbis le respectent : elles renvoient les rapports comme si la politique était active, mais ne mettent pas réellement le courrier en quarantaine ou en rejet. Les implémentations plus anciennes, qui ne connaissent pas t, l'ignorent et appliquent la politique pleinement. Conséquence pratique : pendant la transition, t=y est un filet partiel, pas total.

Le bon usage, donc : se servir de t=y comme d'une fenêtre d'observation lors d'un durcissement, en sachant que certains destinataires appliqueront déjà la politique pour de vrai. La surveillance porte sur les rapports agrégés ; dès qu'ils sont propres, t=y disparaît et la politique mord partout. Rester bloqué en t=y « par prudence » est un contresens : ce serait se croire protégé alors que les destinataires à jour, eux, n'appliquent rien. La prudence, c'est la propreté des rapports avant de durcir — pas un drapeau de test qu'on laisse traîner indéfiniment.

En bref

DMARCbis supprime la balise pct (déploiement par pourcentage, jugé peu fiable) et la remplace par t, un mode test binaire : t=y signale « politique en test, ne l'appliquez pas encore strictement ». La montée se pilote désormais à l'observation des rapports, pas au pourcentage. t=y est une étape de transition à retirer dès que les rapports sont propres — jamais une destination.

Thomas pilote la montée

Choisir le bon moment pour retirer t=y, passer de quarantine à reject, vérifier qu'aucune source ne tombe : c'est exactement le genre de décision que Thomas, le RSSI virtuel, prend sur la base des données réelles d'un domaine. Il génère l'enregistrement DMARCbis adapté à chaque étape et signale quand l'étape suivante est sûre.

Analyser un domaine gratuitement ou créer un compte. Pour le contexte complet, voir ce nouveau standard expliqué simplement.