Rapports forensiques DMARC (RUF) et vie privée : ce qu'il faut savoir

Implications RGPD

Pour qui décide de recevoir et d'exploiter des RUF, voici les points de conformité à considérer :

Base légale. Les en-têtes d'email contiennent des données personnelles (adresses email, métadonnées de messages). Le traitement de ces données nécessite une base légale au sens du RGPD — typiquement l'intérêt légitime (sécurité du système d'information), à documenter dans le registre RGPD.

Minimisation des données. Les RUF servent uniquement au diagnostic de sécurité, pas à d'autres usages. Leur conservation se limite à ce qui est nécessaire (quelques jours à quelques semaines suffisent pour un diagnostic).

Transmission à des tiers. Transmettre des RUF à une plateforme DMARC tierce fait de cette plateforme un sous-traitant au sens du RGPD — un DPA (Data Processing Agreement) doit être en place et la plateforme doit respecter les exigences de sécurité du responsable de traitement.

Registre RGPD. Un traitement de RUF s'ajoute au registre RGPD (art. 30) : finalité (sécurité email), catégorie de données (en-têtes, adresses email), durée de conservation, base légale.

Chiffrement et isolation. Les RUF ne doivent pas se retrouver dans une boîte partagée ou accessible à des personnes sans besoin de les consulter. Leur place est une boîte dédiée à accès limité.

La question de l'utilité réelle

Compte tenu des limitations actuelles (peu de FAI qui envoient des RUF) et des contraintes RGPD, la question se pose : est-ce que les RUF valent l'effort ? Pour la grande majorité des déploiements, la réponse est non. Les rapports agrégés (RUA) donnent tout le nécessaire pour identifier et corriger les sources : IPs, résultats d'authentification, volume. Les RUF apportent un détail sur un message individuel souvent inexploitable (le FAI en question n'en envoie peut-être pas).

Les cas où les RUF gardent une utilité réelle : le diagnostic d'un type précis de message qui échoue, avec confirmation que le FAI concerné envoie bien des RUF ; ou un contexte d'infrastructure de messagerie maîtrisée de bout en bout, où l'organisation s'envoie des RUF à elle-même.

Comment configurer (ou ne pas configurer) ruf=

Renoncer aux RUF — la recommandation pour la plupart des cas — revient à omettre simplement ruf= et fo= de l'enregistrement. Un enregistrement DMARC fonctionne parfaitement avec seulement rua= :

_dmarc.exemple.fr.  IN TXT
  "v=DMARC1; p=reject; rua=mailto:dmarc@exemple.fr"

Pour utiliser les RUF, la balise à ajouter est :

ruf=mailto:ruf@exemple.fr; fo=1

fo=1 génère un RUF dès qu'un check échoue — c'est la valeur la plus informative mais aussi la plus volumineuse. fo=0 (défaut) ne génère un RUF que si tous les checks échouent — moins de volume, moins d'information.

Un dernier réflexe d'hygiène : auditer l'existant. Beaucoup de domaines traînent un ruf= posé il y a des années, pointant vers une boîte que plus personne ne lit — voire vers l'adresse d'un ancien salarié ou d'un outil tiers résilié depuis. C'est le pire des deux mondes : aucune valeur diagnostique n'en est tirée, mais des données personnelles continuent de s'accumuler dans une boîte sans propriétaire, sans durée de conservation maîtrisée, parfois hors du contrôle de l'organisation. Au regard du RGPD, c'est un traitement orphelin — collecté sans finalité active ni responsable identifié. D'où la vérification de ce que l'enregistrement DMARC déclare réellement aujourd'hui : si l'adresse ruf= ne correspond plus à un destinataire actif et légitime, la balise est à retirer — c'est la correction la plus rapide de tout ce guide.

Questions fréquentes

Google envoie-t-il encore des RUF ? Non, Google a arrêté l'envoi de rapports forensiques. La plupart des RUF reçus aujourd'hui proviennent d'acteurs moins connus.

Les RUF sont-ils dangereux pour la vie privée ? Potentiellement, selon leur contenu. Ils peuvent révéler des adresses email, des sujets de message, et des routes d'envoi. Ils demandent autant de soin que toute autre donnée sensible.

Dois-je mettre fo= dans mon enregistrement ? Uniquement en présence d'un ruf=. Sans ruf=, la balise fo= n'a aucun effet. Et sans ruf=, il n'y a rien à configurer.

Un outil DMARC tiers peut-il recevoir mes RUF ? Oui, via un ruf=mailto:adresse@outil-tiers.com. Encore faut-il que l'outil ait signé un DPA (accord de traitement de données) et que ses conditions de traitement correspondent aux exigences RGPD du responsable de traitement.

Comment savoir si je reçois des RUF ? En regardant la boîte ruf= : les RUF arrivent avec un objet distinct des RUA, souvent en tant que fichiers texte MIME (pas du XML comme les RUA, mais du message/feedback-report).

Les RUF sont-ils couverts par une durée de conservation RGPD spécifique ? Non — il n'y a pas de durée légalement imposée pour les RUF en tant que tels. En pratique, la minimisation des données (principe RGPD) suggère de ne les garder que le temps du diagnostic, soit quelques jours à quelques semaines. Au-delà, ils sont à effacer ou à anonymiser. C'est d'autant plus important dans une boîte email partagée.

Puis-je désactiver les RUF si j'en ai déjà configuré ? Oui. Il suffit de retirer ruf= et fo= de l'enregistrement DMARC — les FAI qui lisent l'enregistrement régulièrement cesseront d'en envoyer. La propagation DNS s'applique, mais en 24-48h il n'en arrive plus de nouveaux.

Les RUF donnent-ils accès aux messages des destinataires ou des expéditeurs ? Uniquement des expéditeurs (les messages qui ont échoué à passer DMARC depuis le domaine ou en prétendant en venir). Un RUF ne contient jamais le contenu d'un message entrant adressé à l'un des utilisateurs du domaine — il porte sur les messages qui ont utilisé son From: de façon non conforme, légitimement ou non. C'est une distinction importante pour évaluer le risque vie privée réel : le risque porte sur les expéditeurs du domaine lui-même (les utilisateurs qui envoient via des chemins mal configurés), pas sur les destinataires externes.

La situation concrète en 2025-2026

La réalité du marché a largement tranché la question des RUF. Depuis que Google a cessé d'en envoyer en 2023, la couverture des RUF s'est effondrée : les grands FAI qui représentent l'essentiel du trafic email mondial ne les envoient plus. Ce qu'un ruf= fait arriver aujourd'hui provient principalement de petits fournisseurs ou de serveurs auto-hébergés, souvent une minorité du trafic total.

Cette réalité opérationnelle rend les RUF peu exploitables pour la grande majorité des déploiements : aucun RUF n'arrive sur les messages qui échouent chez Gmail (les destinataires les plus nombreux), ce qui limite la valeur diagnostique. En revanche, dans une organisation qui envoie principalement vers des serveurs internes (messagerie d'entreprise à d'autres serveurs d'entreprise), ou pour un test en environnement maîtrisé, les RUF peuvent encore avoir leur utilité.

RUF dans DMARCbis (RFC 9990)

DMARCbis — la nouvelle version de DMARC définie par les RFC 9989/9990/9991 — traite les rapports forensiques dans la RFC 9990, distincte de la RFC 9989 qui définit le protocole lui-même. La RFC 9990 reconnaît explicitement les problèmes vie privée liés aux RUF et ne renforce pas leur utilisation — elle précise au contraire que les implémentations PEUVENT choisir de ne pas les émettre. C'est une reconnaissance officielle de l'état actuel du marché. Lors d'une migration vers DMARCbis (voir migrer vers ce nouveau standard), la stratégie RUF peut rester inchangée ou disparaître complètement.

Thomas gère les rapports

Qu'il s'agisse de RUA, de RUF ou des deux, Thomas, le RSSI virtuel, s'occupe de la lecture, du diagnostic et du plan d'action. Aucun XML à ouvrir, aucun email à trier, aucune statistique à calculer — Thomas dit ce qui compte et quoi faire.

Analyser un domaine gratuitement ou créer un compte pour une gestion DMARC complète sans friction.