Comment lire un rapport DMARC RUA (et ce qu'il révèle)

<?xml version="1.0" ?>
<feedback>
  <report_metadata>
    <org_name>Google Inc.</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>3456789012345678901</report_id>
    <date_range>
      <begin>1719273600</begin>
      <end>1719359999</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>exemple.fr</domain>
    <p>reject</p>
    <sp>reject</sp>
    <adkim>r</adkim>
    <aspf>r</aspf>
  </policy_published>
  <record>
    <row>
      <source_ip>40.107.1.25</source_ip>
      <count>347</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>exemple.fr</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>exemple.fr</domain>
        <result>pass</result>
        <selector>selector1</selector>
      </dkim>
      <spf>
        <domain>exemple.fr</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Lire un rapport en pratique : le flux de lecture

Quand un rapport arrive, la lecture suit cet ordre :

1. org_name — qui l'envoie (Gmail, Outlook, Yahoo…).
2. date_range — de quelle période (hier ? il y a deux jours ?).
3. policy_published/p — la politique est-elle bien visible ?
4. Pour chaque <record> :
   • source_ip : cette IP est-elle reconnue ?
   • count : combien de messages ?
   • policy_evaluated/dkim et spf : est-ce que ça passe ou ça échoue ?
   • Si ça échoue : pourquoi ? auth_results donne le détail.

En quelques minutes, ce flux dit si les sources légitimes passent et si des IP suspectes envoient au nom du domaine.

Pourquoi un outil d'analyse fait la différence

Un rapport Gmail seul contient parfois des dizaines de blocs <record>. Multiplié par les rapports Microsoft, Yahoo, Apple, et les autres, la lecture manuelle devient rapidement épuisante. Les outils d'analyse DMARC agrègent ces rapports, les enrichissent avec l'identité des IP (hébergeurs, plateformes connues) et en présentent une vue consolidée. Notre analyseur fait exactement ça : il lit les rapports, identifie les sources, et présente l'état de chacune — sans qu'un seul fichier XML ait besoin d'être ouvert.

Questions fréquentes

Mes rapports arrivent en .gz ou .zip. Comment les ouvrir ? En décompressant le fichier (gunzip sur Mac/Linux, 7-Zip ou WinRAR sur Windows) pour obtenir le .xml, puis en l'ouvrant dans un éditeur texte ou un navigateur. Mieux : un outil d'analyse qui le fait automatiquement.

Pourquoi je reçois plusieurs rapports par jour ? Non, en général un par expéditeur par jour (période de 24h par défaut). Plusieurs rapports d'un même acteur peuvent traduire un découpage si le volume est très élevé.

Je vois disposition=quarantine mais ma politique est p=reject. Pourquoi ? Le policy_evaluated/disposition reflète ce que le FAI a effectivement appliqué, pas la politique déclarée. Certains acteurs ont des override (whitelists, accords bilatéraux) qui adoucissent l'application. Ce n'est pas une erreur côté domaine.

Je ne reçois aucun rapport. Que se passe-t-il ? L'enregistrement DMARC doit être bien publié et contenir rua=mailto:adresse@exemple.fr. L'adresse de réception doit aussi être accessible, et les emails ne pas finir en spam. Si l'adresse rua= est sur un domaine externe, ce domaine externe doit avoir un enregistrement _dmarc d'autorisation.

Chaque email envoyé génère-t-il un rapport ? Non. Les rapports sont agrégés : un bloc par combinaison IP/résultats sur la période. 1000 emails depuis la même IP avec les mêmes résultats = 1 <record> avec count=1000.

Que faire quand je vois une IP que je ne reconnais pas ? Commencer par la résoudre en reverse DNS (nslookup IP ou dig -x IP) et regarder à quel service elle appartient. Si c'est un hébergeur cloud connu, c'est peut-être une ancienne VM ou un service oublié. Si c'est une plage inconnue sans reverse DNS clair, c'est un signal d'alerte — peut-être de la contrefaçon. Dans tous les cas, elle ne doit pas être marquée « légitime » sans que sa source ait été identifiée avec certitude.

Les rapports incluent-ils les messages rejetés par mon propre filtre spam ? Non. Les rapports RUA portent sur les messages qui ont atteint le serveur destinataire et ont été évalués par DMARC. Les messages rejetés avant évaluation DMARC (connexion TCP bloquée, rejet SMTP) n'y apparaissent pas.

Est-ce que les rapports reflètent tous mes emails ou seulement certains ? Seulement les messages qui arrivent chez les destinataires dont le FAI envoie des rapports DMARC. Un envoi vers un domaine qui n'a pas implémenté le reporting n'y apparaît pas — même avec une politique active. C'est pour ça que les données des grands FAI (Gmail, Outlook, Yahoo) sont les plus représentatives : ils couvrent l'essentiel du trafic mondial.

Ce qu'un rapport révèle de la posture réelle

Un rapport RUA n'est pas qu'une liste de résultats — c'est un instantané de la posture d'authentification. Une lecture attentive de chaque bloc <record> reconstitue une image précise de la situation : quelles sources fonctionnent, lesquelles sont cassées, et lesquelles n'avaient jamais été identifiées. Ce dernier point est souvent le plus révélateur : les rapports DMARC découvrent régulièrement des sources d'envoi que les organisations ont oubliées — une ancienne application, un prestataire dont on n'utilise plus le service mais dont la configuration DNS n'a pas été nettoyée, un outil SaaS qui envoie des notifications au nom du domaine à l'insu de tous.

Pour tirer le maximum d'un rapport, il faut aller au-delà de la lecture source par source et chercher les patterns : est-ce que les échecs sont concentrés sur quelques IPs ou dispersés ? Est-ce que les mêmes IPs échouent dans les rapports de plusieurs FAI ou seulement chez l'un ? Est-ce que le volume d'échecs augmente dans le temps ? Ces questions transforment un diagnostic ponctuel en une compréhension systémique de la posture.

Les signaux d'alarme à surveiller

Quelques configurations dans un rapport appellent une attention immédiate. Un count élevé sur une IP inconnue : quelqu'un envoie beaucoup de messages sous l'identité du domaine, depuis une IP non reconnue. Avec une politique en p=none, ces messages arrivent à destination — avec l'image du domaine. Des échecs soudains sur une IP identifiée : une configuration a changé quelque part (rotation de clé DKIM mal exécutée, modification de configuration SPF, changement de provider). Un policy_published/p différent de la politique déclarée : l'enregistrement n'est pas bien publié, ou il y a eu une modification non souhaitée. Ces trois signaux méritent une investigation immédiate, indépendamment du reste du rapport.

Un quatrième signal mérite le même réflexe : un header_from qui affiche un sous-domaine inutilisé. Les rapports ne couvrent pas que le domaine principal — quand un message se réclame d'un sous-domaine, le bloc <record> correspondant le montre dans header_from, et c'est la balise <sp> de la politique qui s'applique alors. Un expéditeur légitime peut s'y loger (une plateforme configurée sur un sous-domaine dédié), mais un usurpateur aussi : les sous-domaines sont souvent moins surveillés que la racine, et c'est exactement ce qui les rend attractifs. Balayer les valeurs de header_from de chaque rapport, pas seulement les IP, doit devenir une habitude — un sous-domaine inattendu est une découverte au même titre qu'une adresse inconnue.

Thomas décode les rapports

Ouvrir et décoder des XML à la main, c'est faisable — mais fastidieux et potentiellement trompeur si on ne sait pas où regarder. Thomas, le RSSI virtuel, lit les rapports en continu, indique quelles sources passent et lesquelles méritent attention, et présente un diagnostic clair sans XML brut.

Analyser un domaine gratuitement ou créer un compte pour des rapports DMARC lisibles d'un coup d'œil.