Comment lire un rapport agrégé DMARC (rua) et quoi en faire

Un rapport agrégé DMARC est une synthèse quotidienne que les grands fournisseurs de messagerie envoient à l’adresse indiquée dans la balise rua de votre enregistrement DMARC. Il liste chaque adresse IP qui a envoyé du courrier avec votre domaine dans le champ From, le nombre de messages envoyés par chacune, et si SPF et DKIM ont réussi et sont alignés sur votre domaine. Il ne contient ni le contenu des messages, ni les objets, ni les adresses des destinataires.

Lire ces rapports, c’est découvrir qui envoie réellement des e-mails en votre nom : vos propres serveurs de messagerie, le CRM, l’outil de facturation, la plateforme de newsletter, et toute personne qui se contente de mettre votre domaine dans le champ From. C’est cette liste qu’il vous faut avant de faire passer votre politique de p=none à une politique appliquée.

Depuis mai 2026, le format est défini par la RFC 9990 qui, avec la RFC 9989 (le mécanisme DMARC lui-même), remplace l’ancienne RFC 7489. Pour un rappel sur les 3 enregistrements, commencez par SPF, DKIM et DMARC expliqués.

Comment les rapports vous parviennent

Vous demandez des rapports avec la balise rua de votre enregistrement DMARC :

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

Chaque fournisseur participant vous envoie alors par e-mail un fichier XML, généralement compressé. La RFC 9990 indique que le XML SHOULD be GZIP compressed (devrait être compressé en GZIP), avec l’extension .xml.gz, et le nom du fichier suit un modèle fixe :

mail.receiver.example!example.com!1013662812!1013749130.xml.gz

On y trouve l’organisation émettrice du rapport, votre domaine, ainsi que le début et la fin de la période sous forme d’horodatages Unix. La période couverte correspond en général à une seule journée UTC.

Si les rapports doivent arriver dans une boîte d’un autre domaine (par exemple un service de traitement des rapports sur reports.example.net), ce domaine doit confirmer qu’il les accepte. Les destinataires recherchent un enregistrement TXT tel que example.com._report._dmarc.reports.example.net contenant v=DMARC1, et s’il est absent, ils ignorent l’adresse rua. Un enregistrement de confirmation manquant explique souvent pourquoi aucun rapport n’arrive.

La structure d’un rapport

Chaque rapport comporte les mêmes 3 parties. Voici un exemple abrégé, tiré de l’exemple de la RFC 9990 :

<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0">
  <report_metadata>
    <org_name>Sample Reporter</org_name>
    <date_range><begin>302832000</begin><end>302918399</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <p>quarantine</p>
    <testing>n</testing>
  </policy_published>
  <record>
    <row>
      <source_ip>192.0.2.123</source_ip>
      <count>123</count>
      <policy_evaluated>
        <disposition>pass</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <envelope_from>example.com</envelope_from>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim><domain>example.com</domain><result>pass</result><selector>abc123</selector></dkim>
      <spf><domain>example.com</domain><result>fail</result></spf>
    </auth_results>
  </record>
</feedback>

• report_metadata : qui a envoyé le rapport et quelle période il couvre.
• policy_published : l’enregistrement DMARC vu par le destinataire. Comparez-le avec ce que vous pensez avoir publié.
• record : un bloc par combinaison d’IP d’envoi et de résultats. Un domaine très actif en reçoit beaucoup.

Lire un enregistrement, champ par champ

source_ip et count. Le serveur qui s’est connecté au destinataire et le nombre de messages qu’il a remis sur la période. C’est ici que vous identifiez les expéditeurs : une résolution DNS inverse (dig -x 192.0.2.123 +short) ou le propriétaire de l’IP vous indique souvent s’il s’agit de votre fournisseur de messagerie, de votre CRM ou d’un inconnu.

policy_evaluated. Le verdict DMARC. Ici, dkim et spf ne sont pas les résultats bruts mais les résultats d’alignement : le contrôle a-t-il réussi pour un domaine correspondant à votre domaine From. DMARC réussit si au moins l’un des deux vaut pass. disposition montre ce qu’a fait le destinataire : none, pass, quarantine ou reject. Si cela diffère de votre politique, un élément reason en donne la raison, par exemple une dérogation liée à un transfert ou à une liste de diffusion.

identifiers. header_from est le domaine que vos destinataires ont vu. envelope_from est le domaine utilisé par le contrôle SPF, souvent un sous-domaine de votre service d’envoi plutôt que le vôtre.

auth_results. Les résultats SPF et DKIM bruts, avec les domaines pour lesquels ils ont été vérifiés. La RFC 9990 exige désormais le sélecteur DKIM, ce qui vous aide à savoir quel service a signé le message.

Dans l’exemple ci-dessus, DKIM a réussi et est aligné, SPF a échoué, et le message a tout de même passé DMARC. C’est un cas typique pour un service qui signe avec votre domaine mais envoie depuis son propre domaine d’enveloppe.

Classer les expéditeurs en 3 groupes

Après quelques semaines de rapports, chaque IP source entre dans l’un de ces groupes :

1. Connus et conformes. Votre fournisseur de messagerie et les services correctement configurés. Rien à faire.
2. Connus mais en échec. Un outil légitime (support client, facturation, newsletter) qui envoie sans DKIM aligné, ou qui manque dans SPF. Activez DKIM avec votre domaine dans cet outil, ou ajoutez-le à SPF en surveillant la limite de 10 requêtes DNS.
3. Inconnus et en échec. Des serveurs que vous ne pouvez rattacher à aucun outil que vous utilisez. Certains sont des relais de transfert ou des listes de diffusion ; d’autres sont le fait de quelqu’un qui met votre domaine dans le champ From. Ce sont exactement les messages qu’une politique p=quarantine ou p=reject bloquerait, le même type de courrier que celui des arnaques aux fausses factures.

C’est le groupe 2 qui compte avant l’application de la politique. Si vous passez à p=quarantine alors qu’un outil légitime échoue encore, ses e-mails partent en spam.

Conseils pratiques

• Utilisez une boîte dédiée ou un outil de traitement des rapports. Du XML brut venant de plusieurs fournisseurs chaque jour est difficile à lire à la main.
• Surveillez la valeur testing. La RFC 9989 a remplacé l’ancienne balise pct par une balise de mode test t ; t=y demande aux destinataires d’appliquer une action plus douce que votre politique.
• Regardez les volumes, pas seulement les échecs. Une nouvelle source soudaine avec un count élevé mérite votre attention, même si elle réussit.
• Conservez les rapports quelques mois pour pouvoir comparer avant et après un changement.
• Gardez à l’esprit que les fournisseurs de messagerie attendent de plus en plus DMARC des expéditeurs en masse, comme expliqué dans les exigences de Gmail et Yahoo pour les expéditeurs.

Une courte liste de contrôle

• Un enregistrement DMARC avec une adresse rua que quelqu’un lit vraiment.
• Les destinations externes des rapports confirmées par un enregistrement _report._dmarc.
• Chaque IP source rattachée à un service que vous connaissez.
• DKIM aligné activé pour chaque expéditeur légitime.
• Les sources inconnues en échec examinées, puis la politique passée à p=quarantine et plus tard à p=reject.

La place de Guarding

Les rapports DMARC montrent ce que les destinataires ont vu. Nous surveillons l’autre côté, depuis l’extérieur, chaque jour : vos enregistrements SPF, DKIM et DMARC, les domaines sosies et le reste de votre exposition externe. Quand un enregistrement est affaibli ou qu’un sélecteur disparaît, une personne l’examine et vous recevez la modification exacte à apporter, comme décrit dans ce qui se passe quand nous trouvons quelque chose. Vous pouvez voir à quoi cela ressemble dans le tableau de bord d’exemple.