Qu'est-ce que l'ARF ? Format de signalement des abus et rapports d'échec DMARC (RFC 5965)

Qu'est-ce que l'ARF (Abuse Reporting Format) ?

ARF signifie « Abuse Reporting Format » (format de signalement d’abus). Il s’agit d’un format normalisé et lisible par machine permettant d’informer les expéditeurs qu’un e-mail a posé problème. Il a été défini dans la RFC 5965 en 2010, à une époque où les signalements d’abus prenaient principalement la forme d’e-mails en texte brut hétérogènes que les administrateurs de messagerie devaient lire manuellement. Ce système fonctionnait bien lorsque le volume était faible, mais il s’est révélé inefficace dès que les fournisseurs ont souhaité automatiser le processus. L'ARF a fourni aux destinataires, aux FAI et aux fournisseurs de boîtes mail une structure commune permettant de signaler les incidents d'abus aux propriétaires de domaines et aux expéditeurs dans un format facilement exploitable par des scripts et des analyseurs syntaxiques.

Aujourd'hui, l'ARF est présente dans quatre domaines principaux :

• Rapports d'échec DMARC – lorsqu'un message échoue à l'authentification DMARC, un destinataire peut envoyer un rapport ARF décrivant précisément la nature du problème.
• Boucles de rétroaction des FAI: lorsqu'un destinataire clique sur « C'est un spam », certains fournisseurs transmettent cette plainte à l'expéditeur au format ARF.
• Plaintes adressées au service de signalement des abus – signalements manuels d'abus acheminés via des systèmes automatisés de gestion des abus.
• Signalements de hameçonnage et de fraude – signalements indiquant qu’un message est frauduleux et non pas simplement indésirable.

Autant le préciser d'emblée : cet ARF n'a rien à voir avec les autres acronymes auxquels vous pourriez penser. Dans le domaine du courrier électronique, ARF désigne toujours l'« Abuse Reporting Format » (format de signalement des abus).

Comment est structuré un rapport ARF (les trois parties)

La RFC 5965 définit l'ARF comme un message MIME de type « multipart/report », ce qui signifie simplement qu'il s'agit d'un e-mail composé de trois parties distinctes regroupées. Chaque partie s'adresse à un destinataire différent : l'une est destinée à un humain, l'autre à une machine, et la troisième constitue la preuve.

Partie 1 : Résumé lisible par l'utilisateur (text/plain)

La première partie est un bloc de texte brut destiné à une personne qui parcourt rapidement sa boîte de réception. Elle présente généralement un résumé d'une ou deux lignes de ce qui s'est passé, afin que la personne qui jette un coup d'œil au rapport n'ait pas besoin d'analyser les champs lisibles par machine pour en saisir l'essentiel.

Partie 2 : Rapport lisible par machine (message/feedback-report)

Il s'agit du cœur du rapport et de la partie que les systèmes automatisés analysent réellement. Il s'agit d'un ensemble de champs « clé-valeur » tels que « Feedback-Type », « Version », « User-Agent », « Source-IP » et « Arrival-Date », ainsi que de champs spécifiques à l'authentification comme « Auth-Failure ». C'est là que réside véritablement la valeur diagnostique du rapport.

Partie 3 : Le message d'origine (message/rfc822 ou text/rfc822-headers)

La dernière partie contient soit l'intégralité du message d'origine, soit uniquement ses en-têtes, selon la configuration choisie par l'expéditeur et le niveau de détail que le destinataire est disposé à partager. Le contenu du message pouvant contenir des informations personnelles, de nombreux destinataires ne conservent que les en-têtes ou en masquent certaines parties avant de transmettre le rapport.

Types de retours d'information de l'ARF

Le champ « Type de retour d'information » vous indique de quel type de rapport il s'agit :

Dans le cadre du protocole DMARC, vous ne verrez jamais qu'une seule valeur apparaître ici : « auth-failure ». D'autres types de retours d'information peuvent être enregistrés auprès de l'IANA si un nouveau cas d'utilisation se présente, mais le cas d'utilisation du protocole DMARC est resté inchangé avec « auth-failure » depuis le tout début.

ARF, AFRF, RUF, rapports médico-légaux : démêler la terminologie

Si vous vous êtes renseigné sur les rapports DMARC et que vous avez remarqué que les termes ARF, AFRF, RUF et « rapport d'analyse » sont utilisés de manière presque interchangeable, vous ne rêvez pas. Ces termes se recoupent effectivement, et voici en quoi ils sont liés :

• Le format ARF est le format de base défini dans la RFC 5965. Il s'agit d'un format générique qui n'a jamais été spécifique à DMARC.
• L'AFRF (Authentication Failure Reporting Format) est l'extension définie dans la RFC 6591 qui adapte l'ARF spécifiquement au signalement des échecs d'authentification SPF, DKIM et DMARC.
• RUF est la balise DMARC (ruf=) que vous ajoutez à votre enregistrement DNS pour demander que les rapports d'échec, message par message, soient envoyés à une adresse donnée.
• Le terme « rapport d'analyse » est l'ancienne appellation de ce même élément, héritée de la spécification DMARC d'origine, la RFC 7489. La série actuelle de RFC l'appelle désormais « rapport d'échec ».

Ainsi, lorsqu'une personne demande un « exemple de rapport d'expertise » et qu'une autre parle d'un « rapport d'échec DMARC », elles font référence à la même chose. C'est la terminologie qui a évolué avec la norme, et non le mécanisme sous-jacent.

ARF et DMARC : explication des rapports d'échec

Lorsque vous ajoutez une balise « ruf= » à votre enregistrement DNS DMARC, vous demandez aux serveurs de messagerie destinataires de vous envoyer un rapport chaque fois qu’un message prétendant provenir de votre domaine échoue au contrôle DMARC. Contrairement aux rapports agrégés, qui regroupent le trafic d’une journée entière dans un seul résumé XML, les rapports d’échec sont censés être générés peu après l’échec et ne concerner qu’un seul message.

Un rapport d'échec DMARC vous fournit des informations qu'un rapport agrégé ne peut pas vous apporter : les résultats d'authentification pour ce message spécifique, des détails sur le mécanisme qui a échoué, des informations sur la source d'envoi, ainsi que le message complet ou ses en-têtes, ce qui vous permet de retracer sa provenance exacte. C'est ce niveau de détail qui rend les rapports d'échec utiles pour détecter une tentative d'usurpation d'identité en temps quasi réel, à condition bien sûr que vous en receviez un, ce qui nous amène à la section suivante.

Ce qu'a changé la RFC 9991 (mise à jour 2026)

En mai 2026, l'IETF a publié une nouvelle série de documents DMARC qui remplacent la RFC 7489 d'origine : la RFC 9989 (DMARC de base), la RFC 9990 (rapports agrégés/RUA) et la RFC 9991 (rapports d'échec/RUF). Ensemble, ces documents rendent la RFC 7489 obsolète. Voici ce qui a effectivement changé concernant les rapports d'échec :

• La structure des RFC a évolué : la RFC 9991 traite désormais des rapports d'échec et remplace les sections consacrées à ce sujet dans la RFC 7489. Elle met également à jour la RFC 6591 (AFRF) en définissant un ensemble plus précis de champs obligatoires.
• Le format de transmission ARF n'a pas changé en soi : la RFC 5965 reste le format de base sous-jacent.
• Un nouveau champ obligatoire : « Identity-Alignment » : une liste séparée par des virgules indiquant quel mécanisme (DKIM ou SPF) n'a pas réussi à générer un identifiant aligné, ou « none » si un identifiant aligné a permis l'authentification. C'est le champ le plus utile pour toute personne consultant un rapport, car il indique directement s'il s'agit d'une erreur de configuration ou d'une usurpation pure et simple,
• Un nouveau type d'échec d'authentification : dmarc : utilisé spécifiquement lorsqu'aucun identifiant aligné n'a permis d'authentifier le message, par opposition à un échec SPF DKIM générique.
• Nouveaux champs obligatoires pour le diagnostic des échecs d'alignement : les champs « DKIM-Domain », « DKIM-Identity » et « DKIM-Selector » sont obligatoires lorsqu'une signature DKIM alignée a échoué. Le champ SPF » est obligatoire lorsqu'une SPF alignée a échoué.
• Nouveaux champs facultatifs permettant d'ajouter des détails supplémentaires : « Delivery-Result » et la paire « DKIM-Canonicalized-Header/Body », disponibles lorsqu'un destinataire souhaite inclure davantage d'informations de diagnostic.

Pourquoi l'alignement identitaire revêt-il une telle importance ?

Le protocole DMARC n'a jamais vraiment vérifié si SPF DKIM étaient réussies prises isolément ; il vérifie si un identifiant authentifié correspond au domaine figurant dans l'adresse « De : » visible. Un message peut techniquement passer les validations SPF DKIM tout en échouant au contrôle DMARC si aucun des deux n'est aligné avec le domaine « De : ». Ce champ l'indique clairement.

RUA vs RUF : rapports globaux vs rapports d'échec

Recommandation (identique à la précédente)

Veillez à toujours configurer le paramètre `rua=` dans votre enregistrement DMARC. Les principaux fournisseurs de messagerie prennent largement en charge les rapports agrégés DMARC et vous offrent la visibilité quotidienne dont vous avez besoin pour surveiller l'authentification. La configuration du paramètre `ruf=` est facultative et peut fournir des informations de diagnostic supplémentaires, mais comme de nombreux destinataires n'envoient pas de rapports d'analyse approfondie, considérez-les comme une source de données complémentaire.

Comment lire un rapport ARF (exemple champ par champ)

Vous trouverez ci-dessous un exemple de rapport d'échec DMARC pouvant correspondre à une usurpation de domaine direct, dans laquelle un pirate envoie un e-mail prétendant provenir de votre domaine sans qu'aucun SPF DKIM valide ne vienne l'authentifier :

Feedback-Type: auth-failure
Version: 1
User-Agent: MailReceiver/2.1
Auth-Failure: dmarc
Identity-Alignment: dkim, spf
Original-Mail-From: <[email protected]>
Reported-Domain: yourdomain.com
Source-IP: 198.51.100.44
SPF-DNS: v=spf1 include:_spf.yourdomain.com ~all
Authentication-Results: mx.receiver.example;
    dmarc=fail (p=reject) header.from=yourdomain.com;
    spf=fail smtp.mailfrom=spoofed-source.net;
    dkim=none
Arrival-Date: Wed, 22 Jul 2026 09:14:02 +0000

En se promenant dans les champs qui comptent le plus :

• Le type de retour d'information « auth-failure » confirme qu'il s'agit d'un problème d'authentification, et non d'un signalement de spam ou d'abus.
• Échec d'authentification : dmarc indique que l'échec est spécifiquement un échec d'alignement DMARC, du type introduit par la RFC 9991.
• Alignement d'identité : « dkim, spf » est la ligne de diagnostic clé. Ces deux mécanismes n'ont pas réussi à générer un identifiant aligné, ce qui, combiné à l'absence de signature DKIM valide et à un échec SPF , indique clairement qu'il s'agit d'une usurpation pure et simple plutôt que d'une erreur de configuration de votre part.
• Les champs « Source-IP » et « Original-Mail-From » vous indiquent d'où provient réellement le message, ce qui est utile pour l'ajouter à une liste noire ou pour mener une enquête plus approfondie.
• La fonctionnalité « Reported-Domain » vous permet de savoir lequel de vos domaines a été ciblé, ce qui est très pratique si vous en gérez plusieurs.
• SPF affiche SPF utilisé par le destinataire pour l'évaluation, ce qui vous permet de vérifier si votre propre enregistrement a bien été lu correctement.

Si, au contraire, il s'était agi d'un expéditeur tiers légitime que vous aviez oublié d'autoriser, vous auriez généralement vu « Identity-Alignment » n'indiquer qu'un seul mécanisme, l'autre affichant « OK », ce qui vous aurait orienté vers une correction de configuration plutôt que vers une attaque.

Pourquoi vous pourriez ne pas recevoir de rapports d'échec

Si vous avez configuré ruf= et que les rapports n'apparaissent jamais, ou n'arrivent qu'au compte-gouttes, plusieurs raisons valables peuvent expliquer ce phénomène :

1. La plupart des grands fournisseurs ne les envoient pas

Gmail et Yahoo, qui comptent parmi les principales sources de courriers entrants pour la plupart des domaines, ne génèrent généralement pas de rapports d'échec.

2. Confidentialité et expurgation

Les rapports d'erreur peuvent révéler des informations personnelles contenues dans les en-têtes ou le corps des messages, ce qui expose l'expéditeur à des risques liés au RGPD et au CCPA. La norme RFC 6590 traite de la suppression des données sensibles dans les rapports d'abus, mais cette suppression peut priver le rapport d'une grande partie de son utilité initiale.

3. Les destinations externes doivent être vérifiées

Si votre adresse « ruf= » pointe vers une destination située en dehors du domaine de votre organisation, la norme RFC 9991 impose au destinataire d'effectuer une vérification externe de la destination (le même mécanisme que celui défini par la norme RFC 9990 pour les rapports agrégés) avant d'y envoyer quoi que ce soit. En l'absence de cet enregistrement d'autorisation, les rapports ne parviendront pas à destination.

4. On s'attend à une limitation du débit

La RFC 9991 invite les expéditeurs à limiter le nombre de rapports d'échec qu'ils envoient à un même destinataire, d'une part pour éviter de saturer une boîte mail et d'autre part pour empêcher les boucles de signalement.

5. Pas de défaillances, pas de rapports

Si vos e-mails légitimes sont authentifiés sans problème, il n'y a a priori aucune raison qu'un rapport d'échec soit généré.

6. Les paramètres de votre balise « fo »

La balise `fo=` permet de contrôler précisément quand un rapport est généré : `fo=0` (valeur par défaut) ne génère un rapport que lorsque SPF DKIM échouent tous les deux ou ne concordent pas ; `fo=1` génère un rapport dès qu'un des deux échoue ; `fo=d` signale spécifiquement un échec de DKIM ; et `fo=s` signale spécifiquement SPF . La plupart des domaines qui souhaitent obtenir des diagnostics utiles définissent `fo=1`.

Boucles de rétroaction par e-mail et ARF

Les rapports d'échec ne sont pas les seuls endroits où l'ARF apparaît. Les boucles de retour d'information des FAI (notammentla boucle de retour d'information sur les plaintes de Yahoo et les programmes JMRP/SNDS de Microsoft ) utilisent exactement le même format ARF, à la seule différence que le paramètre « Feedback-Type » est défini sur « abuse » au lieu de « auth-failure ».

Ces rapports sont générés lorsqu'un destinataire signale un message comme spam ; ils constituent un indicateur précoce utile des problèmes de délivrabilité, même s'ils ne sont en rien liés au protocole DMARC.

Comment configurer le système ARF / de signalement des pannes pour votre domaine

Si vous souhaitez commencer à recueillir des rapports d'erreur pour votre domaine :

1. Ajoutez une balise « ruf= » à votre enregistrement DNS DMARC en la faisant pointer vers une boîte mail dédiée ou une adresse de signalement.

2. Définissez fo=1 si vous souhaitez recevoir des rapports en cas d'échec SPF du DKIM, et non pas uniquement lorsque les deux échouent.

3. Si l'adresse « ruf= » se trouve en dehors du domaine de votre organisation, assurez-vous que l'enregistrement d'autorisation de destination externe est bien en place, sinon les destinataires n'enverront rien à cette adresse.

4. Inscrivez-vous séparément aux programmes de boucle de rétroaction proposés par les principaux FAI, car ceux-ci fonctionnent en dehors du cadre du DMARC.

5. Ne comptez pas les analyser manuellement en grande quantité. Même un volume de courrier restreint peut générer un nombre de rapports ARF bruts trop important pour être traité manuellement. C’est là qu’un outil d’analyse automatisé des rapports DMARC facilite grandement les choses.

Résumé

Les rapports d’échec constituent une application spécifique de l’ARF au sein du protocole DMARC. Le RUF vous fournit des informations détaillées pour chaque message dès sa réception, mais une part non négligeable de destinataires ne l’envoie pas, ce qui fait des rapports agrégés (RUA) votre source fiable et quotidienne de visibilité. La norme DMARC étant désormais officialisée par les RFC 9989, RFC 9990 et RFC 9991, il est plus important que jamais d’utiliser correctement la terminologie et de bien comprendre les détails, en particulier si vous devez résoudre un véritable incident d’usurpation d’identité plutôt qu’une simple erreur de configuration.

Si vous configurez le système de rapports pour la première fois ou si vous souhaitez consulter ces données sans avoir à analyser vous-même les messages ARF bruts, notre outil DMARC Report Analyzer est spécialement conçu pour répondre à ce besoin. Inscrivez-vous dès aujourd'hui pour bénéficier d'un essai gratuit et consultez vos rapports en toute simplicité !

Foire aux questions

Qu'est-ce qu'un rapport d'échec DMARC (d'analyse judiciaire) ?

Il s'agit d'un rapport ARF généré pour chaque message lorsqu'un e-mail échoue à l'authentification DMARC. Il contient des informations détaillées sur le message concerné, notamment les mécanismes d'authentification qui ont échoué et s'ils ont produit un identifiant correspondant au domaine indiqué dans le champ « De : ». Le terme « rapport d'analyse » est l'ancienne appellation de ce même document, issue de la norme RFC 7489.

Quelle est la différence entre RUA et RUF dans DMARC ?

Les rapports RUA (agrégés) sont des résumés XML quotidiens couvrant l'ensemble des e-mails provenant d'un domaine, désormais définis dans la RFC 9990. Les rapports RUF (échecs) sont des rapports ARF en temps quasi réel concernant des messages individuels ayant échoué, définis dans la RFC 9991. Le protocole RUA est largement pris en charge ; le protocole RUF est facultatif et son envoi n'est pas systématique.

Qui envoie les rapports d'échec DMARC ?

Seuls certains destinataires les génèrent, et les principaux fournisseurs de messagerie comme Gmail et Yahoo ne le font généralement pas. La prise en charge varie selon les destinataires, et les préoccupations en matière de confidentialité, les exigences de limitation de débit ainsi que les règles de vérification de la destination prévues par la norme RFC 9991 réduisent toutes la fréquence à laquelle ces messages parviennent effectivement à leur destinataire.

Quelle est la différence entre l'ARF et le XARF ?

Le format ARF (RFC 5965) est le format normalisé par l'IETF utilisé dans les rapports d'échec DMARC et les boucles de rétroaction des FAI. XARF est une extension propriétaire développée par un fournisseur qui ajoute une charge utile au format JSON afin de faciliter l'analyse. Il ne s'agit pas d'une norme IETF et n'est pas utilisé par les principaux fournisseurs pour les rapports DMARC.

Pourquoi ne reçois-je aucun rapport d'échec DMARC ?

Parmi les causes possibles, on peut citer l'envoi à des fournisseurs majeurs qui ne génèrent pas ces rapports, la suppression de certaines informations pour des raisons de confidentialité, l'absence d'enregistrement de vérification de la destination externe si votre adresse « ruf= » se trouve hors du domaine, une limitation de débit obligatoire du côté du destinataire, ou tout simplement l'absence d'échecs d'authentification à signaler. Le paramètre de votre balise « fo= » détermine également à quel moment précis un rapport est déclenché.

• À propos de
• Derniers messages

Ahona Rudra

Expert en sécurité des domaines et des e-mails chez PowerDMARC

Ahona est la responsable du marketing chez PowerDMARC, avec plus de 5 ans d'expérience dans l'écriture sur des sujets de cybersécurité, spécialisée dans la sécurité des domaines et des courriels. Ahona est titulaire d'un diplôme de troisième cycle en journalisme et communication, solidifiant sa carrière dans le secteur de la sécurité depuis 2019.

Derniers messages de Ahona Rudra (voir tous)

• Qu'est-ce que l'ARF ? Format de signalement des abus et rapports d'échec DMARC (RFC 5965) - 24 juillet 2026
• La plupart des établissements financiers ont mis en place le protocole DMARC. Presque aucun n'est protégé. - 22 juillet 2026
• Qu'est-ce que la « fatigue MFA » (bombardement par poussée) ? - 21 juillet 2026