Analyse d’un cas de spoof reçu sur une adresse professionnelle

Le point de départ était l’arrivée d’un message douteux dans une boîte de réception d’une adresse professionnelle, avec un objet alarmant : une pseudo-désactivation de compte CPanel. L’adresse de destination était bien une adresse locale, et l’expéditeur semblait provenir du même domaine.

Le mail avait toutes les caractéristiques d’une tentative de phishing : contenu HTML à thème d’urgence, lien vers un domaine tiers (glitch.me), header « From » forgé à partir du domaine cible, et champs critiques absents (à commencer par le champ Date et Message-ID).

Pourtant, le domaine disposait d’un enregistrement SPF cohérent, et d’une politique DMARC déclarée. Le message était bien reçu, sans blocage à l’entrée.

Inspection des en-têtes : ce que le serveur a vraiment vu

L’analyse des en-têtes SMTP a permis de reconstituer le parcours du message :

• Return-Path vide (<>), typique des bounces ou des mails piégés mimant des messages système.
• IP d’envoi : 34.34.17.78 (Google Cloud / GCP), rDNS dynamique, listé sur Spamhaus.
• Serveur de destination : Exim sur mandarine.o2switch.net (LMTP local).
• From : cpanel@domaine-cible.fr, donc même domaine que la boîte cible.
• Absence de DKIM, SPF échoué (IP non autorisée), pas d’alignement d’authentification.

Malgré cela, le message est arrivé.

Diagnostic : DMARC inefficace faute de politique stricte

Une vérification de la configuration DNS du domaine montre :

• Un enregistrement SPF correct :

v=spf1 +a +mx ip4:xxx.xxx.xxx.xxx include:spf.xxxx.fr include:zoho.com -all

- Un enregistrement DMARC présent mais configuré avec `p=none` :

v=DMARC1; p=none; sp=none; adkim=r; aspf=r; …

Cette politique signifie explicitement : "ne rien faire en cas d'échec SPF/DKIM".

Le serveur de destination (même interne) n'étant pas configuré pour appliquer d'autres contrôles, il a livré le message tel quel.

## Correction recommandée : durcir la politique DMARC

Pour empêcher ces tentatives de spoof, la politique DMARC doit passer de `p=none` à `p=reject`, avec alignement strict :

v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; pct=100; fo=1; rf=afrf; ri=86400; rua=mailto:votreadresse@exemple.fr; ruf=mailto:votreadresse@exemple.fr

Ce changement impose aux serveurs destinataires (ceux qui respectent DMARC) de **rejeter tout message non authentifié**, même si l'expéditeur prétend venir du domaine.

En complément :

- Vérifier que tous les serveurs légitimes (Zoho, Jabatus, etc.) ont bien SPF **ou** DKIM **valide et aligné**.
- S'assurer que les mails internes ou routés ne court-circuitent pas les filtres DMARC.
- Tester la nouvelle configuration avec des outils comme Mail-tester ou Postmark.

## Cas typique d'usurpation invisible sans rejets explicites

Le cas rencontré ici montre que même avec une infrastructure mail correctement authentifiée en apparence, l’absence de politiques actives rend le domaine vulnérable. Un spammeur peut utiliser n’importe quelle IP et forger un en-tête `From:` sans se heurter à un refus.

Une politique DMARC `none` est utile uniquement en phase de surveillance. Elle doit être remplacée par une politique `quarantine` ou `reject` une fois les flux analysés.

## Besoin d'aide pour vérifier ou corriger votre configuration mail ?

Si vous avez déjà reçu un message en votre nom que vous n’avez pas envoyé, ou si vous souhaitez vous assurer que votre domaine est correctement protégé, nous pouvons analyser votre configuration SPF, DKIM et DMARC, et vous aider à la mettre en conformité avec les meilleures pratiques actuelles.

Contactez-nous pour évaluer ensemble les risques réels sur votre domaine.