Configurer l'adresse rua de DMARC (sans se faire piéger)

v=DMARC1; p=none; rua=mailto:dmarc@exemple.fr

v=DMARC1; p=none; rua=mailto:dmarc@exemple.fr,mailto:rapports@prestataire-analyse.com

Le piège : l'autorisation de destination externe

Voici la règle que beaucoup ignorent : envoyer les rapports DMARC vers une adresse d'un autre domaine que le domaine émetteur exige une autorisation explicite, publiée côté domaine récepteur.

Pourquoi ? Pour éviter l'abus. Sans cette règle, n'importe qui pourrait publier rua=mailto:victime@autre-domaine.fr et faire déverser des rapports (potentiellement volumineux) sur un tiers non consentant. DMARC impose donc au domaine récepteur de déclarer qu'il accepte de recevoir les rapports d'un autre domaine.

Concrètement, si exemple.fr envoie ses rapports à dmarc@prestataire.com, alors le domaine prestataire.com doit publier un enregistrement TXT sur ce nom précis :

exemple.fr._report._dmarc.prestataire.com  IN TXT  "v=DMARC1"

Sans cet enregistrement d'autorisation côté prestataire.com, les destinataires refusent d'envoyer les rapports à cette adresse externe — d'où de longues heures passées à chercher pourquoi rien n'arrive. Les services d'analyse DMARC sérieux gèrent cette autorisation automatiquement (ils fournissent l'enregistrement à publier, ou l'hébergent de leur côté). Mais une redirection maison bricolée vers un second domaine interne oblige à la poser soi-même.

À l'inverse, tant que rua pointe vers une adresse du domaine lui-même, aucune autorisation n'est nécessaire — c'est pourquoi commencer avec dmarc@exemple.fr est le chemin le plus simple.

Boîte mail dédiée ou service d'analyse ?

Une fois les rapports qui affluent, la question suivante est : qu'en faire ? Deux options.

• Une boîte dédiée. rua pointe vers dmarc@exemple.fr et les XML se lisent à la main. Viable pour un petit domaine à faible volume, mais vite ingérable : les rapports sont nombreux, compressés, et pénibles à agréger manuellement. C'est un bon point de départ pour comprendre, pas pour exploiter dans la durée.
• Un service d'analyse. rua pointe (ou copie) vers une plateforme qui ingère le XML et le restitue en tableaux de bord — sources d'envoi, taux d'alignement, évolution. C'est le choix réaliste dès que le volume grimpe. Les outils du marché sont comparés dans comment lire un rapport DMARC : outils & méthode.

Quelle que soit l'option retenue, un point reste vrai : les rapports agrégés ne contiennent aucun contenu de message — uniquement des métadonnées statistiques — ce qui les rend exploitables sans souci de confidentialité, contrairement aux rapports forensiques (ruf, voir RUA vs RUF).

Le volume à prévoir

L'affluence a de quoi surprendre. Chaque grand destinataire (Gmail, Yahoo, Outlook, et des dizaines d'autres) émet un rapport par jour dès qu'il reçoit du courrier prétendant venir du domaine. Pour un domaine actif, cela représente facilement plusieurs dizaines de fichiers quotidiens. C'est précisément pour cela qu'une adresse dédiée, et à terme un outil d'agrégation, valent mieux qu'une boîte personnelle noyée. Et ce volume est une bonne nouvelle déguisée : plus les rapports affluent, plus la vision de qui envoie au nom du domaine est complète — chaque fichier est un fournisseur de messagerie qui raconte ce qu'il a vu passer.

Réglages optionnels : ri et taille

Deux options avancées existent, rarement nécessaires au départ :

• ri= fixe l'intervalle souhaité entre deux rapports agrégés, en secondes (par défaut 86400, soit 24 h). Les destinataires ne sont pas tenus de l'honorer finement ; en pratique, le rythme quotidien domine. Le sujet est traité dans l'intervalle de reporting DMARC.
• La taille maximale. Une URI peut être suffixée d'un ! suivi d'une taille (ex. mailto:dmarc@exemple.fr!10m) pour demander de ne pas dépasser 10 Mo par rapport. Utile pour de très gros domaines ; superflu pour la plupart.

L'enregistrement gagne à rester simple au démarrage : p, rua, et les balises de sous-domaine suffisent. Les options fines s'ajoutent seulement quand un besoin concret se manifeste. Dans la pratique, la quasi-totalité des domaines vivent très bien sans jamais toucher à ri ni à la taille maximale : les destinataires appliquent leurs propres réglages par défaut, largement raisonnables, et s'encombrer de ces balises n'apporte le plus souvent qu'un enregistrement plus long à relire et à maintenir.

Décoder l'enregistrement d'autorisation externe

Comme cet enregistrement _report._dmarc est la source de la plupart des « je ne reçois rien », détaillons-le, car sa structure déroute au premier abord. Le nom complet à publier se lit de gauche à droite comme une phrase : « le domaine émetteur ._report._dmarc. le domaine récepteur ». Dans notre exemple, exemple.fr._report._dmarc.prestataire.com signifie littéralement : « prestataire.com déclare accepter de recevoir les rapports DMARC destinés à exemple.fr. »

La valeur, elle, est minimale : "v=DMARC1" suffit dans la plupart des cas. C'est un simple drapeau de consentement, pas une politique complète. Deux subtilités valent d'être connues :

• L'autorisation vit chez le récepteur, pas chez l'émetteur. C'est une source de confusion majeure : une zone DNS parfaitement maîtrisée côté émetteur ne sert à rien si le domaine de destination ne publie pas son enregistrement d'autorisation. C'est pour ça que déléguer le reporting à un prestataire qui « gère tout » lève l'ambiguïté — l'autorisation est de son côté, et il sait la poser.
• Un joker existe. Un récepteur peut publier une autorisation générique (*._report._dmarc.prestataire.com) pour accepter les rapports de n'importe quel domaine émetteur. Les grandes plateformes d'analyse s'en servent pour ne pas avoir à créer un enregistrement par client. Côté émetteur, rien à faire ; c'est surtout utile à reconnaître lors de l'audit d'une configuration existante.

Pourquoi une adresse dédiée, dès le premier jour

Beaucoup dirigent d'abord rua vers leur adresse habituelle « le temps de voir », puis le regrettent. Trois raisons de créer d'emblée une adresse dédiée du type dmarc@exemple.fr :

• Le volume. Comme vu plus haut, un domaine actif reçoit des dizaines de rapports par jour. Dans une boîte personnelle, ils noient le courrier utile ; dans une boîte dédiée, ils s'accumulent sans gêne, prêts à être traités au moment choisi.
• La traçabilité. Une adresse dédiée rend le flux de reporting identifiable et auditable — précieux dans un contexte de conformité, où il faut pouvoir montrer où et comment les preuves d'authentification sont collectées.
• La transition en douceur. Le jour du passage d'une lecture manuelle à un service d'analyse, seule la redirection de l'adresse dédiée change, sans toucher à l'enregistrement DMARC ni republier quoi que ce soit dans le DNS.

C'est un investissement de cinq minutes qui évite une migration pénible plus tard.

Changer d'adresse plus tard

Point voisin : changer de rua n'est pas instantané non plus. Les destinataires lisent l'enregistrement au moment où ils génèrent un rapport, et le cache DNS fait que certains verront encore l'ancienne valeur pendant un moment après la publication de la nouvelle. Conséquence pratique : l'ancienne boîte ne se supprime pas le jour de la bascule. Elle reste vivante et surveillée jusqu'à ce que le flux qui lui parvient se tarisse de lui-même, et n'est décommissionnée qu'ensuite. L'administrateur confirme aussi que la nouvelle adresse reçoit réellement avant de considérer la migration terminée — un rapport qui rebondit n'apprend rien au destinataire, et rien de plus à l'émetteur. Traité comme une courte période de recouvrement plutôt qu'une bascule sèche, le changement ne coûte rien et ne perd rien.

Erreurs fréquentes

• Oublier l'autorisation externe. Le piège numéro un : rua pointe vers un autre domaine sans l'enregistrement _report._dmarc correspondant, et aucun rapport n'arrive.
• Diriger rua vers une boîte personnelle. Le volume la submerge et les rapports finissent ignorés. Une adresse dédiée s'impose.
• Confondre rua et ruf. rua = rapports agrégés (statistiques, utiles, sans données perso) ; ruf = forensiques (sensibles, rarement envoyés). C'est rua qu'il faut configurer en priorité.
• Publier rua mais oublier p. L'inverse est plus courant, mais un enregistrement bancal empêche parfois toute la lecture. La syntaxe complète mérite une vérification.

Vérifier que ça marche

Une fois rua en place, la question suivante est légitime : « les rapports arrivent-ils vraiment ? » Si rien n'atterrit après quelques jours, le diagnostic a sa propre méthode — voir je ne reçois pas de rapports DMARC, qui passe en revue toutes les causes possibles, de la syntaxe à l'autorisation externe.

Le plus rapide pour valider la configuration reste de passer le domaine à l'analyseur DMARC gratuit : il confirme que rua est syntaxiquement correct et lisible par les destinataires, avant même que le premier rapport n'atterrisse dans la boîte. C'est la vérification qui évite d'attendre trois jours pour découvrir une faute de frappe. Configurer rua une fois, le valider du dehors, et une politique muette devient un flux de preuves sur lequel il est réellement possible d'agir.