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. Pour les organisations comptant de nombreux sous-domaines — écoles, gouvernement, grandes entreprises — cela referme une brèche exploitée par les pirates depuis des années.

Mieux encore, vous pouvez l'adopter en toute sécurité, car np accepte les mêmes valeurs que p (none → quarantine → reject) :

• Commencez par np=none pour surveiller — rien n'est bloqué, mais vos rapports commencent à révéler les courriels prétendant provenir de sous-domaines inexistants. Observez pendant quelques semaines afin de vous assurer qu'aucun système légitime n'utilise un sous-domaine que vous auriez oublié.
• Resserrez ensuite vers np=quarantine, puis enfin np=reject une fois rassuré.

C'est la protection la plus marquante de DMARCbis.

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 — mais c'est le plus grand changement sous le capot, et c'est lui qui rend possible la protection np ci-dessus.

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 si vous avez des sous-domaines et souhaitez fermer la porte à l'hameçonnage par faux sous-domaines — en commençant par np=none pour surveiller.

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 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.