Un rapport DMARC agrégé (rua) est un fichier XML que les grandes messageries vous envoient chaque jour : il liste chaque serveur qui a envoyé des emails au nom de votre domaine, combien, et si ces emails ont passé SPF, DKIM et DMARC. Le lire permet de repérer trois choses : vos propres services mal configurés, les transferts d'emails, et les usurpations. C'est l'étape indispensable avant de durcir votre politique DMARC sans bloquer vos propres messages.
D'où viennent ces rapports
Quand votre enregistrement DMARC contient une adresse rua, vous demandez aux messageries de vous envoyer un bilan :
v=DMARC1; p=none; rua=mailto:dmarc@votre-domaine.fr
Google, Microsoft, Yahoo et d'autres envoient alors, en général une fois par jour, un fichier XML compressé (.zip ou .gz) à cette adresse. Chaque fichier couvre une période (souvent 24 heures) et une seule messagerie. Avec plusieurs services d'envoi et beaucoup de destinataires, vous recevez vite plusieurs rapports par jour et par domaine.
Ces rapports ne contiennent aucun contenu d'email : seulement des adresses IP, des volumes et des résultats d'authentification.
Anatomie d'un rapport
Voici un extrait réaliste, simplifié, d'un rapport envoyé par une grande messagerie :
<feedback>
<report_metadata>
<org_name>google.com</org_name>
<report_id>1234567890123456789</report_id>
<date_range>
<begin>1791158400</begin>
<end>1791244799</end>
</date_range>
</report_metadata>
<policy_published>
<domain>votre-domaine.fr</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>none</p>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>203.0.113.25</source_ip>
<count>148</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>votre-domaine.fr</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>votre-domaine.fr</domain>
<result>pass</result>
</dkim>
<spf>
<domain>bounces.service-envoi.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>
Les blocs à connaître :
- report_metadata : qui envoie le rapport et pour quelle période. Les dates sont en secondes depuis 1970 (horodatage Unix).
- policy_published : votre enregistrement DMARC tel que la messagerie l'a lu. Vérifiez qu'il correspond à ce que vous croyez avoir publié.
- record : une ligne par serveur d'envoi.
source_ip est l'adresse du serveur, count le nombre d'emails.
- policy_evaluated : le verdict DMARC.
dkim et spf valent pass seulement si le contrôle a réussi et qu'il est aligné sur votre domaine. disposition indique ce que la messagerie a fait du message (none, quarantine, reject).
- auth_results : les résultats bruts, avec le domaine réellement contrôlé.
Dans l'exemple, le SPF passe pour bounces.service-envoi.com, mais ce domaine n'est pas le vôtre : il n'est pas aligné, d'où spf: fail dans le verdict. Le DKIM, lui, est signé par votre-domaine.fr : il est aligné. Un seul des deux suffit, donc DMARC passe. C'est le cas typique d'un service d'envoi correctement configuré avec une signature DKIM à votre nom.
| DKIM aligné | SPF aligné | Source | Ce que c'est | Action |
|---|
| pass | pass | Votre serveur ou service connu | Envoi légitime et bien configuré | Rien |
| pass | fail | Service d'envoi connu | DKIM à votre nom, enveloppe au nom du service | Rien, DMARC passe |
| fail | pass | Service connu | DKIM non activé chez ce service | Activer la signature DKIM à votre nom |
| fail | fail | Service que vous utilisez | Service oublié : absent du SPF, sans DKIM | L'ajouter au SPF et activer DKIM |
| pass | fail | IP inconnue, hébergeur de messagerie tiers | Transfert d'email : le SPF casse, la signature tient | Rien, c'est normal |
| fail | fail | IP inconnue, souvent à l'étranger | Usurpation de votre domaine | C'est ce que quarantine et reject bloqueront |
Pour identifier une IP, faites une recherche inverse ou un WHOIS de l'adresse : le nom de l'hébergeur (Google, Microsoft, Brevo, OVH…) suffit généralement à savoir s'il s'agit d'un de vos services.
Le cas le plus fréquent lors d'un premier examen : un outil oublié. Un logiciel de facturation, un CRM ou un formulaire de site envoie des emails à votre nom sans être déclaré dans le SPF ni signé en DKIM. Tant que vous êtes en p=none, ces emails partent quand même. En quarantine, ils finiraient en spam.
Où recevoir et lire les rapports
Ouvrir les fichiers XML à la main devient vite impossible. Mieux vaut confier l'adresse rua à un service qui les analyse et les présente sous forme de tableau :
- Cloudflare DMARC Management : gratuit pour les domaines dont le DNS est chez Cloudflare.
- Brevo : propose une adresse de réception des rapports à ses clients.
- Services dédiés : plusieurs éditeurs spécialisés analysent les rapports, avec des offres gratuites limitées.
Vous pouvez indiquer plusieurs destinataires, séparés par une virgule :
rua=mailto:dmarc@votre-domaine.fr,mailto:rapports@service-dmarc.com
Attention si l'adresse de réception est sur un autre domaine que le vôtre. Le domaine qui reçoit doit publier un enregistrement d'autorisation, sinon les messageries n'envoient rien. Pour que votre-domaine.fr envoie ses rapports à une adresse en @service-dmarc.com, ce dernier doit publier :
votre-domaine.fr._report._dmarc.service-dmarc.com TXT "v=DMARC1"
Les services spécialisés publient cette autorisation pour vous. Si vous centralisez les rapports de plusieurs domaines sur une seule boîte, c'est à vous de l'ajouter.
Et les rapports ruf ?
La balise ruf demande des rapports d'échec détaillés, message par message. En pratique, peu de messageries en envoient, et ceux qui arrivent peuvent contenir des extraits d'emails, donc des données personnelles. Pour la plupart des domaines, les rapports agrégés rua suffisent largement.
Quand passer en quarantine
Les rapports servent à prendre cette décision. Vous pouvez durcir votre politique quand :
- Tous vos services d'envoi apparaissent avec DMARC en
pass, sur au moins une ou deux semaines de rapports.
- Les lignes en échec restantes sont des usurpations ou des transferts.
- Vous avez vérifié les envois rares : relances mensuelles, factures, newsletters ponctuelles.
Passez alors en p=quarantine, éventuellement avec pct=25 pour commencer, puis en p=reject. Continuez à lire les rapports après chaque étape : un nouvel outil ajouté plus tard apparaîtra d'abord ici. Le générateur DMARC vous aide à écrire l'enregistrement, et notre article « n'importe qui peut écrire en ton nom » : que faire ? détaille la démarche complète.
Questions fréquentes
Pourquoi je ne reçois aucun rapport DMARC ?
Vérifiez que l'enregistrement contient bien rua=mailto: avec une adresse valide. Si l'adresse est sur un autre domaine, l'enregistrement d'autorisation _report._dmarc doit exister. Enfin, un domaine qui envoie très peu d'emails peut ne recevoir que de rares rapports.
Les rapports DMARC contiennent-ils le contenu des emails ?
Non. Les rapports agrégés ne contiennent que des adresses IP, des volumes et des résultats d'authentification. Seuls les rapports d'échec (ruf), rarement envoyés, peuvent inclure des extraits de messages.
Une IP inconnue en échec, est-ce forcément une attaque ?
Non. Ce peut être un transfert automatique chez un destinataire, une liste de diffusion qui modifie les messages, ou un service que vous avez oublié. Identifiez l'hébergeur de l'IP avant de conclure. Si DKIM passe, c'est presque toujours un transfert.
Combien de temps lire les rapports avant de durcir DMARC ?
Une à deux semaines suffisent pour la plupart des domaines. Prolongez si vous avez des envois mensuels ou saisonniers, pour les voir passer au moins une fois. Pour le cadre général, voir les exigences DMARC de Google, Yahoo et Microsoft.