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

En mai 2026, l'IETF a publié DMARCbis — la version modernisée du standard DMARC, souvent appelée « DMARC V2 » ou « DMARC 2.0 ». Elle remplace la RFC 7489 d'origine, qui datait de 2015. Si tu as déjà un enregistrement DMARC, la première question est légitime : est-ce que je dois tout refaire ? La réponse courte est non — mais il y a quelques nouveautés qui valent vraiment le coup d'œil. Ce guide explique ce qu'est DMARCbis, pourquoi il existe, ce qui change concrètement, et ce que tu peux faire dès aujourd'hui.

DMARCbis, en une phrase

DMARCbis est une révision de DMARC : même objectif (relier SPF et DKIM au domaine visible du From: pour arrêter l'usurpation), mais un texte réécrit, mieux structuré, avec des définitions plus claires, quelques balises nouvelles et un mécanisme d'attribution de domaine plus robuste. Si tu débutes, commence par qu'est-ce que DMARC ; DMARCbis ne remet pas en cause un seul des principes décrits là-bas — il les précise.

Pourquoi une nouvelle version

La RFC 7489 avait un statut particulier : Informational. En clair, c'était un document de référence, pas une norme officielle de l'IETF. Dix ans d'usage massif plus tard, le groupe de travail a voulu corriger ce décalage. DMARCbis fait donc passer DMARC, pour la première fois, sur la voie des standards (Standards Track, au rang de Proposed Standard). Au passage, l'expérience du terrain a permis de retirer ce qui marchait mal, de clarifier les zones grises, et d'ajouter ce qui manquait.

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 ton 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 fin de pct, place au mode test 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.ton-domaine.fr même si ce sous-domaine n'existe pas. Poser un np=reject ferme cette porte sans aucun risque pour ton 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 : voir la balise np expliquée.

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 le DNS Tree Walk.

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

Voilà le point qui doit te détendre : 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é.
• Ton enregistrement actuel reste valide : aucun destinataire ne va le rejeter parce qu'il « date » de la 7489.

Autrement dit, tu n'as rien à changer pour rester protégé. Les nouveautés sont des améliorations à adopter quand tu veux, pas des corrections urgentes.

Dois-tu agir ?

Si ton domaine est déjà en p=reject avec un alignement propre, tu es tranquille. Trois petits gestes, faciles et sans risque, valent quand même la peine :

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

Si tu es 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 est dans faut-il migrer vers DMARCbis.

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. Tu peux observer la posture réelle de secteurs entiers — combien de domaines sont seulement en p=none, par exemple — 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, pour toi, ça veut dire que t'appuyer sur DMARC n'est plus un pari sur une « bonne pratique » mais sur une norme établie — un argument de poids quand tu dois justifier tes choix auprès d'une direction ou d'un auditeur.

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 tes serveurs, DKIM signe tes messages, DMARC(bis) impose que l'un des deux s'aligne avec ton 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 à ton hébergeur : tu publies toujours 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. Tu peux éditer ton enregistrement à la main. Un outil aide surtout à savoir quoi publier (quelles balises, quelle politique) en fonction de l'état réel de ton 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é : tes clés au bon endroit

DMARC, SPF et DKIM reposent sur des secrets — au premier rang desquels tes 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), regarde Hucency Vault. Une bonne hygiène des clés est le complément naturel d'une bonne politique DMARC.

Laisse Thomas s'occuper de DMARCbis pour toi

Suivre l'évolution d'un standard pendant que tu fais tourner une boîte, ce n'est pas ton métier. Thomas, ton RSSI virtuel, génère le DNS exact à publier (balises DMARCbis comprises : np, t), nomme chaque source d'envoi depuis tes rapports, évalue ta préparation sur des données glissantes, et te dit le moment précis où durcir sans risque — de p=none jusqu'à p=reject.

Analyse ton domaine gratuitement → ou crée un compte et laisse Thomas faire le gros du travail.