Comprendre un rapport DMARC agrégat

Vous avez publié un enregistrement DMARC avec une adresse rua=, et depuis, des fichiers compressés arrivent chaque jour dans votre boîte. Voici comment les lire — et pourquoi ils ne disent pas ce que beaucoup croient.

Ce que c’est

Un rapport agrégat est un fichier XML compressé (gzip ou zip), envoyé une fois par jour par chaque fournisseur de messagerie qui a reçu du courrier prétendant venir de votre domaine. Il ne vient pas de vous ni de votre hébergeur : il vient des destinataires — Google, Microsoft, Yahoo et les autres — qui vous racontent ce qu’ils ont vu.

Conséquence directe : vous ne recevez de rapports que des fournisseurs qui en émettent, et seulement pour le courrier qui leur est parvenu. Un rapport n’est jamais une vue exhaustive de vos envois.

La structure du fichier

report_metadata — qui parle, et de quand

Le nom de l’organisation émettrice, un identifiant de rapport, et surtout la période couverte. C’est en général la veille : DMARC n’a rien de temps réel, comptez 24 à 48 heures de décalage.

policy_published — ce que le fournisseur a lu dans votre DNS

Votre politique telle qu’elle a été vue : p (none, quarantine ou reject), sp pour les sous-domaines, pct le pourcentage de messages concernés, et les modes d’alignement adkim et aspf (r pour souple, s pour strict).

Section précieuse pour une raison inattendue : elle vous dit ce que le monde extérieur voit réellement. Si elle ne correspond pas à ce que vous croyez avoir publié, votre problème est dans le DNS, pas dans vos envois.

record — une entrée par IP source

Le cœur du rapport. Chaque entrée regroupe les messages venus d’une même adresse IP :

• source_ip et count : qui a envoyé, et combien de messages.
• policy_evaluated : la décision — la disposition appliquée (none, quarantine, reject) et les résultats DKIM et SPF après alignement.
• identifiers : le domaine affiché dans le champ From:, celui que voit l’humain.
• auth_results : les résultats bruts de SPF et DKIM, avec les domaines et le sélecteur DKIM utilisés.

Le piège : brut n’est pas aligné

C’est la distinction qui fait trébucher tout le monde. Un message peut très bien avoir un SPF qui passe dans auth_results et un SPF en échec dans policy_evaluated.

Ce n’est pas une contradiction. SPF valide le domaine de l’enveloppe (le Return-Path), que le destinataire ne voit jamais. DMARC exige en plus que ce domaine corresponde à celui du From: affiché. Une plateforme d’emailing qui envoie avec son propre Return-Path obtient un SPF qui passe et un alignement qui échoue : techniquement autorisée, mais pas au nom de votre domaine.

Un message est conforme à DMARC dès que SPF ou DKIM passe et est aligné. Un seul des deux suffit — d’où l’intérêt de DKIM, qui survit aux transferts là où SPF casse.

Ce qu’un rapport agrégat ne contient pas

• Aucun contenu de message, aucun objet, aucune pièce jointe.
• Aucune adresse de destinataire : ce sont des statistiques agrégées, pas un journal d’envoi.
• Pas de temps réel : on regarde toujours hier.
• Pas de verdict sur le spam : DMARC dit si l’authentification passe, pas si votre message a plu au filtre anti-spam. Ce sont deux problèmes distincts.

Par quoi commencer quand on en ouvre un

• Les IP au volume le plus élevé que vous ne reconnaissez pas. C’est presque toujours un outil légitime oublié — mais c’est ce qui vous bloquerait en passant en reject.
• Les entrées où ni SPF ni DKIM n’est aligné et dont le volume ne bouge pas : le profil typique d’un envoi de masse frauduleux.
• L’évolution du taux de conformité dans le temps, plus parlante qu’un rapport isolé.

Tout cela se fait à la main sur un domaine et quelques jours. Au deuxième domaine, ou au bout de trois semaines, ça ne tient plus : Clarsend agrège ces rapports, identifie chaque IP source parmi 23 fournisseurs d’envoi reconnus, et vous alerte quand le taux d’échec bouge.