Comment lire un rapport DMARC sans se noyer dans le XML

Ce qu'est réellement un rapport DMARC

Publiez un enregistrement DMARC avec une adresse rua= et les fournisseurs de messagerie commencent à vous envoyer des rapports agrégés : un fichier XML par fournisseur et par jour, listant chaque IP ayant envoyé du courrier en se réclamant de votre domaine, le nombre de messages de chacune, et si SPF et DKIM ont réussi et étaient alignés.

Deux choses à savoir avant d'en ouvrir un :

• Les rapports agrégés ne contiennent aucun contenu de message. Ni objets, ni destinataires, ni corps. Ce sont des comptages regroupés par IP d'envoi. C'est pourquoi on peut les collecter sans risque, et pourquoi ils ne peuvent pas dire quel message a échoué.
• Ce ne sont pas les rapports forensiques. Une adresse ruf= demande des échantillons d'échecs par message, qui contiennent des en-têtes et parfois davantage. La plupart des fournisseurs n'en envoient plus, pour des raisons de confidentialité : en pratique, la visibilité DMARC, ce sont les rapports agrégés.

Ce qu'ils vous donnent est la seule chose impossible à obtenir autrement : la liste de tout ce qui, dans le monde, envoie des e-mails en votre nom, y compris les systèmes internes que personne ne se rappelle avoir mis en place. Cet inventaire est tout l'intérêt, et c'est lui qui rend possible un passage sans casse à l'application de la politique.

Commencer à les recevoir

Un enregistrement minimal qui ne fait que collecter, sans rien changer à la délivrabilité :

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Il se place sur _dmarc.example.com en enregistrement TXT. p=none signifie « n'applique aucune politique, contente-toi de me dire » : c'est le bon point de départ et cela ne peut pas nuire à vos envois. Vérifiez que l'enregistrement est bien publié et lisible avec un outil de requête DNS avant d'attendre des rapports qui n'arriveront jamais.

Deux remarques pratiques. Les rapports arrivent chaque jour et en nombre : envoyez-les vers une boîte dédiée plutôt que vers la vôtre. Et si vous voulez les recevoir à une adresse d'un autre domaine, ce domaine doit l'autoriser par son propre enregistrement DNS — cette autorisation manquante est la raison la plus courante pour laquelle les rapports n'arrivent jamais.

Lire le XML : trois blocs

Tous les rapports agrégés ont la même forme. Une fois vue, elle cesse d'être intimidante.

Bloc 1 : qui a envoyé le rapport

<report_metadata> nomme l'organisme émetteur et donne un identifiant et une plage de dates. C'est la plage qu'il faut regarder : les rapports couvrent en général 24 heures et arrivent avec un ou deux jours de retard, donc l'IP que vous examinez a envoyé dans le passé.

Bloc 2 : la politique qu'ils ont vue

<policy_published> est votre propre enregistrement DMARC tel que ce fournisseur l'a lu : p (votre politique), sp (celle des sous-domaines), pct (le pourcentage demandé) et les modes d'alignement. Ce bloc sert de contrôle : si cela ne correspond pas à ce que vous pensez avoir publié, votre enregistrement a un problème de syntaxe ou ne s'est pas encore propagé.

Bloc 3 : les lignes qui comptent

Viennent ensuite des éléments <record>. Chacun est un groupe de messages venant d'une IP avec un même résultat, pas un courriel isolé. Chacun contient un <row> avec l'IP source et un compteur, un <policy_evaluated> avec le résultat DMARC et ce que le fournisseur a fait, et un <auth_results> avec les résultats SPF et DKIM sous-jacents.

Lire une ligne en pratique

Procédez dans cet ordre et la ligne s'explique d'elle-même :

1. Quelle est cette IP ? Cherchez-la. Un nom de plateforme d'e-mailing connue signifie que c'est un service à vous ; un réseau inconnu est celui à examiner.
2. Combien de messages ? Deux messages, c'est du bruit. Vingt mille, c'est un système.
3. Que dit <policy_evaluated><disposition> ? none, quarantine ou reject : ce que le fournisseur en a fait.
4. SPF et DKIM ont-ils réussi, et étaient-ils alignés ? Ce couple est tout le diagnostic, et c'est la section suivante.

Les quatre combinaisons et leur signification

DMARC réussit si l'un ou l'autre, SPF ou DKIM, réussit et est aligné avec le domaine From: visible. D'où quatre cas :

• SPF réussi + DKIM réussi. Votre expéditeur correctement configuré. Rien à faire.
• SPF réussi, DKIM échoué. En général un service qui envoie depuis une IP autorisée sans signer. Activez la signature DKIM : SPF seul est fragile, car il casse dès qu'un message est transféré.
• SPF échoué, DKIM réussi. Le plus souvent du courrier transféré légitime : l'IP du transfert n'est pas dans votre enregistrement SPF, mais la signature a survécu. DMARC réussit grâce au seul DKIM, ce qui est exactement le fonctionnement prévu.
• Les deux échouent. Soit un expéditeur à vous jamais configuré, soit quelqu'un qui vous usurpe. Les distinguer est l'objet de la section suivante.

Attention à un piège du XML : un résultat peut indiquer pass dans <auth_results> et faire quand même échouer DMARC, parce que le domaine authentifié n'était pas aligné avec le domaine From:. Une plateforme qui signe avec son propre domaine produit exactement cela. Si c'est trouble, pourquoi un SPF réussi n'est pas un DMARC réussi détaille l'alignement.

Distinguer vos expéditeurs d'une usurpation

Les premiers rapports paraissent alarmants à presque tout le monde, et presque rien n'est une attaque. Rangez les IP en échec en trois tas :

• Les vôtres, mal configurées. Un CRM, un système de facturation, un outil de tickets, une plateforme marketing, un serveur applicatif. Indices : l'IP résout vers un prestataire reconnaissable, le volume est régulier jour après jour, et les messages sont distribués. Correctif : autorisez-le correctement, de préférence avec DKIM.
• Les transferts. Faible volume, IP dispersées, universités et petits hébergeurs de courrier, SPF en échec tandis que DKIM passe. Ce n'est pas un problème et cela ne se corrige pas de votre côté.
• L'usurpation réelle. Réseaux inconnus, souvent par salves, fréquemment étrangers à votre activité, échouant aux deux contrôles. Le point rassurant : avec une politique en place, ce courrier est déjà rejeté, et c'est tout l'objectif.

L'ordre compte. Identifiez tout le premier tas avant de durcir la politique, car l'application transforme un expéditeur mal configuré en courrier non distribué.

Pourquoi les transferts ressemblent à des attaques

Cela trouble tout le monde une fois. Une liste de diffusion ou un alias relaie votre message depuis son propre serveur : votre enregistrement SPF est donc vérifié contre une IP que vous n'avez jamais autorisée, et il échoue, à juste titre. Le rapport montre une IP inconnue en échec SPF tout en envoyant en votre nom, ce qui se lit exactement comme un abus.

Deux indices les séparent. Le courrier transféré passe généralement DKIM, car la signature voyage avec le message, donc DMARC réussit malgré tout. Et le volume est faible et réparti sur de nombreuses IP sans lien entre elles, plutôt que concentré. Les listes de diffusion sont l'exception qui peut casser les deux : certaines réécrivent l'objet ou ajoutent un pied de page, ce qui invalide la signature DKIM et laisse un message légitime en échec partout.

Se servir des rapports pour passer à l'application

Les rapports existent pour rendre ce passage sûr. Une marche à suivre qui fonctionne :

• Restez en p=none jusqu'à ce que les rapports soient ennuyeux : quelques semaines en général. Vous attendez que chaque expéditeur légitime trouvé soit autorisé et que rien de nouveau n'apparaisse.
• Corrigez les expéditeurs au fur et à mesure, en privilégiant DKIM. Un expéditeur avec DKIM survit au transfert ; un expéditeur avec seulement SPF, non.
• Passez à p=quarantine, éventuellement avec pct= pour monter progressivement. Le courrier en échec part en spam au lieu de disparaître : une erreur reste rattrapable.
• Puis p=reject, une fois la quarantaine devenue calme. C'est là que le courrier usurpant votre domaine est réellement refusé.
• Continuez à lire les rapports ensuite. Un nouveau prestataire ajouté dans six mois apparaîtra comme une IP en échec, et vous voulez le voir avant qu'on vous dise que ses factures rebondissent.

Ne mettez pas p=reject dès le premier jour. La seule chose qui rend l'application sûre, c'est l'inventaire fourni par les rapports, et il met des semaines à être complet. Le guide SPF, DKIM et DMARC traite des enregistrements eux-mêmes.

Erreurs fréquentes

• Sauter à p=reject sans lire les rapports. Le système oublié est généralement celui qui facture vos clients.
• Lire chaque ligne comme un message. Une ligne est un groupe de messages d'une IP avec un même résultat.
• Prendre toute IP en échec pour un attaquant. La plupart des premiers échecs sont vos propres services et des transferts ordinaires.
• Croire qu'un pass dans auth_results signifie DMARC réussi. Sans alignement avec le domaine From:, non.
• Envoyer les rapports vers une boîte humaine. Ils arrivent quotidiennement de dizaines de fournisseurs. Utilisez une adresse dédiée.
• Oublier la politique des sous-domaines. Sans sp=, les sous-domaines héritent de p, ce qui n'est pas forcément voulu pendant un déploiement.
• Ne corriger que SPF. SPF casse au transfert ; c'est DKIM qui y fait survivre DMARC.
• Couper les rapports une fois en reject. C'est justement là qu'ils deviennent un système d'alerte précoce.

En bref

Un rapport DMARC agrégé est une liste XML quotidienne de chaque IP envoyant en votre nom, avec des comptages et les résultats SPF et DKIM — sans aucun contenu de message. Lisez chaque ligne en quatre temps : identifiez l'IP, regardez le volume, lisez la disposition, puis vérifiez si SPF ou DKIM a réussi et était aligné. Attendez-vous à ce que la plupart des premiers échecs soient vos propres services non configurés et des transferts ordinaires plutôt qu'une usurpation, corrigez les expéditeurs avec DKIM dès que possible, et ne passez de p=none à la quarantaine puis au rejet qu'une fois les rapports devenus calmes. Vérifiez que votre enregistrement _dmarc est publié et lisible avec l' outil gratuit de requête DNS, et si un résultat SPF dans un rapport semble contradictoire, le guide de dépannage SPF l'explique.

Outils et guides associés :

• Recherche DNS : Interrogez les enregistrements A, AAAA, MX, TXT, NS et plus, avec valeurs et TTL, ainsi que le DNS inversé.
• Pourquoi votre enregistrement SPF échoue (et comment le corriger) : Comment lire votre enregistrement SPF

Questions fréquentes