Comment lire un rapport forensique DMARC : guide champ par champ

Votre enregistrement DMARC peut aussi comporter une balise ruf=, qui ne fonctionne pas du tout comme rua=. Les rapports agrégés arrivent une fois par jour sous forme de fichier XML compressé. Les rapports forensiques (aussi appelés rapports d'échec), lorsqu'un destinataire les envoie, arrivent quasiment en temps réel, un par message en échec, et sont conçus pour être lus par une personne qui enquête sur un incident précis, pas résumés par un tableau de bord. Voici ce qu'ils contiennent réellement et comment les lire sans supposer qu'ils fonctionnent comme les rapports que vous connaissez déjà.

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

Un rapport forensique DMARC, aussi appelé rapport d'échec ou rapport RUF, est une notification quasi instantanée générée par un serveur de messagerie destinataire dès qu'un message échoue à l'évaluation DMARC. Il contient des détails au niveau du message : quelle IP l'a envoyé, pourquoi l'authentification a échoué, et à quoi ressemblait réellement le message. C'est un rôle fondamentalement différent d'un rapport agrégé, qui résume chaque source d'envoi sur une fenêtre de 24 heures et ne nomme jamais un message individuel.

Red Sift OnDMARC traite les deux types de rapports, mais les données forensiques bénéficient particulièrement d'une gestion centralisée et à accès contrôlé, car contrairement aux rapports agrégés, elles peuvent contenir des informations personnelles sur vos destinataires. Comprendre ce que contient réellement un rapport forensique, et où se situe le risque, facilite grandement la décision de l'activer ou non.

À la fin, vous serez capable de :

• Distinguer un rapport forensique d'un rapport agrégé au premier coup d'œil, et savoir pourquoi les formats de fichier diffèrent
• Lire chaque champ d'un rapport au format AFRF réel sans fiche de référence
• Comprendre ce que contrôle la balise fo= et par quel réglage la plupart des équipes devraient commencer
• Reconnaître les quatre schémas qui apparaissent le plus souvent dans les données forensiques
• Savoir quand activer les rapports forensiques vaut le compromis en matière de confidentialité, et quand ce n'est pas le cas

Si vous avez déjà lu un rapport agrégé, la première chose qui surprend dans les rapports forensiques est le format. Les rapports agrégés sont en XML car ils sont conçus pour être analysés en masse par des machines. Les rapports forensiques utilisent un format complètement différent appelé AFRF, l'Authentication Failure Reporting Format, une extension spécifique à DMARC du format ARF, l'Abuse Reporting Format à usage général utilisé dans l'ensemble de l'industrie de l'email pour les plaintes de spam et d'abus [1].

AFRF ressemble à un ensemble d'en-têtes d'email, pas à un document balisé. C'est voulu. Les rapports de la famille ARF ont été conçus il y a des décennies pour être lisibles par une personne examinant un seul message problématique, transféré comme n'importe quel autre email. Un rapport forensique est essentiellement une version structurée de « voici le message qui a échoué et pourquoi », enveloppée dans un bloc d'en-têtes analysable par machine plutôt qu'en prose.

Cela vaut la peine d'être intégré avant d'ouvrir votre premier rapport : si vous cherchez des balises <record> ou un élément racine feedback comme dans un rapport agrégé, vous ne les trouverez pas. Vous trouverez à la place un bloc qui ressemble davantage à une notification de non-remise qu'à un fichier de données.

Voici un rapport forensique représentatif, utilisant des domaines et plages IP réservés selon la RFC 5737 afin que rien ici ne pointe vers un expéditeur ou destinataire réel.

Feedback-Type: auth-failure
User-Agent: RedSiftReporter/1.0
Version: 1
Original-Mail-From: <billing@vendor.example>
Original-Rcpt-To: <ap@redsift.example>
Arrival-Date: Wed, 19 Aug 2026 09:14:22 +0000
Message-ID: <a1b2c3d4@vendor.example>
Authentication-Results: dmarc=fail; dkim=fail; spf=pass
Identity-Alignment: dkim
Source-IP: 198.51.100.7
Reported-Domain: redsift.example
Original-Envelope-Id: <e5f6g7h8@vendor.example>
Dkim-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=vendor.example; q=dns/txt; s=mta; t=1788429698; x=1788436898; h=Message-Id: List-Unsubscribe-Post: List-Unsubscribe: To: To: From: From: Subject: Subject: Content-Type: Mime-Version: Date: Sender; bh=Qfn6ZXFS7sI6eJdL8VkYJGkZTxvNbH2aoX0/pIfZpWA=; b=0LACbKma2jAg+wWxUparh41AAGDpG5VXIHNg6iq8RoIn4cj6cChPfyZwkF+YmF8T5T7zB6mPYNSSo5ImUHA63Be+Dz39qwQZQXeb1X1f9KYSM0YH6UBpYS460gSS7OwS/mhdUdgodlI12iiG3ol4Ls9IyXWml9/p0PqFDZnPKgpkhbQuRtcyECWNQj6ZuaKVCKmiPALKa/8NOZaX9eXJ906LAEwzfkCjgR/9CSp1sITKtpZdIhHy0hb73lavr3BHKEsf/vsAayDvHH/leoTaIzO+lU3fHkXKmQWy9orGqEjHEmgQ4zUu5Q9HGNl+gPOs0+ILok5kzFUQkImuA9m91g==

Voici ce que chaque ligne vous indique réellement :

• Feedback-Type: auth-failure confirme qu'il s'agit spécifiquement d'un rapport d'échec DMARC, et non d'une plainte pour spam ou abus. ARF est utilisé pour plusieurs types de rapports, donc cette ligne vous indique lequel vous consultez.
• User-Agent nomme le logiciel de reporting. Utile surtout pour déboguer un destinataire qui envoie des rapports mal formés.
• Original-Mail-From est l'expéditeur enveloppe, l'adresse utilisée dans la transaction SMTP. C'est ce même champ que SPF valide réellement, et il peut différer de l'adresse From visible que voit un destinataire.
• Original-Rcpt-To est le destinataire. C'est le champ qui fait que les rapports forensiques contiennent des données personnelles, puisqu'il s'agit d'une véritable adresse de messagerie plutôt que d'un résumé au niveau du domaine.
• Arrival-Date horodate exactement le moment où le message est arrivé, ce qui importe pour la corrélation avec vos propres journaux de passerelle de messagerie.
• Authentication-Results est le champ principal. Ici, SPF a réussi mais DKIM a échoué, et DMARC a échoué globalement. Comme DMARC n'a besoin que de l'alignement de SPF ou de DKIM, un échec DMARC avec SPF indiqué comme réussi signifie que la réussite SPF ne s'est pas alignée avec le domaine From visible, pas que SPF était cassé.
• Identity-Alignment indique précisément quel(s) mécanisme(s) n'a pas réussi à authentifier une identité alignée, ou affiche « none » si toutes les méthodes tentées se sont alignées. Ce champ est devenu obligatoire avec la mise à jour de 2026, et c'est le moyen le plus rapide de confirmer si vous êtes face à un problème d'alignement DKIM, SPF, ou les deux, sans devoir recouper vous-même la ligne brute Authentication-Results [2].
• Source-IP est le serveur d'envoi exact. Recoupez-le avec votre inventaire d'expéditeurs approuvés avant de tirer une conclusion.
• Reported-Domain confirme quel domaine a déclenché le rapport via sa politique, utile lorsque vous gérez le reporting forensique sur plusieurs domaines à la fois.
• Dkim-Signature : La signature DKIM du message.

Conseil pratique : posez-vous ces quatre questions dans l'ordre à chaque ouverture d'un rapport forensique. Le Source-IP est-il reconnu ? SPF ou DKIM (ou les deux) ont-ils échoué ? L'Original-Mail-From est-il aligné avec votre domaine ? Cela ressemble-t-il à un artefact de transfert plutôt qu'à une attaque ? Si vous ne pouvez pas répondre avec certitude, transmettez-le au responsable de la réponse à incident plutôt que d'agir seul.

Certains rapports forensiques vont plus loin et joignent une copie expurgée ou complète des en-têtes et de la ligne d'objet du message en échec. C'est cette partie qui transforme un outil de diagnostic en enjeu de confidentialité, abordé plus loin.

La balise fo= de votre enregistrement DMARC contrôle si un destinataire génère un rapport forensique. La plupart des destinataires ne vérifient cette balise que si vous avez également publié une destination ruf=.

fo=1 offre la plus grande visibilité et c'est ce que la plupart des équipes sécurité choisissent, car un message peut échouer à DMARC sur l'alignement même quand un protocole techniquement réussit, ce que fo=0 manquerait. Le compromis est le volume : fo=1 sur un domaine avec un trafic de transfert significatif peut générer un rapport pour chaque redistribution de liste de diffusion et chaque chaîne de transfert cassée, dont la plupart ne sont pas des attaques.

1. Repérez votre enregistrement DMARC TXT existant à _dmarc.votredomaine.com.
2. Ajoutez une destination ruf=. Un enregistrement représentatif : v=DMARC1; p=quarantine; rua=mailto:aggregate@votredomaine.com; ruf=mailto:forensic@votredomaine.com; fo=1;
3. Définissez fo= délibérément, pas par défaut.
4. Si le domaine de destination diffère du domaine d'envoi, publiez un enregistrement d'autorisation à la destination, la même exigence qui s'applique aux rapports rua= envoyés inter-domaines.
5. Redirigez la boîte aux lettres vers une plateforme, pas une personne. Une boîte partagée recevant des rapports contenant des données personnelles crée une exposition qu'un système centralisé et à accès contrôlé évite.
6. Prévoyez la propagation. Les changements DNS peuvent prendre jusqu'à 48 heures pour atteindre tous les destinataires.

Pour la configuration DMARC plus large, y compris les balises rua=, p= et d'alignement, consultez notre guide de mise en œuvre de DMARC.

Une destination ruf= vide ne signifie pas nécessairement une mauvaise configuration.

C'est pourquoi les rapports agrégés restent la source de référence pour la surveillance continue de la santé du domaine, et les rapports forensiques demeurent un outil complémentaire pour des enquêtes précises plutôt qu'un remplacement.

Un rapport forensique peut inclure une véritable adresse de destinataire, une ligne d'objet, et parfois le contenu du message, ce qui explique précisément pourquoi les grands fournisseurs de messagerie, dont Gmail et Microsoft 365, ne les envoient généralement pas du tout. Ce compromis de confidentialité est la raison même pour laquelle le reporting forensique bénéficie d'un support bien plus faible dans l'industrie que le reporting agrégé : les destinataires doivent mettre en balance le besoin de diagnostic d'un propriétaire de domaine et la confidentialité de leurs propres utilisateurs, et la plupart choisissent par défaut de ne pas envoyer.

Pour les organisations de secteurs réglementés, ces données ont un poids réel en matière de conformité au titre de cadres comme le RGPD et le CCPA. Quelques pratiques comptent ici plus que presque partout ailleurs dans DMARC :

Acheminez les rapports vers une plateforme sécurisée et à accès contrôlé, jamais vers une boîte de réception généraliste.

Limitez l'accès par rôle. Toute personne pouvant voir les tableaux de bord agrégés n'a pas besoin de voir les données forensiques au niveau du message.

Définissez une politique de conservation. Les données forensiques ont une durée de vie utile courte à des fins d'enquête, et les conserver plus longtemps que nécessaire augmente l'exposition sans ajouter de valeur.

Considérez les destinataires qui expurgent des champs comme vous rendant service, et non comme retenant des données. Certains destinataires suppriment les lignes d'objet ou le corps des messages avant l'envoi ; c'est un comportement soucieux de la confidentialité de leur part, pas un rapport défaillant du vôtre.

1. Expéditeur légitime, alignement mal configuré. SPF ou DKIM réussit à la vérification brute, mais Authentication-Results affiche un échec DMARC. C'est presque toujours un problème d'alignement, pas une tentative d'usurpation. Corrigez la configuration de l'expéditeur plutôt que de la traiter comme une menace.

2. Rupture liée au transfert ou à une liste de diffusion. Source-IP appartient à un serveur de transfert ou de liste reconnu, SPF échoue, mais DKIM réussit souvent encore car les signatures DKIM survivent généralement intactes au transfert. Vérifiez si DMARC peut être satisfait par l'alignement DKIM seul avant d'escalader.

3. Shadow IT. Un Source-IP que vous ne reconnaissez pas s'avère appartenir à un outil SaaS adopté par une équipe sans en informer l'IT. Le volume est généralement faible et constant jour après jour, pas soudain. Ajoutez l'expéditeur à SPF et passez à autre chose.

4. Véritable usurpation. Un Source-IP non reconnu, sans lien avec un fournisseur ou service de transfert connu, SPF et DKIM échouant tous les deux, et aucun schéma correspondant à une explication interne. C'est le schéma qui mérite d'être escaladé : confirmez que votre politique est assez stricte pour mettre en quarantaine ou rejeter, et impliquez votre équipe sécurité si le volume dépasse un cas isolé.

Validez chacun de ces schémas par rapport aux tendances de vos rapports agrégés et aux journaux de votre passerelle de messagerie avant d'agir. Un rapport forensique isolé est un point de données, pas un verdict.

Le reporting forensique n'est pas un réglage activé par défaut. Il mérite sa place dans des situations précises :

• Vous avez une équipe sécurité qui agira sur des données au niveau du message. Sans personne pour les trier, le volume de fo=1 devient un bruit que personne ne lit.
• Vous dépannez activement un expéditeur précis et les données agrégées ne sont pas assez précises pour le diagnostiquer.
• Vous disposez déjà d'une infrastructure de reporting sécurisée et à accès contrôlé, donc le détail supplémentaire présente un risque marginal minime.

Évitez-le, ou reconsidérez-le, lorsque les rapports atterriraient dans une boîte partagée sans chiffrement ni contrôle d'accès, ou lorsque personne n'est responsable du tri des résultats. Dans les deux cas, les rapports agrégés couvrent déjà la surveillance de la santé du domaine dont la plupart des équipes ont réellement besoin au quotidien.

En mai 2026, l'IETF a remplacé la spécification DMARC d'origine, la RFC 7489, par trois documents Standards Track distincts : la RFC 9989 couvre le protocole principal, la RFC 9990 couvre le reporting agrégé, et la RFC 9991 couvre spécifiquement le reporting d'échec [2, 3]. Avant cette mise à jour, le reporting forensique n'était couvert que de manière informelle dans la spécification DMARC principale. Lui consacrer un document dédié signifie que le reporting d'échec peut désormais évoluer selon son propre calendrier, le même changement structurel qui s'est produit pour le reporting agrégé.

Quelques changements concrets valent la peine d'être connus la prochaine fois que vous consultez un rapport :

• Identity-Alignment est désormais un champ obligatoire, nommant précisément quel(s) mécanisme(s) n'a pas réussi à produire une identité alignée, plutôt que de vous laisser le déduire de la ligne brute Authentication-Results [2].
• DKIM-Domain, DKIM-Identity et DKIM-Selector sont désormais obligatoires chaque fois qu'un échec DKIM concerne un identifiant aligné, et SPF-DNS est désormais obligatoire pour les échecs SPF d'un identifiant aligné, resserrant ce qui était auparavant un détail optionnel [2].
• La vérification de la destination externe est désormais explicite. Si votre adresse ruf= pointe hors de votre domaine organisationnel, les destinataires doivent vérifier cette destination de la même manière qu'ils vérifient déjà les destinations rua= externes, comblant une faille qui permettait auparavant à un acteur malveillant de rediriger les rapports d'échec vers une adresse non autorisée [2].

Rien de tout cela ne change l'enveloppe AFRF elle-même ni le fonctionnement quotidien des balises ruf= et fo=. Ce qui a changé, c'est que des champs sur lesquels les équipes sécurité s'appuyaient déjà de manière informelle sont désormais normativement obligatoires, donc un rapport que vous recevrez désormais devrait être plus systématiquement complet que les rapports d'avant mai 2026.

S'attendre à du XML. Les rapports forensiques utilisent AFRF, pas le format XML des rapports agrégés. Chercher des éléments <record> dans un rapport forensique revient à chercher dans le mauvais format.

Traiter un rapport isolé comme un verdict. Un rapport forensique vous renseigne sur un seul message. Validez avec les tendances agrégées et les journaux avant de conclure quoi que ce soit.

Supposer que tout échec est une usurpation. La plupart des rapports forensiques reflètent un transfert, une mauvaise configuration d'alignement, ou du shadow IT, pas une attaque.

Acheminer les rapports vers une boîte partagée. Comme les rapports forensiques peuvent contenir des données personnelles, une boîte non protégée transforme un outil de diagnostic en risque de conformité.

Activer fo=1 sans plan de tri. Un volume élevé sans personne pour le lire est du bruit, pas de la visibilité.

Supposer qu'une boîte ruf= vide signifie qu'elle est cassée. De nombreux grands fournisseurs n'envoient tout simplement jamais de rapports forensiques, pour la confidentialité de leurs propres utilisateurs.

Un rapport forensique DMARC est une poignée de champs de type en-tête décrivant exactement un message en échec, livré en AFRF, pas en XML, et il existe pour répondre à une question plus précise qu'un rapport agrégé ne le pourra jamais. Il vaut la peine d'être activé quand vous avez quelqu'un pour le lire et un endroit sécurisé où l'envoyer, et vaut la peine d'être évité sinon.

Pour le type de rapport par lequel la plupart des équipes devraient commencer, consultez notre guide de lecture d'un rapport agrégé DMARC. Si vous dépannez un échec précis en ce moment plutôt que de décider s'il faut activer le reporting forensique, notre guide de débogage des échecs DMARC détaille directement les corrections d'alignement, les erreurs DNS et les problèmes de transfert.

Red Sift OnDMARC centralise à la fois les données agrégées et forensiques, applique un accès basé sur les rôles au contenu sensible des rapports, et fait ressortir automatiquement les quatre schémas ci-dessus au lieu de vous demander de lire l'AFRF à la main. Il bénéficie aussi de partenariats spéciaux avec des fournisseurs, ce qui signifie que vous recevrez plus de rapports forensiques que sur une boîte aux lettres classique grâce à nos partenariats de données.

[1] RFC 5965 - An Extensible Format for Email Feedback Reports

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

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

[4] RFC 6591 - Authentication Failure Reporting Using the Abuse Reporting Format