Vous avez configuré DMARC avec un tag rua= et les rapports commencent à arriver. Mais que faire de ces fichiers XML souvent incompréhensibles ? Ce guide vous apprend à les lire, les interpréter, et à en tirer des actions concrètes.

Qu’est-ce qu’un rapport DMARC RUA

Un rapport RUA (Report URI Aggregate) est un fichier XML envoyé quotidiennement par les fournisseurs de messagerie (Google, Microsoft, Yahoo, etc.) à l’adresse définie dans votre record DMARC.

Il résume toutes les tentatives d’envoi observées pour votre domaine sur les dernières 24 heures : qui a envoyé, depuis quelle IP, quel résultat SPF/DKIM/DMARC.

Ce que contient un rapport

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <date_range>
      <begin>1717200000</begin>
      <end>1717286400</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>votredomaine.com</domain>
    <p>reject</p>
    <sp>reject</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>198.51.100.42</source_ip>
      <count>1523</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>votredomaine.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>votredomaine.com</domain>
        <result>pass</result>
        <selector>s1</selector>
      </dkim>
      <spf>
        <domain>votredomaine.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Les champs clés à analyser

<source_ip> : qui envoie

L’adresse IP du serveur qui a envoyé les emails. C’est le premier indice pour identifier la source :

  • IP connue (votre ESP, votre serveur) → source légitime
  • IP inconnue → potentiel shadow IT ou usurpation

Utilisez un service de lookup IP (whois, rDNS) pour identifier le propriétaire.

<count> : le volume

Le nombre d’emails envoyés depuis cette IP pendant la période du rapport. Un volume élevé depuis une IP inconnue est un signal d’alerte.

<disposition> : ce qui s’est passé

L’action appliquée par le fournisseur :

ValeurSignification
noneAucune action (le plus souvent quand p=none)
quarantineMessage placé en spam
rejectMessage rejeté

<dkim> et <spf> dans <policy_evaluated>

Le résultat DMARC (avec alignement) :

  • pass : l’authentification a réussi et le domaine est aligné
  • fail : soit l’authentification a échoué, soit l’alignement n’est pas respecté

<auth_results> : les résultats bruts

Les résultats SPF et DKIM avant le contrôle d’alignement DMARC. Un spf=pass ici avec un spf=fail dans policy_evaluated signifie que SPF a passé mais que le domaine Return-Path ne s’aligne pas avec le From:.

Scénarios courants dans les rapports

Tout passe : source légitime configurée

source_ip: 198.51.100.42 (votre ESP)
dkim: pass, spf: pass, disposition: none

Rien à faire, tout est en ordre.

SPF pass mais DKIM fail : problème de signature

source_ip: 198.51.100.42 (votre ESP)
dkim: fail, spf: pass, disposition: none

Votre ESP envoie pour vous mais la signature DKIM n’est pas configurée ou est cassée. Activez DKIM personnalisé chez votre ESP.

IP inconnue, tout fail : tentative d’usurpation

source_ip: 203.0.113.99 (inconnu)
dkim: fail, spf: fail, disposition: reject

Quelqu’un tente d’envoyer des emails en utilisant votre domaine. Si p=reject, les messages sont bloqués. C’est DMARC qui fait son travail.

IP inconnue, SPF pass : shadow IT

source_ip: 203.0.113.50 (Salesforce, HubSpot, etc.)
dkim: fail, spf: pass, disposition: none

Un service SaaS que quelqu’un dans votre organisation utilise pour envoyer des emails depuis votre domaine. SPF passe car l’IP est dans votre record SPF, mais DKIM n’est pas configuré pour ce service. C’est le shadow IT : identifiez le service et configurez DKIM, ou retirez l’autorisation SPF si non légitime.

Automatiser l’analyse

Lire du XML brut, c’est pénible. Plusieurs approches :

Sender Audit Dashboard

Si vous ajoutez votre domaine sur Sender Audit , une adresse RUA unique est générée pour votre compte. Une fois configurée dans votre record DMARC, les rapports sont :

  • Parsés automatiquement
  • Visualisés avec graphiques et tableaux
  • Alertes en cas d’anomalie
  • Historique consultable dans le dashboard

Manuellement avec des outils open-source

Des outils comme parsedmarc (Python) peuvent parser les fichiers XML et les stocker en base de données pour analyse.

Du rapport à l’action

L’objectif des rapports DMARC est de vous guider vers p=reject. Voici le workflow :

  1. Inventoriez toutes les IP sources dans les rapports
  2. Identifiez chaque source : serveur propre, ESP, SaaS, usurpation
  3. Corrigez les sources légitimes qui échouent (DKIM manquant, SPF incomplet)
  4. Retirez les autorisations SPF pour les sources non légitimes
  5. Montez la politique progressivement : none → quarantine → reject

Pour un guide détaillé de cette migration, consultez DMARC : de p=none à p=reject.

Pour aller plus loin