Rapports DMARC : RUA vs RUF, quelle différence ?

Quand tu publies un enregistrement DMARC, tu peux demander à recevoir des rapports sur l'authentification de tes emails. Mais il y a deux types de rapports très différents : les RUA (rapports agrégés) et les RUF (rapports forensiques). La confusion entre les deux est courante, et mal choisir peut t'envoyer soit trop peu d'information pour diagnostiquer, soit trop — avec des risques vie privée. Ce guide explique la différence, ce que contient chacun, et comment les configurer.

Les RUA : rapports agrégés, les statistiques de vol

Les rapports RUA (Reporting URI for Aggregate) sont envoyés par les FAI et les grands fournisseurs de messagerie (Gmail, Yahoo, Outlook…) à l'adresse email que tu indiques. Ils récapitulent, pour chaque expéditeur, les résultats d'authentification observés sur une période (souvent 24h) : combien de messages ont passé SPF, DKIM, DMARC, depuis quelle IP, avec quel résultat.

Ce sont des fichiers XML compressés, envoyés quotidiennement par chaque destinataire qui choisit d'en envoyer. Un rapport RUA typique dit quelque chose comme : « 347 messages depuis l'IP 40.107.1.25, avec spf=pass, dkim=pass, dmarc=pass — et 12 messages depuis 192.0.2.1 avec spf=fail, dkim=fail, dmarc=fail. »

Ils ne contiennent aucun contenu de message : pas d'objet, pas de corps, pas de destinataire. C'est uniquement des métadonnées statistiques. C'est pour ça que les RUA sont à la fois utiles (vision globale) et conformes RGPD (pas de données personnelles des destinataires).

Les RUF : rapports forensiques, le détail d'un échec

Les rapports RUF (Reporting URI for Forensic) sont d'une toute autre nature. Envoyés également à une adresse que tu choisis, ils sont déclenchés par un événement individuel : un message qui a échoué à l'authentification. Chaque rapport RUF décrit cet échec en détail, et selon l'implémentation du destinataire, peut inclure des en-têtes complets du message, voire parfois un extrait du corps.

C'est beaucoup plus granulaire — et beaucoup plus sensible. Un rapport RUF peut contenir l'adresse email de l'expéditeur, le sujet, l'IP d'origine, et d'autres métadonnées de l'email qui a échoué. C'est utile pour diagnostiquer un problème précis (pourquoi ce message spécifique a-t-il échoué ?), mais ça soulève des questions sérieuses de vie privée et de conformité RGPD — en particulier si l'email qui a échoué provenait d'un vrai utilisateur (voir rapports forensiques et vie privée).

Autre réalité : la plupart des grands fournisseurs (Google, Microsoft, Yahoo) n'envoient plus de RUF. La prise en charge des rapports forensiques est bien moins universelle que celle des RUA. Dans la pratique, tu reçois des RUA de presque tout le monde, et des RUF seulement de quelques acteurs.

Configurer RUA et RUF dans ton enregistrement DMARC

Les deux adresses se configurent dans ton enregistrement _dmarc :

_dmarc.ton-domaine.fr.  IN TXT
  "v=DMARC1; p=quarantine; rua=mailto:dmarc@ton-domaine.fr;
   ruf=mailto:ruf@ton-domaine.fr; fo=1"

• rua= : l'adresse où tu veux recevoir les rapports agrégés. Tu peux en mettre plusieurs, séparées par des virgules.
• ruf= : l'adresse pour les rapports forensiques. Souvent différente, parfois absente.
• fo= : contrôle quand un RUF est généré. fo=0 (défaut) = seulement si toutes les vérifications échouent. fo=1 = dès qu'une vérification échoue. fo=d = uniquement si DKIM échoue. fo=s = uniquement si SPF échoue. En pratique, fo=1 donne le plus de détail, mais aussi le plus de volume.

Si tu ne veux pas de RUF (par choix de conformité, ou parce que tu ne les exploites pas), omets simplement ruf= et fo=. Le rapport agrégé (RUA) est la vraie valeur — le RUF est un complément pour des diagnostics spécifiques.

Ce que tu devrais faire en pratique

Pour la grande majorité des déploiements, les RUA suffisent largement. Ils donnent une vision complète de qui envoie en ton nom, avec quels résultats, depuis quelles IP — exactement ce qu'il faut pour progresser vers p=reject. Les analyser régulièrement (ou les faire analyser par un outil ou par Thomas) te dit quelles sources corriger, dans quel ordre, et quand tu es prêt à durcir ta politique.

Les RUF sont utiles si tu dois diagnostiquer un problème très spécifique : un type de message particulier qui échoue, une source inconnue qui envoie en ton nom. Mais ouvre-les seulement en connaissance de leur contenu potentiellement sensible, et surtout ne les transmets pas à des tiers sans vérifier ce qu'ils contiennent.

Le bon réflexe au démarrage : configure un rua= vers une boîte dédiée (ou une plateforme DMARC), laisse les rapports arriver quelques jours, et lis-les. Le diagnostic de qui envoie en ton nom y est presque entier.

Qui envoie des rapports RUA

Les grands acteurs envoient des RUA de manière fiable : Gmail, Outlook/Microsoft, Yahoo, Apple Mail, AOL, ProtonMail, et beaucoup d'autres. Ce n'est pas exhaustif — seuls les acteurs qui ont implémenté le protocole envoient des rapports — mais en pratique, les rapports reçus couvrent la grande majorité du trafic email mondial. Si tu envoies des emails en volume, tu auras rapidement suffisamment de données pour diagnostiquer.

Note : les RUA ne couvrent que le trafic vers les boîtes des fournisseurs qui les envoient. Si tu envoies à des serveurs auto-hébergés ou à des petits fournisseurs, ces résultats n'apparaissent pas dans tes rapports.

Questions fréquentes

Dois-je configurer ruf= ? Non. Les RUA suffisent pour la quasi-totalité des cas. Configure ruf= seulement si tu as un besoin de diagnostic forensique précis et que tu as évalué les implications vie privée.

Combien de temps avant de recevoir des rapports ? Quelques heures à 24h après publication de ton enregistrement DMARC. Les premiers rapports arrivent souvent le lendemain matin. Ils couvrent la période précédente.

Les rapports arrivent-ils de tous les destinataires ? Non. Seulement des acteurs qui ont implémenté le protocole. Gmail et Microsoft envoient des rapports très fiables ; beaucoup de petits serveurs n'en envoient pas.

Est-ce que les RUA exposent des données personnelles ? Non : les rapports agrégés contiennent des statistiques et des IP, mais pas le contenu des messages ni les adresses des destinataires. Les RUF, eux, peuvent en contenir — c'est pour ça qu'ils sont à manier avec précaution.

Puis-je recevoir les rapports sur une adresse externe ? Oui, mais il faut que le domaine de l'adresse de réception soit autorisé via un enregistrement TXT à _dmarc.domaine-externe.fr (pour éviter que n'importe qui puisse envoyer ses rapports à n'importe quelle boîte). Si l'adresse est dans ton propre domaine, c'est automatique.

Comment les rapports t'aident à progresser vers p=reject

La valeur principale des rapports DMARC n'est pas de confirmer que tes emails passent — c'est de te montrer comment les faire passer. Un rapport RUA est en réalité une carte de tes flux d'envoi : chaque bloc <record> est une source, et le résultat d'authentification de cette source te dit exactement ce qu'il faut corriger. Le processus est itératif par nature.

Au départ, avec p=none, tu reçois des rapports sans que rien ne soit bloqué. C'est la phase d'observation : tu découvres quelles IPs envoient en ton nom, lesquelles passent, lesquelles échouent, et lesquelles tu ne reconnaissais même pas. Tu corriges les sources légitimes une par une — en activant DKIM, en alignant SPF, en excluant les sources inconnues — et tu surveilles les rapports pour confirmer que chaque correction a bien pris.

Une fois que tes rapports montrent que la grande majorité de tes sources légitimes passent (typiquement >95%), tu passes à p=quarantine. La même logique s'applique : surveille les rapports, vérifie qu'aucune source légitime n'est impactée, affine. Puis tu montes à p=reject. À chaque étape, les rapports RUA sont ton instrument de mesure : ils te disent où tu en es, pas juste si ça passe ou ça casse.

La subtilité : un rapport qui montre dmarc=fail sur une IP n'est pas forcément un problème. Si c'est une IP que tu ne reconnais pas, peut-être est-ce de la contrefaçon (quelqu'un essaie d'usurper ton domaine) — et ton p=reject l'en empêchera. Si c'est une IP que tu reconnais comme une source légitime mal configurée, c'est quelque chose à corriger. Distinguer les deux est l'essentiel du travail d'interprétation que les rapports rendent possible.

Identifier les sources dans tes rapports

Un rapport brut te donne une IP. Un rapport bien exploité te dit à qui appartient cette IP. C'est cette conversion — IP → service d'envoi identifié — qui transforme un rapport en plan d'action. Les outils DMARC font ce travail automatiquement (voir les outils pour analyser les rapports), mais tu peux aussi le faire manuellement pour quelques IPs clés via des outils de résolution inverse.

Les IPs récurrentes avec dkim=pass, spf=pass, dmarc=pass sont tes sources bien configurées — ne les touche pas. Les IPs récurrentes avec des échecs sur une source que tu reconnais sont tes priorités de correction. Les IPs inconnues avec dmarc=fail sont soit de la contrefaçon (aucune action de ta part, laisse p=reject faire son travail), soit une source légitime que tu avais oubliée (à corriger ou à confirmer comme éteinte).

Laisse Thomas lire tes rapports pour toi

Recevoir des rapports RUA, c'est une chose ; les exploiter en est une autre. Thomas, ton RSSI virtuel, lit tes rapports à ta place, te dit quelles sources passent, lesquelles échouent, pourquoi, et dans quel ordre les corriger. Il transforme un XML brut en plan d'action clair vers p=reject.

Analyse ton domaine gratuitement → ou crée un compte pour des rapports DMARC décodés automatiquement.