Rapport DMARC XML : interpréter les échecs

Un rapport DMARC XML devient utile lorsque chaque ligne conduit à une décision : corriger un expéditeur autorisé, examiner une source inconnue ou documenter un transfert attendu. Le nombre total d’échecs, seul, ne permet pas de choisir entre ces actions. Un petit flux de facturation mal configuré peut demander une intervention plus rapide qu’un grand volume d’usurpations déjà rejetées.

Cette méthode transforme un rapport agrégé en file de travail. Elle ne suppose pas que tous les destinataires produisent des rapports ni que les messages signalés ont atteint la boîte de réception.

Vérifier le fichier avant de compter

Conservez le message transportant le rapport, son fichier joint original et une copie de travail décompressée. Notez l’organisme déclarant, l’identifiant du rapport, le domaine concerné et la période couverte. La date de réception du fichier n’est pas nécessairement la date des événements.

Traitez l’entrée comme un fichier externe. Imposez des limites de taille après décompression et utilisez un parseur XML dont les entités externes sont désactivées. Les recommandations OWASP contre les attaques XXE expliquent pourquoi un parseur mal configuré peut accéder à des ressources inattendues. Aucun accès réseau n’est nécessaire pour lire les valeurs d’un rapport.

Vérifiez le format effectivement reçu. La RFC 9990 définit le format actuel des rapports agrégés DMARC ; des producteurs peuvent encore utiliser le format historique. Faites remonter un format non pris en charge comme une erreur d’import, pas comme un rapport contenant zéro message.

Séparer trois niveaux de lecture

Les métadonnées décrivent qui rapporte et pour quelle période. La politique publiée décrit ce que le récepteur a observé. Les lignes record regroupent des résultats associés à une IP source et à des identités d’authentification. Dans chaque ligne, count est un nombre de messages.

Le bloc policy_evaluated décrit l’évaluation DMARC, alors que auth_results expose les résultats SPF et DKIM sous-jacents. Cette séparation explique les apparentes contradictions. Gardez les deux dans votre export, ainsi que les domaines évalués, avant toute agrégation.

Créez une table de travail avec une ligne par groupe observé : organisme déclarant, période, IP, domaine visible, domaine SPF, domaine DKIM, résultats, disposition et volume. Ajoutez ensuite vos propres colonnes : service reconnu, responsable interne, preuve de reconnaissance et action. Ces dernières rendent la table exploitable par une équipe, sans modifier les données reçues.

Un extrait qui paraît contradictoire

Cet exemple fictif est un fragment pédagogique, pas un rapport complet à importer. Les domaines .example et l’adresse IP sont réservés à la documentation.

<record>
  <row>
    <source_ip>192.0.2.74</source_ip>
    <count>24</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>entreprise.example</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>prestataire.example</domain>
      <selector>support</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>rebonds.prestataire.example</domain>
      <scope>mfrom</scope>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Pour cet exercice, supposons une politique observée p=none. Le prestataire réussit ses contrôles bruts, mais ses identités ne correspondent pas au domaine visible de l’entreprise. La règle d’alignement DMARC explique ce résultat : une authentification réussie doit aussi être alignée avec l’identité de l’auteur. Voir la RFC 9989.

La bonne question est donc : « ce prestataire doit-il envoyer au nom de cette entreprise, et sa configuration personnalisée est-elle complète ? ». Ajouter arbitrairement son IP à une liste de confiance ne répond pas au problème montré par cet extrait.

Reconnaître un service avec une preuve métier

Commencez par les sources que votre inventaire associe à un service interne. Demandez un envoi de test, son identifiant et les en-têtes du message reçu. Rapprochez ces pièces du groupe XML. Une IP appartenant à un grand fournisseur ne suffit pas : plusieurs clients peuvent partager son infrastructure.

Pour une source inconnue, cherchez le responsable possible dans les équipes finance, support, marketing et informatique. Un nom de domaine évocateur est une piste, pas une approbation. Documentez la réponse obtenue et la période vérifiée, notamment pour les applications qui n’envoient qu’en fin de mois.

Si personne ne reconnaît le flux, conservez-le comme inconnu. Le guide d’enrichissement IOC pour le SOC aide à compléter cette enquête avec le contexte des IP et domaines. Ce contexte ne prouve pas qu’une plateforme était autorisée à utiliser votre identité.

Prioriser selon l’impact observable

Attribuez d’abord une action aux flux légitimes qui échouent : propriétaire à solliciter, paramètre à vérifier et test attendu. Précisez le risque métier, par exemple des notifications de support non reçues. Évitez une priorité fondée uniquement sur le volume.

Pour une source inconnue dont les messages échouent, ouvrez une investigation ciblée. Examinez si le groupe est nouveau, s’il persiste et si un utilisateur a signalé un message correspondant. Un rapport agrégé ne contient pas nécessairement assez d’informations pour attribuer une campagne ou confirmer le contenu envoyé.

Une source inconnue qui réussit mérite également une revue. Cherchez une autorisation oubliée, une intégration déployée sans inventaire ou un usage inattendu d’un service existant. Le succès d’authentification ne remplace pas la validation de son usage.

Le guide général de déploiement DMARC présente les étapes de configuration. Pour choisir un durcissement, appuyez-vous sur les flux reconnus et testés, avec une période d’observation couvrant vos usages réels.

Comparer les périodes sans créer de faux progrès

Dédupliquez les rapports avant de sommer leurs volumes. Utilisez l’identité du déclarant et son identifiant de rapport, tout en conservant le domaine et la période pour détecter les anomalies. Si deux fichiers prétendent représenter le même rapport avec des contenus différents, signalez le conflit au lieu de conserver silencieusement le dernier.

Comparez ensuite des ensembles de récepteurs équivalents. Une baisse des échecs peut venir d’un fichier manquant ou d’un producteur qui ne rapporte plus. Affichez les rapports attendus et reçus à côté des volumes, afin de distinguer une correction d’une perte de visibilité.

Après chaque changement, gardez un tableau avant/après par service et les résultats des essais de réception. Une amélioration globale peut masquer un nouveau problème sur un petit flux. Conservez aussi les écarts encore inexpliqués avec leur propriétaire et une date de revue.

Pour une IP ou un domaine inconnu, ouvrez un rapport IsMalicious et joignez le résultat daté à la ligne d’investigation. Vous obtenez alors une décision argumentée sur chaque source, tout en laissant aux traces de messagerie le rôle de démontrer l’envoi et la réception.