Comment lire les rapports agrégés DMARC (RUA)

<report_metadata>
  <org_name>google.com</org_name>
  <report_id>14217...</report_id>
  <date_range><begin>1718...</begin><end>1718...</end></date_range>
</report_metadata>

<policy_published>
  <domain>exemple.fr</domain>
  <p>none</p><adkim>r</adkim><aspf>r</aspf><pct>100</pct>
</policy_published>

<record>
  <row>
    <source_ip>203.0.113.10</source_ip>
    <count>42</count>
    <policy_evaluated><disposition>none</disposition><dkim>pass</dkim><spf>fail</spf></policy_evaluated>
  </row>
  <identifiers><header_from>exemple.fr</header_from></identifiers>
</record>

Les champs qui décident de tout

Pour chaque source, trois choses méritent l'attention :

• source_ip et count — qui a envoyé, et combien. Les sources à fort volume sont les plus importantes à régler correctement.
• Les résultats dkim et spf dans policy_evaluated — ils reflètent l'alignement, pas seulement le passage du mécanisme isolé. C'est le chiffre qui compte : une source peut passer SPF brut et afficher quand même spf: fail ici parce que le domaine ne s'alignait pas avec le From:.
• disposition — ce que le destinataire a réellement fait (none, quarantine, reject), selon la politique en vigueur.

Une source où dkim ou spf affiche pass est authentifiée et sûre à enforcer. Une source où les deux fail est l'ensemble problématique — soit un expéditeur légitime pas encore aligné, soit un usurpateur.

Transformer les rapports en actions

Le flux est toujours le même, et c'est tout l'enjeu :

1. Agréger sur plusieurs rapports. Un seul jour d'un seul fournisseur n'est qu'un fragment. Combiner de nombreux rapports sur quelques semaines donne le tableau complet des expéditeurs du domaine.
2. Identifier chaque source légitime. Cette IP à fort volume qui passe DKIM est sans doute la plateforme mail de l'entreprise. Celle qui échoue aux deux peut être le CRM, la facturation, ou un outil qu'une équipe a installé sans prévenir la DSI. Chacune doit être nommée.
3. Corriger l'alignement des légitimes. Ajouter l'include: manquant à SPF, mettre en place une signature DKIM avec un d= aligné, jusqu'à ce que chaque vraie source affiche un pass.
4. Regarder les échecs diminuer. Quand les seules sources en fail restantes sont inconnues — des usurpateurs — le durcissement est mûr.
5. Monter la politique. Passer à quarantine, puis reject, en vérifiant que les rapports restent propres. La séquence complète est dans atteindre p=reject.

La lecture est une habitude, pas un projet

Le flux ci-dessus ne rapporte que si quelqu'un le déroule vraiment. La lecture des rapports est un rituel récurrent avec un responsable désigné, pas un audit ponctuel : une courte revue hebdomadaire tant que la politique reste en p=none, un examen plus attentif dans les jours qui suivent tout changement DNS ou de politique, et un coup d'œil après l'arrivée de chaque nouvel outil d'envoi. En parallèle vient un inventaire vivant des sources — chaque IP ou service identifié, son propriétaire en interne, son statut d'alignement actuel. C'est cet inventaire qui survit aux départs et aux changements de prestataires : dans quelques mois, personne ne devrait avoir à redécouvrir que telle plage d'IP est « la plateforme de facturation ». Écrit une fois, vérifié à chaque revue, il transforme chaque nouveau rapport en simple comparaison plutôt qu'en enquête.

Pourquoi on abandonne — et comment l'éviter

Lire du XML brut à la main ne passe pas à l'échelle. Une entreprise de taille moyenne peut recevoir des dizaines de rapports par jour de nombreux fournisseurs, chacun listant de nombreuses IP. Faire correspondre un flux d'adresses IP à « ah, c'est le Zendesk maison » est fastidieux et source d'erreurs — c'est exactement pourquoi tant de domaines collectent des rapports un temps puis s'arrêtent discrètement en p=none. Les rapports n'ont jamais été le problème ; leur donner du sens, si.

La solution est de laisser un logiciel faire l'agrégation et la traduction. C'est ce pour quoi Thomas, le RSSI virtuel, est conçu : il ingère les rapports agrégés, transforme les IP brutes et les PTR en noms de services reconnaissables (« un compte Mailchimp », « un sous-compte SendGrid non configuré »), évalue la préparation du domaine sur une fenêtre glissante, et désigne exactement les sources à corriger avant chaque étape vers p=reject.

Ce que les rapports agrégés ne disent pas

Les rapports agrégés sont puissants, mais connaître leurs limites évite d'en tirer de fausses conclusions :

• Aucun contenu de message. Les rapports agrégés contiennent des comptes et des résultats d'authentification, jamais les objets, corps ou adresses des destinataires. Ils disent *qu'*une source a émis au nom du domaine et comment elle s'est authentifiée — pas ce que disait le courrier. (Un type de rapport distinct et plus rare — forensique ou d'échec, RUF — peut inclure des échantillons caviardés, mais beaucoup de fournisseurs n'en envoient pas du tout, pour des raisons de vie privée.)
• Un délai d'environ un jour. Les rapports couvrent une fenêtre de 24 h et arrivent ensuite : ils montrent toujours hier, pas l'instant présent. Aucun retour en temps réel n'est à attendre après la modification d'un enregistrement ; il faut laisser un jour ou deux. Ce rythme quotidien est inscrit dans le standard — pourquoi les rapports arrivent une fois par jour en explique les mécanismes.
• Par source, pas par message. Une ligne agrège de nombreux messages d'une même IP au même résultat. Tracer un email individuel est impossible avec les seules données agrégées.
• Seulement les destinataires participants. La plupart des grands fournisseurs envoient des rapports, mais pas tous. Les rapports reçus représentent la large majorité du courrier, pas littéralement la totalité.
• Des IP brutes, pas des noms. Le rapport dit 198.51.100.7, pas « le Zendesk maison ». Faire correspondre les adresses aux services incombe à l'équipe — et c'est la partie la plus chronophage du travail.

Rien de tout cela ne diminue leur valeur ; cela signifie seulement que les rapports agrégés sont une carte, pas une caméra en direct. Ils se lisent comme des tendances sur des semaines, pas comme une télémétrie instantanée, et gagnent à être associés à un outillage qui transforme les IP en expéditeurs reconnaissables.

Trois pièges de lecture fréquents

Quelques réflexes évitent de tirer de mauvaises conclusions d'un rapport :

• Confondre passage de mécanisme et alignement. Les champs dkim/spf dans policy_evaluated reflètent l'alignement. Une source peut très bien passer un SPF brut et afficher quand même spf: fail ici parce que son enveloppe ne s'aligne pas sur le From:. Ces champs se lisent toujours comme « aligné ? », pas « le mécanisme a-t-il techniquement passé ? ».
• Paniquer devant des IP inconnues. Un pic de petites sources éparses est souvent du transfert (un destinataire qui réexpédie le courrier reçu) plutôt qu'une attaque. Le volume et la régularité se regardent avant de conclure à l'usurpation : un usurpateur cherche le volume, un forward laisse une longue traîne de comptes à un message.
• Oublier ce que dit disposition. En p=none, la disposition reste none même quand dkim et spf échouent — c'est normal, rien n'est encore appliqué. Un disposition: none ne se lit pas comme « tout va bien » : ce sont dkim/spf qui disent si une source est saine.

DMARCbis et les rapports (RFC 9990)

DMARCbis (mai 2026) a réparti la spécification en trois RFC : 9989 pour le protocole, et surtout 9990, désormais dédiée aux rapports agrégés décrits ici. L'esprit ne change pas — mêmes blocs source / volume / résultats — mais deux détails apparaîtront progressivement dans ces rapports :

• Le bloc <policy_published> ne montrera plus <pct> (balise supprimée) et pourra inclure <np>, la politique des sous-domaines inexistants. Un pct encore présent signale simplement un destinataire pas encore à jour.
• La détermination du domaine organisationnel s'appuie désormais sur le DNS Tree Walk plutôt que sur la Public Suffix List, ce qui rend l'attribution plus prévisible.

Concrètement, la façon de lire un rapport ne bouge pas. À noter seulement que, pendant la transition, les rapports peuvent mêler ancien et nouveau format selon le fournisseur.

Faire arriver les rapports

Deux choses suffisent pour démarrer : un enregistrement DMARC avec une adresse rua=, et un endroit où envoyer les rapports. La syntaxe exacte de cette balise — y compris l'étape supplémentaire quand les rapports partent vers un autre domaine — est détaillée dans configurer son adresse rua. Le plus rapide est une boîte de collecte DMARC gratuite qui ingère et parse le XML automatiquement — une ligne DNS, et les rapports quotidiens deviennent un tableau de bord lisible au lieu d'un dossier de pièces jointes.

La première étape est de vérifier la configuration actuelle avec notre analyseur gratuit — il montre si une adresse rua= est bien en place et comment les sources s'alignent aujourd'hui. Puis créer un compte pour collecter et lire ces rapports en continu, avec Thomas qui traduit chaque source et indique le chemin vers l'application.

Sur les fondamentaux, deux points d'entrée : qu'est-ce que DMARC et comment SPF, DKIM et DMARC fonctionnent ensemble.