Spoofing e-mail : définition et comment l’empêcher

Quand la réponse à l’usurpation change

La bonne réponse dépend de vos preuves et de qui possède le domaine.

Pour un message reçu, examinez l’adresse réelle de l’expéditeur et les résultats d’authentification du message remis. Un expéditeur peut utiliser un service tiers légitime, et un enregistrement DNS public ne peut pas expliquer ce qui est arrivé à un message donné. Si le message demande de l’argent, des identifiants, un changement de destination de paiement ou contient une pièce jointe inattendue, vérifiez la demande par un autre moyen de contact connu avant d’agir.

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

Pour votre domaine, publiez et maintenez les enregistrements d’authentification, puis validez le trafic réel. La protection DMARC est incomplète si un service d’envoi légitime n’a pas de réussite SPF ou DKIM alignée. Une politique p=reject n’est pas un ordre universel appliqué à l’identique par tout destinataire. La RFC 9989 laisse les destinataires appliquer une politique locale aux résultats DMARC.

Règle de décision :

• Si vous avez reçu un e-mail suspect, conservez-le et examinez ses en-têtes complets ou sa source. Vérifiez l’adresse affichée, l’adresse de réponse et les résultats d’authentification avant de répondre, d’ouvrir une pièce jointe ou de suivre un lien.
• Si vous avez un nom de domaine et voulez voir sa posture d’authentification publiée, consultez l’enregistrement DMARC public.
• Si vous administrez le domaine, validez quatre niveaux avant de juger les contrôles anti-usurpation efficaces : DNS faisant autorité et public, statut chez le fournisseur d’envoi, un vrai message remis par le chemin de production, et rapports agrégés DMARC une fois accumulés.
• Si l’expéditeur utilise un domaine différent mais trompeusement proche, le DMARC de votre domaine ne peut pas authentifier ce sosie. Signalez et bloquez le message via le processus de votre fournisseur de messagerie, puis enquêtez à part sur le domaine usurpateur.

Ne passez pas un domaine en p=quarantine ou p=reject sans avoir identifié et testé les principaux expéditeurs de production. Ce changement peut toucher des e-mails légitimes encore en échec d’alignement DMARC.

Exemple d’Authentication-Results

Un message remis peut contenir un en-tête Authentication-Results qui consigne l’évaluation d’authentification du destinataire. La RFC 8601 définit le champ d’en-tête Authentication-Results. L’exemple suivant est purement illustratif, pas tiré d’un vrai message :

Authentication-Results: receiver.example;
  spf=pass smtp.mailfrom=mailer.yourdomain.com;
  dkim=pass header.d=yourdomain.com;
  dmarc=pass header.from=yourdomain.com

Cet exemple indique que SPF a réussi pour mailer.yourdomain.com, DKIM pour une signature utilisant yourdomain.com, et DMARC pour le domaine From visible yourdomain.com.

Un résultat comme dmarc=pass est une preuve utile pour ce message chez ce destinataire. Il ne prouve pas que tout futur message réussira, que chaque expéditeur du domaine est autorisé, ni que le message mérite la boîte de réception. Examinez tout le contexte, dont la relation connue du destinataire avec l’expéditeur et la demande formulée.

Prochaines étapes

Si vous avez reçu un message suspect, utilisez les contrôles de signalement du client de messagerie et contactez l’expéditeur apparent par un numéro connu, l’annuaire interne ou une adresse déjà vérifiée. N’utilisez pas les coordonnées de réponse du message suspect pour cette vérification. Pour l’usurpation d’identité qui n’implique pas toujours un domaine falsifié, lisez ce qu’est l’usurpation d’identité par e-mail et comment la prévenir.

Si vous gérez le domaine From visible, recensez chaque service qui envoie pour lui. Pour chacun, vérifiez le statut d’authentification actuel chez le fournisseur, envoyez un message test par le chemin de production exact et examinez les en-têtes reçus. Puis utilisez les rapports agrégés DMARC pour repérer dans la durée les sources et les échecs d’authentification ou d’alignement. Le filtrage peut ajouter une couche pour les e-mails entrants, mais ne remplace pas l’authentification du domaine. Voyez comment le filtrage bloque le spam.

Utilisez un test d’enregistrement public si votre question est : « Quelle politique DMARC ce domaine publie-t-il en ce moment ? » Ce n’est pas le bon outil pour prouver l’origine d’un message suspect précis.

Problèmes courants face à l’usurpation

Mes vrais e-mails échouent à DMARC : pourquoi ?

Presque toujours un problème d’alignement ou de source manquante. Un flux peut réussir SPF ou DKIM avec un autre domaine que celui de l’adresse From, et échoue donc à l’alignement. Ou un expéditeur oublié, comme un CRM ou un outil de paie, n’a jamais été ajouté à SPF ni doté d’une clé DKIM. Lisez les rapports agrégés du domaine, identifiez la source, puis authentifiez-la ou faites-la passer par un chemin autorisé avant de passer à p=reject.

Pourquoi SPF renvoie-t-il un permerror ?

L’enregistrement dépasse la limite de 10 requêtes DNS, ou le domaine a plus d’un enregistrement SPF. Chaque mécanisme include, a et mx coûte une requête. Regroupez les fournisseurs, retirez les entrées include inutiles ou aplatissez SPF, et gardez un seul enregistrement v=spf1. La correction complète : corriger le permerror SPF : trop de requêtes DNS.

Des attaquants usurpent un domaine sosie, pas le mien. DMARC aide-t-il ?

DMARC ne protège que le domaine exact où il est publié. Un domaine cousin comme yourdomaìn.com ou yourdomain-support.com est un autre domaine et exige ses propres défenses : enregistrez les variantes évidentes, surveillez les nouveaux dépôts et associez l’application à la formation. DMARC bloque l’usurpation du domaine exact, mais ne peut pas surveiller les noms d’autrui. Vue d’ensemble : comment les domaines sosies contournent DMARC.

Avec p=reject, mes e-mails transférés sont rejetés. Pourquoi ?

Le transfert casse SPF, car le serveur de transfert devient l’expéditeur, et peut casser DKIM s’il réécrit le message. Si DKIM survit intact au transfert, DMARC réussit encore grâce à lui : d’où l’importance de DKIM. Examinez les en-têtes d’un message rejeté pour voir quel contrôle a échoué, et vérifiez que le chemin de transfert signe ou re-signe correctement.

Vérifier l’enregistrement DMARC en cause

Passez le domaine de l’adresse From visible dans le test Palisade pour voir son enregistrement DMARC publié et ses balises de politique. Comparez le résultat aux résultats d’authentification du message remis avant de décider s’il s’agit d’une usurpation non autorisée ou d’une autre tentative d’usurpation d’identité.

Vérifier le DMARC

Un test DNS public ne peut pas prouver qui a envoyé un message, réparer un expéditeur non authentifié, montrer le filtrage privé d’un destinataire ni suivre l’évolution des sources d’envoi d’un domaine.

Si une équipe IT ou un MSP doit traiter des rapports sur plusieurs domaines, Palisade est un logiciel DMARC agentique. Il analyse les rapports agrégés DMARC, identifie les sources d’envoi et les problèmes d’authentification ou d’alignement, et crée des tickets de remédiation priorisés. Il peut proposer l’étape de politique suivante d’après les preuves ; un humain les examine et applique tout changement.

Commencez avec Palisade

Palisade ne change pas seul votre politique DMARC, ne prouve pas que tout futur message s’authentifiera et ne contrôle pas la décision finale du destinataire.

Pour l’usurpation hors e-mail (variantes IP et identifiant d’appelant comprises), voyez Le spoofing : définition et attaques.