Retour au blog

Tutoriels

Lire un rapport DMARC XML et identifier qui envoie des emails avec votre domaine

Comprendre un rapport DMARC XML, repérer les sources d'envoi et distinguer flux légitimes, erreurs et usages suspects.

17 mai 2026 - 12 min

Rapport DMARC XML annoté avec explication des champs source_ip, count, disposition, DKIM, SPF et header_from

Comprendre un rapport DMARC XML, repérer les sources d’envoi et distinguer flux légitimes, erreurs et usages suspects. L’objectif est simple : lire source_ip, count, disposition, dkim, spf, header_from et policy_evaluated, sans casser les emails utiles de l’entreprise. Ce guide privilégie une méthode prudente, documentée et mesurable pour les PME, équipes IT, responsables marketing et dirigeants.

Réponse directe : commencez par identifier les flux réels, vérifiez les DNS, appliquez les corrections une par une, testez vers Gmail et Outlook, puis observez les résultats avant de durcir. Pour ce sujet, le fil conducteur consiste à lire source_ip, count, disposition, dkim, spf, header_from et policy_evaluated.

À retenir : Ne modifiez pas un enregistrement DNS critique sans comprendre quel outil l’utilise. Une correction techniquement juste peut interrompre des factures, notifications, formulaires web ou campagnes si le flux n’a pas été inventorié.

En bref

  • Le bon diagnostic commence par les flux réels, pas par une supposition.
  • Les changements DNS doivent être datés, testés et réversibles.
  • Gmail et Outlook réagissent à la technique, mais aussi à la réputation et à l’engagement.
  • Une méthode progressive protège la délivrabilité et les usages métier.

Schéma : lire les champs clés du XML

Un rapport DMARC brut paraît dense, mais quelques champs structurent presque tout le diagnostic.

Rapport DMARC XML annoté avec explication des champs source_ip, count, disposition, DKIM, SPF et header_from

Un rapport DMARC XML contient les informations nécessaires pour comprendre quelles sources envoient des emails avec votre domaine.

Concentrez-vous d’abord sur source_ip, count, header_from, dkim, spf et disposition. Ces champs indiquent le volume, la source et le résultat d’authentification.

Schéma : transformer le XML en tableau

Pour piloter DMARC, le XML doit devenir une vue lisible par source, volume et action.

Transformation d’un rapport DMARC XML en tableau lisible avec IP source, volume, SPF, DKIM, DMARC et action

La conversion du XML en tableau permet d’identifier rapidement les flux légitimes, inconnus ou suspects.

Un tableau rend les priorités évidentes : les gros volumes légitimes à corriger passent avant les flux faibles, mais les flux inconnus ne doivent pas être ignorés.

Schéma : enquêter sur une IP source

Une IP source ne suffit pas à conclure. Il faut la relier à un fournisseur, un outil et un propriétaire interne.

Processus d’enquête sur une IP source trouvée dans un rapport DMARC

L’analyse d’une IP source consiste à croiser le reverse DNS, le WHOIS, le fournisseur probable et les résultats d’authentification.

Cette méthode évite les erreurs de classement. Une IP inconnue peut être un outil oublié, un prestataire légitime mal configuré ou un abus réel.

Schéma : repérer un flux inconnu

Les petits volumes sont faciles à négliger, mais ils peuvent révéler une configuration ancienne ou un usage non autorisé.

Détection d’un expéditeur inconnu ou suspect dans un rapport DMARC

Un faible volume, une IP inconnue, un échec DKIM ou un SPF non aligné peuvent révéler un flux non autorisé ou mal configuré.

La bonne réaction n’est pas de bloquer immédiatement. Il faut vérifier, identifier le propriétaire éventuel, corriger si le flux est utile, puis durcir la politique.

Quand utiliser cette méthode ?

Utilisez cette méthode lorsque le domaine envoie depuis plusieurs plateformes, lorsqu’une baisse de délivrabilité apparaît, ou avant une politique DMARC plus stricte. Elle est aussi utile après une migration Microsoft 365, Google Workspace, CRM ou plateforme marketing.

Elle s’applique aussi aux organisations qui veulent fiabiliser leur authentification email avant un audit client, une migration DNS, un changement de plateforme ou une campagne importante.

Procédure étape par étape

ÉtapeActionValidation
1Cartographier les flux d’envoi réels, y compris site web, CRM, facturation, support, marketing et messagerie collaborative.Contrôle documenté
2Vérifier les enregistrements DNS avant modification et conserver une copie datée de l’état initial.Contrôle documenté
3Appliquer la correction sur un périmètre limité, avec une fenêtre d’observation claire.Contrôle documenté
4Tester les messages critiques vers Gmail, Outlook et une boîte externe neutre.Contrôle documenté
5Comparer les résultats techniques avec les retours métier : réception, spam, promotions, rejets et bounces.Contrôle documenté
6Documenter la décision, les propriétaires d’outil et la prochaine date de contrôle.Contrôle documenté

Exemple DNS concret

Adaptez toujours les valeurs au fournisseur réel. Ne copiez jamais un exemple DNS sans vérifier le domaine, le sélecteur DKIM, l’adresse de rapport et la politique attendue.

example.com. TXT "v=spf1 include:spf.protection.outlook.com include:example-esp.net -all"
selector1._domainkey.example.com. CNAME selector1-example-com._domainkey.provider.example.
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s"

Précautions métier pour la délivrabilité

Ne modifiez pas un enregistrement DNS critique sans comprendre quel outil l’utilise. Une correction techniquement juste peut interrompre des factures, notifications, formulaires web ou campagnes si le flux n’a pas été inventorié.

La délivrabilité ne dépend pas uniquement de SPF, DKIM ou DMARC. Les plaintes, les bounces, la qualité de la base, les volumes, la régularité des campagnes et la clarté du contenu comptent aussi. Reliez ce tutoriel aux services d’audit et de délivrabilité.

Définitions courtes

  • SPF : enregistrement DNS qui autorise des serveurs à envoyer pour un domaine.
  • DKIM : signature cryptographique qui prouve l’intégrité du message.
  • DMARC : politique qui vérifie l’alignement et demande une action en cas d’échec.
  • Domaine d’envoi : domaine visible ou technique utilisé par une plateforme pour expédier.
  • Réputation domaine : niveau de confiance construit par les fournisseurs à partir de l’historique.

Liens internes utiles

Checklist finale

  • Cartographier les flux d’envoi réels, y compris site web, CRM, facturation, support, marketing et messagerie collaborative.
  • Vérifier les enregistrements DNS avant modification et conserver une copie datée de l’état initial.
  • Appliquer la correction sur un périmètre limité, avec une fenêtre d’observation claire.
  • Tester les messages critiques vers Gmail, Outlook et une boîte externe neutre.
  • Comparer les résultats techniques avec les retours métier : réception, spam, promotions, rejets et bounces.
  • Documenter la décision, les propriétaires d’outil et la prochaine date de contrôle.
  • Surveiller les résultats pendant plusieurs jours.
  • Documenter la date, le propriétaire et la raison de chaque changement.

Méthode de validation opérationnelle

Après chaque changement, créez une petite fiche de contrôle. Notez le domaine concerné, l’outil modifié, l’enregistrement DNS touché, l’heure de modification, le résultat attendu et la personne responsable. Cette fiche évite les diagnostics confus lorsque plusieurs équipes interviennent sur la même zone DNS ou sur la même plateforme d’envoi.

Envoyez ensuite trois types de messages : un message humain depuis la messagerie principale, un message applicatif depuis le site ou le CRM, et un message marketing si une plateforme de campagne est concernée. Vérifiez l’en-tête complet du message reçu, pas seulement l’affichage dans la boîte de réception. Les lignes SPF, DKIM et DMARC indiquent si le message passe techniquement et si le domaine visible reste cohérent.

Surveillez enfin les signaux métier. Une baisse de réponse, une hausse des bounces, des plaintes inhabituelles ou des retours clients doivent être rapprochés de la date du changement. Cette discipline simple permet de corriger rapidement sans multiplier les modifications simultanées. Pour une PME, c’est souvent la différence entre une amélioration maîtrisée et une série d’essais difficiles à interpréter.

FAQ

Combien de temps faut-il observer avant de durcir ?

Pour une PME, deux à quatre semaines donnent souvent une base correcte. Il faut couvrir les campagnes, factures, relances, notifications et outils utilisés rarement.

Peut-on tout corriger depuis le DNS ?

Non. Le DNS expose l’autorisation et l’authentification, mais il ne remplace pas la configuration dans Microsoft 365, Google Workspace, le CRM ou la plateforme marketing.

Quel est le risque principal ?

Le risque est de bloquer un flux légitime que personne n’avait inventorié : facture, formulaire web, outil métier ou ancien routeur SMTP.

Faut-il séparer les flux marketing ?

Oui dès que les volumes, audiences ou objectifs diffèrent du courrier humain. Un sous-domaine rend le diagnostic plus lisible.

Un test isolé suffit-il ?

Non. Les fournisseurs utilisent des signaux agrégés. Il faut observer plusieurs jours et plusieurs types de messages.

Quand demander un audit ?

Dès que le domaine est critique, que plusieurs outils envoient, ou qu’une baisse de délivrabilité touche le chiffre d’affaires ou la relation client.

Conclusion

Dharmail peut vous aider à auditer vos flux, corriger les DNS et suivre les effets sur Gmail, Outlook et vos outils métier. Contactez Dharmail pour transformer ce tutoriel en plan d’action adapté à votre domaine.