Comment lire un rapport agrégé DMARC : guide pas à pas par champ

Votre enregistrement DMARC contient un tag rua= et, chaque jour, les fournisseurs de messagerie vous envoient un fichier XML. Voici ce qu’il contient réellement et comment le lire sans y laisser votre santé mentale.

Gardez ce tableau à portée de main. Tout ce qui suit explique pourquoi chaque ligne est importante et comment la lire dans un vrai rapport.

Les rapports agrégés DMARC sont la seule partie du système DMARC conçue spécifiquement pour l’humain, même si ce sont encore des fichiers XML. C’est tout le problème ! Red Sift OnDMARC les transforme en tableaux de bord pour que vous ne touchiez jamais au XML brut, mais comprendre ce que résument ces tableaux accélérera toutes vos décisions concernant votre politique DMARC, et vous permettront de mieux les justifier. Ce guide décortique un véritable rapport, champ par champ, et vous montre comment distinguer une rotation d’ESP d’une vraie tentative d’usurpation.

Ceci n’est pas un rappel de la définition d’un rapport agrégé ni des raisons pour lesquelles votre boîte rua= peut être vide. Pour ça, consultez d’abord notre guide des bases du reporting agrégé DMARC. Ici, on part du moment où le fichier arrive dans votre boîte mail et on vous montre comment l’exploiter.

À la fin du guide, vous saurez :

• Ouvrir un rapport et identifier chaque section sans aide-mémoire
• Faire la différence entre le résultat pass/fail DMARC et le résultat brut SPF/DKIM sous-jacent
• Lire la colonne "disposition" et savoir exactement ce qu’il est advenu de ce mail
• Repérer les quatre schémas les plus fréquents dans les rapports (transferts, rotation ESP, usurpation, etc.)
• Comprendre ce qui évolue dans le format de rapport avec la mise à jour DMARC de 2026

Chaque rapport agrégé DMARC est un document XML, dont la racine est feedback. Trois blocs résument toutes les informations nécessaires [1].

• report_meta identifie qui vous a envoyé le rapport et quand. Il contient le nom de l’organisation émettrice, une adresse de contact, un identifiant de rapport unique, et un date_range donnant la période couverte en secondes depuis le 1er janvier 1970 (Unix Epoch). La plupart des receveurs utilisent une fenêtre glissante de 24 h.
• policy_published est l’état de lecture, vu par le destinataire, de votre enregistrement DMARC au moment où vos mails étaient évalués. C’est plus important que ça en a l’air : si vous changez votre politique de p=none à p=quarantine en cours de journée, différents rapports pour ce même jour afficheront parfois des valeurs différentes, à cause de la propagation DNS et du cache (tous les serveurs ne voient pas le changement au même instant) [1].
• record : c’est là qu’est la donnée brute. Vous avez un bloc par combinaison d’adresse IP source, de résultat évalué et d’identifiants d’authentification. La même IP peut donc apparaître dans plusieurs records, même si la disposition (verdict) est identique. Un rapport en comporte de un à plusieurs milliers selon votre volume. Chaque record se décompose en : row (IP, nombre, verdict), identifiers (domaines DMARC vérifiés), et auth_results (résultat brut SPF/DKIM avant alignement DMARC).

Une fois que vous savez reconnaître ces trois blocs, lire un rapport consiste juste à aller au bon endroit, pas à tout décoder à la main à chaque fois.

Voici à quoi ressemble un record une fois décompressé, selon la RFC 9990 [1]. La plupart des fournisseurs le compressent (.zip pour Gmail, .xml.gz ailleurs), donc la première étape : décompresser avant toute lecture.

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>16215678901234567890</report_id>
    <date_range>
      <begin>1754784000</begin>
      <end>1754870399</end>
    </date_range>
  </report_metadata>

  <policy_published>
    <domain>redsift.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>quarantine</p>
    <sp>none</sp>
  </policy_published>

  <record>
    <row>
      <source_ip>203.0.113.42</source_ip>
      <count>842</count>
      <policy_evaluated>
        <disposition>pass</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>redsift.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>redsift.com</domain>
        <result>pass</result>
        <selector>google</selector>
      </dkim>
      <spf>
        <domain>redsift.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

À quoi correspond chaque ligne :

• org_name et date_range : Google génère ce rapport pour une fenêtre de 24 h ; tout ce qui suit concerne les emails envoyés dans cette plage horaire, non ceux du jour.
• policy_published : Google lit que le DMARC de redsift.com applique un alignement relaxé (r) sur DKIM et SPF, politique quarantine. C’est la politique réellement appliquée pour cette analyse, pas forcément celle en ligne maintenant si elle a changé depuis.
• source_ip : 842 messages envoyés par cette IP sur la période. C’est un total cumulé, pas 842 lignes de log.
• disposition : pass indique un passage positif DMARC pour cette politique. La disposition signale le résultat/action DMARC ici, sans garantir la gestion réelle par la boîte de réception.
• dkim et spf dans policy_evaluated : Les deux sont pass, le message est aligné DMARC, pas seulement réussi au protocole brut.
• auth_results : Résultat brut avant DMARC. DKIM avec le selector google a réussi, SPF aussi. Ici, brute et alignée coïncident. Ce n’est pas toujours le cas.

C'est souvent ce dernier point qui échappe lors d'une première lecture. Il mérite donc sa propre explication. Mais avant, un mot sur le bloc identifiers, car c'est lui qui détermine quel domaine sera associé au verdict.

L'élément identifiers ne contient que trois champs au maximum, et on le survole facilement car aucun ne porte un résultat pass/fail. C’est tout l’enjeu. Ce bloc précise quels domaines DMARC a contrôlés, et tous les autres résultats sont rapportés vis-à-vis de ces valeurs.

• header_from : domaine de l’adresse visible dans le champ From – celle que voit le destinataire. Obligatoire dans chaque record : c’est l’ancrage de toute la logique d’alignement DMARC. Chaque contrôle d'alignement dans policy_evaluated se pose la question : le domaine SPF/DKIM validé correspond-il à celui-ci ?
• envelope_form : domaine du MAIL FROM SMTP ("return-path"). Jamais vu directement par le destinataire ; c’est là-dessus que SPF valide. Quand un service marketing envoie vos mails, ce champ montre souvent un domaine d’infrastructure (pas le vôtre), d’où échec régulier de l’alignement SPF sauf si vous avez un return-path personnalisé.
• envelope_to : optionnel ; domaine destinataire, utile surtout pour voir si l’échec touche un fournisseur ou plusieurs.

À bien retenir : si header_from indique redsift.com mais envelope_from indique bounce.some-esp.com, SPF va vérifier le domaine ESP, pas le vôtre. SPF peut donc "passer" sur ce domaine ESP mais échouer à l’alignement DMARC, car l’alignement compare envelope_from et header_from, qui ne coïncident que pour un sous-domaine pleinement délégué à l’ESP. Cette relation explique l’immense majorité des tickets "pourquoi ce mail échoue" dans les rapports…

Chaque record donne des verdicts séparés pour DKIM et SPF, et ils répondent à des questions différentes.

• auth_results répond : « Le test SPF/DKIM brut est-il positif ? » C’est la réponse protocolaire, sur le domaine mentionné par la signature ou l’enregistrement SPF.
• policy_evaluated répond : « Ce résultat vaut-il pour DMARC ? » C’est l’alignement qui compte et détermine la disposition.

La différence : c’est l’alignement. DMARC ne demande pas si SPF/DKIM ont passé, mais si le domaine validé correspond à l’adresse From (exact adkim=s/aspf=s ou organisationnel – par défaut pour la plupart des expéditeurs) [2]. Un mail validé SPF sur bounce.thirdpartyesp.com peut échouer DMARC si bounce.thirdpartyesp.com n’est pas aligné avec redsift.com.

D’où les cas où auth_results indique pass mais policy_evaluated indique fail pour le même record. Ce décalage explique la plupart des "on a tout qui passe mais DMARC échoue" : le tableau de bord du fournisseur montre le brut, DMARC exige l’alignement en plus.

Le champ disposition renseigne le sort du mail ; il prend quatre valeurs [1] :

Un point piégeux que rencontrent presque tout le monde : si votre politique est p=none, la plupart des records afficheront disposition:none, même lorsque DKIM et SPF échouent tous les deux. C’est en général le comportement attendu (le destinataire pouvant éventuellement opposer sa propre politique locale, voir ci-après). À p=none, vous demandez en fait aux récepteurs de rapporter ce qu’ils feraient, sans appliquer quoi que ce soit. Le rapport fait son travail. Rien n’est bloqué, car rien n’a été demandé.

Si la disposition ne correspond pas à ce que vous attendez de votre politique, vérifiez la présence d’un élément reason dans policy_evaluated. La RFC 9990 définit cinq types de dérogation possibles dans un rapport : local_policy, mailing_list, trusted_forwarder, policy_test_mode et other [1]. Un motif mailing_list sur un échec indique généralement une redistribution type serveurs de liste qui modifient ou cassent la signature DKIM ou SPF, mais ce champ n’atteste pas du détail précis de l’échec. Dans tous les cas, c’est le fonctionnement normal du forwarding et non une menace à traquer.

Lire un enregistrement isolé a ses limites. L’utilité d’un rapport agrégé, c’est l’analyse de plusieurs records sur plusieurs jours pour un même expéditeur. Quatre schémas apparaissent constamment ; reconnaître lequel on observe évite d’ignorer un vrai souci ou de poursuive un faux problème.

1. Expéditeur légitime pas encore autorisé : Une nouvelle source_ip surgit, auth_results indique DKIM/SPF échoués, et ce nombre reste constant sur plusieurs jours. Le plus souvent, c’est une solution marketing/CRM/helpdesk qu’un collègue a adopté sans remonter l’info à l’IT. Il faut l’ajouter dans SPF et activer la signature DKIM, pas la bloquer…

2. Rotation d’IP chez un ESP ou cloud : Un expéditeur est autorisé depuis longtemps, puis de nouveaux IPs échouent SPF alors que DKIM passe toujours. Les gros expéditeurs font régulièrement tourner leur infrastructure. Comme la signature DKIM voyage avec le message, peu importe l’IP source, la stabilité DKIM + rupture SPF signifie rotation, pas usurpation. Vérifiez avec l’ESP si un changement a eu lieu côté infrastructure.

3. Mailing lists et transferts : SPF et DKIM échouent, le champ reason indique mailing_list ou le nombre dispersé sur plein d’IPs, mais header_from porte toujours votre domaine. Il s’agit d’un collègue qui transfère ou d’une liste qui réexpédie. C’est un effet collatéral prévu du forwarding selon la RFC 9989 [2].

4. Vraie usurpation : SPF/DKIM échouent, l’IP n’a aucun lien avec vos prestataires, aucun override dans reason et le volume est un pic ou une goutte régulière non attribuable à une activité interne. Là, vérifier que votre politique est assez stricte pour bloquer (quarantine/reject), et traiter le volume comme une attaque de phishing si élevé.

Faire ces vérifications à la main pour des milliers de records par jour n’est pas viable… d’où l’intérêt de plateformes comme Red Sift OnDMARC : elles automatisent la détection de ces schémas pour vous éviter d’examiner du XML brut chaque matin.

En mai 2026, l’IETF a remplacé la spécification DMARC originelle (RFC 7489) par trois RFC : la RFC 9989 sur le protocole principal, RFC 9990 sur l’agrégation, et RFC 9991 pour les rapports d’échec [1,2]. Si vous lisez déjà ces rapports, le format reste fonctionnel. Les outils existants restent en général compatibles car RFC 9990 impose la tolérance des extensions non supportées [1] ; attention cependant : namespace, schéma et quelques notions (comme la disposition "pass") changent, donc un parseur strict RFC 7489 pourrait refuser un rapport RFC 9990.

Quelques apports à connaître :

• discover_method peut apparaître dans policy_published pour indiquer psl (méthode Public Suffix List, héritée) ou treewalk (nouvelle méthode DNS pour trouver le domaine organisationnel) [1].
• Selectors désormais obligatoires dès lors qu’il y a une signature DKIM dans auth_results. Avant, ce champ pouvait être omis.
• Champ generator possible dans report_metadata : logiciel ayant produit le rapport, utile pour le debugging si des fichiers sont malformés.

Rien de tout cela ne change la lecture quotidienne : les parseurs et tableaux de bord restent adaptés, car l’extensibilité RFC 9990 impose la tolérance des champs inconnus [1]. Cela n’est pas une règle générale du XML, mais bien une stipulation délibérée de la RFC. À retenir si vous développez ou choisissez un parseur, et preuve que le reporting DMARC reste un standard vivant, en évolution, non figé depuis 2015. Le changement le plus fondamental est que la partie agrégée a maintenant sa propre spécification, ce qui permettra de faire évoluer le reporting sans attendre une révision complète du protocole. Voir le détail des changements et leur impact DNS dans notre analyse de la RFC 9989.

Un domaine moyen reçoit chaque jour 15 à 30 rapports d’autant de fournisseurs de messagerie, chacun avec son format de fichier, de compression, et sa façon de renseigner les champs optionnels. Rien n’est pensé pour être ouvert, décompressé et parcouru manuellement. C’est du "machine-readable" ; seul le résumé le rend exploitable pour un humain.

Les exigences de Google pour les expéditeurs de masse, en vigueur depuis février 2024, imposent à tout domaine envoyant plus de 5 000 mails quotidiens vers Gmail d’activer SPF et DKIM et de publier DMARC au moins en p=none [3]. Ce seul point a poussé une masse de domaines à adopter DMARC, pour buter immédiatement sur la lisibilité : rapports corrects, complets, mais ingérables sans outil dédié.

C’est à ce niveau que Red Sift OnDMARC fait la différence : ingestion automatique, regroupement par source d’émission, détection immédiate des nouveaux tiers, et taux de succès par source sur une interface unique. Vous pouvez ainsi passer de p=none à p=quarantine, puis p=reject l’esprit tranquille. Si vous en êtes plus tôt dans la démarche, notre guide d’implémentation DMARC explique chaque étape jusqu’à l’application stricte.

Lire un seul rapport au lieu d’analyser la tendance : Un rapport journalier ne couvre que 24 h. Infrastructure, volume et incidents varient chaque jour. Pensez comparatif au moins à la semaine par source pour statuer.

Confondre auth_results et verdict DMARC : Ces résultats peuvent diverger. Si "tout passe en interne" mais DMARC chute, l’alignement est (presque) toujours l’explication.

Interpréter disposition:none comme "aucun échec" : À p=none, signifie "rien n’a été bloqué", PAS "tout a réussi". Vérifiez dkim et spf dans policy_evaluated directement.

Ignorer le champ count : Un seul échec sur IP inconnue : bruit. Même schéma sur centaines de messages tout au long de 2 semaines : source à autoriser… ou à bloquer.

Prendre chaque échec pour une attaque : La majorité des échecs DMARC viennent des redirections, listes ou vendeurs non mis à jour dans SPF – pas de la fraude. Gardez l’alerte pour les motifs sans explication interne ni override reason.

Faire l’impasse sur identifiers : Pas de statut visuel, on saute vers policy_evaluated. Mais sans vérifier header_from face à envelope_from, on ne fait que supposer l’échec d’alignement…

Un rapport agrégé DMARC utilise trois blocs XML et quelques champs répétés pour chaque source d’émission. Une fois que vous pouvez nommer report_metadata, policy_published et record d’emblée, et que vous savez regarder policy_evaluated plutôt que auth_results pour connaître le résultat DMARC réel, vous n’avez plus rien à craindre du fichier en soi. Le plus complexe reste de gérer cette lecture sur des dizaines de fournisseurs et des milliers de records chaque jour sans perdre le fil.

C’est le moment où l’automatisation devient clé : Red Sift OnDMARC analyse instantanément chaque rapport, détecte automatiquement les nouveaux tiers et vous affiche le taux de réussite par source, donc le passage à un durcissement de politique se fait en un clin d’œil – sans tableur.

[1] RFC 9990 - Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting

[2] RFC 9989 - Domain-Based Message Authentication, Reporting, and Conformance (DMARC)

[3] Email sender guidelines FAQ - Gmail Aide