Rapports agrégés DMARC (RFC 9990)
Le format XML des rapports agrégés : structure du rapport, transport, conventions de nom de fichier et d’objet, vérification des destinations externes et motifs de dérogation à la politique.
Référence5 min de lecture
À qui cela s’adresse Opérateurs ESP, Expéditeurs
S’applique aux expéditeurs, quelle que soit leur plateforme
SommaireSur cette page : 6 sections
Quand l’enregistrement DMARC de votre domaine indique une adresse rua=, les serveurs de réception envoient régulièrement à cette adresse des récapitulatifs XML des emails qui utilisent votre domaine. Ces rapports agrégés sont la principale source de données pour décider quand un domaine peut passer à une politique contraignante (voir DMARC).
La RFC 9990 définit le format du rapport. C’est une spécification sur la voie des normes publiée en mai 2026, et l’un des trois documents DMARCbis qui rendent ensemble obsolète la RFC 7489, avec la RFC 9989 et la RFC 9991.
Contenu d’un rapport
Un rapport est un document XML dont l’élément racine est feedback et l’espace de noms urn:ietf:params:xml:ns:dmarc-2.0. Il comporte trois parties :
| Section | Contenu |
|---|---|
| Métadonnées du rapport | Le nom de l’organisation qui produit le rapport, une adresse email de contact, un identifiant unique du rapport, et le début et la fin de la période couverte, en secondes Unix. |
| Politique publiée | L’enregistrement DMARC que le serveur de réception a trouvé : le domaine, p, sp et np, adkim et aspf, et la façon dont l’enregistrement a été découvert (correspondance exacte ou Tree Walk). |
| Enregistrements (un ou plusieurs) | Les résultats pour chaque adresse IP source : la ligne, les identifiants et les résultats d’authentification bruts décrits ci-dessous. |
Éléments de chaque enregistrement
| Élément | Champs |
|---|---|
row |
L’adresse IP source (IPv4 ou IPv6) ; le nombre de messages pour cette combinaison d’adresse IP et de traitement ; le traitement appliqué (none, pass, quarantine, reject) ; et les résultats d’alignement DKIM et SPF, pass ou fail, tels que DMARC les évalue. |
identifiers |
header_from, le domaine RFC5322.From (obligatoire) ; envelope_from, le domaine RFC5321.MailFrom (facultatif) ; et le domaine envelope_to (facultatif). |
auth_results |
Le résultat brut de chaque mécanisme. Les entrées DKIM donnent le domaine, le sélecteur (son signalement est obligatoire dans la 9990), le résultat et une note facultative destinée à être lue par des personnes. Les entrées SPF donnent le domaine, la portée (mfrom) et le résultat. |
Quand un message porte de nombreuses signatures DKIM, le serveur de réception les signale dans cet ordre de priorité : un pass avec alignement strict, puis un pass avec alignement souple, puis les autres signatures valides, puis les signatures en échec. La spécification recommande de signaler au plus environ 100 signatures par ligne.
Motifs de dérogation à la politique
Quand le traitement appliqué par le serveur de réception diffère de la politique publiée, l’enregistrement en donne la raison :
| Motif | Signification |
|---|---|
local_policy |
Une exemption locale du serveur de réception, souvent fondée sur ARC (voir ARC) |
mailing_list |
Les heuristiques du serveur de réception ont détecté une liste de diffusion |
policy_test_mode |
Le mode test t=y de l’enregistrement était actif |
trusted_forwarder |
Une exemption accordée à un service de transfert connu |
other |
Tout autre motif, avec un commentaire facultatif |
Calendrier et transport
- La période couverte est généralement un jour UTC, qui commence à 00:00 UTC. Les périodes NE DEVRAIENT PAS se chevaucher.
- Les rapports sont envoyés par email à chaque URI mailto de
rua=. Le serveur de réception écarte d’abord toute URI mal formée, puis doit tenter la livraison vers chacune des URI restantes. - Le contenu DEVRAIT être du XML compressé en GZIP (
application/gzip). À défaut, il est envoyé entext/xml. - Le nom du fichier joint suit le modèle
receiver!policy-domain!begin-timestamp!end-timestamp[!unique-id].extension, par exemplemail.receiver.example!example.com!1013662812!1013749130.xml.gz. - La ligne d’objet suit le modèle
Report Domain: <policy-domain> Submitter: <reporter-domain> Report-ID: <id>. - Le flux d’emails qui transporte les rapports doit lui-même réussir DMARC avec un pass aligné. Un transport sécurisé (STARTTLS ou TLS) est recommandé.
Destinations de rapport externes
Si une adresse rua= se trouve hors du domaine organisationnel du domaine de la politique, le serveur de réception confirme d’abord que la destination a accepté de recevoir les rapports. Il interroge cet enregistrement :
<policy-domain>._report._dmarc.<destination-host> (TXT)
L’enregistrement doit contenir v=DMARC1, et il peut remplacer l’URI de rapport. Si l’enregistrement est absent, le serveur de réception n’envoie pas les rapports à l’adresse externe. C’est pourquoi les prestataires tiers de surveillance DMARC vous demandent soit de publier cet enregistrement de « vérification de destination externe » pour le compte de leur domaine, soit le publient déjà sur leur propre domaine.
Changements par rapport à la RFC 7489
- Le schéma XML (XSD) est resserré et clarifié, et les identifiants de rapport sont structurés plus rigoureusement.
- Le signalement du sélecteur DKIM est obligatoire. Les rapporteurs soumis à la 7489 l’omettaient souvent. Avec le sélecteur, il est bien plus facile d’identifier quel système a produit une signature en échec.
- La prise en compte des domaines de suffixe public (Public Suffix Domains) est intégrée, et un mécanisme d’extension est ajouté.
- Le document unique de la RFC 7489 a été scindé en trois : 9989 (base), 9990 (rapports agrégés) et 9991 (rapports d’échec).
Exploiter les rapports agrégés
- Les rapports sont des documents XML lisibles par des machines, et ils arrivent chaque jour de tous les grands serveurs de réception. Personne ne les lit à la main à grande échelle : dirigez donc
rua=vers une boîte aux lettres dédiée ou vers un service d’analyse DMARC. - Servez-vous-en pour répondre à une question : quelles sources envoient des emails au nom de mon domaine, et ces emails obtiennent-ils un pass aligné ? Des lignes en échec sur les deux mécanismes, depuis des adresses IP que vous reconnaissez, désignent une source légitime mal configurée ; corrigez SPF, DKIM ou l’alignement. Des lignes provenant d’adresses IP que vous ne reconnaissez pas désignent une usurpation d’identité (spoofing) ou de l’informatique parallèle (shadow IT).
- Quand toutes les sources légitimes affichent des pass alignés sur une période prolongée, le domaine est prêt pour
p=quarantineoup=reject.
Voir aussi
- DMARC
- Référence de la norme DMARC
- Rapports d’échec DMARC
- En-tête Authentication-Results, les mêmes données pour un seul message
Vérifier votre propre enregistrement
Le diagnostic gratuit lit ce que votre domaine publie dans le DNS.
Dans ce thème
- SPF (Sender Policy Framework)
- DKIM (DomainKeys Identified Mail)
- Rotation des clés DKIM
- Attaques par rejeu DKIM