DMARCbis (DMARC V2) : ce qui change vraiment, expliqué simplement

Les trois RFC de DMARCbis

DMARCbis n'est pas un seul document mais trois, ce qui clarifie une organisation autrefois confuse :

• RFC 9989 — le cœur du protocole (politiques, alignement, balises). C'est le successeur direct de la 7489.
• RFC 9990 — les rapports agrégés (RUA), le canal de retour quotidien.
• RFC 9991 — les rapports d'échec (RUF), plus rares et soumis à des contraintes de vie privée.

Ensemble, ces trois RFC rendent obsolète la RFC 7489. On détaille leur contenu dans RFC 9989/9990/9991 : ce qui change dans DMARC.

Ce qui change concrètement

Trois changements méritent l'attention. Aucun n'est une rupture, mais chacun a un effet pratique.

1. La balise pct disparaît, remplacée par t

L'ancienne balise pct permettait d'appliquer la politique à un pourcentage du courrier (pct=25, puis 50, puis 100) pour un déploiement progressif. En pratique, elle se comportait de façon imprévisible selon les destinataires. DMARCbis la retire et introduit un mode test binaire, la balise t (t=y signifie « j'expérimente, ne durcis pas encore strictement »). La montée en puissance s'appuie désormais sur l'observation des rapports plutôt que sur un pourcentage. On creuse le sujet dans un article dédié à la balise t.

2. Deux nouvelles balises de sous-domaine : np et psd

La balise np fixe la politique des sous-domaines inexistants — une cible d'usurpation classique, car un attaquant peut forger facture.exemple.fr même si ce sous-domaine n'existe pas. Poser un np=reject ferme cette porte sans aucun risque pour le courrier légitime. La balise psd sert aux opérateurs de domaines de suffixe public (registres). Pour la plupart des organisations, c'est surtout np qui compte : un article dédié à la balise np sera disponible prochainement.

3. Le DNS Tree Walk remplace la Public Suffix List

Pour déterminer le « domaine organisationnel » (par exemple que mail.ma-banque.fr appartient à ma-banque.fr), DMARC s'appuyait sur la Public Suffix List, une liste externe maintenue à la main. DMARCbis la remplace par le DNS Tree Walk : une suite de requêtes DNS de proche en proche (huit au maximum), sans dépendance à une liste tierce. Plus robuste, plus prévisible. Détails dans un article dédié au DNS Tree Walk.

Ce qui ne change pas (et c'est rassurant)

Voilà le point qui doit rassurer : DMARCbis n'est pas une rupture.

• Les enregistrements commencent toujours par v=DMARC1. Pas de v=DMARC2, pas de nouveau format à apprendre.
• Les balises p, sp, rua, ruf, adkim, aspf, fo gardent exactement le même sens.
• Le principe d'alignement — le cœur de DMARC — est inchangé.
• Un enregistrement existant reste valide : aucun destinataire ne va le rejeter parce qu'il « date » de la 7489.

Autrement dit, rien à changer pour rester protégé. Les nouveautés sont des améliorations à adopter au moment voulu, pas des corrections urgentes.

Faut-il agir ?

Un domaine déjà en p=reject avec un alignement propre n'a aucune inquiétude à avoir. Trois petits gestes, faciles et sans risque, valent quand même la peine :

1. Ajouter np=reject pour verrouiller les sous-domaines fantômes.
2. Retirer un pct devenu inutile s'il traîne encore dans l'enregistrement.
3. Vérifier que les rapports arrivent toujours (le canal RUA est désormais cadré par la RFC 9990).

Pour un domaine encore bloqué en p=none, la priorité n'est pas DMARCbis : c'est d'atteindre l'application. La méthode est la même qu'avant — voir atteindre p=reject sans casser ses emails. La feuille de route complète de migration sera détaillée dans un article dédié.

Où en est le marché ?

L'adoption de DMARCbis est progressive : les destinataires mettent à jour leurs implémentations à leur rythme, et les nouvelles balises (np, t) apparaîtront petit à petit dans les rapports. La posture réelle de secteurs entiers — combien de domaines sont seulement en p=none, par exemple — s'observe dans l'Observatoire DMARC. Le constat reste sans appel : la majorité des domaines, dans de nombreux secteurs, n'applique toujours aucune politique. DMARCbis ne changera pas ça tout seul ; la discipline d'alignement, si.

De 2015 à 2026 : pourquoi maintenant

DMARC a été publié comme RFC 7489 en 2015, au statut Informational. En une décennie, il est devenu un standard de fait : Google, Microsoft et Yahoo l'exigent des expéditeurs en masse, et des réglementations comme NIS2 ou DORA en font un contrôle attendu. Ce décalage — un usage critique reposant sur un document seulement « informatif » — devait être corrigé. DMARCbis est le fruit de plusieurs années de travail au sein de l'IETF pour transformer l'expérience du terrain en une vraie norme : promouvoir le protocole sur la voie des standards, retirer ce qui marchait mal (pct), et combler les angles morts (np pour les sous-domaines inexistants, Tree Walk à la place de la PSL). Le calendrier de mai 2026 n'a rien d'arbitraire : il acte la maturité d'un protocole devenu incontournable. Concrètement, cela veut dire que s'appuyer sur DMARC n'est plus un pari sur une « bonne pratique » mais sur une norme établie — un argument de poids au moment de justifier ses choix auprès d'une direction ou d'un auditeur.

Les références à mettre à jour, pas le DNS

La conséquence la plus concrète est peut-être documentaire. Quand des politiques de sécurité internes, des procédures d'exploitation ou des réponses aux questionnaires d'audit citent la RFC 7489, ces références pointent désormais vers un texte obsolète. L'occasion est bonne de les rafraîchir : c'est une correction de quelques minutes qui évite une remarque facile d'un auditeur pointilleux. Même chose côté prestataires — un fournisseur qui affiche une conformité « RFC 7489 » n'est pas disqualifié pour autant (le protocole reste compatible), mais c'est un indice que sa documentation n'a pas suivi le standard. À l'inverse, rien à toucher côté DNS : cette mise à jour porte sur le papier, pas sur les enregistrements, qui restent valides tels quels.

Questions fréquentes sur DMARCbis

DMARCbis remplace-t-il SPF et DKIM ? Non. DMARCbis ne touche ni à SPF ni à DKIM : il reste la couche qui les relie au domaine visible via l'alignement. SPF déclare les serveurs autorisés, DKIM signe les messages, DMARC(bis) impose que l'un des deux s'aligne avec le From:. Les trois fonctionnent toujours ensemble — voir comment SPF, DKIM et DMARC fonctionnent ensemble.

Mon enregistrement v=DMARC1 est-il encore valide ? Oui, totalement. DMARCbis a délibérément conservé l'identifiant v=DMARC1 pour ne rien casser. Un enregistrement écrit pour la RFC 7489 reste un enregistrement DMARCbis parfaitement valide ; aucun destinataire ne le rejettera.

Dois-je attendre que mon hébergeur DNS « supporte » DMARCbis ? Non. DMARCbis ne demande rien de spécial à l'hébergeur : la publication reste un simple enregistrement TXT. Les nouveautés (np, t) ne sont que de nouvelles balises à l'intérieur de ce TXT, et n'importe quel DNS sait héberger un TXT.

Faut-il un nouvel outil pour « passer » à DMARCbis ? Non plus. L'enregistrement s'édite très bien à la main. Un outil aide surtout à savoir quoi publier (quelles balises, quelle politique) en fonction de l'état réel du domaine — c'est le rôle de Thomas, plus bas.

Est-ce que ça concerne les petits domaines ? Oui, mais sans urgence. Un petit domaine gagne surtout à poser np=reject (gratuit, sans risque) et, s'il n'est pas encore protégé, à viser p=reject — DMARCbis ou pas. La taille ne change pas la logique, seulement le nombre de sources à aligner.

Une note sécurité : les clés au bon endroit

DMARC, SPF et DKIM reposent sur des secrets — au premier rang desquels les clés privées DKIM. Les laisser traîner dans un fichier de configuration ou un e-mail est exactement le genre de négligence qu'un attaquant adore. DMARC.com est édité par Hucency, spécialiste de la cybersécurité ; pour centraliser et chiffrer ce type de secrets (clés DKIM, identifiants DNS, jetons d'API), il y a Hucency Vault. Une bonne hygiène des clés est le complément naturel d'une bonne politique DMARC.

Thomas s'occupe de DMARCbis

Suivre l'évolution d'un standard tout en faisant tourner une entreprise, ce n'est le métier de personne. Thomas, le RSSI virtuel, génère le DNS exact à publier (balises DMARCbis comprises : np, t), nomme chaque source d'envoi depuis les rapports, évalue la préparation du domaine sur des données glissantes, et signale le moment précis où durcir sans risque — de p=none jusqu'à p=reject.

Analyser un domaine gratuitement ou créer un compte et laisser Thomas faire le gros du travail.