DMARCbis est officiel : ce que le nouveau DMARC signifie pour votre domaine

DMARC vient de recevoir sa première refonte majeure en plus de dix ans. Après des années de travail à l'IETF — les efforts ont commencé vers 2020 — la norme mise à jour, surnommée DMARCbis, a été officiellement publiée ce mois-ci (mai 2026) sous le nom de RFC 9989, accompagnée de deux spécifications complémentaires pour les rapports (RFC 9990 et RFC 9991). Si vous possédez un domaine et publiez un enregistrement DMARC, voici ce qui change, ce qui compte vraiment, et si vous avez quelque chose à faire.

D'abord, la bonne nouvelle : votre enregistrement actuel continue de fonctionner

DMARCbis est une évolution, pas une remise à zéro. Votre enregistrement DMARC actuel — p=none, quarantine ou reject, votre adresse de rapports (rua), sp, adkim, aspf — reste entièrement valide et toujours pris en compte. Rien ne casse du jour au lendemain, et il n'y a aucune urgence.

Ce qui change vraiment (l'essentiel)

1. Une meilleure protection contre les faux sous-domaines — la nouvelle balise np (le grand changement).

Les pirates adorent inventer des sous-domaines qui n'existent pas — paie.votredomaine.com, connexion-securisee.votredomaine.com — pour donner une apparence légitime à leurs courriels d'hameçonnage. La nouvelle politique np (« sous-domaine inexistant ») vous permet de dire : rejeter tout courriel provenant d'un sous-domaine qui n'existe pas.

Deux nuances honnêtes, que nous avions toutes deux mal formulées à la première publication de cet article :

• np aide surtout quand vous avez peu de sous-domaines, pas beaucoup. Elle ne s'applique qu'aux noms qui n'existent pas : tout ce qu'un attaquant invente est donc couvert par définition. Les sous-domaines réels relèvent plutôt de leur propre enregistrement ou de votre politique sp.
• np ne change rien si vous êtes déjà à p=reject ou sp=reject — les sous-domaines inventés héritent déjà de cette politique — et elle ne change rien du tout si votre DNS utilise un enregistrement générique (*), puisqu'alors aucun nom n'est vraiment « inexistant ».

Réglez-la à np=reject, ou ne la mettez pas. N'utilisez pas np=none comme étape de « surveillance » : ce n'en est pas une. Elle demande aux destinataires de ne rien faire, donc sur un domaine déjà en quarantine ou reject, elle retire une protection que vous aviez déjà. La seule chose à vérifier d'abord : envoyez-vous du courriel depuis un sous-domaine qui n'a aucun enregistrement DNS ? C'est le seul trafic légitime que np=reject peut intercepter.

2. Une façon plus intelligente pour les destinataires de trouver votre domaine — le « parcours d'arbre DNS ».

Auparavant, les fournisseurs de messagerie s'appuyaient sur une grande liste externe (la Public Suffix List) pour déterminer votre domaine « principal » et la manière dont les sous-domaines héritent de la politique. DMARCbis remplace cela par un parcours d'arbre DNS (DNS Tree Walk) : les destinataires remontent simplement l'arbre DNS pour trouver votre domaine organisationnel et sa politique. C'est plus fiable, cela élimine une dépendance fragile et le comportement devient plus prévisible pour les configurations complexes. Vous ne le verrez pas directement — c'est la façon dont les destinataires lisent votre enregistrement — et cela ne vous demande rien.

3. La balise pct disparaît — la seule chose à vérifier. ⚠️

L'ancien DMARC avait une balise pct= pour n'appliquer votre politique qu'à un pourcentage des courriels (utilisée pour les déploiements progressifs). DMARCbis la supprime. Si votre enregistrement contient encore quelque chose comme pct=10, les destinataires modernes l'ignorent désormais et appliquent votre politique complète. Donc si vous comptiez sur pct pour adoucir l'application, cette hypothèse ne tient plus — cela vaut une vérification rapide. La nouvelle façon d'y aller en douceur est la balise de test t=y, en plus de la progression classique none → quarantine → reject.

4. Le reste.

Il y a aussi une balise psd et des formats de rapports plus propres, désormais séparés (RFC 9990 / 9991). La plupart des propriétaires de domaine peuvent laisser ces deux éléments de côté : le parcours d'arbre DNS détermine déjà votre frontière organisationnelle, vous n'avez donc pas à définir psd vous-même. (Cela concerne surtout les opérateurs de registres / « suffixes publics », qui publient psd=y pour protéger les domaines enregistrés sous eux.)

Alors — avez-vous quelque chose à faire ?

Pour la plupart des domaines, rien d'urgent — votre enregistrement continue de fonctionner. Mais deux points méritent un coup d'œil :

• Revoyez toute balise pct= — elle ne fait plus ce qu'elle faisait avant.
• Envisagez np=reject pour fermer la porte à l'hameçonnage par faux sous-domaines — mais seulement si votre politique est actuellement plus douce que reject, et seulement si votre DNS n'a pas d'enregistrement générique. Jamais np=none.

En toute honnêteté, les bons changements dépendent de votre configuration DNS, de vos sous-domaines et de la rigueur de votre politique actuelle. Resserrer DMARC sans précaution peut bloquer des courriels légitimes — il vaut donc la peine de faire une évaluation avant d'actionner quoi que ce soit.

Nous avons depuis écrit une suite plus courte et plus pratique : quoi changer vraiment dans votre enregistrement DMARC — classé selon ce qui mérite votre attention aujourd'hui, ce qui peut attendre et ce que vous pouvez ignorer complètement.

Nous vous guidons

C'est exactement ce que fait DMARC Guy. Nous préparons des directives détaillées et adaptées pour aider les propriétaires de domaine à adopter les améliorations de DMARCbis en toute sécurité — les bonnes balises, dans le bon ordre, sans perturber les courriels légitimes. Vous aimeriez que nous examinions votre domaine et établissions les étapes précises pour votre configuration ? Contactez-nous.

Mis à jour le 19 août 2026. Nous avons corrigé notre conseil d'origine sur la balise np. La première version de cet article suggérait de commencer par np=none pour surveiller, et présentait np comme étant destinée aux organisations comptant de nombreux sous-domaines. Les deux étaient faux : np=none n'est pas un mode de surveillance — elle demande aux destinataires de ne rien faire, ce qui affaiblit un domaine déjà réglé à quarantine ou reject — et np couvre en réalité d'autant plus de terrain que vous avez peu de sous-domaines réels. Nous préférons corriger en public que discrètement. Le raisonnement complet se trouve dans quoi changer vraiment dans votre enregistrement DMARC.