Comment lire les rapports DMARC : guide complet sur les indicateurs RUA et RUF

Vous avez publié un enregistrement DMARC, défini « rua= » sur votre adresse e-mail, et vous recevez désormais dans votre boîte de réception des rapports sous forme de fichiers XML compressés. Ceux-ci sont difficiles à lire, proviennent d’entreprises dont vous n’avez jamais entendu parler, et vous ne savez pas vraiment quoi en faire, si tant est qu’il y ait quelque chose à faire.

Ce guide vient remédier à cela. Il explique ce que contiennent les rapports DMARC, comment lire le code XML champ par champ, ce que signifient réellement les termes RUA et RUF, et, surtout, quelles mesures prendre lorsqu'un expéditeur est validé, rejeté ou apparaît de manière inattendue. Si vous avez votre premier rapport entre les mains en ce moment même, commencez par le début et lisez-le de haut en bas.

Ce blog part du principe que vous disposez déjà d'un enregistrement DMARC. Si ce n'est pas le cas, commencez par publier un enregistrement DMARC, puis revenez ici pour interpréter les rapports qu'il génère.

Que sont les rapports DMARC ?

Les rapports DMARC sont des récapitulatifs quotidiens envoyés par les serveurs de messagerie destinataires à l'adresse indiquée dans votre balise `rua=`. Chacun d'entre eux répertorie toutes les adresses IP ayant envoyé un e-mail prétendant provenir de votre domaine au cours d'une période de rapport, et indique si SPF et DKIM ont réussi ou échoué pour chaque source. Ils constituent l’outil principal pour surveiller le niveau d’authentification des e-mails de votre domaine. Ils vous offrent la seule véritable visibilité sur les expéditeurs qui envoient des e-mails en votre nom, qu’ils soient légitimes ou non.

Qui envoie les rapports DMARC ?

Chaque serveur de messagerie qui reçoit des e-mails provenant de votre domaine enverra un rapport si vous avez configuré « rua= ». Cela inclut bien sûr Google, Microsoft et Yahoo, mais aussi les petits prestataires de services de messagerie (ESP), les passerelles de messagerie d'entreprise, les systèmes universitaires et les fournisseurs internationaux que vos destinataires utilisent. 

Recevoir des messages provenant d'organisations que vous ne connaissez pas est normal et prévisible. Cela peut simplement signifier qu’un serveur quelque part a traité un message qui semblait provenir de votre domaine. Notez toutefois qu’un volume élevé de courriers dans ces rapports provenant d’une adresse IP que vous ne contrôlez pas justifie tout de même une enquête, car il s’agit d’un signe d’usurpation d’identité.

Le nombre de rapports que vous recevez chaque jour dépend du nombre de serveurs de messagerie distincts qui ont reçu votre e-mail. Si vous n'envoyez vos e-mails qu'à une poignée de destinataires, vous pouvez recevoir deux ou trois rapports par jour. Les expéditeurs qui envoient un volume important de messages peuvent en recevoir des centaines. En soi, cela n'indique pas qu'il y ait un problème. Le volume de rapports reflète la répartition de vos destinataires, et non l'état de santé de votre domaine.

Quand les rapports sont-ils disponibles ?

La plupart des fournisseurs envoient un rapport global toutes les 24 heures, et ces rapports parviennent généralement dans les 24 à 48 heures suivant l'activité de messagerie qu'ils décrivent. Vous recevez un rapport distinct de la part de chaque organisme de reporting (Google et Microsoft envoient chacun le leur, de manière indépendante) ; ainsi, les e-mails envoyés en une seule journée à des destinataires variés donnent lieu à plusieurs rapports couvrant la même période.

Les rapports sont envoyés sous forme de pièces jointes compressées au format .zip ou .gz par des expéditeurs automatisés. Certains clients de messagerie les signalent comme suspects ; par conséquent, si vous attendez des rapports et que vous n'en voyez aucun, vérifiez votre dossier « spam » ou « courrier indésirable » avant de conclure à un dysfonctionnement.

Types de rapports DMARC : RUA et RUF

Il existe deux types de rapports DMARC. Pour la quasi-totalité des domaines, vous n'aurez en principe à vous préoccuper que du premier.

Rapports agrégés (RUA) : la norme

Rapports agrégés DMARC constituent un résumé sur 24 heures de l’ensemble du trafic de messagerie provenant de votre domaine et traité par un serveur de messagerie donné. Ils sont fournis au format XML compressé et indiquent les adresses IP d’origine, les volumes de messages, SPF , DKIM (réussite/échec) et la disposition DMARC (l’action entreprise par le destinataire). Il est important de noter qu’ils ne contiennent aucun contenu d’e-mail ni aucune information permettant d’identifier une personne, mais uniquement des métadonnées d’authentification, ce qui permet de les recevoir et de les stocker en toute sécurité dans toutes les régions. C’est sur ce rapport que se concentre ce guide. 

Rapports d'échec (RUF) : échecs par message

Rapports d'échec DMARC (anciennement appelés « rapports d'analyse ») sont des notifications en temps quasi réel indiquant qu'un message spécifique n'a pas réussi l'authentification. La norme RFC 9991 (mai 2026) a officiellement normalisé ce type de rapport. Étant donné qu’un rapport d’échec peut inclure les en-têtes du message et parfois le contenu du corps (données susceptibles de contenir des informations personnelles identifiables), les principaux fournisseurs, notamment Google, Microsoft et Yahoo, ne les envoient pas du tout. N’activez ruf= que si vous disposez d’un processeur dédié au traitement de ces données, et ne vous attendez en aucun cas à recevoir de rapports de la part des grands fournisseurs de messagerie. 

RUA contre RUF 

Que contient un rapport DMARC : champ par champ

Un rapport agrégé DMARC est un fichier XML divisé en trois sections principales : les métadonnées du rapport (qui l'a envoyé et quand), la politique publiée (votre enregistrement DMARC tel que le destinataire l'a perçu), et les enregistrements, une ligne par source d'envoi. Comprenez ces trois éléments, et le reste n'est que détail.

Section 1: Report Metadata (<report_metadata>)

Ce bloc indique l'auteur du rapport et la période qu'il couvre.

• org_name : l'organisation déclarante (par exemple, google.com).
• e-mail : l'adresse de contact de l'expéditeur du rapport.
• report_id : identifiant unique de ce rapport spécifique.
• date_range (début + fin) : la période de référence, exprimée sous forme d'horodatages « epoch » ; vous devrez les convertir en dates lisibles par l'utilisateur.

À vérifier ici : assurez-vous que le rapport couvre bien la période souhaitée.

Section 2: Policy Published (<policy_published>)

Cela affiche votre enregistrement DMARC exactement tel que le destinataire l'a évalué au moment du traitement.

• domaine : le domaine auquel s'applique la politique.
• adkim / aspf : modes SPF DKIM et SPF (assoupli ou strict).
• p : votre politique (aucune, quarantine ou rejet).
• sp : votre politique relative aux sous-domaines, le cas échéant.
• pct : champ de pourcentage obsolète. Notez que le champ « pct » a été supprimé conformément à la RFC 9989 (mai 2026) ; il peut encore apparaître dans d'anciens rapports, mais les nouveaux enregistrements ne doivent plus le comporter.

Ce qu'il faut vérifier ici : assurez-vous que la politique publiée correspond bien à ce que vous aviez prévu. Si ce n'est pas le cas, il se peut que votre DNS ne se soit pas encore entièrement propagé.

Section 3: Records (<record>): The Important Part

Each <record> represents all the emails from one source IP during the reporting period. This is where you spend most of your time.

• source_ip : l'adresse IP de l'expéditeur. Consultez-la pour identifier l'expéditeur du message.
• nombre : combien de messages provenaient de cette adresse IP.
• policy_evaluated/disposition : l'action entreprise (aucune, quarantine ou rejet).
• policy_evaluated/dkim etspf: le résultat « réussi » ou « échoué » pour chacun, conformément à la norme DMARC.
• identificateurs/header_from : le domaine « De : » visible, qui est celui que protège le protocole DMARC.
• spf: le SPF et le résultat.
• auth_results/dkim : le domaine DKIM, le sélecteur et le résultat.

Ce qu'il faut vérifier ici : toutes les adresses IP que vous reconnaissez sont-elles conformes à DMARC, et y a-t-il des adresses IP que vous ne reconnaissez pas ?

Exemple de rapport DMARC au format XML

Voici un rapport agrégé réaliste et anonymisé présentant trois sources d'envoi : un expéditeur légitime dont la validation a abouti, un expéditeur légitime dont la validation a échoué et une adresse IP inconnue. Chaque champ est accompagné d'un commentaire rédigé en langage clair. 

<?xml version="1.0" encoding="UTF-8"?>
<feedback>

  <!-- ===== SECTION 1: WHO SENT THIS REPORT AND WHEN ===== -->
  <report_metadata>
    <org_name>google.com</org_name>             <!-- The provider that generated this report -->
    <email>[email protected]</email>  <!-- Where the report came from -->
    <report_id>1234567890123456789</report_id>  <!-- Unique ID for this report -->
    <date_range>
      <begin>1718928000</begin>                 <!-- Start of window (epoch) = 2024-06-21 00:00 UTC -->
      <end>1719014400</end>                      <!-- End of window (epoch)   = 2024-06-22 00:00 UTC -->
    </date_range>
  </report_metadata>

  <!-- ===== SECTION 2: YOUR POLICY AS THE RECEIVER SAW IT ===== -->
  <policy_published>
    <domain>example.com</domain>                <!-- The domain this report is about -->
    <adkim>r</adkim>                             <!-- DKIM alignment: r = relaxed -->
    <aspf>r</aspf>                               <!-- SPF alignment:  r = relaxed -->
    <p>none</p>                                  <!-- Your policy: monitoring only -->
    <sp>none</sp>                                <!-- Subdomain policy -->
  </policy_published>

  <!-- ===== SECTION 3: ONE RECORD PER SENDING SOURCE ===== -->

  <!-- RECORD 1: Legitimate sender (Google). All passing, no action needed. -->
  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>      <!-- A Google sending IP -->
      <count>150</count>                         <!-- 150 messages from this IP -->
      <policy_evaluated>
        <disposition>none</disposition>          <!-- No action taken -->
        <dkim>pass</dkim>                         <!-- DKIM aligned & passed -->
        <spf>pass</spf>                           <!-- SPF aligned & passed -->
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>      <!-- Visible From: domain -->
    </identifiers>
    <auth_results>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
      <dkim>
        <domain>example.com</domain>
        <selector>google</selector>
        <result>pass</result>
      </dkim>
    </auth_results>
  </record>

  <!-- RECORD 2: Known ESP. SPF passes but DKIM is not configured.
       Action: ask the provider to enable DKIM signing for your domain. -->
  <record>
    <row>
      <source_ip>198.51.100.42</source_ip>      <!-- Your email service provider -->
      <count>45</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>                         <!-- DKIM not aligned / not signed -->
        <spf>pass</spf>                           <!-- SPF passes -->
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
      <dkim>
        <domain>esp-vendor.example.org</domain>  <!-- Signed by vendor domain, not yours -->
        <selector>s1</selector>
        <result>fail</result>
      </dkim>
    </auth_results>
  </record>

  <!-- RECORD 3: Unknown sender. Both DKIM and SPF fail.
       Low volume here = monitor. High volume would signal active spoofing. -->
  <record>
    <row>
      <source_ip>203.0.113.17</source_ip>       <!-- Unrecognized IP -->
      <count>8</count>
      <policy_evaluated>
        <disposition>none</disposition>          <!-- Not blocked yet (p=none) -->
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>      <!-- Claiming to be your domain -->
    </identifiers>
    <auth_results>
      <spf>
        <domain>example.com</domain>
        <result>fail</result>
      </spf>
      <dkim>
        <domain>example.com</domain>
        <selector>unknown</selector>
        <result>fail</result>
      </dkim>
    </auth_results>
  </record>

</feedback>

Comment lire vos rapports DMARC : étape par étape

Étape 1 : Ouvrir et décompresser le rapport

Les rapports sont joints à un e-mail dont l'objet se présente comme suit : « Rapport concernant le domaine : votredomaine.com – Auteur : google.com – ID du rapport : … ». Enregistrez la pièce jointe, décompressez-la (les outils de décompression intégrés à votre système d'exploitation prennent parfaitement en charge les fichiers .zip et .gz), puis ouvrez le fichier .xml obtenu dans n'importe quel éditeur de texte. 

Si vous souhaitez aller plus loin qu’un simple coup d’œil, téléchargez-le sur notre outil d'analyse des rapports DMARC plutôt que de lire le code XML brut, afin d'analyser les données en profondeur dans un format lisible par l'utilisateur.

Étape 2 : Identifier l'organisme déclarant

Check <org_name> in the metadata so you know whose view you are looking at. Google’s report covers your Gmail recipients; Microsoft’s covers Outlook and Hotmail. You will get separate reports from each, so never assume one report is the whole picture.

Étape 3 : Vérifiez votre police publiée

Confirm <p>, <sp>, <adkim>, and <aspf> match what you intended to publish. If they do not, your record may have been propagated incorrectly or edited. Verify the live record with our DMARC Checker.

Étape 4 : Vérification de chaque enregistrement (source d'envoi)

For each <record>: look up the <source_ip> with a reverse DNS or IP lookup to identify the service (for example, 209.85.220.41 resolves to Google). Check the <count>. High volume from an IP you do not recognize is a red flag. Then check the disposition and the DKIM/SPF results. A legitimate sender should show both dkim=pass and spf=pass; a failure on either for a sender you recognize means something needs fixing.

Étape 5 : Classer chaque source par catégorie

Classez chaque source dans l'une des trois catégories suivantes :

1. Valide et conforme : aucune action requise.
2. Légitime mais inefficace : à améliorer (voir le cadre d'action ci-dessous).
3. Inconnu et en cours d'envoi : risque d'usurpation d'identité ; surveillez le volume et envisagez de renforcer votre politique s'il est élevé.

Analyse des rapports DMARC à grande échelle : outils et automatisation

Dès lors que les rapports affluent quotidiennement de la part de plusieurs fournisseurs, la lecture manuelle des fichiers XML devient impossible à gérer. Un domaine qui envoie des messages à des utilisateurs de Gmail, Outlook et Yahoo reçoit au moins trois rapports par jour, tous les jours, et la lecture manuelle de chacun d'entre eux n'est plus viable au-delà de la première semaine. Ce n'est pas un hasard si l'analyse automatisée est la norme dans le secteur.

Pour une vérification rapide et ponctuelle, des outils gratuits tels que le « DMARC Report Analyzer » de PowerDMARC vous permettent d'importer un fichier XML brut et d'en consulter le contenu dans un format lisible par l'utilisateur, sans avoir à ouvrir d'éditeur de texte.

Pour assurer une surveillance continue à grande échelle, une plateforme dédiée gère automatiquement l'ensemble du processus : elle harmonise les rapports de tous les fournisseurs en une vue unique, vous alerte lorsqu'un expéditeur inconnu apparaît, conserve l'historique et génère des fichiers d'exportation prêts pour les audits. 

Pour les utilisateurs de PowerDMARC, notre tableau de bord de reporting gère tout cela aussi bien dans les environnements à domaine unique que dans ceux à domaines multiples ; l'analyse s'effectue ainsi en continu, et non plus uniquement lorsque vous pensez à vérifier.

• Tous vos rapports réunis au même endroit : Au lieu d'avoir des dizaines de fichiers XML séparés éparpillés dans votre boîte de réception, tous les rapports de tous les fournisseurs sont regroupés dans une vue unique.
• Couverture de tous les domaines: pour les équipes gérant plusieurs domaines, cette consolidation s'étend à l'ensemble du portefeuille, de sorte qu'un seul tableau de bord couvre tous les domaines dont vous êtes responsables.
• Des données historiques, pas seulement des instantanés: l’historique conservé vous permet de suivre votre taux de réussite semaine après semaine, de vérifier qu’une correction apportée à un expéditeur défaillant a bien été appliquée, et de repérer une augmentation progressive des activités suspectes avant qu’elles ne se transforment en incident.
• Filtrage et recherche : Identifiez une source d'envoi ou un type de défaillance spécifique au lieu de passer en revue chaque enregistrement manuellement.
• Alertes concernant les nouveaux expéditeurs: Recevez une notification dès qu'un nouvel expéditeur non autorisé apparaît, afin de ne pas avoir à attendre la prochaine vérification manuelle pour le repérer.
• Exportation prête pour l'audit: Générez des rapports exportables à des fins de vérification de conformité et de communication aux parties prenantes.

Que faire de vos rapports DMARC ?

La lecture du rapport n'est qu'une première étape. C'est en agissant que vous protégez réellement votre domaine. Suivez les étapes suivantes dans l'ordre chaque fois que vous examinez une nouvelle série de rapports.

Corriger les expéditeurs légitimes qui ne sont pas reconnus

Si un expéditeur que vous connaissez (votre fournisseur de services de messagerie, votre CRM, votre service d'assistance ou votre plateforme de newsletter) affiche « dkim=fail » ou spf:

1. En cas SPF : ajoutez la plage d'adresses IP de l'expéditeur ou incluez le mécanisme « include » dans votre SPF , puis effectuez une nouvelle vérification à l'aide de notreSPF .
2. En cas d'échecs DKIM : demandez à votre fournisseur d'activer la signature DKIM personnalisée pour votre domaine et publiez la clé qu'il vous fournira, puis vérifiez à l'aide de notre vérificateur DKIM.

Identifier et surveiller les expéditeurs inconnus

Une adresse IP que vous ne reconnaissez pas et qui envoie des e-mails au nom de votre domaine peut correspondre à un outil adopté par une équipe sans en informer personne, à un service de transfert légitime ou à une tentative active d'usurpation d'identité. Un faible volume de messages provenant d'une adresse IP inconnue est courant et présente peu de risques. En revanche, un volume élevé de messages provenant d'une adresse IP inconnue constitue un signe fort d'usurpation d'identité, et c'est dans ce cas précis que le renforcement de votre politique, visant à quarantine à rejeter ces messages, permet de mettre activement fin à cet abus.

Suivez l'évolution de votre taux de réussite au fil du temps

Votre taux de réussite DMARC correspond au pourcentage d'e-mails qui réussissent l'authentification DMARC. Lorsque p=none, cela n'affecte pas la livraison, mais vous indique dans quelle mesure vous êtes prêt à appliquer la politique. Visez un taux de réussite supérieur à 95 % pour l'ensemble des expéditeurs légitimes, de manière constante, avant de renforcer votre politique. Surveillez ce taux chaque semaine pendant au moins deux à quatre semaines, plutôt que de réagir en fonction des résultats d'une seule journée.

Déterminez à quel moment faire évoluer votre police d'assurance

Passer à l'état «quarantine les trois vérifications de préparation sont satisfaites :

1. Tous les expéditeurs légitimes connus sont conformes à la norme DMARC.
2. Aucun expéditeur générant un volume important et inattendu n'apparaît dans vos rapports.
3. Le taux de réussite s'est maintenu de manière constante au-dessus de 95 %.

Passez à p=reject lorsque ces mêmes conditions sont remplies pendant une à deux semaines en quarantine incident. Le déroulement complet de la politique est décrit dans notre guide de configuration DMARC.

PowerDMARC automatise l'intégralité de cette analyse. Notre plateforme suit les taux d'acceptation, identifie les expéditeurs par leur nom plutôt que par leur adresse IP, et vous alerte dès qu'un nouvel expéditeur non autorisé apparaît ; ainsi, la décision d'acceptation est prise à votre place, plutôt que d'être reconstituée à partir de données XML brutes.

Pourquoi ne reçois-je pas de rapports DMARC ?

Si vous avez publié une fiche avec le paramètre « rua= » défini mais que vous n'avez reçu aucun rapport, cela est presque toujours dû à l'une de ces six causes.

Problème n° 1: Aucune balise « rua= » n'est présente dans votre enregistrement DMARC. Il s'agit de la cause la plus courante. Sans « rua= », vous avez explicitement choisi de ne pas recevoir de rapports. Solution : ajoutez « rua=mailto:[email protected] » à votre enregistrement et vérifiez le résultat à l'aide de notre outil DMARC Checker.

Problème n° 2: Adresse e-mail incorrecte ou invalide. Une faute de frappe, une boîte de réception inexistante ou une boîte de réception pleine entraîneront le rejet silencieux des rapports. Solution : vérifiez que l'adresse rua= peut effectivement recevoir des e-mails en lui envoyant un message test.

Problème n° 3: Destination de rapport externe non autorisée. Si votre paramètre rua= pointe vers une adresse située sur un domaine différent de celui de votre enregistrement DMARC (votre domaine est company.com mais rua= pointe vers [email protected]), le domaine externe doit publier un enregistrement d'autorisation à l'adresse _report._dmarc.reportingservice.com contenant v=DMARC1. Sans cela, les rapports sont ignorés. La plupart des plateformes DMARC gèrent cela automatiquement pour vous.

Problème n° 4: Vous avez publié un nouvel enregistrement, mais la propagation DNS n'a pas encore eu lieu. Les rapports commencent à arriver 24 à 48 heures après la mise en ligne de votre enregistrement à l'échelle mondiale. Pour résoudre ce problème, vérifiez la propagation à l'aide de notre outil de vérification de la propagation DNS.

Problème n° 5: Les rapports atterrissent dans le dossier spam. Les rapports sont envoyés sous forme de pièces jointes compressées par des expéditeurs automatisés et sont souvent filtrés. Pour résoudre ce problème, vérifiez votre dossier spam et ajoutez les expéditeurs des rapports à votre liste blanche ([email protected], [email protected]).

Numéro 6: Aucun e-mail n'a encore été envoyé. Les rapports ne sont générés que lorsque votre domaine a effectivement envoyé des e-mails qui ont atteint un fournisseur de messagerie. Si aucun e-mail n'a été envoyé depuis la publication de l'enregistrement, il n'y a pour l'instant rien à signaler.

RFC 9990 : Norme relative au rapport agrégé de 2026

À compter de mai 2026, la RFC 9990 régit le format et la transmission des rapports agrégés DMARC, reprenant ainsi le rôle de reporting qui relevait auparavant de la RFC 7489. Le schéma XML est rétrocompatible (les analyseurs syntaxiques existants et les rapports que vous recevez déjà continuent de fonctionner), et le principal changement réside dans la normalisation formelle du format de rapport et de la fréquence quotidienne. 

Pour un aperçu complet des dernières mises à jour, vous pouvez consulter notre guide DMARC RFC 9989/9990/9991 . 

Foire aux questions

Qu'est-ce qu'un rapport DMARC ?

Un rapport DMARC est un fichier XML quotidien envoyé par les serveurs de messagerie destinataires à l'adresse indiquée dans votre balise `rua=`. Il répertorie toutes les adresses IP ayant envoyé des e-mails depuis votre domaine et indique si SPF DKIM ont abouti ou échoué pour chacune d'entre elles. Des fournisseurs tels que Google, Microsoft et Yahoo génèrent ces rapports chaque fois qu'ils reçoivent un e-mail prétendant provenir de votre domaine. Ils constituent l'outil principal pour surveiller l'état d'authentification des e-mails de votre domaine.

Quelle est la différence entre RUA et RUF dans DMARC ?

Les rapports RUA (agrégés) sont des résumés quotidiens au format XML qui couvrent l'ensemble de l'activité de messagerie de votre domaine. Les rapports RUF (d'échec) sont des notifications d'échec par message pouvant contenir les données d'en-tête de chaque e-mail. La plupart des principaux fournisseurs, notamment Google, Microsoft et Yahoo, n'envoient plus de rapports d'échec en raison de contraintes liées à la confidentialité ; les rapports agrégés sont donc plus courants et pris en charge à l'échelle mondiale.

À quelle fréquence les rapports DMARC sont-ils envoyés ?

La plupart des fournisseurs envoient un rapport global toutes les 24 heures. Étant donné que chaque serveur de messagerie destinataire envoie son propre rapport, vous en recevez un de chaque fournisseur dont les utilisateurs ont reçu vos e-mails. Ainsi, un domaine envoyant des e-mails à des utilisateurs de Gmail, Outlook et Yahoo doit s'attendre à recevoir au moins trois rapports par jour.

Comment lire un rapport DMARC au format XML ?

Un rapport XML DMARC comporte trois sections principales : « report_metadata » (l'expéditeur et la période concernée), « policy_published » (votre enregistrement DMARC tel qu'il a été évalué) et « records » (une entrée par adresse IP d'envoi avec ses résultats SPF DKIM). Pour un guide pratique, vous pouvez consulter l'exemple XML présenté plus haut dans ce guide. Cependant, la plupart des équipes informatiques utilisent un outil d'analyse automatisé qui identifie les expéditeurs par leur nom plutôt que de lire le code XML brut.

Pourquoi est-ce que je reçois des rapports DMARC provenant d'organisations que je ne connais pas ?

Tout serveur de messagerie qui reçoit un e-mail prétendant provenir de votre domaine envoie un rapport si vous avez configuré l'option `rua=`. Cela inclut les petits FAI, les passerelles de messagerie d'entreprise et les fournisseurs internationaux utilisés par vos destinataires, et pas seulement Google et Microsoft. Il est normal de recevoir des rapports provenant d'organisations que vous ne connaissez pas ; cela signifie simplement que ces serveurs ont traité des e-mails qui semblaient provenir de votre domaine.

• À propos de
• Derniers messages

Maitham Al Lawati

Expert en cybersécurité, PDG de PowerDMARC

Maitham est un entrepreneur technologique, expert en cybersécurité, PDG et fondateur de PowerDMARC avec plus de 15 ans d'expérience dans l'industrie. Maitham est titulaire d'un Global MBA de l'Université de Manchester et de diverses certifications professionnelles, notamment CISSP, CISM, CRISC et ISC2 CCSP.

Derniers messages de Maitham Al Lawati (voir tous)

• Comment configurer DMARC : guide complet de configuration étape par étape (2026) - 20 juin 2026
• Comment lire les rapports DMARC : guide complet sur les indicateurs RUA et RUF - 10 juin 2026
• Qu'est-ce que le DMARC ? Définition, fonctionnement et importance - 28 avril 2026