Les pièges à spam sont de véritables boîtes mail créées ou réutilisées pour détecter les pratiques douteuses des listes de diffusion. Les atteindre peut nuire à la réputation de l'expéditeur et à son placement en boîte de réception. Courriel…
Points clés à retenir
- Le XML brut est intentionnellement formaté par machine. La méthode la plus rapide pour en tirer profit consiste à analyser les rapports et à les convertir en un tableau des sources d'envoi et des résultats ; manuellement pour un examen ponctuel, ou via un analyseur DMARC pour une surveillance continue.
- L'approche la plus efficace pour bloquer les adresses e-mail jetables consiste à effectuer un blocage en temps réel au niveau du formulaire d'inscription à l'aide d'une API de validation qui vérifie la présence de ces adresses dans une liste de domaines jetables mise à jour régulièrement.
- L'objectif de la lecture des rapports est opérationnel : recenser chaque expéditeur, confirmer que les expéditeurs légitimes respectent les critères d'alignement et identifier les sources non autorisées ou mal configurées avant de renforcer la politique.
- Les rapports « ennuyeux » (taux de réussite constants provenant d'expéditeurs connus sans surprises) signalent qu'il est possible de passer en toute sécurité de p=aucun à p=quarantaine et p=rejet.
Dans les 24 à 72 heures suivant la publication d'un enregistrement DMARC, le premier rapport agrégé est disponible et révèle immédiatement tous les serveurs, légitimes ou non, ayant envoyé des e-mails depuis votre domaine pendant cette période. Le hic, comme indiqué dans DMARC.orgLa spécification du protocole stipule que ces rapports sont des fichiers XML formatés par machine, conçus pour des analyseurs automatisés et non pour des lecteurs humains.
Savoir lire les rapports DMARC transforme ces données brutes en informations opérationnelles. La visibilité est véritablement précieuse, mais seulement après le décodage du XML en un format exploitable. Statistiques sur le spam par e-mail Expliquez pourquoi cette visibilité est importante : l’usurpation d’identité est courante, vous avez donc besoin de rapports DMARC pour identifier les sources qui envoient des e-mails en utilisant votre domaine.
Comment lire les rapports DMARC
La première lecture prend entre 15 et 30 minutes. Les lectures suivantes provenant des mêmes expéditeurs prennent entre 2 et 3 minutes une fois le modèle identifié. Les étapes ci-dessous décrivent la génération d'un rapport agrégé DMARC complet, du début à la fin.
Voici un extrait XML anonymisé qui illustre la structure du rapport utilisée dans les étapes de révision ci-dessous :
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
<report_metadata>
<org_name>google.com</org_name>
<email>[email protected]</email>
<report_id>10296513920663916120</report_id>
<date_range>
<begin>1716768000</begin>
<end>1716854400</end>
</date_range>
</report_metadata>
<policy_published>
<domain>yourdomain.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>none</p>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>209.85.220.41</source_ip>
<count>847</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<auth_results>
<dkim>
<domain>yourdomain.com</domain>
<result>pass</result>
</dkim>
<spf>
<domain>yourdomain.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
<record>
<row>
<source_ip>198.51.100.23</source_ip>
<count>312</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<auth_results>
<dkim>
<domain>unknownsender.net</domain>
<result>fail</result>
</dkim>
<spf>
<domain>unknownsender.net</domain>
<result>fail</result>
</spf>
</auth_results>
</record>
</feedback>Étape 1 : Configurer une boîte de réception ou un service pour recevoir les rapports
Vérifiez qu'une boîte de réception dédiée collecte les rapports à l'adresse spécifiée dans la balise rua= de votre enregistrement DMARC (par exemple, [email protected]Les fournisseurs de messagerie envoient quotidiennement des rapports agrégés, de sorte que même un domaine à faible trafic accumule des dizaines de fichiers XML par mois ; ainsi, une boîte de réception partagée générale devient rapidement ingérable.
Pour les petits domaines nécessitant des vérifications ponctuelles, une boîte mail dédiée suffit. Au-delà de quelques rapports par semaine, ou pour les organisations gérant plusieurs domaines, configurez la balise rua= pour qu'elle pointe vers l'adresse d'ingestion d'un analyseur DMARC afin d'automatiser l'analyse.
Étape 2 : Ouvrir et décompresser le fichier XML
Téléchargez le fichier joint à l'e-mail de rapport. La plupart des rapports arrivent sous forme d'archives .xml.gz ou .zip qui doivent d'abord être décompressées (sous macOS et Linux, double-cliquez ou utilisez gunzip ; sous Windows, faites un clic droit et extrayez).
Ouvrez le fichier .xml obtenu dans un éditeur de texte comme VS Code, Sublime Text ou Notepad++. Vous pouvez également l'ouvrir dans un navigateur ; cela facilite souvent la lecture du XML car les sections apparaissent sous forme de nœuds extensibles plutôt que d'un seul bloc de texte.
Pour consulter un rapport ponctuellement, l'ouverture manuelle du fichier XML est suffisante. Si vous recevez plusieurs rapports par semaine, il est préférable d'utiliser un analyseur automatique. Les rapports DMARC suivent une structure uniforme, ce qui permet aux outils de convertir le XML en tableaux et en synthèses beaucoup plus rapidement.
Étape 3 : Identifier l’organisation et la politique de déclaration
Localisez le Le bloc en haut du fichier identifie l'organisme déclarant (Google, Microsoft, Yahoo, Mail.ru ou autre) ainsi que les horodatages Unix du début et de la fin de la période de rapport. La conversion de ces horodatages en dates lisibles permet de confirmer la période de 24 heures couverte par le rapport.
Localisez le Le bloc suivant indique la politique DMARC active pendant la période de génération du rapport (p=aucune, p=quarantaine ou p=rejet) ainsi que les modes d'alignement pour SPF (aspf) et DKIM (adkim). La valeur r signifie un alignement souple ; s signifie un alignement strict.
Vérifiez que la politique affichée dans le rapport correspond bien à celle indiquée dans votre enregistrement DNS. Une différence signifie que le rapport couvre une période antérieure à la propagation d'une modification récente de la politique ; ceci est normal et ne pose pas de problème, mais sert simplement de contexte pour l'interprétation des résultats.
Étape 4 : Examiner chaque source d’envoi dans la section des archives
Défilez jusqu'à Les enregistrements sont regroupés par blocs. Chaque enregistrement représente une adresse IP d'envoi et ses résultats, classés par nombre de messages. Dans l'extrait ci-dessus, l'adresse 209.85.220.41 a envoyé 847 messages et a réussi le test DMARC ; l'adresse 198.51.100.23 a envoyé 312 messages et a échoué aux tests SPF et DKIM.
Pour chaque enregistrement, capturez le et L'adresse IP identifie le serveur qui a prétendu envoyer des messages au nom de votre domaine, tandis que le nombre indique le nombre de messages provenant de ce serveur pendant la période considérée.
Effectuez une recherche DNS inverse pour chaque adresse IP source inconnue. Les expéditeurs légitimes correspondent à des noms d'hôtes reconnaissables (mail-sor-f41.google.com pour Gmail, sendgrid.net pour SendGrid et amazonses.com pour AWS SES). Les adresses IP inconnues nécessitent une investigation avant d'être considérées comme légitimes.
Étape 5 : Vérifier l’alignement SPF et DKIM pour chaque expéditeur
Dans chaque enregistrement, trouvez le Ce bloc contient le résultat SPF et le résultat DKIM pour cette adresse IP source, ainsi que le domaine pour lequel chaque méthode d'authentification a été évaluée.
DMARC exige seulement que l'un des protocoles SPF ou DKIM soit validé en mode aligné pour que le message global réussisse le contrôle DMARC. Ce champ affiche le verdict final (aucun, mise en quarantaine ou rejet) en fonction de la politique en vigueur pendant la période de rapport.
Signalez tout enregistrement où SPF et DKIM indiquent un échec, alors que la source est censée être un expéditeur légitime. Il s'agit d'un expéditeur mal configuré qui doit être corrigé avant que la politique puisse être renforcée en toute sécurité. Un enregistrement indiquant SPF=échec mais DKIM=réussite est généralement acceptable, car le message réussit tout de même le contrôle DMARC.
Que vous indique chaque champ XML d'un rapport DMARC ?
Les rapports agrégés DMARC sont conformes à la RFC 7489. Tous les rapports conformes utilisent la même structure, quel que soit le fournisseur de messagerie qui les a envoyés. Utilisez cette référence de champ lors de toute consultation de rapport :
- — l'organisme déclarant (Google, Microsoft, Yahoo, etc.). Indique quel fournisseur de messagerie a envoyé le rapport. Les grands fournisseurs envoient généralement des rapports distincts par domaine.
- — Horodatage Unix du début et de la fin de la période couverte. La plupart des rapports couvrent une période de 24 heures, mais certains fournisseurs envoient des rapports moins fréquemment.
- — la politique DMARC active pendant la période (balise p) ainsi que les modes d'alignement pour SPF (aspf) et DKIM (adkim). L'alignement relâché (r) autorise les sous-domaines à satisfaire l'alignement ; l'alignement strict (s) exige une correspondance exacte.
- — l'adresse IP qui a envoyé les messages. Utilisez une requête DNS inverse pour identifier le service d'envoi.
- — le nombre de messages envoyés depuis cette adresse IP source pendant la période concernée. Un nombre élevé de messages provenant d'adresses IP inconnues est suspect.
- — le verdict final de DMARC : aucun (aucune action entreprise), quarantaine (dossier spam) ou rejet (rejeté).
- — Les résultats SPF et DKIM pour la source. Chaque résultat indique le domaine authentifié et un verdict de réussite/échec. C’est la concordance entre le domaine authentifié et le domaine d’origine qui détermine la réussite globale de DMARC, et non la réussite isolée de SPF ou DKIM.
Que faut-il rechercher dans les rapports DMARC ?
Une fois ces quatre modèles identifiés, les rapports DMARC deviennent beaucoup plus faciles à lire. Au lieu de parcourir un bloc de code XML, vous pouvez classer chaque enregistrement dans une catégorie claire.
Expéditeurs légitimes affichant dmarc=pass
Si un expéditeur connu, comme votre ESP, votre plateforme marketing, votre service d'assistance ou votre CRM, apparaît dans le rapport avec les mentions dkim=pass et spf=pass, cela signifie que la configuration fonctionne correctement pour cette source.
Vérifiez que l'adresse IP source appartient bien au fournisseur attendu via DNS inverse, surtout pour les enregistrements DNS comportant un grand nombre de connexions. Un volume important de courriels provenant d'une adresse IP connue avec dmarc=pass est normal. Confirmez-le une fois, puis utilisez cette information comme référence pour les rapports futurs.
Sources suspectes avec un nombre élevé de messages
Les adresses IP inconnues envoyant des centaines ou des milliers de messages avec dmarc=fail appartiennent à l'une des deux catégories suivantes : les expéditeurs non autorisés qui usurpent activement votre domaine, ou un expéditeur légitime oublié (un ancien outil marketing, une intégration informatique fantôme) qui n'a jamais été correctement authentifié.
Effectuez une enquête en vérifiant les enregistrements WHOIS et DNS inverses de l'adresse IP. Une adresse IP connue pour le spam indique généralement une usurpation d'identité, tandis qu'une plateforme SaaS oubliée révèle souvent un problème d'authentification. Ces deux cas nécessitent des réponses différentes : bloquer ou rejeter les courriels usurpés, mais corriger l'alignement SPF ou DKIM pour les expéditeurs légitimes.
SPF échoue, mais DKIM réussit : généralement, le transfert
Un message qui échoue au test SPF mais réussit le test DKIM indique souvent un transfert d'e-mail. Le serveur de transfert n'est pas répertorié dans l'enregistrement SPF de l'expéditeur d'origine, ce qui explique l'échec du test SPF. En revanche, DKIM fonctionne différemment : il signe les en-têtes du message, et cette signature est généralement conservée lors du transfert. C'est pourquoi DKIM peut réussir le test même en cas d'échec du test SPF.
L'authentification DMARC est réussie dès lors que SPF ou DKIM est aligné ; ces enregistrements ne posent donc aucun problème. Pour les domaines dont les destinataires utilisent le transfert de courrier, ce comportement est normal. Le rapport indique l'impact du transfert sur l'authentification, et non un échec de la configuration DMARC.
Pics de volume soudains provenant d'adresses IP inconnues : généralement une usurpation d'identité.
Une adresse IP inconnue qui envoie soudainement un volume important de messages alors que les vérifications SPF et DKIM échouent est la signature classique d'usurpation d'identité. Quelqu'un envoie des courriels en prétendant provenir de votre domaine via sa propre infrastructure, tentant ainsi de contourner les filtres anti-spam en empruntant les signaux de confiance de votre domaine.
Vérifiez l'adresse IP dans des outils de veille sur les menaces tels qu'AbuseIPDB ou Cisco Talos. Si l'adresse IP est associée à du spam ou à des abus, le pic est probablement malveillant. C'est à ce moment que l'activation de la règle p=reject devient importante. Une fois que tous les expéditeurs légitimes sont contrôlés, une application stricte de cette règle permet de bloquer les courriers usurpés avant qu'ils ne puissent nuire à votre compte. réputation de l'expéditeur des e-mails.
Outils pour analyser et visualiser les rapports DMARC
La plupart des équipes passent d'une analyse manuelle des fichiers XML à un analyseur automatisé dès la première semaine suivant la réception des rapports. Ce choix dépend du volume de données, du budget et du niveau d'analyse requis.
Pour la plupart des équipes débutantes, l'utilisation de MXToolbox pour des vérifications manuelles ponctuelles et de Postmark DMARC Digests pour une surveillance passive constitue une solution pratique et gratuite. Il est conseillé de passer à un analyseur dédié comme DMARCian lorsque le nombre de domaines ou le volume quotidien de rapports rend la vérification manuelle impossible.
Du rapport à l'action : quand renforcer votre politique
La lecture des rapports DMARC n'est utile que si elle sert à la prise de décisions. La procédure est simple : identifier chaque expéditeur, corriger les problèmes d'alignement, puis passer à l'application de la réglementation.
- Phase d'inventaire (semaines 1 à 4 à p=aucun) : Identifiez toutes les sources légitimes envoyant des e-mails depuis votre domaine. Si une source nécessite un alignement, veuillez effectuer les opérations nécessaires. SPF, DKIM et DMARC Mise en place avant de passer à l'application de la loi.
- Phase d'alignement (semaines 4 à 8 à p=aucun) : Vérifiez que chaque source légitime réussit le test SPF ou DKIM et que l'alignement avec le domaine d'origine est correct. Corrigez les cas non conformes en ajoutant la source au SPF, en activant la signature DKIM, ou les deux. Avant de passer à la mise en œuvre de mesures coercitives, l'objectif est d'atteindre des taux de réussite supérieurs à 95 % pour tous les expéditeurs légitimes sur plusieurs cycles de rapports consécutifs.
- Phase de mise en application (semaine 8+ à p=quarantaine, puis p=rejet) : Une fois que les rapports indiquent un alignement constant sans défaillances importantes provenant d'expéditeurs légitimes, passez en mode quarantaine (p=quarantine). Maintenez ce mode pendant 2 à 4 semaines et poursuivez la surveillance. Passez ensuite en mode rejet (p=reject). Maintenez la surveillance en mode rejet, car l'ajout de nouveaux expéditeurs peut entraîner de nouvelles défaillances d'alignement.
L'association d'un renforcement des liens et d'une hygiène rigoureuse des listes est essentielle. L'authentification confirme que l'e-mail provient bien de vous, tandis que des listes propres évitent les taux de rebond qui nuisent à la réputation, quel que soit le niveau d'authentification. La validation des listes avant les envois importants permet de maîtriser les taux de rebond. nettoyer votre liste de diffusion L'élimination des contacts obsolètes ou invalides protège les signaux de réputation qui soutiennent chaque étape de l'évolution des politiques.
Transformer les données DMARC en décisions
Les rapports DMARC agrégés sont des données opérationnelles. L'objectif n'est pas de les analyser à des fins théoriques, mais d'agir en fonction des informations qu'ils révèlent. Corrigez les expéditeurs légitimes qui ne sont pas alignés. Examinez les adresses IP inconnues. Passez à l'application des règles une fois que vos sources de confiance réussissent systématiquement.
L'objectif est un rapport fiable : sources connues, taux de réussite constants et absence de pics de trafic soudains provenant d'adresses IP inconnues. C'est cette prévisibilité qui garantit la sécurité de l'option p=reject et protège votre domaine contre l'usurpation d'identité.
Dans le cadre de votre phase d'alignement, validez vos listes d'envoi avec DeBounce. Validation de la liste de courrier électronique Supprime les adresses invalides, jetables et à haut risque des listes alimentant vos flux d'envoi authentifiés, ce qui réduit les taux de rebond et préserve la réputation que vous bâtissez grâce à l'authentification. Importez votre liste, supprimez les adresses indésirables et envoyez vos e-mails en toute confiance : l'authentification et la qualité des données sont garanties.
