emailmarketing.net
EnglishFrançais

Rapports d’échec DMARC (RFC 9991)

Les rapports d’échec DMARC par message (rapports « forensiques ») : format ARF, champs obligatoires, balises ruf et fo, contraintes de vie privée, et pourquoi peu de fournisseurs en envoient.

Référence4 min de lecture

À qui cela s’adresse Opérateurs ESP, Expéditeurs

S’applique aux expéditeurs, quelle que soit leur plateforme

SommaireSur cette page : 6 sections

Lorsque vos rapports DMARC agrégés montrent qu’une source échoue, un rapport d’échec peut vous montrer un message précis en échec, pour que vous voyiez pourquoi il a échoué. Lorsque l’enregistrement DMARC de votre domaine indique une adresse pour les rapports d’échec, les serveurs de réception peuvent envoyer à cette adresse un rapport chaque fois qu’un message précis échoue à DMARC. Ces rapports d’échec sont souvent appelés « rapports forensiques » (forensic reports), et ils diffèrent des rapports agrégés statistiques quotidiens.

La RFC 9991 les définit. C’est une spécification de la voie normative publiée en mai 2026, et l’un des documents DMARCbis, avec la RFC 9989 et la RFC 9990. Elle met à jour la RFC 6591 et remplace la partie de la RFC 7489 consacrée aux rapports d’échec.

Les rapports d’échec ont deux usages : diagnostiquer des échecs d’authentification individuels repérés d’abord dans les données agrégées, et révéler rapidement qu’une personne abuse directement et activement de votre domaine.

Déclenchement : les balises ruf et fo

Ces balises se configurent dans l’enregistrement DMARC du domaine (voir le registre des balises) :

Balise Rôle
ruf= Une liste d’URI mailto: séparées par des virgules, qui reçoivent les rapports d’échec. Le serveur de réception doit tenter la livraison vers chaque destination listée. Les destinations externes doivent être vérifiées de la même manière que pour les rapports agrégés (<policy-domain>._report._dmarc.<destination-host>).
fo= Quand envoyer un rapport. 0 (la valeur par défaut) signifie uniquement lorsque aucun mécanisme n’a produit de réussite alignée. 1 signifie lorsque un mécanisme quelconque a échoué. d signifie à tout échec DKIM, quel que soit l’alignement. s signifie à tout échec SPF, quel que soit l’alignement. Les valeurs peuvent être combinées, séparées par des deux-points (par exemple, fo=1:d:s).

Les rapports sont « normalement générés et envoyés presque immédiatement après que le serveur de réception a détecté un échec DMARC ». Ils arrivent quasiment en temps réel, contrairement aux rapports agrégés quotidiens.

Format des rapports

Les rapports d’échec utilisent l’Abuse Reporting Format (ARF) de la RFC 6591 (message/feedback-report, avec le type de feedback auth-failure), avec des champs ajoutés pour DMARC :

Champ Obligatoire ? Contenu
Identity-Alignment Obligatoire Une liste, séparée par des virgules, des mécanismes qui ont échoué à l’alignement : dkim, spf ou none.
DKIM-Domain, DKIM-Identity, DKIM-Selector Obligatoires pour les échecs DKIM La signature qui a échoué (d=, i=, s=).
SPF-DNS Obligatoire pour les échecs SPF L’enregistrement DNS SPF concerné.
Delivery-Result Facultatif Ce que le serveur de réception a fait du message.
DKIM-Canonicalized-Header, DKIM-Canonicalized-Body Facultatifs Les formes canonicalisées, pour déboguer une signature cassée.

Le rapport contient généralement les en-têtes du message en échec, et parfois son corps. C’est ce qui rend ce format à la fois utile et sensible pour la vie privée.

Vie privée

Les rapports d’échec peuvent exposer des données personnelles : les adresses de l’expéditeur et du destinataire, le contenu du message et, pour le trafic des listes de diffusion, les membres de la liste. La RFC 9991 demande aux générateurs de rapports :

  • de limiter les rapports à des diagnostics ciblés plutôt que de tout envoyer ;
  • de valider soigneusement les URI de rapport (vérification des destinations externes) ;
  • de caviarder le contenu des messages et les identifiants ;
  • d’utiliser des canaux de transmission sécurisés.

Dans la pratique, la plupart des grands fournisseurs de messagerie n’envoient aucun rapport d’échec, ou en envoient de fortement caviardés, précisément à cause de ces risques pour la vie privée. Publier ruf= ne coûte rien, mais attendez-vous à recevoir peu de rapports. Les rapports agrégés sont le signal fiable, et les rapports d’échec ajoutent du détail quand vous en recevez.

Sécurité

Les rapports d’échec peuvent servir à une attaque par déni de service qui inonde une boîte aux lettres de rapports. Un attaquant qui envoie en masse du courrier usurpé « provenant » du domaine d’une victime peut amener les serveurs de réception à bombarder la boîte ruf de la victime. Les générateurs sont tenus de réduire ce risque en regroupant les événements liés (le champ ARF Incidents) et en limitant le débit (un nombre maximal de rapports par unité de temps).

Usage opérationnel

  • Servez-vous des rapports d’échec pour comprendre pourquoi une source en échec dans les données agrégées échoue : un mauvais sélecteur, une signature cassée par une passerelle qui ajoute un pied de page (comparez les champs canonicalisés), un domaine de rebond non aligné, etc.
  • Envoyez les rapports ruf= vers une boîte aux lettres à accès restreint, car les rapports peuvent contenir le contenu de messages d’autres personnes.
  • Ne bâtissez pas votre surveillance sur les seuls rapports d’échec. Leur couverture dépend du serveur de réception, et ils proviennent surtout de petits fournisseurs.

Voir aussi

Vérifier votre propre enregistrement

Le diagnostic gratuit lit ce que votre domaine publie dans le DNS.

Dans ce thème

Les 13 articles du thème Authentification →