Les rapports DMARC montrent que quelqu'un usurpe encore votre domaine

Ce qu'un RUA n'est pas

Un rapport agrégé n'est pas une preuve d'exfiltration de votre base, ni un journal d'envoi de votre hébergeur. C'est un résumé : qui a tenté d'envoyer avec votre domaine, et si SPF/DKIM ont aligné. Utile pour voir l'usurpation qui continue après un site propre.

Sans enregistrement DMARC, vous n'avez rien. Sans boîte RUA qui fonctionne, non plus. Si `rua=` pointe vers une adresse morte depuis deux ans, l'incident actuel est aveugle. Créez une boîte dédiée, hors de la file saturée de bounces.

Les fichiers XML sont denses. Un outil de lecture (ou un prestataire mail) aide. L'objectif n'est pas de tout comprendre : c'est de classer les IP.

Lire les IP sans tout bloquer

Pour chaque source fréquente : reverse DNS, ASN, est-ce votre hébergeur, votre ESP, Google, Microsoft, un scanner, un inconnu. Les scanners et les forwards légitimes font du bruit. On ne blacklist pas Internet à la main le soir de l'incident.

Une IP de votre mutualisé qui envoie beaucoup avec fail DKIM : probablement encore le site ou un voisin. Une IP de VPS étranger avec fail SPF : usurpation classique, le levier est le durcissement, pas le FTP.

Ne publiez pas les XML sur un ticket public. Ils contiennent des volumes et parfois des indices d'infra. Stockez-les avec les journaux à conserver.

• IP = votre hébergeur / ESP : chantier site ou config.
• IP = grand webmail (forward) : souvent du bruit.
• IP = inconnu répétitif : usurpation, serrer SPF/DMARC.

Trois colonnes : vous, prestataires, inconnus

Colonne A : IP que vous payez (site, mail, CRM). Tout fail ici est un bug de config ou une pompe encore ouverte. Colonne B : prestataires connus (Stripe emails, marketplace, outil RH). On les `include` volontairement. Colonne C : le reste. C'est l'usurpation et le bruit.

L'erreur fréquente est de mettre C dans le SPF « pour que ça passe » : vous légitimez l'attaquant. L'erreur inverse est de retirer B pendant le chaos : vos vrais messages tombent.

Dressez la liste B avec la compta et l'agence, pas tout seul à minuit. C'est le préalable au durcissement.

SPF trop large et includes morts

`+all` et `?all` disent aux receveurs que tout le monde a le droit. Les RUA montreront alors des « pass » SPF pour des IP pirates. Ce n'est pas que DMARC est cassé : c'est que vous avez ouvert la porte. Passez à `~all` puis `-all` quand la colonne B est complète.

Les `include` d'anciens ESP, d'une agence partie, d'un outil d'emailing d'essai : retirez-les. Chaque include est une délégation. Un prestataire compromis envoie « légitimement » à vos yeux.

Un SPF trop long (limite de consultations DNS) casse aléatoirement. Simplifiez. Ce n'est pas de l'exploit : c'est de la hygiène de zone, à faire quand vous n'êtes plus sous le feu des bounces.

Quand serrer la politique

Pendant le chaos : `none` ou `quarantine` avec RUA, pour voir. Après inventaire des relais et site coupé : monter vers `reject` si votre flux est simple (un ESP, un hébergeur). Une TPE avec cinq outils d'envoi trop tôt en reject se coupe elle-même les factures.

Le pourcentage (`pct=`) permet un durcissement progressif. Utile. Pas obligatoire le jour J.

Serrer n'arrête pas l'usurpation vers les webmails qui ignorent DMARC. Ça réduit la casse chez ceux qui l'appliquent, et ça clarifie les RUA suivants. Ce n'est pas un substitut au nettoyage du site si la colonne A envoie encore.

Forensics : ce qu'on n'ouvre pas à la légère

Les rapports forensics (RUF) peuvent contenir des extraits de messages. Beaucoup d'acteurs ne les envoient plus, et les recevoir pose un problème de correspondance de tiers. Pour une TPE, le RUA suffit presque toujours. N'activez pas le RUF « pour être complet » sans savoir où atterrissent les extraits.

Si vous les recevez déjà, restreignez l'accès à la boîte, ne les collez pas dans un groupe Slack. Ils peuvent entrer dans un constat de fuite s'ils montrent un contenu client.

Lien avec le site piraté

Si les RUA montrent votre IP d'hébergement en volume : le site ou le voisin envoie encore. Journaux d'envoi, cron, clés. Si elles ne montrent que des inconnus : le FTP propre ne suffit pas, le DNS doit suivre. Les deux chantiers en parallèle, sans les fusionner dans un seul « c'est nettoyé ».

Un pic RUA qui continue après fichiers propres confirme l'usurpation résiduelle. C'est le moment de serrer, pas de réinstaller WordPress une troisième fois.

Les mails de notification aux personnes doivent partir d'un flux authentifié, pas d'un bricolage, sous peine d'atterrir en spam et d'aggraver le dossier.

Routine après l'incendie

Ouvrez les RUA une fois par semaine pendant un mois, puis au calme. Une nouvelle IP colonne A = alerte. Une mer de colonne C avec politique reject = le monde qui teste encore votre domaine, normal à bas bruit.

Documentez la politique choisie et la liste des includes dans le contrat de maintenance. Le prochain freelance ne doit pas remettre `+all` « pour que le plugin marche ».

Créer un espace pour le volet site ; joignez un extrait RUA classé (A/B/C) si vous voulez qu'on tranche « pompe locale vs usurpation ».

• Boîte RUA dédiée et lue.
• Inventaire des relais écrit.
• Durcissement daté, après inventaire.