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

La RFC 9991 (voie normative, mai 2026 ; elle fait partie de l’ensemble 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) définit les rapports d’échec (souvent appelés « rapports forensiques », forensic reports) : des rapports par message, envoyés lorsqu’un message précis échoue à DMARC, par opposition aux rapports agrégés statistiques quotidiens.

Ils ont deux usages : diagnostiquer des échecs d’authentification individuels repérés d’abord dans les données agrégées, et faire apparaître rapidement une usurpation active du domaine.

Déclenchement : les balises ruf et fo

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

Balise Rôle
ruf= URI mailto: séparées par des virgules, qui reçoivent les rapports d’échec. Des tentatives de livraison doivent être faites vers toutes les destinations listées. Les destinations externes doivent être vérifiées exactement comme pour les rapports agrégés (<policy-domain>._report._dmarc.<destination-host>).
fo= Quand envoyer un rapport : 0 (par défaut) = uniquement si aucun mécanisme n’a produit de pass aligné ; 1 = si un mécanisme quelconque a échoué ; d = à tout échec DKIM, quel que soit l’alignement ; s = à 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 » : 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, type de feedback auth-failure), avec des champs supplémentaires propres à DMARC :

Champ Obligatoire ? Contenu
Identity-Alignment Obligatoire 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 intègre généralement les en-têtes (et parfois le corps) du message en échec, 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 : adresses de l’expéditeur et du destinataire, contenu du message et, pour le trafic des listes de diffusion, la composition de la liste. La RFC 9991 demande aux générateurs de rapports :

  • de limiter leur portée à des diagnostics ciblés plutôt qu’à un flux systématique ;
  • 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 à une couverture clairsemée : les rapports agrégés sont le signal fiable ; les rapports d’échec sont un complément de détail quand ils arrivent.

Sécurité

Les rapports d’échec créent un vecteur de déni de service par inondation de rapports : un attaquant qui envoie en masse du courrier usurpé « provenant » d’un domaine victime peut amener les serveurs de réception à bombarder la boîte ruf de la victime. Mesures exigées des générateurs : regrouper les événements liés (le champ ARF Incidents) et limiter 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 vue 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.
  • Dirigez ruf= vers une boîte aux lettres à accès restreint : les rapports peuvent contenir le contenu de messages de tiers.
  • Ne bâtissez pas votre surveillance sur les seuls rapports d’échec ; leur couverture dépend des serveurs de réception et penche vers les 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 →