# DMARC en mode reject : lire les rapports agrégés sans perdre d’emails légitimes

> Un client bascule son domaine en politique DMARC stricte pour se protéger du phishing, et perd des emails légitimes sans comprendre pourquoi. La réponse se trouve dans les rapports rua.

- Auteur : Clément Hadrot
- Publié le : 2024-03-06
- Mis à jour le : 2024-03-06
- Catégorie : Hébergement & serveurs
- URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/dmarc-reject-lire-rapports-agreges-sans-perdre-emails/

## L’essentiel

- p=reject sans période de transition est un pari risqué
- Les rapports rua arrivent en XML compressé, pas en texte lisible
- Un service tiers de lecture DMARC change la donne pour une petite équipe

Le client a suivi les recommandations de son assureur cyber à la lettre : passer la politique DMARC de son domaine directement en `p=reject`, pour bloquer tout email usurpant son nom de domaine avant qu'il n'atteigne la boîte d'un destinataire. Une semaine plus tard, un partenaire commercial signale qu'il n'a jamais reçu la facture envoyée via l'outil de facturation SaaS du client. Puis un deuxième cas remonte, avec un service d'emailing marketing cette fois.

Le diagnostic est rapide une fois qu'on sait où chercher : les deux services tiers envoyaient leurs emails au nom du domaine du client sans authentification SPF ni DKIM correctement alignée, et la politique `p=reject`, appliquée sans transition, les a purement et simplement rejetés. La bonne nouvelle est que DMARC fournit exactement l'outil pour éviter ce genre de surprise avant de basculer en mode strict : les rapports agrégés, envoyés à l'adresse déclarée dans `rua`.

## Ce que dit réellement un enregistrement DMARC

Avant de plonger dans les rapports, un rappel s'impose sur la structure de l'enregistrement DNS lui-même, posé en TXT sur `_dmarc.exemple.fr` :

```
_dmarc.exemple.fr. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@exemple.fr; pct=100"
```

Le paramètre `p=reject` indique la politique appliquée aux messages qui échouent l'alignement SPF ou DKIM avec le domaine visible de l'expéditeur. Le paramètre `rua` désigne l'adresse où les serveurs de messagerie qui reçoivent des emails prétendant venir de ce domaine renvoient un rapport agrégé quotidien, résumant les emails vus, alignés ou non.

## Le format brut des rapports rua

Les rapports arrivent par email, sous forme de pièce jointe compressée (généralement en `.zip` ou `.gz`) contenant un fichier XML. Ce format n'est pas pensé pour une lecture humaine directe :

> L'essentiel à retenir : p=reject sans période de transition est un pari risqué ; Les rapports rua arrivent en XML compressé, pas en texte lisible ; Un service tiers de lecture DMARC change la donne pour une petite équipe

```
<record>
  <row>
    <source_ip>198.51.100.42</source_ip>
    <count>340</count>
    <policy_evaluated>
      <disposition>reject</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>exemple.fr</header_from>
  </identifiers>
</record>
```

Ce fragment montre exactement le scénario redouté : 340 emails envoyés depuis l'IP 198.51.100.42, prétendant venir du domaine `exemple.fr`, ont échoué à la fois SPF et DKIM, et ont donc été rejetés conformément à la politique. Reste à identifier ce que représente cette IP : un expéditeur légitime mal configuré, ou une tentative réelle d'usurpation.

## Distinguer un service légitime mal aligné d'une vraie usurpation

La première étape consiste à croiser l'IP source du rapport avec la liste des services autorisés à envoyer au nom du domaine : outil de facturation, plateforme d'emailing marketing, CRM, formulaire de contact du site. Une recherche WHOIS ou une simple recherche du bloc d'IP suffit souvent à identifier le fournisseur.

| Cas observé dans les rapports | Interprétation | Action |
| --- | --- | --- |
| IP d'un outil de facturation connu, SPF/DKIM absents | Service légitime mal configuré | Ajouter son SPF, activer DKIM côté fournisseur |
| IP inconnue, volume faible, une seule occurrence | Tentative de spoofing isolée | Aucune action, DMARC a fait son travail |
| IP inconnue, volume élevé et répété | Campagne de phishing active | Signalement et surveillance renforcée |

## Utiliser un service tiers plutôt que lire le XML à la main

Sur un domaine actif, le volume de rapports rua reçus chaque jour rend la lecture manuelle du XML brut impraticable au-delà de quelques jours. Un service tiers de traitement DMARC agrège automatiquement ces rapports dans un tableau de bord lisible, classant les sources par volume et par statut d'alignement, ce qui a permis sur ce dossier d'identifier en moins d'une heure les deux services tiers fautifs, plutôt qu'en dépouillant manuellement des dizaines de fichiers XML compressés.

## La bonne séquence de bascule

1. Démarrer en `p=none` pendant au moins deux semaines, pour observer sans impact ce que les rapports révèlent.
2. Corriger l'alignement SPF et DKIM de chaque service tiers identifié comme légitime dans les rapports.
3. Passer en `p=quarantine` avec un `pct` réduit (10 à 25 %) pendant au moins une semaine, pour limiter l'impact d'un oubli.
4. Ne passer en `p=reject` qu'une fois les rapports stabilisés sans échec inattendu sur plusieurs jours consécutifs.

> DMARC en `p=reject` sans période d'observation revient à changer une serrure sans vérifier d'abord qui possède encore un double de la clé.

## En résumé

Perdre des emails légitimes après un passage en `p=reject` n'est pas un défaut de DMARC, c'est le signe d'une bascule trop rapide sans phase d'observation. Les rapports agrégés reçus via `rua` révèlent précisément quels services envoient au nom du domaine sans authentification correcte, à condition de les lire avant de durcir la politique, pas après en constatant les dégâts.