ServicesBlogContact
Retour au blog

Tutoriels

Lire un rapport DMARC XML et identifier qui envoie des emails avec votre domaine

Comprendre un rapport DMARC XML, repérer les sources d'envoi et distinguer flux légitimes, erreurs et usages suspects.

17 mai 2026 - 9 min

Extrait de rapport DMARC XML : source_ip, count, policy_evaluated avec DKIM en pass et SPF en fail, header_from, et résultat DMARC pass

Un rapport DMARC agrégé est un fichier XML, généralement compressé, envoyé par un fournisseur de messagerie à l’adresse indiquée dans votre enregistrement DMARC. Il ne contient pas vos messages : il résume, pour une période donnée, les adresses IP qui ont envoyé au nom de votre domaine et le résultat de leur authentification.

Réponse directe : pour savoir qui envoie avec votre domaine, regroupez les enregistrements du rapport par source_ip, identifiez le service derrière chaque IP, puis comparez deux blocs. auth_results indique si SPF et DKIM ont réussi. policy_evaluated indique s’ils ont réussi et s’ils sont alignés avec le domaine visible, header_from. Seul ce second résultat compte pour DMARC : il réussit si dkim ou spf y vaut pass.

À retenir : un message peut réussir SPF et DKIM tout en échouant à DMARC. C’est le cas le plus fréquent d’outil légitime mal configuré, et c’est le premier à repérer dans vos rapports.

En bref

  • Le rapport décrit des sources et des volumes, jamais le contenu des messages.
  • auth_results donne le résultat brut ; policy_evaluated donne le résultat d’alignement.
  • Une source légitime en échec se corrige ; une source inconnue s’identifie avant toute conclusion.
  • Un seul rapport ne suffit pas : comparez plusieurs jours et plusieurs fournisseurs.

Récupérer et ouvrir le rapport

Les rapports arrivent à l’adresse de la balise rua de votre enregistrement DMARC :

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Si cette adresse appartient à un autre domaine, ce domaine doit autoriser la réception en publiant un enregistrement dédié :

example.com._report._dmarc.prestataire.example. TXT "v=DMARC1"

La pièce jointe est le plus souvent compressée. Son nom suit un format normalisé, qui indique déjà qui a émis le rapport, pour quel domaine et sur quelle période :

receiver.example!example.com!1778889600!1778975999.xml.gz

Les deux nombres sont des horodatages Unix, c’est-à-dire un nombre de secondes depuis le 1er janvier 1970 UTC.

Un rapport commenté

Cet exemple suit le format de la RFC 9990. Il est volontairement réduit à trois sources.

<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0">
  <version>1.0</version>
  <report_metadata>
    <org_name>receiver.example</org_name>
    <email>noreply-dmarc@receiver.example</email>
    <report_id>20260516-a1b2c3</report_id>
    <date_range>
      <!-- 16 mai 2026, 00:00:00 à 23:59:59 UTC -->
      <begin>1778889600</begin>
      <end>1778975999</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <!-- observation : rien n'est bloqué -->
    <p>none</p>
    <sp>none</sp>
    <adkim>r</adkim>
    <aspf>r</aspf>
  </policy_published>

  <!-- Cas A : plateforme d'emailing, 860 messages -->
  <record>
    <row>
      <source_ip>198.51.100.25</source_ip>
      <count>860</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <!-- résultat d'ALIGNEMENT, pas de signature -->
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <envelope_from>bounce.esp.example</envelope_from>
      <!-- le domaine que voit le destinataire -->
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <!-- d= aligné avec header_from -->
        <domain>example.com</domain>
        <selector>esp1</selector>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>bounce.esp.example</domain>
        <!-- SPF valide, mais sur un autre domaine -->
        <result>pass</result>
      </spf>
    </auth_results>
  </record>

  <!-- Cas B : outil de facturation, 312 messages -->
  <record>
    <row>
      <source_ip>203.0.113.40</source_ip>
      <count>312</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <envelope_from>mail.billing-tool.example</envelope_from>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>billing-tool.example</domain>
        <selector>s1</selector>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>mail.billing-tool.example</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>

  <!-- Cas C : source inconnue, 3 messages -->
  <record>
    <row>
      <source_ip>192.0.2.77</source_ip>
      <count>3</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <envelope_from>example.com</envelope_from>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>example.com</domain>
        <result>fail</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Les rapports réels varient selon le fournisseur : certains suivent encore le format de la RFC 7489, sans espace de noms et avec d’autres balises. Les champs qui servent au diagnostic restent les mêmes.

Les champs à connaître

Champ Ce qu’il indique Piège à éviter
date_range Période couverte, en UTC Ne pas confondre avec la date de réception
p Politique publiée au moment du rapport Elle peut avoir changé pendant la période
source_ip Serveur qui a remis le message Sur un transfert, c’est le serveur intermédiaire
count Nombre de messages regroupés dans cette ligne Ce n’est pas un nombre de destinataires
disposition Traitement appliqué : none, quarantine, reject et, dans le format RFC 9990, pass none ne veut pas dire que DMARC a réussi
policy_evaluated : dkim, spf Résultat d’alignement C’est lui qui détermine DMARC
header_from Domaine visible par le destinataire Sert de référence à l’alignement
envelope_from Domaine de l’adresse de retour, vérifié par SPF Champ facultatif, parfois absent
auth_results : dkim, spf Résultat brut de la vérification Peut indiquer pass sans alignement
selector Clé DKIM utilisée Aide à reconnaître la plateforme

Interpréter chaque cas

auth_results (brut) policy_evaluated (alignement) DMARC Lecture probable Que faire
SPF pass, DKIM pass, même domaine spf pass, dkim pass Réussi Source correctement configurée Rien, vérifier qu’elle est connue
SPF pass sur le domaine du prestataire, DKIM pass sur le vôtre (cas A) spf fail, dkim pass Réussi Situation courante avec une plateforme d’emailing Acceptable : DKIM porte DMARC
SPF pass sur votre domaine, DKIM absent ou en échec spf pass, dkim fail Réussi Fragile : SPF ne survit pas à un transfert Activer une signature DKIM alignée
SPF fail, DKIM pass sur votre domaine, IP inconnue spf fail, dkim pass Réussi Souvent un transfert ou une liste de diffusion Vérifier, généralement rien à corriger
SPF pass et DKIM pass, tous deux sur le domaine du prestataire (cas B) spf fail, dkim fail Échec Outil légitime non aligné Priorité : configurer DKIM au nom de votre domaine
SPF fail, DKIM en échec sur votre domaine, IP de transfert spf fail, dkim fail Échec Message modifié en route, ou signature cassée Identifier l’intermédiaire ou la plateforme
SPF fail, aucun DKIM, IP inconnue (cas C) spf fail, dkim fail Échec Outil oublié ou tentative d’usurpation Enquêter : voir ci-dessous

Ces lectures sont des hypothèses de départ. Le rapport ne montre pas le contenu des messages : seule l’identification de la source permet de conclure.

Identifier les expéditeurs, étape par étape

Étape Action Validation
1 Décompresser les rapports d’une semaine et convertir chaque record en ligne de tableau. Le total de count par rapport est cohérent et aucun fichier n’a été ignoré.
2 Vérifier d’abord policy_published et, s’il existe, error. La politique affichée correspond à celle que vous pensez avoir publiée.
3 Regrouper les lignes par source_ip, puis par domaine DKIM et domaine SPF. Chaque groupe représente un seul service probable.
4 Identifier chaque source : DNS inverse, propriétaire de l’IP, selector, domaine d= et envelope_from. Chaque source a un nom de service, ou la mention « inconnue ».
5 Trouver le responsable interne de chaque service. Chaque service légitime a un propriétaire nommé.
6 Classer : légitime et conforme, légitime à corriger, transfert, inconnu. Aucune source ne reste sans classement.
7 Corriger par ordre de volume et de criticité, puis contrôler les rapports suivants. L’alignement passe à pass pour cette source dans les nouveaux rapports.

Schéma : enquêter sur une IP source

Processus d’enquête sur une IP source trouvée dans un rapport DMARC

L’analyse d’une IP source consiste à croiser le reverse DNS, le WHOIS, le fournisseur probable et les résultats d’authentification.

Une adresse IP appartenant à Google ou à Microsoft ne prouve pas qu’il s’agit de votre messagerie : ces infrastructures sont partagées entre de nombreux clients. Fiez-vous plutôt au domaine de la signature DKIM et au résultat d’alignement.

Un faible volume ne signifie pas un faible risque, et une source inconnue n’est pas forcément une attaque. Avant de conclure, posez la question aux équipes marketing, finance et support : un ancien outil ou un prestataire oublié est une explication fréquente.

Avant de durcir la politique

  • Plusieurs jours de rapports ont été analysés, chez plusieurs fournisseurs.
  • Les envois peu fréquents, comme la facturation mensuelle, apparaissent dans la période observée.
  • Chaque source légitime a dkim ou spf à pass dans policy_evaluated.
  • Les outils qui ne reposent que sur SPF ont été examinés, car un transfert peut leur faire perdre DMARC.
  • Les sources restantes sont expliquées ou considérées comme illégitimes en connaissance de cause.

Pour passer ensuite aux corrections, voir Configurer SPF, DKIM et DMARC sans casser ses emails.

FAQ

Pourquoi DKIM affiche-t-il pass dans auth_results et fail dans policy_evaluated ?

Parce que les deux blocs ne mesurent pas la même chose. La signature est valide, mais son domaine d= ne correspond pas à header_from. C’est typique d’un outil qui signe avec son propre domaine.

Pourquoi disposition vaut-il none alors que DMARC a échoué ?

Avec p=none, aucune action n’est demandée. Le destinataire peut aussi avoir appliqué une exception locale : le champ reason l’indique alors.

Pourquoi je ne reçois aucun rapport ?

Vérifiez la syntaxe de l’enregistrement, l’adresse rua et, si elle est sur un autre domaine, l’enregistrement d’autorisation _report._dmarc. Sachez aussi que tous les fournisseurs n’émettent pas de rapports et que de très faibles volumes peuvent ne pas en produire.

Les rapports contiennent-ils le contenu de mes emails ?

Non. Les rapports agrégés contiennent des domaines, des adresses IP, des volumes et des résultats, sans objet ni corps de message. Ils restent à traiter avec soin, car ils décrivent vos flux d’envoi.

Quelle différence entre rua et ruf ?

rua reçoit les rapports agrégés décrits ici. ruf concerne les rapports d’échec, propres à un message. Ces derniers sont définis par la RFC 9991, et de nombreux fournisseurs n’en envoient pas.

Faut-il un outil pour lire ces rapports ?

Pour un ou deux rapports, non. Au-delà, la lecture manuelle devient vite difficile : un script ou une plateforme d’analyse permet de cumuler les données par source. L’important reste la même lecture : source, alignement, volume.

Conclusion

Lire un rapport DMARC revient à répondre à trois questions pour chaque source : qui est-ce, est-elle alignée, et quel volume représente-t-elle ? Si vous préférez déléguer ce suivi, voir notre prestation de monitoring DMARC.

Sources