Contrôle e-mailpar Jarod Capella
Contrôle e-mail / Lire un rapport DMARC agrégé (XML) : champ par champ

Lire un rapport DMARC agrégé (XML) : champ par champ

Par Jarod Capella · Mis à jour le 14 novembre 2026 · 3 min de lecture

Quand votre enregistrement DMARC contient une adresse rua, les grands fournisseurs de messagerie vous envoient des rapports. Ils sont en XML, rarement lisibles tels quels. Cette page décrit leur structure, d'après la RFC 9990 (mai 2026), qui remplace la partie « rapports » de la RFC 9990. Les champs que vous voyez dans un rapport dépendent de l'expéditeur : certains fournisseurs suivent encore l'ancien format.

Pour lire un fichier sans effort : l’analyseur de rapport (traitement local dans le navigateur).

Demander les rapports

Ajoutez la balise rua à l'enregistrement DMARC, par exemple v=DMARC1; p=none; rua=mailto:dmarc@exemple.fr. Si l'adresse est sur un autre domaine que le vôtre, ce domaine doit publier un enregistrement TXT d'autorisation sous _report._dmarc (RFC 9990, section 4).

La balise ri (intervalle entre rapports) est classée « historic » dans le registre de la RFC 9989, et la balise pct est supprimée : le mode test t=y la remplace en partie. Voir ce qui change avec la RFC 9989.

Le fichier reçu

Le rapport arrive en pièce jointe d'un e-mail. Le fichier XML « devrait » être compressé en GZIP (extension xml.gz, sinon xml). Son nom suit le modèle receveur!domaine!début!fin.xml.gz, où début et fin sont des horodatages Unix, par exemple mail.receiver.example!example.com!1013662812!1013749130.xml.gz.

Le sujet commence par Report Domain: suivi de votre domaine, puis Submitter: (le fournisseur qui envoie) et, en option, Report-ID:. Un rapport ne concerne qu'un seul domaine de politique. Si vous gérez trois domaines, comptez au moins trois rapports par fournisseur et par période.

Structure du XML

  • report_metadata : org_name (qui envoie le rapport), email, report_id, generator (facultatif), date_range (begin et end).
  • policy_published : la politique que le destinataire a trouvée pour votre domaine (domain, p, puis selon les cas sp, np, fo, adkim, aspf, testing pour la balise t, et discovery_method qui vaut psl ou treewalk). Vérifiez qu'elle correspond à ce que vous avez publié.
  • record (répété) : une ligne par groupe de messages, avec row, identifiers et auth_results.

Lire une ligne (record)

  • source_ip : l'adresse IP qui a envoyé les messages. C'est ce qui permet d'identifier un service d'envoi que vous aviez oublié.
  • count : le nombre de messages concernés.
  • policy_evaluated : disposition (ce qui a été appliqué), puis dkim et spf (valeurs pass ou fail : résultat après vérification d'alignement avec DMARC).
  • identifiers : header_from (l'adresse affichée à l'utilisateur) et envelope_from.
  • auth_results : résultats bruts de SPF et de DKIM. Le domaine est indiqué pour les deux ; le sélecteur DKIM est désormais obligatoire dans le format de la RFC 9990. Pour SPF, seule l'identité MAIL FROM compte. Un pass ici avec un fail dans policy_evaluated signale un défaut d'alignement : le domaine authentifié n'est pas celui de l'adresse affichée.
  • reason (dans policy_evaluated) : présent quand le receveur a appliqué autre chose que votre politique. Le type vaut local_policy, mailing_list, trusted_forwarder, policy_test_mode ou other. Une liste de diffusion ou un transfert explique souvent un fail que vous ne pouvez pas corriger chez vous.

Que chercher en pratique

  1. Les IP au volume count élevé avec spf et dkim à fail : soit un service légitime non configuré, soit une usurpation de votre domaine.
  2. Les services légitimes (newsletter, facturation, outil de ticketing) dont l'alignement échoue : à corriger avant de passer de p=none à quarantine ou reject.
  3. Une policy_published différente de votre enregistrement : erreur de publication ou mauvais domaine.

Pour contrôler votre enregistrement, utilisez le vérificateur ; les erreurs fréquentes sont décrites sur la page Erreurs courantes.

Sources

  • RFC 9990, « DMARC Aggregate Reporting », mai 2026, sections 3.1 à 3.5 et annexe C, https://www.rfc-editor.org/rfc/rfc9990 (lue en texte intégral le 2026-11-05).
  • RFC 9989, annexe A.6 (retrait de pct) et registre des balises, https://www.rfc-editor.org/rfc/rfc9989 (lue le 2026-11-05).