Adresse e-mail usurpée : possible ?

Quand une usurpation est plus ou moins probable

Règle de décision : traitez l’expéditeur visible comme non vérifié tant que le service de réception ne montre pas de détails d’authentification à l’appui de son domaine, et évaluez quand même la demande, les liens et le contexte.

Un message suspect peut user de plusieurs formes de tromperie :

• Une usurpation du domaine exact utilise votre vraie adresse, comme ceo@yourdomain.com, sans autorisation. DMARC est conçu pour aider dans ce cas.
• Une usurpation du nom d’affichage reprend un nom familier, mais l’adresse réelle est sur un autre domaine.
• Un message à domaine sosie utilise un domaine qui ressemble au vrai, avec une variante d’orthographe ou un caractère visuellement proche.

Pour Gmail, les conseils d’authentification de Google indiquent qu’un point d’interrogation près du nom de l’expéditeur signale un message non authentifié. Gmail montre aussi « Envoyé par » et « Signé par » dans les détails du message. C’est un indicateur propre à Gmail, pas une règle pour Outlook ou Apple Mail.

Si vous lisez les en-têtes bruts, cherchez un champ Authentication-Results ajouté par votre propre système de réception. La RFC 8601 définit ce champ pour consigner les résultats d’authentification. Ne vous fiez pas à une copie trouvée dans un message transféré ou fournie par un attaquant. La même RFC avertit qu’un expéditeur malveillant peut forger un champ d’apparence crédible si le système de réception ne le supprime pas.

Pour la lecture en-tête par en-tête et les signaux visibles qui trahissent d’abord un faux, voir comment repérer un expéditeur usurpé.

Exemple d’authentification

Prenons un message qui affiche billing@yourdomain.com :

From: Billing <billing@yourdomain.com>
Authentication-Results: mx.recipient.example;
  spf=pass smtp.mailfrom=mailer.unrelated-example.com;
  dkim=pass header.d=unrelated-example.com;
  dmarc=fail header.from=yourdomain.com

C’est un exemple illustratif, pas un en-tête de production copié.

Les contrôles SPF et DKIM ont réussi pour unrelated-example.com, mais aucune identité authentifiée n’est alignée avec yourdomain.com, le domaine affiché dans From. Résultat : un échec DMARC pour le domaine visible.

L’inverse demande aussi de la prudence. Un succès DMARC signifie que le propriétaire du domaine a autorisé l’usage de ce domaine visible pour le message. La RFC 9989 précise que cela ne rend pas un message sûr ou souhaitable, ni ne garantit l’arrivée en boîte de réception. Un compte légitime compromis peut envoyer un hameçonnage authentifié.

À vérifier ensuite

Si vous recevez un e-mail suspect, conservez-le et signalez l’hameçonnage via votre fournisseur. Ne répondez pas, n’ouvrez pas de pièces jointes inattendues et ne suivez pas les liens d’un message qui demande des identifiants, un paiement ou une action urgente. Comparez l’adresse visible à l’adresse complète et lisez les détails d’authentification si votre app les affiche.

Si vous possédez le domaine usurpé, commencez par les guides de sécurité e-mail de Palisade et consultez la rubrique menaces e-mail. Vérifiez que SPF, DKIM et DMARC sont publiés, puis que les vrais messages de production réussissent avec alignement. Un score de sécurité e-mail public peut inspecter les contrôles publiés du domaine, et le guide des e-mails bloqués couvre les échecs de livraison survenant après l’évaluation d’un message par le destinataire.

Contre l’usurpation du domaine exact, ne publiez DMARC qu’après avoir compris et testé les vrais expéditeurs. Le guide anti-hameçonnage de la CISA recommande p=reject pour le courrier envoyé et note que les rapports DMARC peuvent révéler l’origine apparente des faux. Une politique de rejet peut perturber du courrier légitime encore en échec DMARC : validez chaque vrai chemin d’envoi avant tout changement.

Les contrôles de sécurité e-mail du domaine

Une adresse visible usurpée n’est qu’un signal. Utilisez le guide de sécurité e-mail pour comprendre les contrôles requis par votre domaine, puis vérifiez sa posture DNS publique avec l’outil de score.

Revoyez vos contrôles de sécurité

Un contrôle public ne peut pas prouver pourquoi un message reçu a été livré, si un en-tête a été forgé avant livraison, ni si chaque expéditeur de production est authentifié et aligné.