Comment lire un rapport DMARC RUA (et ce qu'il te dit)

Un rapport DMARC RUA arrive dans ta boîte sous forme d'un fichier .xml.gz ou .xml.zip en pièce jointe. À l'intérieur, du XML qui, au premier regard, ressemble à un tableau de bord d'aéroport — beaucoup de balises, peu d'explications. Pourtant, une fois qu'on sait où regarder, un rapport RUA raconte une histoire très claire : qui a envoyé du courrier en ton nom, depuis où, avec quel résultat. Ce guide décode la structure et te dit quelles balises regarder en premier.

La structure générale

Un rapport RUA suit un schéma XML standardisé. Voici sa forme squelettique :

<?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>ton-domaine.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>ton-domaine.fr</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>ton-domaine.fr</domain>
        <result>pass</result>
        <selector>selector1</selector>
      </dkim>
      <spf>
        <domain>ton-domaine.fr</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Ce squelette contiendra en réalité plusieurs blocs <record>, un par combinaison d'IP source / résultats d'authentification observée.

Les balises essentielles à lire

report_metadata

• org_name : qui envoie le rapport. Google, Microsoft, Yahoo — c'est le FAI qui a reçu et évalué tes messages.
• date_range : la période couverte (timestamps Unix). Convertis-les pour savoir de quel jour parle le rapport.
• report_id : identifiant unique du rapport, utile pour le référencer si tu veux creuser avec le FAI.

policy_published

Ce que le FAI a vu comme politique au moment du rapport. Vérifie que <p> correspond à ce que tu veux appliquer. Si c'est none alors que tu pensais avoir mis quarantine, ton enregistrement DNS n'est peut-être pas encore propagé ou mal publié.

<record> — le cœur du rapport

Chaque <record> représente un groupe de messages identiques (même IP, mêmes résultats). C'est là que tout se passe :

• source_ip : l'IP qui a envoyé les messages. C'est ta première question : est-ce une IP que tu reconnais ? Ton serveur, ta plateforme d'envoi ?
• count : combien de messages sont regroupés dans ce bloc. Un count de 347 sur une IP reconnue, c'est normal. Un count de 12 sur une IP inconnue, ça mérite investigation.
• policy_evaluated → disposition : ce que le récepteur a réellement fait du message (none, quarantine, reject). Un disposition=none avec p=reject peut indiquer que le FAI a une override locale ou que le message passe quand même à cause d'un accord de confiance.
• policy_evaluated → dkim et spf : le résultat DKIM et SPF après alignement. C'est ce qui compte pour DMARC, pas les résultats bruts dans auth_results.
• header_from : le domaine du From: de l'email. Il doit toujours être ton domaine.

auth_results

Les résultats bruts SPF et DKIM, avant l'évaluation de l'alignement. Utile pour le diagnostic :

• Si auth_results/dkim/result=pass mais policy_evaluated/dkim=fail, la signature DKIM est valide mais non alignée — le domain dans auth_results/dkim est différent de header_from. C'est le cas classique : une plateforme qui signe avec son propre domaine.
• Si auth_results/spf/result=pass mais policy_evaluated/spf=fail, même logique : SPF passe pour l'enveloppe, mais l'enveloppe n'est pas ton domaine.

Lire un rapport en pratique : le flux de lecture

Quand un rapport arrive, lis-le dans 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 — est-ce que ma politique est bien visible ?
4. Pour chaque <record> :
   • source_ip : est-ce que je reconnais cette IP ?
   • count : combien de messages ?
   • policy_evaluated/dkim et spf : est-ce que ça passe ou ça échoue ?
   • Si ça échoue : pourquoi ? Regarde auth_results pour le détail.

En quelques minutes avec ce flux, tu sais si tes sources légitimes passent et si des IP suspectes envoient en ton nom.

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 te présentent une vue consolidée. Notre analyseur fait exactement ça : il lit tes rapports, identifie tes sources, et te présente l'état de chacune — sans que tu aies à ouvrir un seul fichier XML.

Questions fréquentes

Mes rapports arrivent en .gz ou .zip. Comment les ouvrir ? Décompresse le fichier (gunzip sur Mac/Linux, 7-Zip ou WinRAR sur Windows) pour obtenir le .xml, puis ouvre-le dans un éditeur texte ou un navigateur. Mieux : use d'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). Si tu en reçois plusieurs du même acteur, il peut y avoir 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 ta politique déclarée. Certains acteurs ont des override (whitelists, accords bilatéraux) qui adoucissent l'application. Ce n'est pas une erreur de ta part.

Je ne reçois aucun rapport. Que se passe-t-il ? Vérifie que ton enregistrement DMARC est bien publié et contient rua=mailto:adresse@ton-domaine.fr. Vérifie aussi que l'adresse de réception est accessible et que les emails ne finissent pas en spam. Si l'adresse rua= est sur un domaine externe, le domaine externe doit avoir un enregistrement _dmarc d'autorisation.

Est-ce que chaque email que j'envoie génère 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 ? Commence par la résoudre en reverse DNS (nslookup IP ou dig -x IP) et regarde à 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, ne la marque pas comme « légitime » sans avoir identifié sa source 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. Si tu envoies vers un domaine qui n'a pas implémenté le reporting, ces messages n'apparaissent pas — même si ta politique est 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 te dit sur ta posture réelle

Un rapport RUA n'est pas qu'une liste de résultats — c'est un instantané de ta posture d'authentification. En lisant attentivement chaque bloc <record>, tu peux reconstituer une image précise de ta situation : quelles sources fonctionnent, lesquelles sont cassées, et lesquelles tu n'avais pas 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 en ton nom sans que tu le sachies.

Pour tirer le maximum d'un rapport, va au-delà de la lecture source par source et cherche 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 ta posture.

Les signaux d'alarme à surveiller

Quelques configurations dans un rapport doivent attirer ton attention immédiate. Un count élevé sur une IP inconnue : quelqu'un envoie beaucoup de messages en prétendant être toi depuis une IP que tu ne reconnais pas. Si ta politique est p=none, ces messages arrivent à destination — avec l'image de ton domaine. Des échecs soudains sur une IP que tu reconnais : 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 ta politique : ton 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.

Laisse Thomas décoder tes 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, ton RSSI virtuel, lit tes rapports en continu, te dit quelles sources passent et lesquelles méritent attention, et te présente un diagnostic clair sans XML brut.

Analyse ton domaine gratuitement → ou crée un compte pour des rapports DMARC lisibles d'un coup d'œil.