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 :
<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
- Démarrer en
p=nonependant au moins deux semaines, pour observer sans impact ce que les rapports révèlent. - Corriger l’alignement SPF et DKIM de chaque service tiers identifié comme légitime dans les rapports.
- Passer en
p=quarantineavec unpctréduit (10 à 25 %) pendant au moins une semaine, pour limiter l’impact d’un oubli. - Ne passer en
p=rejectqu’une fois les rapports stabilisés sans échec inattendu sur plusieurs jours consécutifs.
DMARC en
p=rejectsans 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.
