Rapport DMARC et protocole DMARC : comprendre les données

DMARC est configuré et vous recevez des pièces jointes XML de Google, Microsoft ou Yahoo. Il faut maintenant distinguer un rapport DMARC du protocole lui-même.

DMARC est un protocole d’authentification, de politiques et de rapports ; son enregistrement DNS configure la politique demandée. Le rapport contient les observations de certains destinataires après évaluation de messages utilisant votre domaine. La configuration exprime une demande ; le rapport fournit des données partielles.

Pour configurer la messagerie, consultez la création d’e-mails avec votre domaine. Si les transferts affectent l’authentification, lisez le transfert du courrier d’un domaine vers Gmail. Ici, nous examinons les rapports après configuration.

Les rapports peuvent arriver après publication, sans délai garanti ni participation de tous les destinataires. Confondre enregistrement, politique, adresse de rapports et résultats peut conduire à modifier des DNS qui ne sont pas responsables du problème.

Nous verrons le contenu d’un rapport, sa différence avec l’enregistrement et les champs à examiner, sans attribuer automatiquement un échec à un abus ou au transfert.

Qu’est-ce qu’un rapport DMARC ?

Un rapport agrégé résume les données d’un destinataire participant : SPF, DKIM, alignement sur From, politique trouvée et traitement déclaré pour les messages observés.

Le rapport n’est pas la politique. Les destinataires prenant en charge les rapports peuvent lire le DNS, évaluer les messages utilisant votre domaine dans From et envoyer des résumés à rua. RFC 7489 définit ces rapports agrégés pour aider à comprendre l’authentification, les corrections et l’effet des politiques. Leur envoi est facultatif.

Rapport DMARC et enregistrement DMARC

L’enregistrement DNS configure DMARC ; le rapport fournit la télémétrie des destinataires participants. Aucun ne constitue un inventaire complet de tous vos envois.

La correction dépend du problème. Un enregistrement invalide peut empêcher l’application de la politique ; un enregistrement valide avec des échecs demande d’examiner services autorisés, transferts, alignement et sources potentiellement non autorisées. Le rapport ne tranche pas à lui seul.

Que contient un rapport DMARC ?

Les rapports regroupent les messages par IP et résultats. Examinez source, volume, SPF, DKIM, alignement et disposition. Dans le XML, auth_results contient l’authentification brute et policy_evaluated les résultats SPF et DKIM tenant compte de l’alignement ; ne les confondez pas.

Le XML peut contenir politique publiée, disposition, identifiants SPF et DKIM et résultats. DMARC réussit si SPF ou DKIM réussit avec alignement. Une disposition none ne prouve pas une réussite DMARC ni nécessairement une politique de surveillance ; quarantine ou reject rapporte une action, pas la légitimité ou l’innocuité du message.

Un échec SPF ne signifie pas que tous les messages échouent. Si DKIM réussit avec alignement, DMARC réussit ; SPF réussi et aligné peut aussi suffire.

Lisez le rapport dans cet ordre :

1. Examinez l’IP source et l’organisation émettrice du rapport.
2. Évaluez le volume. Un message et 20,000 messages présentent des impacts différents ; un envoi isolé peut aussi être critique.
3. Examinez la disposition none, quarantine ou reject sans la confondre avec le résultat DMARC.
4. Comparez SPF et DKIM et distinguez résultats bruts et évaluations avec alignement.
5. Vérifiez l’alignement sur le domaine réel de From.

Rapports agrégés et rapports d’échec

Un rapport DMARC désigne généralement l’agrégat demandé via rua. Les rapports d’échec ou forensiques utilisent ruf, peuvent fournir des données de messages particuliers et sont moins pris en charge. Ils ne contiennent pas obligatoirement des messages complets et peuvent inclure des données sensibles.

Pour une seule destination, commencer par rua est souvent utile, avec surveillance, contrôle d’accès et autorisation DNS sur le domaine destinataire externe si nécessaire. Les consignes d’envoi de Google expliquent que l’authentification peut influencer le traitement selon les exigences applicables. Les rapports fournissent des données opérationnelles, pas une garantie de remise.

Publier un enregistrement demandant des rapports DMARC

Publiez le TXT sur _dmarc avec une politique et une destination valide. La surveillance permet de demander des données avant les restrictions, même si les filtres locaux restent actifs.

Cet exemple impose un alignement strict : ce n’est pas une configuration initiale universellement sûre. Adaptez-la après vérification des flux et de leurs domaines :

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100"

Comme remplacement ultérieur, après inventaire et tests des flux légitimes, vous pouvez envisager cette politique restrictive :

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100"

Le mode strict exige le domaine exact ; le mode souple compare le domaine organisationnel. L’échantillonnage dépend du destinataire et n’impose pas de restrictions avec la surveillance. Envisagez le rejet après tests, examen des flux rares et plan de retour arrière, pas uniquement des rapports apparemment propres.

Vérifiez la publication avec une recherche :

dig TXT _dmarc.example.com +short

Dans TrekMail, l’assistant et les contrôles DNS disponibles peuvent repérer des absences ou conflits. Comparez recherches externes et messages réels : l’interface ne prouve pas tous les flux. Consultez l’ajout d’un domaine et les e-mails arrivant dans le spam.

Lire un rapport sans conclusions hâtives

Examinez séparément les échecs attendus et les sources potentiellement abusives. Un transfert peut expliquer un échec SPF ; une IP inconnue ne prouve pas une usurpation.

Le rapport aide à mesurer les résultats des sources observées et le traitement déclaré. Il ne prouve pas la remise du message ni l’innocuité du contenu.

Pourquoi le transfert complique les rapports

Après transfert, le destinataire suivant évalue SPF pour l’IP du relais et le domaine réel de MAIL FROM. Cela peut produire des échecs malgré un message original légitime.

N’ajoutez pas automatiquement à SPF les IP de boîtes personnelles ou d’anciens relais. DKIM peut préserver un résultat aligné si la signature reste valide et les données signées sont conservées après canonicalisation ; dire que le message a peu changé ne suffit pas.

SRS peut modifier l’expéditeur d’enveloppe pour SPF sans rétablir l’alignement sur From original. ARC peut éclairer des exceptions locales, pas transformer un échec en authentification DMARC réussie. Consultez la configuration et le dépannage du transfert.

Quand un rapport justifie une modification DNS

Modifiez le DNS lorsque l’examen identifie un expéditeur autorisé dont la configuration doit changer. Confirmez d’abord le service réel et le mécanisme en échec.

Évaluez les changements dans ces cas :

1. Le domaine d’enveloppe réel doit autoriser par SPF le fournisseur utilisant l’IP observée.
2. Le fournisseur signe avec un autre domaine et aucun mécanisme valide et aligné ne reste ; configurez et activez DKIM personnalisé ou un Return-Path adapté, pas simplement le suivi des liens.
3. Une application utilise une ancienne route SMTP : confirmez le changement nécessaire et testez la nouvelle configuration.
4. L’enregistrement n’a pas de destination rua, contient une syntaxe invalide ou une politique inadaptée à l’étape vérifiée.

Ne modifiez pas SPF uniquement parce qu’un rapport montre une IP de transfert Gmail ou Outlook en échec.

TrekMail peut centraliser domaines, contrôles DNS, boîtes, migration et SMTP selon le plan, plutôt que de coordonner registraires, XML et cinq fournisseurs sans inventaire. Vérifiez toujours l’envoi réel et le plafond SPF des mécanismes et modificateurs déclenchant des recherches DNS, évaluations imbriquées comprises, sans doublons. Consultez les paramètres IMAP et SMTP ou l’hébergement multidomaine.

Faut-il lire chaque rapport manuellement ?

Pour un petit domaine, la lecture manuelle initiale peut convenir. Avec davantage de données, un analyseur ou une boîte dédiée aide à organiser le XML et à contrôler l’accès.

Avec un domaine et peu d’expéditeurs, lire les rapports disponibles pendant le déploiement peut être viable. Avec dix domaines, cela prend plus de temps ; avec cinquante, prévoyez l’analyse et standardisez la configuration sans supposer des rapports quotidiens de tous les destinataires.

Des rapports sans échec pour les sources connues peuvent être encourageants, sans prouver un inventaire complet. Testez aussi les messages rares ou critiques ; une disposition restrictive ne démontre pas à elle seule une usurpation.

Processus recommandé pour les rapports DMARC

Publiez, observez, comparez l’inventaire, corrigez authentification et alignement, puis évaluez les restrictions. Les rapports sont une source partielle, pas une permission automatique de durcir la politique.

1. Publiez DMARC avec p=none et une boîte dédiée surveillée.
2. Recueillez des rapports pendant plusieurs jours comme première observation, sans garantie que chaque destinataire en envoie ni que cela couvre tous les flux.
3. Examinez trois catégories possibles : expéditeur autorisé, effet du transfert ou usurpation ; gardez non classées les sources non identifiées.
4. Corrigez les expéditeurs autorisés et vérifiez les transferts avec DKIM valide et aligné, sans les ignorer indistinctement.
5. Évaluez quarantine, puis reject après comparaison des rapports, journaux et tests des flux critiques rares, avec un plan de retour arrière.

Tout nouvel outil demande de vérifier SPF, DKIM et le Return-Path réellement utilisé. Changer de service peut modifier l’alignement sans changer le TXT DMARC.

TrekMail et la coordination DNS

TrekMail ne remplace pas DMARC. Selon le plan, il peut centraliser une partie de la gestion, mais vous devez publier et vérifier les enregistrements et expéditeurs.

Domaines personnalisés, boîtes IMAP, catch-all, transfert, copie IMAP et SMTP propre ou géré dépendent de l’offre et du plan. Pour les agences et MSP, gestion multidomaine et stockage mutualisé peuvent faciliter l’organisation. La copie ne remplace pas le changement des MX et ne migre pas toutes les applications.

Une facturation par utilisateur n’implique pas non plus l’absence d’inventaire ou d’outils. Comparez processus, limites et coûts : l’offre décrite présente des plans à partir de $3.50 par mois, Nano sans frais ni carte selon ses conditions et un essai gratuit de 14 jours pour les plans payants soumis aux exigences applicables. Consultez la page des tarifs TrekMail ; économies et absence d’incidents ne sont pas garanties.

Conclusion sur les rapports DMARC

Le rapport fournit des observations sur la politique et l’envoi réel. Il ne remplace pas le DNS et ne prouve pas que toute la configuration et tous les flux correspondent.

Retenez la distinction : DMARC est le protocole, le DNS configure sa politique et les rapports partiels aident à examiner expéditeurs, usurpations possibles et moment d’envisager quarantaine ou rejet. Combinez-les avec inventaire, journaux et tests pour décider, sans garantie de remise.