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

Configurer RUA et RUF dans l'enregistrement DMARC

Les deux adresses se configurent dans l'enregistrement _dmarc :

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

• rua= : l'adresse de réception des rapports agrégés. Plusieurs sont possibles, 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.

Pour se passer de RUF (par choix de conformité, ou parce qu'ils ne sont de toute façon pas exploités), il suffit d'omettre ruf= et fo=. Le rapport agrégé (RUA) est la vraie valeur — le RUF est un complément pour des diagnostics spécifiques.

Ce qu'il convient de faire en pratique

Pour la grande majorité des déploiements, les RUA suffisent largement. Ils donnent une vision complète de qui envoie au nom du domaine, 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) révèle quelles sources corriger, dans quel ordre, et à quel moment la politique peut être durcie.

Les RUF sont utiles pour diagnostiquer un problème très spécifique : un type de message particulier qui échoue, une source inconnue qui émet au nom du domaine. Mais ils ne s'ouvrent qu'en connaissance de leur contenu potentiellement sensible, et surtout ne se transmettent pas à des tiers sans vérification de ce qu'ils contiennent.

Le bon réflexe au démarrage : configurer un rua= vers une boîte dédiée (ou une plateforme DMARC), laisser les rapports arriver quelques jours, et les lire. Le diagnostic de qui émet au nom du domaine 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. Un domaine qui envoie en volume dispose rapidement de suffisamment de données pour diagnostiquer.

Note : les RUA ne couvrent que le trafic vers les boîtes des fournisseurs qui les envoient. Le courrier adressé à des serveurs auto-hébergés ou à de petits fournisseurs, lui, n'apparaît nulle part dans les rapports reçus.

Questions fréquentes

Dois-je configurer ruf= ? Non. Les RUA suffisent pour la quasi-totalité des cas. ruf= ne se configure qu'en cas de besoin de diagnostic forensique précis, et une fois les implications vie privée évaluées.

Combien de temps avant les premiers rapports ? Quelques heures à 24h après publication de l'enregistrement DMARC. Les premiers 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 le domaine lui-même, c'est automatique.

Comment les rapports mènent à p=reject

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

Au départ, avec p=none, les rapports arrivent sans que rien ne soit bloqué. C'est la phase d'observation : elle révèle quelles IPs envoient au nom du domaine, lesquelles passent, lesquelles échouent, et lesquelles n'étaient même pas identifiées. Les sources légitimes se corrigent une par une — en activant DKIM, en alignant SPF, en excluant les sources inconnues — et les rapports confirment que chaque correction a bien pris.

Une fois que les rapports montrent que la grande majorité des sources légitimes passent (typiquement >95%), vient p=quarantine. La même logique s'applique : surveiller les rapports, vérifier qu'aucune source légitime n'est impactée, affiner. Puis monter à p=reject. À chaque étape, les rapports RUA sont l'instrument de mesure : ils disent où en est le déploiement, 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. S'il s'agit d'une IP non reconnue, peut-être est-ce de la contrefaçon (quelqu'un essaie d'usurper le domaine) — et le p=reject l'en empêchera. S'il s'agit d'une IP identifiée 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 les rapports

Un rapport brut donne une IP. Un rapport bien exploité 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 l'opération reste faisable à la main pour quelques IPs clés via des outils de résolution inverse.

Les IPs récurrentes avec dkim=pass, spf=pass, dmarc=pass sont les sources bien configurées — à ne pas toucher. Les IPs récurrentes qui échouent sur une source pourtant identifiée sont les priorités de correction. Les IPs inconnues avec dmarc=fail sont soit de la contrefaçon (aucune action à mener, p=reject fait son travail), soit une source légitime oubliée (à corriger ou à confirmer comme éteinte).

Thomas lit les rapports

Recevoir des rapports RUA, c'est une chose ; les exploiter en est une autre. Thomas, le RSSI virtuel, lit les rapports à la place de l'équipe, indique 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.

Analyser un domaine gratuitement ou créer un compte pour des rapports DMARC décodés automatiquement.