Les fichiers XML que les messageries destinataires vous envoient chaque jour deviennent lisibles : qui envoie des courriels en votre nom, ce qui passe, ce qui échoue, et ce qu'il faut corriger avant de durcir votre politique.
Ils arrivent par courriel à l'adresse indiquée dans la balise rua= de votre enregistrement DMARC (_dmarc.votre-domaine), en pièce jointe .xml.gz ou .zip, en général une fois par jour et par messagerie destinataire. Enregistrez les pièces jointes puis déposez-les ici, sans les décompresser.
Pas de rapports ? Votre domaine n'a peut-être pas de balise rua= : vérifiez-le avec le score de sécurité du domaine. Les rapports « forensiques » (balise ruf=, un message par échec) ont un autre format et ne sont pas lus par cet outil.
Les exports contiennent les adresses IP et les domaines présents dans les rapports : partagez-les avec prudence.
Les chiffres viennent des rapports eux-mêmes : l'outil additionne ce que les messageries destinataires ont déclaré, sans rien estimer. Seuls le classement des IP et les conseils sont une interprétation, expliquée ci-dessous.
Le type est reconnu au contenu, pas à l'extension. Les .gz sont décompressés par le navigateur (DecompressionStream) ; les .zip par un lecteur intégré (répertoire central, méthodes « stockée » et « deflate », somme de contrôle CRC-32 vérifiée). Les archives chiffrées, ZIP64 ou multi-parties sont refusées. La décompression s'arrête au-delà de 25 Mo par rapport et 200 Mo au total : une « bombe » de décompression ne peut pas saturer la page.
Le XML est lu comme une donnée inerte (DOMParser, mode application/xml) ; tout fichier contenant DOCTYPE ou ENTITY est refusé. Format RFC 7489 (sans espace de noms ou dmarc-xml/0.1, balise pct) et format DMARCbis, RFC 9990 de mai 2026 (espace de noms urn:ietf:params:xml:ns:dmarc-2.0, version 1.0, balises np, testing, discovery_method, generator, traitement « pass »). Un rapport imparfait est lu quand c'est possible, avec un avertissement ; un doublon (même émetteur, même identifiant) est écarté.
Un message est conforme quand le destinataire déclare DKIM aligné et réussi OU SPF aligné et réussi (policy_evaluated). C'est le verdict du destinataire qui compte ; l'outil ne recalcule l'alignement que s'il manque, et le signale. « Rejetés ou en quarantaine » additionne les traitements reject et quarantine déclarés, y compris ceux d'une politique locale du destinataire.
Légitime probable : au moins 90 % des messages de l'IP sont conformes. Échec : aucun message conforme, et aucun authentifié, même pour un autre domaine. À vérifier : tout le reste (résultats mélangés, service authentifié au nom d'un autre domaine, transferts). Une IP « légitime probable » peut appartenir à un compte piraté ; une IP « à vérifier » est souvent un service à vous mal configuré.
Elles découlent des résultats bruts (auth_results) : DKIM ou SPF réussi pour un domaine non aligné (service tiers), alignement strict trop exigeant, conformité par SPF seul, erreurs DKIM ou SPF, absence totale d'authentification, transferts déclarés, politique p=none, pct ou t=y. L'alignement relâché compare les domaines organisationnels, approchés par une liste de suffixes publics courants (extrait de la Public Suffix List). Le nom d'un service connu n'est qu'un indice, déduit du domaine de signature ou de retour.
Un rapport ne date pas chaque message : il couvre une période (date_range, en général une journée UTC). Chaque rapport est donc rattaché au jour UTC du milieu de sa période ; une période de plus de 26 heures est signalée. Plusieurs rapports s'additionnent ; si plusieurs domaines sont présents, un sélecteur permet de les analyser séparément. La politique affichée est la plus récente observée dans les rapports.
Un rapport ne voit que les messages reçus par la messagerie qui l'a envoyé : la somme des rapports n'est pas la totalité de vos envois. Les chiffres sont déclaratifs ; un rapport peut être erroné ou forgé, et l'outil ne vérifie pas son origine. Le classement et les conseils sont des aides à la lecture : avant de passer à p=reject, confirmez chaque source légitime avec ceux qui gèrent vos services d'envoi.
Vérifiez l'enregistrement DMARC publié (p, rua, alignement), SPF, DNSSEC et MTA-STS de votre domaine.
Un message précis échoue ? Ses en-têtes montrent le trajet, SPF, DKIM et DMARC tels que le destinataire les a vus.
Sortez proprement les IP et domaines suspects pour les partager avec votre équipe ou votre prestataire.
Historique, travail à plusieurs et rapports : l'abonnement cloud hébergé au Maroc est en accès anticipé.
