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.
La RFC 9990 (sur la voie des normes, mai 2026 ; elle fait partie de l’ensemble DMARCbis avec la RFC 9989 et la RFC 9991, qui ensemble rendent obsolète la RFC 7489) définit le rapport agrégé (aggregate feedback report) : le récapitulatif XML que les serveurs de réception envoient aux adresses rua= de l’enregistrement DMARC d’un domaine. Les rapports agrégés sont la principale source de données pour décider quand un domaine peut passer à une politique contraignante ; voir DMARC.
Contenu d’un rapport
Document XML, élément racine feedback, espace de noms urn:ietf:params:xml:ns:dmarc-2.0 :
| Section | Contenu |
|---|---|
| Métadonnées du rapport | Nom de l’organisation qui produit le rapport, email de contact, identifiant unique du rapport, début et fin de la période couverte (secondes Unix). |
| Politique publiée | L’enregistrement DMARC trouvé par le serveur de réception : domaine, p/sp/np, adkim/aspf, méthode de découverte (correspondance exacte ou Tree Walk). |
| Enregistrements (un ou plusieurs) | Résultats par 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 |
Adresse IP source (v4 ou v6) ; nombre de messages pour cette combinaison adresse IP/traitement ; traitement appliqué (none, pass, quarantine, reject) ; résultats d’alignement DKIM et SPF (pass/fail du point de vue de DMARC). |
identifiers |
header_from (domaine RFC5322.From, obligatoire) ; envelope_from (domaine RFC5321.MailFrom, facultatif) ; domaine envelope_to (facultatif). |
auth_results |
Résultats bruts par mécanisme : entrées DKIM avec domaine, sélecteur (obligatoire selon la RFC 9990), résultat et note lisible facultative ; entrées SPF avec domaine, portée (mfrom) et résultat. |
Pour les messages qui portent de nombreuses signatures DKIM, l’ordre de priorité du signalement est : pass avec alignement strict > pass avec alignement souple > autres signatures valides > signatures en échec ; il est recommandé de ne pas dépasser environ 100 signatures par ligne.
Motifs de dérogation à la politique
Quand le traitement appliqué diffère de la politique publiée, l’enregistrement en donne la raison :
| Motif | Signification |
|---|---|
local_policy |
Exemption locale du serveur de réception (souvent fondée sur ARC ; voir ARC) |
mailing_list |
Heuristiques de détection des listes de diffusion |
policy_test_mode |
Le mode test t=y de l’enregistrement était actif |
trusted_forwarder |
Exemption accordée à un service de transfert connu |
other |
Tout autre cas, avec un commentaire facultatif |
Calendrier et transport
- Période couverte : en général un jour UTC commençant à 00:00 UTC ; les périodes NE DEVRAIENT PAS se chevaucher.
- Envoi par email à chaque URI mailto de
rua=(après élimination des URI mal formées ; une tentative de livraison doit être faite vers chacune des URI restantes). - Le contenu DEVRAIT être du XML compressé en GZIP (
application/gzip) ; à défaut,text/xml. - Nom du fichier joint :
receiver!policy-domain!begin-timestamp!end-timestamp[!unique-id].extension, par exemplemail.receiver.example!example.com!1013662812!1013749130.xml.gz. - Ligne d’objet :
Report Domain: <policy-domain> Submitter: <reporter-domain> Report-ID: <id>. - Le flux d’emails qui transporte les rapports doit lui-même passer DMARC avec un pass aligné ; un transport sécurisé (STARTTLS/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 vérifie le consentement en interrogeant :
<policy-domain>._report._dmarc.<destination-host> (TXT)
L’enregistrement doit contenir v=DMARC1 (et peut remplacer l’URI de rapport). Sans lui, les rapports ne sont pas envoyés à l’adresse externe. C’est pourquoi les prestataires tiers de surveillance DMARC vous demandent de publier cet enregistrement de « vérification de destination externe » pour le compte de leur domaine, à moins qu’il n’existe déjà chez eux.
Changements par rapport à la RFC 7489
- Schéma XSD resserré et clarifié ; identifiants de rapport structurés plus rigoureusement.
- Le signalement du sélecteur DKIM est obligatoire (les rapports de l’époque de la 7489 l’omettaient souvent), ce qui permet d’identifier bien plus facilement quel système a produit une signature en échec.
- Prise en compte intégrée des domaines de suffixe public (Public Suffix Domain) ; ajout d’un mécanisme d’extension.
- La RFC 7489, d’un seul bloc, a été scindée en 9989 (base), 9990 (rapports agrégés) et 9991 (rapports d’échec).
Exploiter les rapports agrégés
- Ce sont des documents XML destinés aux machines, qui arrivent chaque jour de tous les grands serveurs de réception : dirigez
rua=vers une boîte aux lettres dédiée ou un service d’analyse DMARC ; personne ne les lit à la main à grande échelle. - Lisez-les pour répondre à la question : quelles sources envoient au nom de mon domaine, et obtiennent-elles un pass aligné ? Des lignes en échec sur les deux mécanismes depuis des adresses IP que vous connaissez = une source légitime mal configurée (corrigez SPF/DKIM ou l’alignement). Des lignes provenant d’adresses IP inconnues = usurpation d’identité (spoofing) ou 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=quarantine/p=reject.
Voir aussi
- DMARC · Référence de la norme DMARC · Rapports d’échec DMARC
- En-tête Authentication-Results — la vue message par message des mêmes données