Rapports agrégés DMARC (RUA) : les lire et agir dessus à l’ère de DMARCbis

Un enregistrement DMARC sans adresse rua protège un domaine à l’aveugle : il bloque ou laisse passer du courrier sans jamais dire qui l’a envoyé. Les rapports agrégés DMARC (RUA) comblent ce manque en listant, chaque jour, les adresses IP qui ont expédié du courrier au nom du domaine et le résultat de leur authentification SPF et DKIM. Depuis mai 2026, leur cadre technique a changé : les RFC 9989, 9990 et 9991 remplacent la RFC 7489 de 2015 et font passer DMARC du statut Informational au statut Proposed Standard de l’IETF.

#Pourquoi les rapports RUA restent indispensables

Un domaine qui passe en p=reject sans avoir lu ses rapports agrégés au préalable prend le risque de bloquer ses propres campagnes marketing, ses outils de support ou un prestataire oublié. Les rapports RUA donnent la liste exhaustive des sources d’envoi observées par les grands récepteurs (Gmail, Outlook, Yahoo) sur une période donnée, avec pour chacune le volume de messages et le verdict d’alignement SPF et DKIM. C’est la seule source de données qui ne dépend pas d’une déclaration du domaine lui-même.

Le guide sur SPF, DKIM et DMARC détaille la mise en place de ces trois mécanismes ; celui-ci se concentre sur l’étape suivante, trop souvent ignorée : l’exploitation effective des rapports une fois l’adresse rua renseignée.

#La structure d’un rapport agrégé

Un rapport RUA est un document XML envoyé une fois par jour par chaque récepteur qui a reçu du courrier du domaine. La RFC 9990 en fixe la structure : un en-tête report_metadata qui identifie l’organisation émettrice et la période couverte, un bloc policy_published qui rappelle la politique DMARC lue dans le DNS au moment de l’évaluation, puis une série d’éléments record, un par couple source/résultat.

Voici un extrait simplifié de ce que contient un rapport, pour un seul expéditeur :

<record>
  <row>
    <source_ip>203.0.113.45</source_ip>
    <count>412</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>mail-studio.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>mail-studio.com</domain>
      <selector>s1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>sendgrid.net</domain>
      <result>fail</result>
    </spf>
  </auth_results>
</record>

Ce record montre un cas fréquent : le message passe DKIM (la signature du domaine est valide) mais échoue SPF, parce que l’enveloppe d’expédition porte le domaine du prestataire d’envoi plutôt que celui du site. Comme DMARC exige qu’au moins un des deux mécanismes passe et soit aligné, ce message reste conforme malgré l’échec SPF.

#Ce que change DMARCbis (RFC 9989 à 9991)

Les trois documents publiés en mai 2026 répartissent le protocole en trois textes distincts : la RFC 9989 pour le cœur du protocole (politique, alignement, traitement des enregistrements), la RFC 9990 pour les rapports agrégés, et la RFC 9991 pour les rapports d’échec. Le changement le plus visible pour la lecture des rapports concerne le champ discovery_method du bloc policy_published : il indique désormais si le domaine organisationnel a été déterminé via la liste des suffixes publics (PSL) ou via une méthode de parcours DNS ascendant, le « Tree Walk », qui ne dépend plus d’une liste externe maintenue à la main.

Le tag pct, jugé inconsistant d’un récepteur à l’autre, disparaît de la RFC 9989 (voir son annexe consacrée à son retrait). Deux tags prennent le relais pour des usages plus précis :

#Lire les rapports sans plateforme payante

Les récepteurs envoient les rapports compressés (gzip ou zip) à l’adresse déclarée dans rua. Pour un domaine de taille modeste, un script qui décompresse, parse le XML et agrège par source_ip suffit largement : la plupart des langages disposent d’un analyseur XML natif, et la structure décrite plus haut se prête bien à une transformation en tableau. L’essentiel est de regrouper par expéditeur plutôt que de lire chaque rapport individuellement, car le volume quotidien peut vite atteindre plusieurs dizaines de fichiers pour un domaine actif.

Les plateformes spécialisées (gratuites ou payantes selon le volume) automatisent cette agrégation et affichent des tableaux de bord, ce qui reste préférable dès que plusieurs domaines ou sous-domaines sont suivis en parallèle. Le guide sur les causes de mise en spam détaille d’autres signaux à croiser avec ces rapports pour diagnostiquer un problème de délivrabilité.

Les rapports RUA ne couvrent que ce que les récepteurs acceptent de signaler : ils ne disent rien du placement final d’un message (boîte de réception, onglet promotions ou dossier spam). Pour ce niveau de détail, il faut croiser les rapports agrégés avec un outil de réputation propre à chaque récepteur, comme Google Postmaster Tools côté Gmail, qui expose un indicateur de réputation de domaine et d’IP indépendant du contenu des rapports DMARC. Les deux sources se complètent : DMARC dit qui envoie et avec quel résultat d’authentification, Postmaster Tools dit comment ce courrier est perçu une fois authentifié.

#Les pièges courants de l’interprétation

Un échec SPF n’est pas toujours un problème : dès qu’un message transite par un prestataire d’envoi tiers (plateforme marketing, outil de support), l’enveloppe porte le domaine du prestataire et SPF échoue mécaniquement, sans que DKIM ne soit affecté. Le piège inverse existe aussi : une source légitime qui échoue à la fois SPF et DKIM sur une période prolongée signale presque toujours une configuration incomplète chez le prestataire, à corriger avant d’envisager une politique plus stricte. Le guide sur le rendu des e-mails HTML aborde d’autres écarts entre ce qu’un expéditeur envoie et ce qu’un client de messagerie affiche, dans un esprit similaire de vérification avant diagnostic.

Un autre piège consiste à confondre le volume de messages avec la gravité d’un problème. Une source inconnue qui n’envoie que quelques messages par jour mérite d’être identifiée, mais elle ne justifie pas de retarder un passage en p=quarantine si les sources majoritaires sont propres. À l’inverse, une source qui représente une part importante du volume total et échoue systématiquement l’alignement doit être traitée avant toute bascule de politique, sous peine de bloquer une proportion significative du courrier légitime du domaine. Les rapports d’échec (RUF, désormais définis par la RFC 9991) complètent ce diagnostic avec un niveau de détail par message, mais tous les récepteurs ne les envoient pas, et leur contenu peut inclure des éléments du message original : ils doivent être traités avec les mêmes précautions de confidentialité que n’importe quelle donnée d’en-tête d’e-mail.

#Ce qu’il faut retenir

Les rapports agrégés DMARC restent la source de données la plus fiable pour cartographier qui envoie du courrier au nom d’un domaine. DMARCbis ne bouleverse pas leur lecture, mais clarifie la manière dont le domaine organisationnel est déterminé et retire un tag ambigu au profit de réglages plus explicites. Avant tout passage à une politique plus stricte, la seule méthode robuste reste l’observation des rapports sur plusieurs semaines, source par source.

Pour aller plus loin : le texte intégral de la RFC 9990 détaille le schéma XML complet des rapports agrégés DMARC.