Rapport DMARC : comment le lire et agir

Qu'est-ce qu'un rapport DMARC ?

Un rapport DMARC est un retour qu'un serveur de messagerie destinataire envoie au propriétaire d'un domaine à propos des e-mails qui prétendaient provenir de ce domaine. La spécification DMARC publiée par l'IETF en décrit deux types. Les rapports agrégés sont envoyés à l'adresse indiquée dans la balise rua de votre enregistrement DMARC. Ils résument tous les messages vus par le destinataire, regroupés par IP d'envoi et par résultat. Les rapports d'échec (souvent appelés rapports forensiques) sont envoyés à l'adresse de la balise ruf et décrivent des messages individuels qui ont échoué. Vous ne recevez des rapports que si votre enregistrement les demande. Un enregistrement comme v=DMARC1; p=none; rua=mailto:dmarc@votredomaine.com publie la politique et demande des rapports agrégés. Sans rua, les destinataires appliquent quand même votre politique, mais ils ne vous disent rien. Le rapport couvre ce que le destinataire a vu, pas tout ce que vous avez envoyé. Un domaine qui n'écrit qu'à des utilisateurs Gmail et Microsoft reçoit des rapports de ces deux destinataires, et de personne d'autre. Si vous n'avez pas encore publié d'enregistrement, commencez par créer l'enregistrement TXT sur _dmarc.

À quelle fréquence arrivent les rapports DMARC, et sous quel format ?

La spécification DMARC permet au propriétaire du domaine de demander un intervalle de rapport via la balise ri, et l'intervalle par défaut est d'un jour. Les destinataires restent libres de s'en tenir à des rapports quotidiens quelle que soit votre demande, et la plupart le font. Chaque rapport arrive sous forme d'e-mail avec une pièce jointe compressée, généralement gzip (.xml.gz) ou zip, contenant un fichier XML. Le nom du fichier indique en général le domaine du destinataire, votre domaine et les horodatages de début et de fin. Ces horodatages sont en secondes Unix (epoch) en UTC : un rapport qui « commence à minuit » ne commence donc pas forcément à votre minuit local. Un détail piège souvent ceux qui envoient leurs rapports vers un autre domaine, par exemple un service de monitoring. La spécification DMARC impose au domaine récepteur de publier un enregistrement TXT sur votredomaine.com._report._dmarc.leurdomaine.com pour confirmer qu'il accepte vos rapports. Si cet enregistrement manque, les destinataires conformes ignorent l'adresse rua externe sans aucun avertissement, et votre boîte de réception des rapports reste tout simplement vide.

Comment lire un rapport DMARC agrégé, champ par champ

Un rapport agrégé comporte trois parties : report_metadata (qui l'a envoyé et la période couverte), policy_published (votre enregistrement DMARC tel que le destinataire l'a lu) et un ou plusieurs éléments record. C'est dans les éléments record que se fait le vrai travail d'analyse.

Élément XML	Ce qu'il contient	Ce qu'il faut vérifier
report_metadata / org_name, date_range	Le destinataire qui fait le rapport et les horodatages Unix de début et de fin	Quel fournisseur de messagerie est concerné, et quel jour
policy_published / p, sp, pct, adkim, aspf	Votre politique, la politique des sous-domaines, le pourcentage et le mode d'alignement (r relaxed, s strict)	Que cela correspond bien à ce que vous pensez avoir publié. Une faute de frappe dans le DNS apparaît ici
row / source_ip	L'IP qui a livré les messages	Faites une résolution inverse pour identifier le service : votre Workspace, Brevo, un CRM ou un inconnu
row / count	Le nombre de messages de cette IP ayant obtenu le même résultat	Pondérez les lignes selon le volume. Un seul message depuis une IP inhabituelle relève généralement du transfert
policy_evaluated / disposition	Ce que le destinataire a fait : none, quarantine ou reject	Doit correspondre à votre p=, sauf si le destinataire a appliqué sa propre décision
policy_evaluated / dkim, spf	Le résultat aligné DMARC : pass uniquement si le domaine authentifié correspond à votre domaine From	Au moins l'un des deux doit être en pass pour que DMARC passe
identifiers / header_from	Le domaine de l'adresse From visible	Les sous-domaines apparaissent séparément ici
auth_results / dkim (domain, selector, result)	La vérification DKIM brute, avec le domaine de signature d= et le sélecteur	Un pass sur le domaine d'un prestataire ne compte pas pour DMARC
auth_results / spf (domain, result)	La vérification SPF brute sur le domaine de l'expéditeur d'enveloppe (Return-Path)	Un pass sur un domaine de rebond qui ne vous appartient pas ne sera pas aligné

L'erreur de lecture la plus fréquente consiste à prendre auth_results pour le verdict. Ce n'en est pas un. Prenez une ligne où auth_results indique spf pass alors que policy_evaluated indique spf fail. SPF a bien réussi pour un domaine, en général le domaine de rebond propre au service d'envoi, mais ce domaine ne correspond pas à votre domaine From. SPF ne compte donc pour rien au regard de DMARC, et le message ne passe DMARC que si DKIM est aligné.

Que faire de vos rapports DMARC ?

Les rapports ne servent que si chaque ligne finit dans une catégorie. Regroupez par source_ip, additionnez count pour chaque groupe, puis traitez les cas suivants :

1. 1 Votre propre service, pass aligné en DKIM ou en SPF : rien à faire. Notez la plage d'IP et le sélecteur DKIM pour le reconnaître la prochaine fois.
2. 2 Votre propre service, échec aligné : le service envoie au nom de votre domaine sans signer pour lui. La cause habituelle : DKIM est encore signé avec le domaine d= du prestataire, parce que votre clé DKIM personnalisée n'a jamais été publiée ou activée. Corrigez le DNS avant de toucher à p=.
3. 3 Redirecteur ou liste de diffusion connus, SPF en échec, DKIM parfois en pass : le transfert change l'IP de livraison, ce qui casse SPF, et les pieds de page de liste ou les balises ajoutées à l'objet peuvent aussi casser la signature DKIM. Vous ne pouvez pas corriger cela de votre côté. De petits volumes de ce type sont normaux.
4. 4 IP inconnue, échec des deux, volume significatif : quelqu'un usurpe votre domaine, ou une équipe a souscrit à un outil sans prévenir personne. Renseignez-vous en interne avant de parler d'abus.
5. 5 Lignes sous des sous-domaines header_from que vous n'utilisez pas : candidates à une politique sp=reject une fois votre domaine principal assaini.

Passer de p=none à quarantine n'est sûr qu'une fois que chaque source légitime est restée un moment dans la première catégorie. Si vous durcissez alors qu'un CRM ou un outil de facturation est encore dans la deuxième, les e-mails de cet outil finissent en spam ou sont rejetés. Les rapports des dernières semaines sont le moyen de le savoir. Avant de modifier un enregistrement, prenez le temps de comprendre comment DKIM, DMARC et SPF dépendent les uns des autres. Vous pouvez vérifier ce qui est en ligne en ce moment avec le vérificateur SPF, DKIM et DMARC.

DMARC avec Google Workspace : ce que montrent les rapports

Si votre domaine tourne sous Google Workspace, distinguez bien deux rôles. En tant qu'expéditeur, votre enregistrement DMARC se trouve chez votre hébergeur DNS, sous forme d'enregistrement TXT sur _dmarc.votredomaine.com. La console d'administration Workspace ne le crée pas pour vous. Les e-mails envoyés depuis les boîtes Workspace apparaissent dans les rapports des autres destinataires avec des plages d'IP Google comme source_ip. Si vous avez activé DKIM dans Workspace, ils apparaissent avec une signature DKIM utilisant le sélecteur google et d= votre domaine, le sélecteur par défaut indiqué dans la documentation d'administration de Google. Si la clé DKIM a été générée mais jamais activée via Start authentication (Démarrer l'authentification), ces lignes montrent une signature DKIM par un domaine Google et un échec DKIM aligné. En tant que destinataire, Gmail vous envoie des rapports agrégés avec org_name google.com. L'article d'aide Workspace de Google « About DMARC reports » décrit les rapports agrégés. Ne comptez pas sur des rapports d'échec (ruf) de la part de Gmail. Une configuration Workspace courante associe les e-mails Workspace à un service d'envoi distinct comme Brevo sur le même domaine. Vous verrez alors deux groupes de lignes, chacun ayant besoin de son propre DKIM aligné. L'enregistrement lui-même et l'ordre de déploiement sont détaillés dans notre guide enregistrement DMARC Google Workspace et déploiement.

Quel outil utiliser pour lire vos rapports DMARC ?

Lire le XML brut fonctionne pour un domaine avec deux expéditeurs et un faible volume. Dès que plusieurs destinataires envoient des rapports chaque jour, il vous faut un outil qui analyse les fichiers et regroupe les lignes. Les options ci-dessous sont celles citées dans les résultats de recherche actuels sur ce sujet. La comparaison porte sur le fonctionnement de chaque type d'option, pas sur les limites propres à chaque compte.

Option	Fonctionnement	Adaptée à	Limites
XML brut dans un éditeur de texte	Décompresser la pièce jointe et lire les éléments record à la main	Un domaine, un ou deux services d'envoi, une vérification rapide	Pas de tendance dans le temps ni de regroupement entre destinataires. Laborieux au-delà de quelques lignes
MxToolbox DMARC Report Analyzer	Coller ou téléverser un rapport unique et obtenir une vue analysée (un analyseur XML, d'après le titre de sa page)	Comprendre un rapport que vous venez de recevoir	Fonctionne rapport par rapport et ne collecte pas votre flux quotidien de lui-même
Monitoring DMARC hébergé (par ex. Postmark DMARC, EasyDMARC, PowerDMARC, dmarcreport.com)	Vous faites pointer rua vers l'adresse du prestataire, qui collecte, analyse et synthétise les rapports dans le temps	Surveillance continue de plusieurs expéditeurs et destinataires, avant de passer à quarantine	Le prestataire reçoit vos données de rapport, et un rua externe nécessite l'enregistrement d'autorisation du prestataire. Offres et fonctionnalités varient : consultez la documentation de chaque éditeur
Votre propre boîte mail plus un script	rua pointe vers une boîte que vous contrôlez, et vous analysez le XML avec votre propre code	Les équipes qui veulent garder les données de rapport en interne	Vous développez et maintenez vous-même l'analyse et le stockage

Quel que soit votre choix, aucun de ces outils ne change la décision du destinataire. Ils vous montrent ce qui s'est passé. Les corrections se font toujours dans votre DNS et dans les paramètres de domaine de chaque service d'envoi.

Comment les envois EmailFlow OS apparaissent dans vos rapports DMARC

EmailFlow OS fonctionne sur votre propre infrastructure : son trafic apparaît donc dans vos rapports comme votre trafic. Vous enregistrez une seule vidéo et la téléversez dans EmailFlow OS. Ensuite, vous connectez votre compte Brevo et votre domaine d'envoi, puis vous importez votre liste de prospects dans EmailFlow OS. EmailFlow OS personnalise cet enregistrement unique pour chaque destinataire, et non pour chaque entreprise, et envoie chaque version depuis votre propre boîte mail, via votre propre compte Brevo et votre propre domaine d'envoi. Il n'y a pas d'expéditeur partagé de la plateforme. Dans les rapports agrégés, ces envois apparaissent donc sous votre domaine header_from, avec les IP d'envoi de Brevo comme source_ip. Leur passage de DMARC dépend de la clé DKIM que vous avez publiée pour Brevo sur votre domaine. Si elle est configurée et alignée, les lignes tombent dans la première catégorie. Sinon, elles tombent dans la deuxième, comme n'importe quel autre service mal configuré. Vos rapports vous permettent de le vérifier avant d'envoyer en volume. Pour en savoir plus sur l'e-mail vidéo IA personnalisé depuis votre propre domaine avec EmailFlow OS, rendez-vous sur la page d'accueil.

Questions fréquentes

? Pourquoi je ne reçois aucun rapport DMARC ?

Il y a trois causes habituelles. Votre enregistrement DMARC n'a pas de balise rua. L'adresse rua se trouve sur un autre domaine qui n'a pas publié l'enregistrement TXT d'autorisation exigé par la spécification DMARC pour les adresses de rapport externes. Ou l'enregistrement est cassé, par exemple deux enregistrements v=DMARC1 sur _dmarc, ce que les destinataires traitent comme une absence d'enregistrement. Les rapports arrivent généralement une fois par jour : comptez au moins une journée après toute correction.

? Quelle différence entre les rapports rua et ruf ?

Les rapports rua sont agrégés. Ce sont des synthèses XML quotidiennes regroupées par IP d'envoi et par résultat, sans contenu de message. Les rapports ruf sont des rapports d'échec sur des messages individuels qui ont échoué, et ils peuvent inclure des en-têtes ou des parties du message. Les rapports agrégés sont largement envoyés. Beaucoup de grands destinataires envoient peu ou pas de rapports d'échec, en partie à cause des données personnelles concernées.

? Un rapport DMARC signifie-t-il que mon e-mail est arrivé en boîte de réception ?

Non. Le champ disposition indique seulement si le destinataire a appliqué votre politique DMARC : none, quarantine ou reject. Un message avec disposition none et des pass alignés peut quand même finir en spam à cause de la réputation, du contenu ou des plaintes. Les rapports DMARC couvrent l'authentification, pas le placement en boîte de réception. Le placement se mesure avec d'autres outils, comme Google Postmaster Tools ou des tests sur adresses témoins (seed tests).

? Un échec DMARC dans mon rapport, est-ce toujours de l'usurpation ?

Non. Les échecs viennent aussi du transfert, qui casse SPF et parfois DKIM. Ils viennent aussi des listes de diffusion qui modifient les messages, et de vos propres services qui envoient sans clé DKIM alignée sur votre domaine. Vérifiez d'abord source_ip et le domaine DKIM d=. Ne parlez d'usurpation que si l'IP n'appartient à aucun de vos services ni à un redirecteur connu.