Détecter une usurpation dans les rapports DMARC : la méthode

<record>
  <row>
    <source_ip>203.0.113.47</source_ip>
    <count>612</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>exemple.fr</header_from>
  </identifiers>
</record>

Les signatures d'une campagne d'usurpation

Au-delà de la ligne isolée, les campagnes réelles dessinent des motifs récurrents.

La rafale courte. Une campagne de phishing se prépare, se tire, puis s'éteint : le volume passe de rien à des centaines ou des milliers de messages en 24 à 72 heures, avant de retomber à zéro. Les flux légitimes, eux, persistent. Une source apparue lundi et disparue jeudi ne reviendra pas s'expliquer.

Les IP résidentielles et les botnets. Plutôt qu'une grosse adresse émettrice, des dizaines ou des centaines d'IP envoyant chacune quelques messages, souvent sur des plages d'opérateurs grand public, dispersées géographiquement. Ce morcellement est une signature en soi : aucune infrastructure d'envoi légitime ne ressemble à un essaim.

Les destinataires concentrés chez un seul fournisseur. Les rapports RUA proviennent des fournisseurs des destinataires. Quand une campagne n'apparaît que dans les rapports d'un seul rapporteur — uniquement Google, par exemple — c'est le reflet d'une liste d'adresses achetée ou volée, concentrée chez ce fournisseur. Le trafic légitime, lui, se répartit sur l'ensemble des rapporteurs habituels.

Les cibles improbables. Des envois au nom de sous-domaines qui n'existent pas — un facturation.exemple.fr jamais créé — trahissent un attaquant qui explore le périmètre. DMARCbis a précisément introduit la balise np= pour durcir le sort des sous-domaines inexistants sans toucher au reste de la politique.

Les faux positifs qui ressemblent à une attaque

Trois mécanismes parfaitement légitimes produisent des échecs DMARC, et les confondre avec une usurpation fait perdre du temps — ou déclenche une fausse alerte.

Les redirections. Un destinataire qui fait suivre son courrier vers une autre boîte réémet le message depuis une nouvelle IP : SPF échoue mécaniquement. Mais si le message n'a pas été modifié en route, DKIM survit au transfert. Une ligne spf=fail, dkim=pass alignée n'est donc pas une usurpation : c'est la signature classique d'un transfert.

Les listes de diffusion. Elles modifient le message — étiquette dans le sujet, pied de page ajouté — et cassent DKIM en plus de SPF. Résultat : un double échec qui ressemble à s'y méprendre à une attaque. Les indices qui sauvent : volume faible et stable, IP constante d'un opérateur de listes identifiable, récurrence de semaine en semaine — tout le contraire d'une rafale. Certains destinataires compensent via ARC et livrent malgré tout ; le champ reason du rapport en garde alors la trace.

Les passerelles et scanners de sécurité. Chez certains destinataires, des équipements d'analyse détonnent les pièces jointes puis réinjectent le message en interne : il ressort d'une IP de passerelle, SPF échoue, parfois DKIM aussi si le contenu a été retraité. Ces sources se reconnaissent à leur régularité et à un volume proportionnel au trafic réellement envoyé vers l'organisation concernée.

Trancher l'ambigu. Pour les cas résiduels, le niveau de détail supérieur serait le rapport forensique, envoyé message par message — mais les grands fournisseurs n'en émettent presque plus ; la différence entre rapports agrégés et forensiques explique pourquoi l'essentiel de la détection repose, en pratique, sur le RUA seul.

La méthode de tri hebdomadaire

La détection n'exige pas une salle de crise ; elle exige une routine. Trente minutes par semaine suffisent pour un domaine établi, en cinq passes toujours identiques.

1. Le taux d'alignement d'abord. Part du volume aligné sur le volume total, comparée à la semaine précédente. Stable ou en hausse : rien d'urgent. En baisse : quelque chose a changé, et la suite du tri dira quoi.
2. Les nouvelles sources ensuite. Toute IP apparue depuis la dernière lecture est classée dans une des trois populations. Un prestataire connu, une plage d'entreprise, un inconnu total : trois destins différents.
3. Les doubles échecs en détail. Pour chaque ligne fail/fail : volume, profil temporel, origine réseau, liste des rapporteurs. Rafale + IP dispersées + rapporteur unique : le faisceau d'une campagne est réuni.
4. L'étiquetage. Chaque source reçoit un statut — légitime, à corriger, hostile, indéterminée — conservé d'une semaine sur l'autre. Cette mémoire est ce qui rend la routine rapide : seul le nouveau demande une analyse, le reste est déjà jugé.
5. La décision. Une source à corriger entre au chantier de configuration ; une campagne hostile constatée sous p=none devient un argument daté et chiffré pour accélérer le durcissement.

À la main, sur des fichiers XML compressés, cette routine devient pénible dès la deuxième semaine. Les outils de lecture des rapports en automatisent l'essentiel — enrichissement des IP, étiquetage persistant, alerte sur nouvelle source — et ramènent le rendez-vous hebdomadaire à l'examen des seules anomalies.

Ce que la politique change à la lecture

La même ligne de rapport ne raconte pas la même histoire selon la politique publiée.

Sous p=none, la disposition reste none : chaque message usurpé compté dans le rapport a été livré, sauf filtrage antispam ordinaire du destinataire. La lecture est une observation au sens strict : les lignes hostiles décrivent du phishing arrivé en boîte. C'est la période la plus inconfortable — celle où les rapports documentent l'exposition sans la réduire — et chaque campagne détectée est une raison datée d'en sortir.

Sous p=quarantine puis p=reject, les mêmes lignes changent de nature : disposition=quarantine ou reject signifie que les messages ont été écartés ou refusés. Les échecs deviennent des blocages ; le rapport, un tableau de chasse. Le volume hostile rejeté se lit comme une métrique de protection : chaque rafale est une campagne avortée, sans victime côté destinataires. Une nuance : une ligne disposition=none peut subsister sous p=reject quand le destinataire a passé outre localement — liste de diffusion réhabilitée via ARC, règle interne — et le champ reason documente ce choix.

Détail de version : le déploiement progressif ne passe plus par l'ancienne balise pct, disparue de DMARCbis ; le mode test s'exprime désormais par la balise t=, et la détermination du domaine organisationnel repose sur le DNS Tree Walk. Les enregistrements v=DMARC1 existants restent valides tels quels.

Quand passer en réponse à incident

La routine hebdomadaire suffit tant que l'usurpation reste un bruit de fond — quelques tentatives opportunistes par mois font partie de la vie normale d'un domaine visible. Trois seuils justifient d'en sortir.

Le volume. Une campagne qui dépasse le trafic légitime du domaine, ou qui se maintient plusieurs jours au lieu de retomber, n'est plus du bruit : c'est un investissement de l'attaquant, donc un ciblage.

Le ciblage. Des rapports concentrés chez le fournisseur qui héberge précisément les clients ou partenaires de l'organisation, une corrélation avec des signalements entrants — réponses de victimes, appels au support, alertes internes — indiquent que la campagne touche l'écosystème réel, pas des adresses au hasard.

Le contexte. Une rafale synchronisée avec un événement de l'organisation — campagne de facturation, période de recrutement, annonce publique — trahit une préparation, et une préparation annonce une suite.

Dans ces trois cas, la lecture ne suffit plus : il faut accélérer le calendrier de durcissement, préserver les rapports comme éléments de preuve et informer les parties prenantes exposées. La marche à suivre complète — qualification, communication, durcissement d'urgence — fait l'objet de la réponse à incident après une usurpation. Et le meilleur moment pour se poser la question reste l'avant-campagne : tester si un domaine est usurpable dit en quelques minutes ce que les rapports finiraient par prouver en plusieurs semaines.

En résumé

Un rapport RUA rend l'usurpation visible, à condition de trier. Les sources légitimes alignées se surveillent ; les légitimes mal configurées se corrigent ; les usurpateurs — IP inconnues en double échec SPF et DKIM, sans aucune signature du domaine — ne se neutralisent que par la politique. Une campagne réelle se reconnaît à sa rafale courte, à ses IP dispersées ou résidentielles et à ses rapports concentrés chez un seul fournisseur ; les redirections, listes de diffusion et passerelles de sécurité produisent des échecs comparables sans être des attaques. La routine hebdomadaire — alignement, nouvelles sources, doubles échecs, étiquetage, décision — transforme cette lecture en réflexe, et la politique publiée décide du sens des lignes : observation sous p=none, blocage sous p=reject. Au-delà d'un certain volume, d'un ciblage avéré ou d'une synchronisation suspecte, la détection cède la place à la réponse à incident.

Le premier tri peut commencer aujourd'hui : un passage du domaine par l'analyse DMARC gratuite montre immédiatement qui émet sous son nom et sur quelles bases d'authentification. Pour installer la routine dans la durée — collecte des rapports, enrichissement des sources, alertes sur les rafales — la création d'un compte met la méthode décrite ici en pilotage continu, jusqu'au jour où chaque ligne hostile se lit comme un blocage, et non plus comme une menace.