Vous avez publié un enregistrement DMARC avec un tag rua=. Les premiers fichiers XML arrivent dans votre boîte mail — des pièces jointes ZIP avec des noms cryptiques. Vous ouvrez le fichier, découvrez du XML brut, et vous demandez quoi en faire.

Ce guide vous explique comment lire ces rapports, quelles informations en extraire, et comment agir sur ce que vous trouvez. Pas de théorie abstraite : des exemples concrets de XML annoté, les outils pour automatiser le décodage, et les scénarios les plus fréquents avec leurs résolutions.

Prérequis. Ce guide suppose que DMARC est déjà publié sur votre domaine. Si ce n’est pas encore le cas, commencez par configurer SPF, DKIM et DMARC puis revenez ici.

Ce que sont les rapports DMARC et pourquoi les lire

Quand un serveur de messagerie reçoit un email prétendant venir de votre domaine, il effectue trois vérifications : SPF, DKIM et DMARC. Que l’email soit légitime ou non, ce serveur collecte ces résultats et vous les envoie sous forme de rapport agrégé — à condition que votre enregistrement DMARC contienne un tag rua=.

Ces rapports sont la seule façon de savoir précisément ce qui se passe avec votre domaine :

Quels services envoient des emails pour votre compte
Lesquels passent ou échouent l’authentification
Depuis quelles adresses IP
En quel volume

Sans ce retour d’information, vous gérez votre infrastructure email à l’aveugle. Vous ne savez pas si un prestataire envoie des campagnes avec votre domaine mal configuré, ni si des acteurs malveillants tentent de se faire passer pour vous. Les rapports DMARC sont le tableau de bord de votre authentification email.

Qui envoie des rapports ? Tous les fournisseurs de messagerie qui traitent des emails de votre domaine et qui implémentent DMARC. Google, Microsoft, Yahoo, Apple Mail, Orange, Free, SFR, et une centaine d’autres. Chacun envoie un rapport par jour, couvrant les 24 heures précédentes.

La spécification de référence est la RFC 7489, qui définit le format exact des rapports et le comportement attendu des fournisseurs.

Rapports agrégés (RUA) vs rapports forensic (RUF)

DMARC prévoit deux types de rapports, activés par deux tags distincts dans votre enregistrement.

Rapports agrégés — tag rua=

C’est le type de rapport que vous recevrez dans 99 % des cas. Un fichier XML, compressé en ZIP ou GZ, envoyé une fois par jour par chaque fournisseur.

Ce qu’il contient :

L’identité du fournisseur qui envoie le rapport
La période couverte (timestamps début et fin)
Votre politique DMARC publiée
Une liste d’entrées, une par IP source, avec pour chacune : l’IP, le nombre d’emails, les résultats SPF et DKIM, la disposition appliquée

Ce qu’il ne contient pas : aucun contenu d’email, aucune adresse de destinataire, aucun objet. Les rapports RUA sont agrégés et anonymisés par conception.

Activation :

_dmarc.votredomaine.fr  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@votredomaine.fr"

Rapports forensic — tag ruf=

Les rapports forensic sont envoyés à chaque échec d’authentification individuel. Contrairement aux rapports agrégés, ils peuvent contenir des éléments du message original : en-têtes, et parfois des extraits du corps.

Pourquoi vous n’en recevrez probablement pas : Pour des raisons de confidentialité et de volume, Google et Microsoft ont arrêté d’envoyer des rapports forensic. Yahoo et quelques fournisseurs de moindre taille les envoient encore. En pratique, les rapports RUA agrégés fournissent la grande majorité des informations nécessaires à la gestion de votre infrastructure DMARC.

Si vous activez ruf= quand même :

v=DMARC1; p=none; rua=mailto:dmarc@votredomaine.fr; ruf=mailto:dmarc-fail@votredomaine.fr; fo=1

Le paramètre fo=1 déclenche un rapport forensic à chaque email qui échoue SPF ou DKIM (pas seulement les deux). fo=0 (défaut) ne rapporte que les doubles échecs.

Recommandation pratique : concentrez-vous sur les rapports RUA. Ils contiennent tout ce dont vous avez besoin pour gérer votre infrastructure DMARC.

Lire la structure XML d’un rapport agrégé

Un rapport agrégé est un fichier XML avec une structure standardisée définie par la RFC 7489. Voici un exemple complet annoté.

Structure générale

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

  <!-- Métadonnées du rapport -->
  <report_metadata>
    <org_name>Google Inc.</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>12345678901234567890</report_id>
    <date_range>
      <begin>1744761600</begin>  <!-- timestamp Unix début de période -->
      <end>1744847999</end>      <!-- timestamp Unix fin de période -->
    </date_range>
  </report_metadata>

  <!-- Votre politique publiée, telle que lue par le fournisseur -->
  <policy_published>
    <domain>votredomaine.fr</domain>
    <adkim>r</adkim>   <!-- alignement DKIM : r=relaxé, s=strict -->
    <aspf>r</aspf>     <!-- alignement SPF : r=relaxé, s=strict -->
    <p>none</p>        <!-- votre politique actuelle -->
    <sp>none</sp>      <!-- politique pour les sous-domaines -->
    <pct>100</pct>     <!-- pourcentage du trafic soumis à la politique -->
  </policy_published>

  <!-- Un enregistrement par IP source -->
  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>
      <count>147</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>votredomaine.fr</header_from>
      <envelope_from>mail.votredomaine.fr</envelope_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>votredomaine.fr</domain>
        <result>pass</result>
        <selector>google</selector>
      </dkim>
      <spf>
        <domain>mail.votredomaine.fr</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>

</feedback>

Les champs à lire en priorité

<org_name> : le fournisseur qui envoie le rapport. Google, Microsoft (noreply-dmarc@microsoft.com), Yahoo, Apple, Orange. Chaque rapport ne couvre que le trafic reçu par ce fournisseur.

<source_ip> : l’adresse IP du serveur qui a envoyé les emails. C’est la première information à analyser. Reconnaissez-vous cette IP ? Appartient-elle à Google Workspace, Microsoft 365, Brevo, votre serveur applicatif ?

<count> : le nombre d’emails envoyés depuis cette IP pendant la période. Un volume de 1 ou 2 peut être un scanner. Un volume de 500 sur une IP inconnue mérite investigation immédiate.

<policy_evaluated> : le verdict DMARC pour cette source. Les trois sous-champs :

Champ	Valeur possible	Signification
`<disposition>`	none, quarantine, reject	Action appliquée par le serveur destinataire
`<dkim>`	pass, fail	L’alignement DKIM a-t-il réussi ?
`<spf>`	pass, fail	L’alignement SPF a-t-il réussi ?

Règle de lecture : DMARC passe si au moins l’un des deux (dkim ou spf) est en pass. Un double fail avec disposition=none signifie que l’email a quand même été livré (politique non-bloquante). Avec disposition=reject, il a été refusé.

<auth_results> : le détail brut des vérifications. La différence avec <policy_evaluated> est importante : auth_results montre si SPF et DKIM ont techniquement réussi, tandis que policy_evaluated montre si l’alignement a réussi. SPF peut passer techniquement (l’IP est dans le SPF du domaine de retour) mais échouer l’alignement DMARC si ce domaine ne correspond pas au From visible.

<header_from> : le domaine dans le champ From visible par le destinataire. C’est le domaine que DMARC protège.

Identifier une IP inconnue

Pour chaque <source_ip> que vous ne reconnaissez pas, deux étapes :

Cherchez le propriétaire du bloc IP sur ipinfo.io ou en effectuant une recherche WHOIS. Google Workspace utilise des plages spécifiques (Autonomous System AS15169), Microsoft 365 utilise AS8075, Brevo utilise AS25454.
Croisez avec le <envelope_from> ou <selector> dans <auth_results>. Le sélecteur DKIM google ou s1 vous donne souvent une indication sur l’expéditeur réel.

Outils gratuits pour visualiser les rapports

Les fichiers XML bruts sont lisibles mais fastidieux à analyser à la main dès que vous recevez une dizaine de rapports par jour. Ces quatre outils décodent et présentent vos données DMARC sans frais.

Postmark DMARC

app.dmarc.postmarkapp.com — le plus simple à mettre en place. Vous indiquez votre adresse rua= lors de la configuration, et Postmark vous envoie un résumé hebdomadaire par email avec les sources d’envoi, les volumes, et les taux de succès. Aucune interface web à surveiller quotidiennement.

Points forts : zéro friction, tableau récapitulatif par email. Limite : la granularité quotidienne n’est pas accessible sans compte payant.

dmarcian

dmarcian.com — l’outil de référence dans le secteur, développé par l’un des auteurs de la RFC DMARC. L’interface cartographie les sources d’envoi avec une vue géographique et classe automatiquement les IPs par type (messagerie principale, services tiers, sources inconnues).

Points forts : visualisation détaillée, vue agrégée sur plusieurs domaines. Limite : l’offre gratuite est limitée à un faible volume de rapports par mois.

EasyDMARC

easydmarc.com — plateforme complète avec tableau de bord, alertes, et outils de diagnostic complémentaires (vérificateur SPF, DKIM, blacklist). L’offre gratuite couvre un seul domaine avec un historique limité.

Points forts : tableau de bord complet, alertes en cas de nouvelle source détectée. Limite : fonctionnalités avancées réservées aux abonnements payants.

Google Postmaster Tools

postmaster.google.com — l’outil de Google pour les expéditeurs. Il ne visualise pas les rapports DMARC au sens strict, mais affiche les statistiques de délivrabilité pour votre domaine sur Gmail : taux de spam, réputation IP, volumes. Complémentaire aux rapports DMARC pour comprendre comment Gmail traite vos emails.

Points forts : données directement depuis Google, gratuit, sans configuration DNS supplémentaire. Limite : couvre uniquement Gmail, ne remplace pas un vrai analyseur DMARC.

Analyser un rapport ponctuel

Pour décoder un rapport XML à la main sans configurer un outil permanent, MXToolbox DMARC Report Analyzer accepte un fichier XML en entrée et affiche une vue tabulaire. Pratique pour le diagnostic d’un rapport spécifique.

Scénarios courants et leur résolution

Scénario 1 : un expéditeur légitime échoue l’authentification

Ce que vous voyez dans les rapports :

<source_ip>185.41.28.110</source_ip>
<count>312</count>
<policy_evaluated>
  <disposition>none</disposition>
  <dkim>fail</dkim>
  <spf>fail</spf>
</policy_evaluated>

Vous reconnaissez l’IP : c’est Brevo (ex-Sendinblue), votre outil de newsletter.

Diagnostic : DKIM n’est pas activé sur votre compte Brevo pour ce domaine. SPF échoue parce que le domaine de retour (bounce domain) de Brevo n’est pas aligné avec votre domaine principal.

Résolution :

Connectez-vous à Brevo → Paramètres → Expéditeurs & IP → Domaines
Ajoutez votre domaine, publiez l’enregistrement DKIM fourni dans votre DNS
Vérifiez dans Brevo que le domaine est validé
Attendez 48 heures, confirmez dans les prochains rapports que dkim=pass apparaît pour ces IPs

Pourquoi c’est urgent : tant que ce service échoue, passer en p=reject bloquerait vos propres newsletters.

Scénario 2 : des tentatives de spoofing

Ce que vous voyez dans les rapports :

<source_ip>45.33.89.142</source_ip>
<count>1847</count>
<policy_evaluated>
  <disposition>none</disposition>
  <dkim>fail</dkim>
  <spf>fail</spf>
</policy_evaluated>
<identifiers>
  <header_from>votredomaine.fr</header_from>
</identifiers>

Vous ne reconnaissez pas cette IP. WHOIS indique un hébergeur VPS à l’étranger. Vous n’avez aucun service chez cet hébergeur.

Diagnostic : quelqu’un utilise votre domaine dans le champ From pour envoyer des emails sans y être autorisé. C’est une tentative de spoofing. Avec p=none, ces 1 847 emails ont été délivrés aux destinataires.

Résolution : pas de correction à faire côté configuration — c’est exactement le comportement que DMARC doit bloquer. La correction est de passer en politique active. Avec p=reject, ces emails auraient été refusés avant d’atteindre les boîtes. Consultez le guide migration DMARC vers reject pour la procédure étape par étape.

Scénario 3 : un service d’envoi oublié

Ce que vous voyez dans les rapports :

<source_ip>54.240.11.34</source_ip>
<count>42</count>
<policy_evaluated>
  <disposition>none</disposition>
  <dkim>fail</dkim>
  <spf>pass</spf>
</policy_evaluated>
<auth_results>
  <spf>
    <domain>amazonses.com</domain>
    <result>pass</result>
  </spf>
</auth_results>

L’IP appartient à Amazon SES. SPF passe (Amazon SES est autorisé sur un domaine de retour), mais DKIM échoue l’alignement et la disposition est none.

Diagnostic : une application de votre infrastructure utilise Amazon SES pour envoyer des emails — notifications automatiques, alertes, emails transactionnels — et vous ne le saviez pas (ou vous l’aviez oublié). L’alignement DKIM échoue parce que la clé DKIM n’est pas configurée avec votre domaine dans cette application.

Résolution :

Identifiez quelle application utilise Amazon SES avec ce compte (demandez à l’équipe dev)
Dans la console AWS SES → Verified identities → ajoutez votre domaine et publiez les enregistrements DKIM fournis
Vérifiez que l’application signe les emails avec votre domaine (et non amazonaws.com)

Pourquoi c’est fréquent : les développeurs configurent des relais SMTP pour des applications internes sans toujours coordonner avec l’équipe IT. Les notifications de monitoring, les alertes d’erreur, les exports automatiques — tous peuvent apparaître dans vos rapports DMARC comme des sources inattendues.

Scénario 4 : les transferts d’emails

Ce que vous voyez dans les rapports :

<source_ip>217.182.116.51</source_ip>
<count>8</count>
<policy_evaluated>
  <disposition>none</disposition>
  <dkim>pass</dkim>
  <spf>fail</spf>
</policy_evaluated>

L’IP appartient à OVH. SPF échoue, DKIM passe. La disposition est none.

Diagnostic : des emails envoyés par vos utilisateurs sont transférés (forwarded) via un serveur OVH vers une boîte externe. Le transfert change l’IP expéditrice, ce qui casse SPF — mais DKIM reste intacte car la signature est attachée au message. DMARC passe grâce à DKIM.

Ce qu’il faut faire : rien — c’est le fonctionnement normal. DKIM est là précisément pour gérer ce cas. Si vous voyez des transferts avec double échec (dkim et spf à fail), c’est que le serveur intermédiaire modifie le contenu du message et invalide la signature DKIM. Dans ce cas, le serveur de transfert devrait implémenter ARC (Authenticated Received Chain) pour préserver l’authentification.

Agir sur les résultats des rapports

Les rapports DMARC n’ont de valeur que si vous en tirez des actions concrètes. Voici comment structurer ce travail.

Établir une routine d’analyse

Pour la phase initiale (première configuration ou préparation d’une migration vers reject), analysez vos rapports chaque semaine pendant au moins un mois. Vous cherchez à :

Constituer l’inventaire complet de vos sources d’envoi. Chaque IP qui apparaît avec un volume significatif et un domaine header_from qui est le vôtre correspond à un service qui envoie des emails pour votre compte. Documentez-les tous.
Classer chaque source : légitime bien configurée, légitime mal configurée, ou frauduleuse/inconnue.
Prioriser les corrections par volume. Un service qui envoie 500 emails par jour avec un alignement fail est plus urgent à corriger qu’un service qui envoie 2 alertes par semaine.

Une fois en p=reject et vos sources stabilisées, une revue mensuelle suffit pour détecter l’apparition d’un nouveau service ou d’une nouvelle campagne de spoofing.

Préparer la migration vers une politique active

Les rapports DMARC sont la condition préalable à tout durcissement de politique. Avant de passer de p=none à p=quarantine, vous devez avoir résolu chaque ligne de vos rapports avec dkim=fail et spf=fail provenant d’IPs légitimes.

Un tableau de suivi simple suffit :

IP / Service	Volume/jour	DKIM	SPF	Alignement	Action
209.85.x.x (Google WS)	250	pass	fail	pass DMARC	RAS
185.41.x.x (Brevo)	85	fail	fail	fail	Configurer DKIM Brevo
54.240.x.x (SES)	42	fail	pass	fail	Identifier l’app, configurer DKIM
45.33.x.x (inconnu)	1847	fail	fail	fail	Spoofing — attendre p=reject

Ce tableau est votre liste de tâches avant de durcir la politique. Chaque ligne en rouge est un point de blocage pour la migration. Consultez le guide migration DMARC vers reject une fois ces corrections effectuées.

Surveiller les nouvelles sources

Même avec une politique active et des rapports stables, continuez à surveiller l’apparition de nouvelles IPs sources. Deux signaux d’alerte :

Un nouveau service interne apparaît avec un alignement fail : une application déployée sans coordination avec l’équipe IT. À corriger avant qu’il soit bloqué.
Un volume de spoofing augmente fortement : votre domaine est ciblé par une campagne. Avec p=reject, les emails n’arrivent pas — mais l’information est utile pour anticiper d’autres vecteurs d’attaque.

Si vous utilisez un outil comme dmarcian ou EasyDMARC, activez les alertes pour toute nouvelle source d’envoi non vue auparavant. Vous recevrez un email dès qu’une IP inconnue envoie des emails avec votre domaine.

Compléter la couche technique

L’analyse des rapports DMARC vous donne une visibilité sur l’authentification de vos emails sortants. C’est une protection réelle contre l’usurpation exacte de votre domaine. Mais cette protection est ciblée : elle ne couvre pas les domaines sosies (votre-domaine-fr.com), les comptes email compromis qui envoient depuis votre messagerie légitime, ou le phishing qui n’utilise pas votre domaine du tout.

Pour tester la robustesse de votre configuration actuelle, notre test sécurité email gratuit vérifie vos enregistrements SPF, DKIM et DMARC en quelques secondes et vous donne un score sur 10 avec des recommandations.

FAQ

Dois-je garder les fichiers XML des rapports ?

Si vous utilisez un outil de visualisation (dmarcian, EasyDMARC), l’outil conserve l’historique. Si vous analysez les fichiers manuellement, conservez un mois glissant — le temps de détecter les services qui n’envoient qu’une fois par mois. Au-delà, les données ont peu de valeur opérationnelle.

Mon registrar ne me laisse pas ajouter un enregistrement rua= sur un domaine tiers ?

Ce n’est pas une restriction de votre registrar — c’est la logique DMARC. Si votre adresse rua= est sur un domaine différent de celui que vous protégez, vous devez publier un enregistrement d’autorisation sur ce domaine cible. Voir la FAQ de la section configuration pour les détails.

Puis-je utiliser l’adresse rua= d’un prestataire directement ?

Oui, certains outils (dmarcian, EasyDMARC) vous fournissent une adresse rua= à mettre dans votre enregistrement DMARC. Les rapports leur sont envoyés directement, et ils les affichent dans leur interface. C’est la configuration recommandée pour ne pas gérer manuellement des boîtes mail remplies de fichiers XML.

Thomas Ferreira accompagne des équipes IT dans la sécurisation de leur infrastructure email depuis 2015. Les recommandations de ce guide s’appuient sur la RFC 7489, les recommandations de l’ANSSI et l’analyse de plusieurs centaines de rapports DMARC de domaines d’entreprises françaises.