Faut-il migrer vers DMARCbis ? La checklist sans stress

_dmarc.exemple.fr.  IN TXT
  "v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=s; rua=mailto:rapports@exemple.fr"

Ce qu'il ne faut PAS faire

• Pas de second enregistrement DMARC. Comme avant, un seul enregistrement _dmarc par domaine. Un second rend la politique ambiguë et peut être ignoré.
• Pas de saut direct à p=reject sous prétexte de « moderniser », tant que toutes les sources ne sont pas alignées. DMARCbis ne change rien à cette règle d'or : durcir sur un inventaire incomplet casse du courrier légitime. La séquence reste celle d'atteindre p=reject.
• Pas de précipitation sur psd. Cette balise concerne les opérateurs de domaines de suffixe public (registres), pas les organisations ordinaires.

Dans quel ordre migrer

L'ordre dépend du point de départ.

Domaine déjà en p=reject avec un alignement propre (le cas idéal) :

1. ajouter np=reject ;
2. retirer pct ;
3. contrôler les rapports. C'est terminé.

Domaine encore en p=none ou p=quarantine :

1. ajouter np=reject tout de suite (sans risque, indépendant du reste) ;
2. poursuivre la montée normale vers p=reject (inventaire → alignement → quarantine avec t=y → reject) ;
3. retirer pct au passage. La priorité, dans ce cas, n'est pas DMARCbis : c'est d'atteindre l'application.

Comment vérifier que tout va bien

Après chaque changement, deux contrôles simples :

1. Relire l'enregistrement avec un analyseur pour confirmer la syntaxe et la présence des balises attendues (np, absence de pct) — notre analyseur gratuit le fait en quelques secondes et donne une note.
2. Surveiller les rapports agrégés quelques jours. Deux choses doivent apparaître : les sources légitimes toujours alignées, et les sous-domaines inexistants usurpés désormais en disposition reject. Leur lecture est détaillée dans comment lire les rapports agrégés.

Un écosystème à deux vitesses, et c'est normal

Pendant la période de transition, il faut garder en tête que les destinataires n'adoptent pas DMARCbis tous en même temps. Un même message peut donc être évalué par un serveur à jour, qui honore le np=reject, et par un autre qui ne connaît pas encore la balise et l'ignore purement et simplement. Rien d'inquiétant : c'est exactement le comportement prévu par la rétrocompatibilité. La conséquence pratique se lit dans les rapports agrégés — pour un même trafic usurpé sur un sous-domaine inexistant, certains destinataires remonteront une disposition reject quand d'autres appliqueront encore la politique historique. Cette hétérogénéité n'est ni un bug de configuration ni un signe d'échec de la migration : elle se résorbera d'elle-même à mesure que les implémentations se mettent à jour. Surtout, l'enregistrement ne doit pas être « corrigé » pour la faire disparaître.

Combien de temps ça prend ?

Pour un domaine déjà bien tenu, la « migration » DMARCbis se résume à deux retouches de DNS — quelques minutes, plus le temps de propagation. En p=none, le vrai chantier n'est pas DMARCbis mais l'alignement des sources, qui peut prendre de quelques jours à quelques mois selon la taille du parc d'envoi (voir atteindre p=reject sans casser ses emails).

Trois cas concrets, avant / après

Selon le point de départ, la « migration » prend une forme différente. Voici trois enregistrements réels, avant et après.

Cas 1 — domaine déjà protégé. Avant :

v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:rapports@exemple.fr

Après :

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:rapports@exemple.fr

On retire pct=100 (inutile) et on ajoute np=reject. Deux secondes de travail.

Cas 2 — domaine en surveillance. Avant :

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

Après (np posé tout de suite, la montée vers reject se poursuit) :

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

np=reject ne dépend pas de p : même en p=none, les sous-domaines inexistants se verrouillent sans risque.

Cas 3 — domaine parqué (aucun envoi). Avant : souvent rien du tout. Après :

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:rapports@exemple.fr

Un domaine d'où rien ne part jamais doit tout refuser. C'est la configuration la plus stricte, et la plus simple à justifier.

Trois idées fausses sur la migration

• « Il faut passer à v=DMARC2. » Faux. L'identifiant reste v=DMARC1. Un outil qui réclame v=DMARC2 est un signal d'alarme.
• « Un vieil enregistrement va être rejeté. » Faux. Un enregistrement 7489 reste un enregistrement DMARCbis valide. Rien ne « périme ».
• « Tout doit migrer le même jour. » Faux. Il n'y a pas de date butoir. np peut s'ajouter aujourd'hui, pct disparaître le mois prochain — et un domaine déjà sain peut rester intouché. DMARCbis n'impose aucun calendrier.

Questions fréquentes sur la migration

Combien de domaines dois-je traiter ? Tous ceux du portefeuille, y compris ceux d'où rien ne part jamais — ce sont justement les plus usurpés. Un parc multi-domaines mérite un passage en revue ; le principe (ajouter np, retirer pct) est le même partout.

Faut-il prévenir mon hébergeur ou mon prestataire email ? Non. La migration se résume à éditer un enregistrement TXT dans le DNS. Quand un prestataire gère le DMARC du domaine, une simple demande suffit : ajouter np et retirer pct.

Et avec un service de monitoring DMARC ? La plupart se mettent à jour pour refléter DMARCbis (apparition de np, disparition de pct dans les rapports). Reste à confirmer que l'outil interprète bien np ; sinon, il faut en changer ou ajouter la balise à la main — elle reste valide quoi qu'il arrive.

Dois-je refaire mes clés DKIM ou mon SPF ? Non, DMARCbis ne touche ni à SPF ni à DKIM. Une authentification qui fonctionne aujourd'hui fonctionne après migration. L'occasion est bonne, en revanche, de vérifier que les clés DKIM sont stockées au bon endroit, pas dans un fichier traînant.

Migrer un parc multi-domaines

Pour un portefeuille de plusieurs domaines — c'est le cas de la plupart des organisations, ne serait-ce qu'avec leurs domaines de marque et leurs domaines parqués — la migration s'aborde comme une revue, pas comme une urgence. La méthode :

1. Inventorier tous les domaines, y compris ceux qui ne servent plus mais restent au portefeuille. Ce sont souvent les plus exposés, car personne ne les surveille.
2. Les classer en deux groupes : ceux qui envoient du courrier (à traiter avec soin, alignement compris) et ceux qui n'en envoient pas (domaines parqués, à passer directement en p=reject; sp=reject; np=reject).
3. Appliquer les mêmes deux retouches partout : ajouter np, retirer pct. Pour les domaines parqués, c'est l'occasion de publier un premier enregistrement strict s'il n'y en avait pas.
4. Prioriser par exposition : commencer par les domaines de marque grand public, les plus susceptibles d'être usurpés, avant les domaines internes ou techniques.

Le bénéfice d'un traitement groupé, c'est la cohérence : un parc où chaque domaine applique la même politique stricte ne laisse aucun maillon faible. Et comme np=reject est sans risque, il se déploie sur l'ensemble du parc en une passe, sans crainte de casser quoi que ce soit — aucun de ces domaines n'émet depuis un sous-domaine inexistant. Les rapports agrégés de chaque domaine confirmeront ensuite que rien de légitime n'a été affecté.

Un conseil d'organisation : désigner un responsable de la posture DMARC du parc. Les domaines dérivent — un nouveau prestataire ici, un sous-domaine de campagne oublié là — et sans personne pour surveiller, un parc autrefois propre régresse en silence. La migration vers DMARCbis est un bon moment pour mettre cette responsabilité en place, puisque chaque enregistrement est déjà sur l'établi.

En bref

Il n'y a pas de migration obligatoire : DMARCbis est rétrocompatible et l'enregistrement v=DMARC1 reste valide. Les deux seules retouches utiles sont d'ajouter np=reject et de retirer pct. En p=none, la vraie priorité reste d'atteindre p=reject par la méthode habituelle. Et surtout : pas de v=DMARC2, ça n'existe pas.

Thomas fait la migration

Deux lignes de DNS, mais pas de place pour l'à-peu-près. Thomas, le RSSI virtuel, lit l'état réel du domaine, génère l'enregistrement DMARCbis exact à publier (np, t, sans pct), et vérifie sur les rapports qu'aucune source légitime n'est affectée. Une validation, un copier-coller, c'est réglé.

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