En 2015, l'IETF a publié DMARC (RFC 7489) comme une RFC informative, et au cours des onze années suivantes, son adoption a été, dans une certaine mesure, optionnelle. En tant que RFC informative, il n’y avait pas de standardisation stricte du protocole, exception faite des efforts menés par les fournisseurs de messagerie. Même ainsi, des zones d’ambiguïté ont été résolues différemment selon les éditeurs. Bien que les grands acteurs comme Google, Yahoo et Microsoft aient pu initier des changements dans l’industrie (et instaurer des exigences pour les expéditeurs de courriels en masse), l’écosystème de l’email a beaucoup évolué depuis la publication de la spécification d’origine.
Ce changement approche rapidement. En mai 2026, l’IETF a publié la RFC 9989, communément appelée DMARCbis, qui fait enfin passer cette mise à jour attendue de DMARC au statut de Projet de Standard. Cette RFC, aux côtés de la RFC 9990 (rapport agrégé) et de la RFC 9991 (rapport d’échecs), rapproche encore DMARC du statut de Standard Internet bien défini. Le document mis à jour formalise DMARC afin qu’il corresponde aux usages actuels de l’email. Avec le futur document DKIM2 en cours de rédaction, ils posent les bases de l’authentification des emails à l’ère moderne.
Comprendre les nouvelles RFC
Les trois RFC sont maintenant sur la voie de la normalisation, en tant que Projets de Standard. Dans le processus IETF, c’est la première étape (et la plus courante) sur ce parcours. Cela signifie que la spécification a été examinée par la communauté, un consensus approximatif a été atteint, et le tout est considéré comme assez stable pour l’implémentation.
- RFC 9989 est la spécification centrale du protocole DMARC. Elle définit la manière dont les propriétaires de domaines publient leur politique, comment les récepteurs évaluent les messages, et que faire en cas d’échec d’authentification. Cette RFC remplace la RFC 7489 en tant que référence de DMARC.
- RFC 9990 concerne les rapports agrégés. Il s’agit des rapports XML quotidiens que les récepteurs renvoient aux propriétaires de domaines, indiquant quelles adresses IP ont envoyé des mails en leur nom et comment ces derniers ont été vérifiés par les contrôles SPF, DKIM et DMARC. Si vous avez déjà consulté vos données RUA, c’est cette spécification qui en régit le contenu et la livraison.
- RFC 9991 concerne les rapports d’échecs. Contrairement aux rapports agrégés, ceux-ci sont quasi immédiats et par message. Lorsqu’un message unique échoue à l’authentification DMARC, un rapport d’échec donne au propriétaire du domaine des informations détaillées sur ce message. Ils sont demandés via le tag ruf dans votre enregistrement DMARC, et sont utiles pour diagnostiquer rapidement des problèmes d’authentification.
Qu’est-ce qui change par rapport à la précédente RFC concernant DMARC ?
Si la désignation Projet de Standard compte, les changements techniques sont également importants au sein de cette suite.
Pour commencer, le tag pct va disparaître. Ce tag permettait d’appliquer la politique DMARC à un pourcentage seulement des emails non conformes, ce qui entraînait une application inégale selon les récepteurs. Désormais, DMARC doit s’appliquer à l’ensemble du trafic, point final. Si vous utilisiez pct en configuration longue durée plutôt que comme étape transitoire, il est temps de finaliser la transition. La mise à jour introduit un nouveau tag t=y ou t=n pour définir un mode test, qui remplace effectivement l’usage de pct. Deux autres tags supprimés étaient les peu utilisés rf et ri.
Le support des Public Suffix Domain (PSD) fait désormais officiellement partie du cœur de la spécification. La principale nouveauté est la manière dont les suffixes publics sont identifiés. Jusqu’ici, les récepteurs s’appuyaient sur la Public Suffix List, maintenue à la main, à laquelle les opérateurs de suffixes devaient se référer, en espérant que tous les récepteurs utilisaient une version à jour. PSD remplace cela par une exploration arborescente dans le DNS, ce qui permet aux suffixes publics d’être identifiés directement via le DNS, contrôlés par le suffixe lui-même, et disponibles partout sans attendre la mise à jour d’une liste.
De plus, le tag psd=n permet de désigner certains sous-domaines comme Organizational Domains, ce qui a un impact sur l’alignement et l’héritage de la politique.
Côté reporting, le travail est désormais scindé délibérément. La RFC 9990 définit le format du rapport agrégé en tant que standard (notamment le schéma XML, la gestion des changements de politique en cours de période de rapport, et les modalités de transmission). La RFC 9991 définit la même chose pour les rapports d’échecs : des rapports quasi-instantanés, par message, pour aider les propriétaires de domaines à identifier rapidement des problèmes d’authentification spécifiques. Ces deux documents sont maintenant sur la voie de la standardisation, ce qui donne aux implémentations côté récepteurs des objectifs bien plus clairs que l’ancien modèle tout-en-un.
À noter pour les rapports d’échec : la RFC 9991 précise explicitement que ceux-ci peuvent inclure l’intégralité des en-têtes de message et le corps, qui peuvent contenir des informations personnelles identifiables.
Ce que les expéditeurs doivent faire dès maintenant
Si votre DMARC est déjà correctement configuré et en mode d’application, rien ne change opérationnellement aujourd’hui. La RFC 9989 ne casse pas les enregistrements existants et ne nécessite aucune republication. Mais quelques points méritent votre attention :
- Vérifiez votre usage de
pct. Les récepteurs pourront tolérer l’existence de ce tag pendant la période transitoire, mais l’intention de la nouvelle spécification est claire. - Reconsidérez p=none. La communauté a désormais formalisé ce qu’est une implémentation DMARC correcte, et les expéditeurs restant indéfiniment en mode surveillance ne sont plus en phase avec l’évolution générale du secteur.
En résumé : gardez votre calme
Le passage de DMARC à Projet de Standard ne transformera pas le paysage des menaces du jour au lendemain, mais cela signifie que nous nous rapprochons d’un référentiel de bonnes pratiques pour l’ensemble du protocole. Ces RFC marquent une avancée majeure pour l’email et Internet dans son ensemble. Un écosystème numérique plus sûr profite à tous, et s’aligner tôt sur la bonne politique d’application vous évitera un casse-tête le jour où DMARC deviendra enfin un Standard Internet.
Si vous voulez savoir où en sont vos domaines aujourd’hui, Red Sift Investigate vérifie votre configuration DMARC, SPF, DKIM, BIMI, MTA-STS et TLS en envoyant un véritable email, pas simplement