// comment corriger
Comment lire les rapports agrégés DMARC (rua)
Les rapports DMARC sont des fichiers XML envoyés par Gmail, Microsoft et d'autres. Découvrez ce que signifie chaque partie et comment repérer les vrais problèmes et l'usurpation.
Ce que ça veut dire
Quand votre enregistrement DMARC contient une adresse rua=, les serveurs de réception comme Google, Microsoft et Yahoo vous envoient un résumé quotidien appelé rapport agrégé. Il liste chaque adresse IP qui a envoyé des emails avec votre domaine, le nombre d'emails, et s'ils ont passé le SPF et le DKIM.
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
Les rapports arrivent en pièces jointes compressées (.zip ou .gz) qui contiennent un fichier XML. Ils sont écrits pour des machines, mais vous pouvez les lire.
Pourquoi c'est important
- Ils montrent tous vos expéditeurs, y compris ceux que vous avez oubliés : un outil de facturation, un vieux serveur, l'application d'un collègue.
- Ils révèlent les personnes qui tentent d'envoyer de faux emails avec votre domaine.
- Vous en avez besoin avant de faire passer le DMARC de
p=noneàquarantineoureject, pour être sûr que rien de légitime ne sera bloqué.
Les grandes parties d'un rapport
Qui a envoyé le rapport
Dans report_metadata : org_name (par exemple google.com), un report_id et une date_range, en général 24 heures, écrite sous forme de timestamps Unix.
Votre politique publiée
Dans policy_published : l'enregistrement DMARC vu par le serveur de réception, comme p=none et les modes d'alignement.
Un bloc par source
Chaque record décrit une IP d'envoi :
<source_ip>203.0.113.10</source_ip> <count>42</count> <disposition>none</disposition> <dkim>pass</dkim> <spf>fail</spf> <header_from>yourdomain.com</header_from>
count: le nombre d'emails venant de cette IP.disposition: ce qu'a fait le serveur de réception (none, quarantine, reject).dkimetspfsouspolicy_evaluated: le résultat DMARC, qui exige que le domaine corresponde à celui de votre adresse From. Un seul « pass » suffit pour que le DMARC passe.auth_results: les contrôles SPF et DKIM bruts, avec le domaine réellement vérifié. Comparez-le avecheader_frompour comprendre les échecs d'alignement.
Comment les utiliser
- Identifiez chaque IP. Cherchez son nom reverse DNS ou son propriétaire. Des noms comme
google.com,outlook.comou le domaine de votre outil de newsletter sont en général les vôtres. - Classez-les en trois groupes :
- Vos services, qui passent : rien à faire.
- Vos services, qui échouent : ajoutez-les au SPF, ou configurez le DKIM avec votre domaine dans ce service.
- Des IP inconnues qui échouent partout : probablement de l'usurpation. Votre future politique
rejectles bloquera.
- Suivez la tendance pendant quelques semaines avant de durcir votre politique.
À noter : les emails transférés et les listes de diffusion apparaissent souvent comme des échecs venant d'IP que vous ne connaissez pas. Un petit nombre est normal.
Simplifiez-vous la vie
Lire du XML à la main devient vite fastidieux quand vous recevez beaucoup de rapports. Utilisez une boîte dédiée pour le rua, et envisagez un outil qui collecte et résume les rapports. La surveillance DMARC du tableau de bord payant le fait pour vos domaines.
Vérifiez que ça fonctionne
Analysez votre domaine sur /domain-scanner pour confirmer que l'enregistrement DMARC contient une adresse rua valide. Les rapports commencent en général à arriver sous un ou deux jours, de la part des fournisseurs qu'utilisent vos destinataires.
Vérifiez que c'est corrigé
Une modification DNS peut prendre de quelques minutes à quelques heures. Ensuite, envoyez un nouvel email de test ou scannez à nouveau votre domaine.
Fiches liées
- Aucun enregistrement SPF sur votre domaineVotre domaine n'indique pas quels serveurs ont le droit d'envoyer des emails en son nom. Ajoutez un enregistrement TXT et les destinataires sauront distinguer vos vrais emails des faux.
- Erreur SPF : trop de requêtes DNS (permerror)Le SPF autorise au maximum 10 requêtes DNS. Au-delà, tout l'enregistrement est cassé et les destinataires le considèrent comme invalide. Voici comment l'alléger.
- Plusieurs enregistrements SPF sur un même domaineUn domaine ne doit avoir qu'un seul enregistrement SPF. Avec deux ou plus, le SPF échoue pour tous vos emails. Fusionnez-les en une seule ligne.
- Échec SPF : le serveur d'envoi n'est pas autoriséVotre domaine a un enregistrement SPF, mais le serveur qui a envoyé votre email n'y figure pas. Trouvez quel service a envoyé l'email et ajoutez-le.
- Aucune signature DKIM sur vos emailsLe DKIM ajoute une signature numérique qui prouve qu'un email vient bien de votre domaine. Activez-le chez votre fournisseur de messagerie et publiez sa clé dans le DNS.