Analyse des rapports DMARC : lire un rapport agrégé et repérer les expéditeurs fantômes

Pour analyser un rapport DMARC agrégé (RFC 9990, mai 2026), lisez dans l’ordre org_name avec la période, policy_published, puis chaque record : source_ip, count et policy_evaluated, comparé à auth_results. Une IP inconnue ou un alignement en échec désigne un expéditeur à identifier avant tout passage à p=reject.

6 mois après avoir publié rua=mailto:dmarc@exemple.com, la boîte peut contenir des centaines de fichiers .xml.gz que personne n’ouvre. Un seul de ces fichiers suffit pour apprendre la structure. Le reste se traite en lot.

Par où commencer face à des centaines de rapports

Ouvrez d’abord un seul fichier, celui d’un gros receveur, après décompression avec gunzip (commande gunzip rapport.xml.gz). Repérez les blocs décrits plus bas. Ensuite, chargez l’ensemble dans parsedmarc (auto-hébergé) ou dans un analyzer hébergé comme dmarcian, PowerDMARC ou EasyDMARC, qui agrège les record par IP. Un critère de choix suffit : trouver une IP inconnue en moins de 3 clics. Triez sur count décroissant : les premières lignes concentrent le volume et se classent vite.

Ne lisez pas les fichiers un par un. Les grands receveurs comme Google et Yahoo envoient en général un rapport par domaine et par période de 24 heures. La RFC 9989 (section 5.3.8) recommande (SHOULD) au moins un envoi toutes les 24 heures, sans l’imposer. Certains receveurs n’envoient aucun rapport. Le nom de la pièce jointe suit le gabarit receveur!domaine!début!fin.xml.gz, avec des horodatages en secondes Unix (RFC 9990). Exemple tiré de la RFC : mail.receiver.example!example.com!1013662812!1013749130.xml.gz, qui couvre la période du 14 février 2002 à 05 h 00 UTC au 15 février 2002 à 04 h 58 UTC.

Les champs d’un rapport agrégé

La RFC 9990 (mai 2026) décrit une racine feedback, un bloc report_metadata, un bloc policy_published et au moins un record. Un record associe une IP source à ses résultats d’authentification.

Lire un extrait XML annoté

L’extrait omet report_metadata. Les IP appartiennent à la plage 203.0.113.0/24 réservée à la documentation.

<policy_published>
  <domain>exemple.com</domain>
  <p>none</p>           <!-- politique lue dans le DNS -->
  <adkim>r</adkim>        <!-- alignement DKIM relaxed -->
  <aspf>r</aspf>          <!-- alignement SPF relaxed -->
</policy_published>

<record>                 <!-- IP connue : MTA maison -->
  <row>
    <source_ip>203.0.113.10</source_ip>
    <count>1240</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim><spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers><header_from>exemple.com</header_from></identifiers>
  <auth_results>
    <dkim><domain>exemple.com</domain><selector>s1</selector><result>pass</result></dkim>
    <spf><domain>exemple.com</domain><result>pass</result></spf>
  </auth_results>
</record>

<record>                 <!-- IP à examiner : outil d'envoi tiers -->
  <row>
    <source_ip>203.0.113.55</source_ip>
    <count>380</count>
    <policy_evaluated>
      <disposition>none</disposition>  <!-- livré car p=none -->
      <dkim>fail</dkim><spf>fail</spf>  <!-- alignement en échec -->
    </policy_evaluated>
  </row>
  <identifiers><header_from>exemple.com</header_from></identifiers>
  <auth_results>
    <dkim><domain>esp-envoi.example</domain><selector>k1</selector><result>pass</result></dkim>
    <spf><domain>bounce.esp-envoi.example</domain><result>pass</result></spf>
  </auth_results>
</record>

Le premier record (IP 203.0.113.10, 1240 messages) ne demande rien. Le second (IP 203.0.113.55) montre le cas qui fait perdre du temps : 380 messages livrés grâce à p=none, avec un DKIM et un SPF en pass dans auth_results et un échec dans policy_evaluated.

policy_evaluated contre auth_results

D’après la RFC 9990, auth_results contient les résultats DKIM et SPF « non interprétés » au regard de DMARC. Elle impose en revanche que les valeurs dkim et spf de policy_evaluated soient celles « évaluées » pour DMARC. Un message passe quand au moins un identifiant authentifié s’aligne avec le domaine du From (RFC 9989, section 5.3.5).

Dans l’extrait, pour l’IP 203.0.113.55, la signature DKIM porte d=esp-envoi.example et le domaine SPF est bounce.esp-envoi.example. Aucun des deux ne s’aligne avec exemple.com. Le receveur note donc un échec DMARC alors que les deux mécanismes réussissent sur leurs propres domaines. Les analyzers affichent cette ligne en rouge. La correction se fait chez le prestataire : signer en DKIM avec votre domaine ou, à défaut, utiliser un domaine de retour (MAIL FROM) sous le vôtre. Côté SPF, un include: de plus consomme l’un des 10 termes déclenchant une requête DNS que la RFC 7208 (2014) autorise par évaluation (au-delà : permerror). La checklist de diagnostic SPF détaille ce plafond. La signature DKIM sur votre domaine évite ce coût.

Un message transféré perd souvent son alignement SPF, car l’IP du relais ne figure pas dans votre enregistrement. DKIM (RFC 6376, 2011) survit au transfert tant que le contenu signé reste intact.

adkim et aspf : relaxed ou strict

Les tags adkim et aspf valent r (relaxed) par défaut selon la RFC 9989. En mode relaxed, les domaines s’alignent s’ils partagent le même « Organizational Domain » : bounce.exemple.com s’aligne avec exemple.com. En mode « s » (strict), les deux domaines doivent être identiques : ce même sous-domaine échoue. Le mode strict protège mieux un domaine très usurpé mais impose à chaque sous-domaine d’envoi de signer avec le domaine exact du From, soit un changement de configuration chez chaque prestataire.

Identifier les expéditeurs fantômes par IP source

Un expéditeur fantôme est une IP qui envoie sous votre domaine sans que personne ne l’ait déclarée. Dans l’exemple, 203.0.113.55 a envoyé 380 messages en une journée. Filtrez les record dont policy_evaluated échoue sur DKIM et SPF, puis classez chaque source_ip en trois catégories : serveur connu mal configuré, service oublié, tentative d’usurpation.

Le reverse DNS (dig -x 203.0.113.55) renvoie le nom du serveur. Il reste à croiser ce nom avec les outils réellement utilisés en 2026 : formulaires de contact, plateformes de e-commerce, outils d’enquête, anciens routeurs d’envoi dont le compte SMTP n’a jamais été fermé. Une IP absente de toute liste interne, qui envoie quelques messages par jour sans signature DKIM, ressemble à une usurpation. Une IP de prestataire connu avec un alignement en échec est plus souvent une erreur de configuration.

Surveillez aussi la moyenne : 40 messages en échec sur 10 000 donnent 99,6 % de conformité globale (0,4 % d’échec). Le chiffre rassure alors qu’il peut s’agir d’une source légitime, comme un sous-domaine transactionnel, qui passera en rejet au durcissement.

Une alerte sur toute nouvelle source_ip à fort volume suffit à ouvrir la discussion avant qu’un flux passe en rejet. La gouvernance de la délivrabilité fixe ensuite qui valide l’ajout d’un expéditeur et qui possède chaque flux.

Publier et régler l’enregistrement _dmarc

La politique vit dans un enregistrement TXT publié sous _dmarc (exemple pour exemple.com) :

_dmarc.exemple.com.  IN  TXT  ( "v=DMARC1; p=none; "
                            "rua=mailto:dmarc@exemple.com; "
                            "adkim=r; aspf=r" )

Le premier tag doit être v=DMARC1 (sensible à la casse) sinon l’enregistrement est ignoré. Selon la RFC 9989, seul p est recommandé : sans lui, un enregistrement valide est traité comme p=none. Le tag fo n’a d’effet que si ruf est présent. Si rua pointe vers une adresse hors de votre « Organizational Domain », le domaine destinataire doit publier exemple.com._report._dmarc.domaine-collecteur.example contenant au moins v=DMARC1 ; sans cela, le receveur ignore cette URI (RFC 9990). Un collecteur prêt à recevoir pour tous les domaines peut publier un enregistrement générique *._report._dmarc contenant au moins v=DMARC1.

Ce que Google, Yahoo et Microsoft exigent et ce qu’ils vous envoient

Les trois grands receveurs posent un plancher DMARC aux gros volumes. Ce plancher décide de ce que vos rapports vont montrer :

• Gmail, depuis le 1er février 2024 : un enregistrement DMARC pour tout expéditeur de plus de 5 000 messages par jour, la politique pouvant rester à none (consignes aux expéditeurs de Google). Les Postmaster Tools affichent le taux de spam, à garder sous 0,10 % sans jamais atteindre 0,30 %.
• Yahoo, depuis février 2024 : une politique DMARC publiée pour les expéditeurs en volume, selon Yahoo Sender Hub.
• Outlook.com (Hotmail, Live, Outlook grand public), depuis le 5 mai 2025 pour plus de 5 000 emails par jour : SPF et DKIM en pass. DMARC doit valoir p=none au moins, avec un alignement SPF ou DKIM (annonce Microsoft sur les expéditeurs à fort volume).

Microsoft annonce le rejet des messages non conformes avec l’erreur 550 5.7.515 Access denied, sending domain [domaine] does not meet the required authentication level. La même annonce évoque d’abord un passage par le dossier Junk : relisez les réponses SMTP de vos logs pour savoir ce que vous subissez. Côté rapports, selon Microsoft, les RUA partent vers les adresses de votre enregistrement et aucun RUF n’est prévu. Si aucun rapport de Microsoft n’arrive, vérifiez d’abord la publication de votre rua.

RUF contre RUA et RGPD

Les rapports agrégés (rua) regroupent les résultats par IP source et par combinaison d’identifiants, sans contenu de message. Les rapports d’échec (ruf) décrivent des messages individuels. La RFC 9991 (mai 2026) le dit sans détour : ces rapports peuvent contenir des données personnelles et des informations « non publiques ». Ses auteurs notent que ces risques ont conduit de nombreux opérateurs à restreindre leur usage. Les agrégés restent le mécanisme recommandé.

Selon le RGPD (règlement 2016/679), une adresse email de destinataire est une donnée personnelle. Activer ruf suppose une base légale, une durée de conservation limitée et une boîte dédiée.

Ce que DMARCbis change dans les rapports

Publiée en mai 2026, la RFC 9989 fait passer DMARC du statut Informational (RFC 7489, 2015) à Standards Track et obsolète aussi la RFC 9091. Les rapports agrégés relèvent désormais de la RFC 9990 et les rapports d’échec de la RFC 9991. L’analyse détaillée des trois textes se trouve dans l’article sur les effets de DMARCbis sur la délivrabilité.

Côté rapports, les tags pct, rf et ri sont retirés (statut « historic » dans le registre IANA des tags DMARC de la RFC 9989). Le tag t (valeurs « y » ou « n ») remplace pct pour signaler un test. L’élément testing apparaît dans policy_published à côté de discovery_method. La Public Suffix List cède la place au DNS Tree Walk pour trouver la politique et l’Organizational Domain.

Selon la RFC 7489 (2015), ri demandait un rapport toutes les 86 400 secondes par défaut, soit 24 heures. Pour pct, la RFC 9989 (annexe A.6) explique que seules les valeurs 0 et 100 étaient appliquées de façon fiable : les autres variaient d’une implémentation à l’autre. Elle ajoute que pct=0 servait à certains intermédiaires de signal pour réécrire le From, d’où la création de t. Dans les rapports, discovery_method indique comment le receveur a trouvé votre enregistrement, ce qui aide à comprendre pourquoi un sous-domaine hérite d’une politique inattendue. La valeur v=DMARC1 reste inchangée.

MTA-STS et TLS-RPT : d’autres rapports sur la même boîte

Les rapports TLS-RPT arrivent souvent sur la même boîte que les rapports DMARC et se confondent avec eux. Les rapports DMARC en XML décrivent l’authentification des messages. Les rapports TLS-RPT (RFC 8460, septembre 2018) décrivent autre chose : le chiffrement du transport entre serveurs, au format JSON I-JSON. Un enregistrement TXT publié sous _smtp._tls, avec v=TLSRPTv1 et un tag rua en mailto: ou https:, demande aux expéditeurs un rapport par journée UTC sur leurs échecs STARTTLS, DANE et MTA-STS.

Le MTA-STS (RFC 8461, septembre 2018) est la politique que ces rapports surveillent. Un enregistrement TXT _mta-sts (v=STSv1; id=...) renvoie vers un fichier servi en HTTPS sur mta-sts.exemple.com/.well-known/mta-sts.txt, qui liste les hôtes mx, le mode et un max_age en secondes. Selon la RFC 8461, le mode « testing » livre les messages malgré l’échec et seuls les rapports TLS-RPT le signalent. Le mode « enforce » interdit à l’expéditeur de livrer vers un hôte dont le certificat ne valide pas. Le fichier doit répondre en HTTP 200 sur un certificat valide pour l’hôte mta-sts, sans suivre de redirection. Un rapport TLS-RPT ne dit rien de l’alignement DMARC. L’inverse vaut aussi : si les deux arrivent sur la même adresse, triez par format, XML pour DMARC et JSON pour TLS-RPT.

De p=none à p=reject par paliers

Les rapports disent quand durcir la politique. Voici l’ordre (le détail de chaque palier est dans Configurer DMARC étape par étape) :

1. Publiez p=none avec un rua et laissez passer au moins un cycle complet de vos envois, newsletter mensuelle comprise.
2. Inventoriez les source_ip : chaque service légitime doit afficher un alignement DKIM ou SPF en pass dans policy_evaluated. Dans l’exemple, 203.0.113.55 doit signer avec d=exemple.com avant toute étape suivante.
3. Passez à p=quarantine. Avec t=y (RFC 9989, annexe A.6), vous signalez un test : le receveur applique un traitement un cran en dessous. Un receveur resté sur la RFC 7489 lit encore pct.
4. Traitez les flux de redirection (listes de diffusion, alias) : un transfert casse le SPF. Si l’intermédiaire appose un scellement ARC (RFC 8617, 2019), il enregistre les résultats d’authentification d’origine, que le receveur peut choisir de prendre en compte.
5. Passez à p=reject quand les record en échec ne contiennent plus que des IP que vous avez décidé de bloquer.

Après le passage, relisez les rapports : une IP légitime en disposition: reject signale un flux à corriger.

BIMI, une fois p=quarantine ou p=reject atteint

BIMI se débloque avec le passage à p=reject, une fois les rapports propres. Il affiche le logo de la marque dans la boîte de réception, sur un domaine déjà protégé. Selon la documentation Google Workspace, « BIMI doesn’t support DMARC policies that have the p option set to none » : p doit valoir quarantine ou reject, avec pct=100. Il faut aussi un certificat VMC ou CMC dans un fichier PEM. Le logo est un SVG au profil tiny-ps (version 1.2), de 96 × 96 pixels minimum et de préférence de 32 Ko au plus. La RFC 9989 (mai 2026) classe pct en « historic » alors que cette exigence le cite encore : vérifiez ce que lit votre receveur.

Pour commencer aujourd’hui, ouvrez le dernier rapport de Google, repérez la source_ip au plus gros count dont policy_evaluated échoue, puis rattachez-la à un service. Une fois toutes les IP assignées, p=quarantine se décide sur des données.