Que sont les rapports DMARC reçus par e-mail

Si votre enregistrement DMARC contient une adresse rua, des fournisseurs comme Google, Microsoft ou Yahoo peuvent envoyer régulièrement des messages avec des objets proches de Report Domain et un fichier XML, généralement compressé en ZIP ou GZIP.

Ce ne sont pas des rebonds. Leur réception ne signifie pas à elle seule qu'il existe un problème ou que le domaine a envoyé du spam : ce sont des rapports agrégés sur les systèmes qui ont livré des messages en utilisant votre domaine et sur le résultat de SPF, DKIM et DMARC. L'IP observée peut appartenir à l'expéditeur d'origine, à un relais ou à un service de redirection ; ne la classez pas comme autorisée ou malveillante sans examiner le parcours et l'alignement.

Contenu du rapport

Le XML regroupe des informations comme :

• l'IP du système qui a livré les messages au destinataire ayant généré le rapport ;
• le nombre de messages observés ;
• le résultat de SPF et DKIM ;
• la politique DMARC appliquée ;
• le domaine visible dans l'en-tête From.

Le résultat brut de SPF ou DKIM n'équivaut pas à lui seul au résultat DMARC. Vérifiez aussi si le domaine authentifié est aligné sur le domaine visible dans From : DMARC réussit lorsqu'il y a alignement en SPF ou en DKIM.

Les rapports agrégés ne contiennent normalement pas le corps complet des messages. Évitez tout de même de publier ces fichiers, car ils contiennent des informations techniques sur vos sources d'envoi.

Différence entre rua et ruf

• rua demande des rapports agrégés et c'est l'option habituelle pour la surveillance.
• ruf demande des rapports d'échec détaillés (forensic). Beaucoup de fournisseurs ne les envoient pas et, lorsqu'ils existent, ils peuvent contenir des en-têtes, des extraits, voire le message d'origine. Ne les activez pas sans définir qui peut y accéder et combien de temps ils seront conservés.

Ne plus les recevoir ou changer de destinataire

Modifiez l'enregistrement TXT de _dmarc.votredomaine.com et changez l'adresse ou supprimez entièrement la balise rua= ou ruf=. Ne supprimez pas tout l'enregistrement DMARC uniquement pour arrêter les rapports : vous supprimeriez aussi la politique qui protège le domaine contre l'usurpation.

Il doit exister un seul enregistrement DMARC. Si vous voulez analyser les XML sans les recevoir dans une boîte mail personnelle, utilisez une adresse dédiée ou un service de traitement des rapports.

Si l'adresse de rua ou ruf appartient à un domaine organisationnel différent de celui qui publie la politique, le domaine destinataire doit autoriser ces rapports par DNS. Par exemple, pour une politique sur votredomaine.com qui envoie à dmarc@informes.example, il doit exister un TXT portant ce nom :

votredomaine.com._report._dmarc.informes.example

Sa valeur est v=DMARC1. Sans cette autorisation, les générateurs conformes ignorent cette destination externe. Le fournisseur qui reçoit les rapports doit vous fournir l'enregistrement exact. Une adresse sous un autre sous-domaine du même domaine organisationnel ne nécessite pas cette autorisation externe.

Que vérifier dans les résultats

Cherchez les IP inconnues avec beaucoup de messages et les sources légitimes qui échouent à l'alignement SPF ou DKIM. Avant de durcir la politique de p=none vers quarantine ou reject, identifiez et authentifiez tous les services autorisés : hébergement, formulaires, boutique, CRM, Microsoft 365, Google Workspace ou plateformes marketing. Appliquez le changement progressivement et suivez les rapports ; p=reject n'est pas adapté tant que vous n'avez pas confirmé qu'il ne bloquera pas de sources légitimes.

Le guide Configurer l'enregistrement DMARC explique la politique et ses principales balises.

Lire un cas sans confondre les résultats

Si une ligne montre un DKIM valide pour un domaine de la plateforme alors que l'expéditeur visible appartient à votre entreprise, vérifiez l'alignement avant de le considérer comme correct. La signature peut être valide sans permettre de réussir le DMARC de votre domaine. Le DMARC peut aussi réussir grâce à un SPF aligné même si cette signature ne l'est pas.

Associez chaque IP et chaque domaine à un service connu et à la période du rapport. Un volume inattendu mérite un examen, mais une IP inconnue isolée peut être un service de redirection. N'autorisez pas automatiquement toutes les IP qui apparaissent dans le XML.

Les rapports décrivent ce que chaque destinataire a observé ; ce n'est ni une liste complète de tous vos envois ni une mesure d'arrivée en boîte de réception principale. Comparez des périodes équivalentes et notez quand vous avez modifié la politique pour interpréter l'évolution.