Comment lire et comprendre un rapport DMARC

En bref : Un rapport DMARC agrégé arrive dans votre boîte sous forme de fichier XML compressé, envoyé chaque jour par les fournisseurs de messagerie comme Google ou Microsoft. Il recense les adresses IP qui expédient des emails en votre nom et indique si ces messages passent l’authentification SPF et DKIM. Savoir le lire vous permet de repérer une usurpation, de corriger un prestataire mal configuré et de durcir votre politique en toute confiance. Ce guide décortique chaque balise du fichier et liste les pièges d’interprétation à éviter.

Un rapport DMARC arrive d’abord sous forme de pièce jointe XML

La première surprise, quand on découvre DMARC, tient à la forme du rapport. Vous attendez un tableau de bord clair, vous recevez un fichier .xml.gz accroché à un email. Rien d’engageant au premier coup d’œil.

Ce fichier n’est généré que si votre enregistrement DNS contient la balise rua=, suivie de l’adresse qui doit recevoir les rapports. Sans ce tag, aucun fournisseur ne vous enverra quoi que ce soit, même si votre politique DMARC est publiée. C’est une étape oubliée par beaucoup : selon EasyDMARC, sur 1,8 million de domaines analysés en 2026, à peine 159 691 combinent une politique stricte p=reject et le tag rua= qui donne la visibilité. Autrement dit, une majorité applique une règle sans jamais regarder ce qu’elle bloque.

Pour ouvrir le rapport, décompressez l’archive (gzip ou zip selon l’émetteur), puis ouvrez le .xml obtenu dans un éditeur de texte ou un navigateur. Vous tombez sur une structure balisée, lisible une fois qu’on en connaît la logique. Et cette logique se résume à trois blocs.

Les trois blocs d’un rapport agrégé

Tout rapport agrégé s’ouvre sur une balise racine <feedback> qui contient trois sections successives. Voici un exemple réduit, commenté :

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>          <!-- qui génère le rapport -->
    <email>noreply-dmarc@google.com</email>
    <report_id>14829471028401</report_id>
    <date_range>
      <begin>1719273600</begin>              <!-- début de période (timestamp Unix) -->
      <end>1719360000</end>                  <!-- fin = begin + 86400, soit 24 h -->
    </date_range>
  </report_metadata>

  <policy_published>
    <domain>votredomaine.fr</domain>
    <adkim>r</adkim>                          <!-- alignement DKIM : relaxed -->
    <aspf>r</aspf>                            <!-- alignement SPF : relaxed -->
    <p>none</p>                               <!-- politique appliquée -->
    <pct>100</pct>                            <!-- % de messages concernés -->
  </policy_published>

  <record>
    <row>
      <source_ip>203.0.113.10</source_ip>
      <count>42</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>votredomaine.fr</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>votredomaine.fr</domain>
        <selector>s1</selector>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>votredomaine.fr</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Le bloc report_metadata identifie l’émetteur et la fenêtre temporelle. Le bloc policy_published rappelle la politique que le fournisseur a trouvée dans votre DNS au moment de l’analyse. Le bloc record, enfin, est le cœur du rapport : un enregistrement par groupe d’IP et de résultat. Un même fichier peut en contenir des dizaines.

Décoder un enregistrement, ligne par ligne

Chaque record raconte l’histoire d’un flux d’emails partis d’une même adresse IP. Quatre informations comptent vraiment.

<source_ip> désigne le serveur qui a envoyé les messages. C’est votre premier indice : reconnaissez-vous cette IP ? Correspond-elle à votre routeur, votre CRM, votre outil de facturation ?

<count> donne le nombre de messages partis de cette IP sur la période. Un volume élevé venant d’une source inconnue mérite votre attention immédiate.

Le bloc <policy_evaluated> indique l’action réellement prise par le destinataire : disposition vaut none, quarantine ou reject. Les champs dkim et spf qu’il contient reflètent le verdict DMARC, c’est-à-dire le résultat de l’authentification une fois l’alignement vérifié.

<header_from>, dans le bloc identifiers, correspond au domaine visible dans le champ From: de l’email. C’est contre lui que tout l’alignement se mesure.

Le bloc <auth_results>, pour finir, donne les résultats bruts de SPF et DKIM, avec le domaine signataire et le sélecteur. Cette distinction entre verdict brut et verdict aligné est précisément là où la plupart des lectures dérapent.

Alignement : pourquoi un SPF « pass » peut quand même échouer

Voici le point que les guides survolent et qui pourtant explique 80 % des incompréhensions. DMARC ne se contente pas de vérifier que SPF ou DKIM passe techniquement. Il vérifie que le domaine authentifié correspond au domaine du From: visible. C’est ça, l’alignement.

Prenons SPF. Un message peut afficher <auth_results><spf><result>pass</result> parce que l’enveloppe d’expédition est valide. Mais si ce domaine d’enveloppe diffère de celui du From:, l’alignement échoue, et le rapport indiquera <policy_evaluated><spf>fail</spf>. Un SPF techniquement bon, un alignement raté, un échec DMARC à la clé.

Deux modes existent. En mode relaxed (r), les sous-domaines de la même organisation suffisent. En mode strict (s), le domaine doit être identique au caractère près. La règle de validation finale reste simple : un message passe DMARC dès qu’un seul des deux alignements, SPF ou DKIM, est satisfait. Inutile que les deux réussissent, l’un suffit.

Pour comprendre la mécanique SPF, DKIM et DMARC dans le détail, notre guide complet de l’authentification email pose les bases avant la lecture des rapports.

Cinq erreurs d’interprétation qui faussent votre lecture

Lire les balises ne suffit pas. Encore faut-il éviter les contresens qui mènent à de mauvaises décisions.

Confondre auth_results et policy_evaluated. Le premier donne le résultat technique, le second le verdict DMARC après alignement. Un DKIM pass dans auth_results n’empêche pas un fail dans policy_evaluated si la signature n’est pas alignée.

Prendre un volume de « fail » pour une attaque. Le plus souvent, ces échecs viennent d’un prestataire légitime que vous avez oublié de configurer : un outil de signature électronique, une plateforme de support, un service de facturation. La vraie usurpation existe, mais elle se cache derrière des IP que vous ne reconnaissez pas du tout.

S’étonner d’un disposition=none alors que la politique est reject. Regardez le pct. S’il vaut 10, seuls 10 % des messages non conformes sont rejetés, le reste passe en none. Un déploiement progressif explique ce décalage.

Buter sur le timestamp Unix. Les balises <begin> et <end> ne sont pas des dates lisibles mais des secondes écoulées depuis 1970. Un convertisseur en ligne, ou la commande date -r 1719273600, vous rend la période exacte.

Ignorer le forwarding. Une redirection d’email ou une liste de diffusion casse régulièrement SPF. Ces messages légitimes apparaissent en échec sans que votre configuration soit en cause. Le contexte de la source IP permet de les distinguer d’une vraie menace.

Des outils gratuits pour parser vos rapports

Lire le XML à la main reste formateur, mais devient vite ingérable au-delà de quelques fichiers par jour. Plusieurs outils convertissent ces rapports en vues lisibles, sans frais.

Outil	Type	Usage
parsedmarc	Open source (Python)	Agrège vos rapports dans un tableau de bord auto-hébergé
MxToolbox DMARC Report Analyzer	En ligne	Collez ou importez un XML, lecture immédiate
dmarcian XML-to-Human	En ligne	Traduit un rapport brut en tableau lisible

L’outil n’invente rien : il remet en forme ce que vous savez désormais lire. C’est un gain de temps, pas un substitut à la compréhension. Quand un fournisseur vous signale un flux suspect, vous voulez pouvoir remonter à la balise exacte.

De la lecture à l’action : durcir votre politique

Lire un rapport n’a de sens que si vous en tirez des décisions. La logique de déploiement est connue : on démarre en p=none pour observer sans bloquer, on identifie et on authentifie chaque source légitime, puis on bascule en quarantine, et enfin en reject une fois la base assainie.

Les chiffres montrent que peu de domaines franchissent cette dernière marche. Sur les domaines en .fr, l’AFNIC relève en 2025 un taux d’adoption DMARC de 19,5 %, dont seulement 20,6 % en politique reject. La majorité reste en observation. Pourtant, l’efficacité du dispositif est mesurable : Google a constaté une baisse de 75 % des messages non authentifiés reçus sur Gmail en 2024, après l’entrée en vigueur de ses nouvelles exigences pour les expéditeurs en masse.

La lecture régulière de vos rapports est ce qui rend cette progression sûre. Elle révèle aussi des sources d’envoi parasites et des adresses qui dégradent votre réputation, deux sujets qui rejoignent directement la qualité de votre base et votre délivrabilité globale.

Questions fréquentes sur les rapports DMARC

Qu’est-ce qu’un rapport DMARC agrégé ?

C’est un fichier XML qu’un fournisseur de messagerie génère et vous envoie pour récapituler les emails reçus en votre nom. Il liste les adresses IP émettrices, le volume de messages et les résultats d’authentification SPF et DKIM. Il ne contient aucun contenu d’email, uniquement des statistiques d’authentification.

Quelle est la différence entre un rapport RUA et un rapport RUF ?

Le rapport RUA est agrégé : il regroupe des statistiques sur une période, sans détail message par message. Le rapport RUF, dit forensique, porte sur des échecs individuels et peut contenir des extraits d’en-têtes. Le RUA est de loin le plus répandu et le plus utile au quotidien.

Qui envoie les rapports DMARC ?

Les grands fournisseurs de messagerie qui reçoivent vos emails : Google, Microsoft, Yahoo et bien d’autres. Chacun analyse les messages prétendant venir de votre domaine, puis vous transmet son bilan. Le nom de l’émetteur figure dans la balise org_name du rapport.

À quelle fréquence reçoit-on les rapports DMARC ?

En règle générale une fois par jour, chaque fournisseur couvrant une fenêtre de 24 heures. Les balises begin et end du rapport délimitent précisément cette période. Le volume de rapports dépend du nombre de fournisseurs qui reçoivent vos envois.

Pourquoi un email légitime apparaît-il en échec dans mon rapport ?

Le plus souvent à cause d’un prestataire non authentifié, d’une redirection d’email ou d’une liste de diffusion qui casse SPF. L’adresse IP source vous aide à trancher : si elle correspond à un service que vous utilisez, il s’agit d’une configuration à corriger, pas d’une attaque.

Comment passer de p=none à p=reject sans risque ?

Restez en p=none le temps d’identifier et d’authentifier toutes vos sources d’envoi légitimes via SPF et DKIM. Passez ensuite en quarantine, surveillez les rapports quelques semaines, puis basculez en reject une fois qu’aucun flux légitime n’échoue plus. La lecture des rapports guide chaque étape.