RFC 9989, 9990, 9991 : ce qui change vraiment dans DMARC

RFC 9990 — les rapports agrégés (RUA)

Les rapports agrégés sont les résumés quotidiens que les destinataires envoient à l'adresse rua=. La RFC 9990 leur consacre désormais un document entier : format XML, contenu, fréquence, et bonnes pratiques d'envoi. Le contenu reste familier — des comptes par source d'envoi, avec les résultats d'alignement SPF/DKIM — mais deux détails évoluent dans le bloc policy_published des rapports : la balise pct n'y figure plus, et la balise np peut y apparaître. Leur lecture est détaillée dans comment lire les rapports agrégés.

RFC 9991 — les rapports d'échec (RUF)

Les rapports d'échec (aussi appelés forensiques) sont l'autre canal, bien plus rare. Ils peuvent contenir des échantillons — d'où des contraintes fortes de vie privée, qui font que beaucoup de destinataires n'en envoient tout simplement pas. La RFC 9991 cadre ce canal séparément, justement pour que ses enjeux de confidentialité ne polluent pas le reste du protocole. Pour la différence pratique entre les deux types, voir comment lire les rapports agrégés.

Les balises : ce qui est ajouté, retiré, conservé

C'est le tableau que la plupart des lecteurs viennent chercher ici.

Balises ajoutées :

• np — politique des sous-domaines inexistants (cf. la balise np).
• psd — marqueur de domaine de suffixe public (pour les registres).
• t — mode test binaire (t=y), qui remplace le déploiement par pourcentage.

Balises retirées :

• pct — le déploiement « sur un pourcentage du courrier », jugé peu fiable, est supprimé au profit de t (cf. fin de pct).
• ri et rf — l'intervalle et le format des rapports migrent vers les documents de reporting (9990/9991), ils ne sont plus dans le cœur du protocole.

Balises inchangées :

• v (toujours v=DMARC1), p, sp, adkim, aspf, fo, rua, ruf — même sens qu'en 7489.

Ce que ça implique pour un enregistrement

La bonne nouvelle, encore une fois : rien d'urgent. Un enregistrement écrit sous la 7489 reste parfaitement valide, et il commence toujours par v=DMARC1. Les seules retouches utiles :

• retirer pct s'il y figure encore (il n'est plus interprété par les implémentations à jour) ;
• ajouter np=reject pour couvrir les sous-domaines fantômes ;
• ne rien changer pour ri/rf : leur disparition du cœur est transparente côté émetteur.

La feuille de route détaillée, étape par étape, est dans faut-il migrer.

Pourquoi le passage en « Proposed Standard » compte

Au-delà de la technique, le changement de statut a une portée concrète. Un Proposed Standard est un point d'appui bien plus solide pour les auditeurs et les régulateurs : citer « DMARC selon la RFC 9989 » a plus de poids que citer un document Informational. Pour les organisations soumises à des cadres comme NIS2 ou DORA, où l'authentification email est un contrôle attendu, c'est un argument de conformité de plus. On en parle dans les banques.

Et l'interopérabilité pendant la transition ?

Une question revient souvent : « les nouvelles balises vont-elles casser chez les vieux destinataires ? » Non. DMARCbis est conçu pour la rétrocompatibilité : un destinataire qui ne connaît pas encore np ou t ignore simplement ce qu'il ne comprend pas, et continue d'appliquer p, sp et l'alignement comme avant. Les nouvelles balises peuvent donc se publier dès maintenant, sans attendre que tout l'écosystème soit à jour — il n'y a aucun inconvénient à être en avance, et un vrai bénéfice à fermer la faille des sous-domaines inexistants.

Un enregistrement avant / après

Rien de tel qu'un exemple concret pour voir ce que les RFC changent. Voici un enregistrement typique tel qu'on l'écrivait sous la RFC 7489 :

v=DMARC1; p=reject; sp=reject; pct=100; adkim=s; aspf=s; rua=mailto:rapports@exemple.fr

Et le même, modernisé pour DMARCbis :

v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=s; rua=mailto:rapports@exemple.fr

Deux différences seulement : pct=100 a disparu (la balise est retirée, et pct=100 ne servait de toute façon à rien), et np=reject est apparu pour couvrir les sous-domaines inexistants. Tout le reste — v=DMARC1, p, sp, l'alignement strict, le rua — est identique. C'est exactement pour ça qu'on parle de révision et non de réécriture : 90 % de l'enregistrement ne bouge pas.

Qui est concerné par quelle RFC

Les trois documents ne s'adressent pas au même public, et identifier le bon évite de lire 80 pages pour rien :

• Publier DMARC pour un domaine ? Seule la RFC 9989 compte vraiment, et encore : seulement la partie sur les balises. Le code de rapport ne s'écrit pas de ce côté-là, il se consomme.
• Recevoir et analyser des rapports (soi-même ou via un prestataire) ? La RFC 9990 décrit ce qui arrive et comment l'interpréter.
• Développer une solution DMARC ou opérer un service de messagerie ? Les trois RFC sont au programme, plus les sections sur le Tree Walk et l'interopérabilité.

Pour la grande majorité des organisations, le travail réel tient en deux lignes de DNS (voir l'exemple ci-dessus). Les RFC sont la référence ; les lire n'est pas une condition de conformité — publier le bon enregistrement, si.

Une question de vocabulaire : « DMARC V2 » existe-t-il vraiment ?

« DMARC V2 » ou « DMARC 2.0 » circulent un peu partout. Ce sont des surnoms commodes, pas des termes officiels : l'IETF parle de « DMARCbis » (le suffixe -bis signifie « la version révisée »). Et surtout, il n'existe pas de v=DMARC2 dans la syntaxe — l'identifiant reste v=DMARC1. Un outil ou un article qui prescrit de « passer à DMARC2 » dans l'enregistrement doit donc éveiller la méfiance : c'est faux, et ça trahit une mauvaise compréhension du standard.

Comment vérifier qu'un enregistrement est « à jour »

Nul besoin de lire les trois RFC pour savoir si un enregistrement est moderne. Trois contrôles suffisent :

• v=DMARC1 en tête — toujours présent (sinon ce n'est pas un enregistrement DMARC valide).
• Pas de pct — s'il en reste un, il est à retirer ; les implémentations récentes l'ignorent.
• np présent — sans cette balise, les sous-domaines inexistants ne sont pas couverts.

Un analyseur fait ces vérifications en quelques secondes : un passage du domaine dans notre analyseur gratuit signale les balises obsolètes et les manques. La posture d'un domaine se situe aussi par rapport à tout un secteur dans l'Observatoire — où l'on voit, chiffres à l'appui, combien de domaines n'ont même pas atteint p=reject.

Les RFC elles-mêmes sont publiques et gratuites sur le site de l'IETF, pour qui veut la source de vérité. Mais pour la quasi-totalité des cas, l'enregistrement compte plus que le texte : c'est ce que voient les destinataires, et c'est lui qui protège — ou non — le domaine. Lire 80 pages de RFC ne change rien tant que l'enregistrement publié n'est pas à jour.

En bref

DMARCbis n'est pas un seul document mais trois RFC : 9989 (le protocole et ses balises), 9990 (les rapports agrégés) et 9991 (les rapports d'échec), qui remplacent ensemble la RFC 7489. Côté émetteur, l'essentiel tient en deux gestes — ajouter np, retirer pct — sur un enregistrement qui commence toujours par v=DMARC1. Le passage en Proposed Standard renforce surtout la valeur de DMARC comme contrôle auditable.

Thomas traduit les RFC en DNS

Lire trois RFC pour en tirer deux lignes de DNS n'est pas la meilleure allocation d'un temps d'ingénieur. Thomas, le RSSI virtuel, connaît DMARCbis : il génère l'enregistrement exact à publier — balises np et t comprises — à partir de l'état réel du domaine, nomme chaque source d'envoi depuis les rapports, et guide la montée jusqu'à p=reject.

Analyser un domaine gratuitement ou créer un compte pour démarrer. En première approche du sujet, ce nouveau standard expliqué simplement reste le meilleur point d'entrée.