E-mail : Hameçonnage depuis votre domaine — un playbook d’intervention efficace

Playbook de diagnostic rapide

Vous cherchez le goulot d’étranglement : est-ce que le courrier a été émis par votre infrastructure, ou est‑ce que quelqu’un forge simplement vos en‑têtes et profite d’Internet public ? Ne « révisez pas tout ». Vérifiez les trois éléments qui séparent ces mondes.

Première étape : un message a‑t‑il transité par vos systèmes sortants ?

• Vérifiez vos logs MTA (suivi des messages Postfix/Exim/Exchange). S’il n’y a aucune trace du spam sortant de vos systèmes, vous avez principalement affaire à de l’usurpation et à une question de politique, pas à un expéditeur compromis.
• Vérifiez le traçage de messages de votre fournisseur (Microsoft 365 / Google Workspace). Si cela montre des envois sortants réussis, il s’agit probablement d’un vol d’identifiants ou d’un abus de jeton API.

Deuxième étape : les en‑têtes des destinataires montrent‑ils une authentification réussie ?

• Si SPF=pass pour votre domaine et DKIM=pass avec votre sélecteur, l’expéditeur a probablement utilisé votre véritable infrastructure ou vos identifiants.
• Si SPF/DKIM échouent mais que le message arrive quand même, votre politique DMARC est trop faible (ou inexistante), et les destinataires prennent leurs propres décisions.

Troisième étape : votre politique de domaine applique‑t‑elle quelque chose ?

• Vérifiez l’enregistrement DMARC : si c’est p=none, vous observez, vous ne protégez pas.
• Vérifiez l’alignement : SPF/DKIM peuvent « passer » mais échouer DMARC s’ils ne sont pas alignés avec le domaine From:.

Règle de rapidité : dans les premières 30 minutes, privilégiez l’arrêt des envois supplémentaires et la préservation des preuves. La réparation de réputation peut attendre que l’incendie soit maîtrisé.

Ce que signifie réellement « hameçonnage depuis votre domaine »

Il y a trois réalités courantes derrière la même capture d’écran inquiétante.

1) Usurpation pure (votre domaine est forgé, pas piraté)

L’e‑mail a été conçu à une époque où « soyez sympa » était un modèle de sécurité raisonnable. N’importe qui peut écrire From: ceo@yourdomain.com dans un message. Si votre domaine manque d’une forte application DMARC, de nombreux systèmes récepteurs le livreront quand même — surtout à des humains formés par la vie en entreprise à cliquer sur les urgences.

2) Compromission de compte (quelqu’un envoie en votre nom)

Une boîte mail a été hameçonnée, un écran de consentement OAuth a été approuvé, un jeton API a fui, ou l’AMF a été contournée via le vol d’un cookie de session. L’attaquant envoie depuis votre vrai tenant, donc SPF et DKIM passent souvent. C’est la situation la plus douloureuse car le spam est « authentique ».

3) Mauvaise utilisation de l’infrastructure (relai ouvert, soumission SMTP exposée, outil marketing abusé)

Moins fréquent, mais catastrophique quand c’est vrai : votre MTA relaie pour le monde, un identifiant SMTP oublié est encore valable, ou un service d’envoi tiers autorisé dans SPF est abusé. La différence ici est que vous le verrez dans vos logs.

La bonne réponse d’incident est surtout de classifier. Une fois que vous savez lequel des trois cas il s’agit, la correction devient ennuyeuse. L’ennuyeux, c’est bien.

Faits intéressants et contexte historique

• SMTP a été livré sans authentification au début des années 1980 ; l’identité était supposée, pas vérifiée. L’usurpation n’était pas un « bug », elle était hors du modèle de menace initial.
• SPF a commencé comme une idée d’autorisation d’expéditeurs basée sur le DNS au début des années 2000, principalement pour réduire le spam avec enveloppe forgée.
• DKIM provient des travaux DomainKeys et Identified Internet Mail ; il signe cryptographiquement le contenu des e‑mails pour que les destinataires puissent vérifier le contrôle du domaine.
• DMARC (vers 2012) a relié SPF et DKIM avec des règles d’alignement et un bouton de politique (none/quarantine/reject), plus des rapports.
• Les rapports DMARC ont créé une nouvelle industrie de la télémétrie : soudain, vous pouviez voir qui « envoie en votre nom », y compris des prestataires oubliés.
• L’« alignement » est la trappe : SPF peut passer pour un domaine tandis que le From: visible est un autre ; DMARC s’occupe de ce décalage.
• ARC (Authenticated Received Chain) existe parce que le renvoi et les listes de diffusion cassent l’authentification ; ARC permet aux intermédiaires d’attester ce qu’ils ont vu.
• Les gros fournisseurs de boîtes ont progressivement durci les règles : au fil du temps, les expéditeurs en volume ont été poussés vers l’application de SPF/DKIM/DMARC et des attentes de désinscription en un clic.
• Les équipes de sécurité l’ont appris à leurs dépens : « nous avons SPF » n’est pas une défense. SPF est une porte. Les attaquants contournent les portes.

Arbre décisionnel : usurpation vs compromission vs relais

Si les logs sortants montrent que les messages ont quitté vos systèmes

• Probable : boîte compromise, identifiant SMTP compromis, intégration fournisseur abusée.
• À faire maintenant : bloquer l’expéditeur, révoquer les jetons, réinitialiser les identifiants, forcer la déconnexion, analyser les logs d’accès, préserver des échantillons.

Si les logs sortants ne montrent rien, mais que les destinataires voient votre From :

• Probable : usurpation.
• À faire maintenant : durcir DMARC, s’assurer que DKIM est activé partout où vous envoyez légitimement, et vérifier que SPF n’inclut que ce que vous contrôlez.

Si les logs montrent que votre MTA a relayé vers de nombreux domaines avec lesquels vous ne faites pas affaire

• Probable : relai ouvert ou soumission/auth exposée.
• À faire maintenant : verrouiller les règles de relais, restreindre les ports de soumission, faire tourner les identifiants, bloquer les IP fautives et vérifier la présence de malware sur l’hôte.

Citation à garder au mur (idée paraphrasée) : John Allspaw : la fiabilité vient de la façon dont les systèmes se comportent sous stress, pas de la beauté de vos diagrammes.

Tâches pratiques avec commandes (et comment décider)

Ce sont des tâches réelles que vous pouvez lancer sur un hôte MTA Linux ou une box de saut avec des outils DNS. Chaque tâche inclut : la commande, ce que signifie la sortie et la décision à prendre. Adaptez les domaines et les noms d’hôtes en conséquence.

Task 1 — Pull SPF record and sanity-check it

cr0x@server:~$ dig +short TXT yourdomain.com
"v=spf1 ip4:203.0.113.10 include:_spf.google.com include:sendgrid.net ~all"

Ce que cela signifie : SPF autorise 203.0.113.10 plus Google plus SendGrid. Le ~all est un « softfail », essentiellement une suggestion polie.

Décision : inventoriez chaque include. Si vous ne pouvez pas expliquer pourquoi il est là, ce n’est pas « temporaire », c’est un « risque inconnu ». Avancez vers -all seulement quand vous êtes sûr que tous les expéditeurs légitimes sont couverts.

Task 2 — Check DMARC record and policy level

cr0x@server:~$ dig +short TXT _dmarc.yourdomain.com
"v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.com; adkim=r; aspf=r; pct=100"

Ce que cela signifie : Vous collectez des rapports mais n’appliquez pas de restriction. L’alignement est relax.

Décision : si vous subissez activement des usurpations, p=none n’est pas un plan de réponse. Passez rapidement à p=quarantine, puis à p=reject après validation que les sources légitimes signent/s’authentifient correctement.

Task 3 — Verify DKIM selector exists (common failure: missing record)

cr0x@server:~$ dig +short TXT s1._domainkey.yourdomain.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Ce que cela signifie : La clé publique DKIM existe pour le sélecteur s1.

Décision : si elle manque, DKIM échouera pour le courrier signé avec ce sélecteur. Corrigez le DNS, puis validez la signature côté expéditeur.

Task 4 — Inspect a phishing sample’s Authentication-Results

cr0x@server:~$ grep -E "Authentication-Results|From:|Return-Path:|Received-SPF|DKIM-Signature" -n sample.eml | sed -n '1,120p'
12:From: "Accounts Payable" <ap@yourdomain.com>
18:Return-Path: <bounce@evil-example.net>
31:Authentication-Results: mx.example.net;
32: spf=fail (mx.example.net: domain of bounce@evil-example.net does not designate 198.51.100.77 as permitted sender) smtp.mailfrom=evil-example.net;
33: dkim=none (message not signed);
34: dmarc=fail (p=none) header.from=yourdomain.com

Ce que cela signifie : Non signé, SPF échoue pour le domaine d’enveloppe, DMARC échoue mais la politique est none donc le message peut quand même être livré.

Décision : traitez cela comme de l’usurpation. Votre travail est de faire en sorte qu’un DMARC échoué signifie « ne pas livrer ». Durcissez DMARC et assurez‑vous que les expéditeurs légitimes sont alignés.

Task 5 — Confirm your outbound IP reputation signals (quick: check if you’re listed)

cr0x@server:~$ dig +short 10.113.0.203.zen.spamhaus.org A
127.0.0.2

Ce que cela signifie : 203.0.113.10 semble listé (exemple de code de réponse). Certaines listes renvoient des loopbacks différents selon la raison.

Décision : si vous êtes listé et que vous avez réellement envoyé le courrier, la contention et le nettoyage importent plus que de discuter avec la liste. Si vous ne l’avez pas envoyé, vous devez quand même appliquer DMARC et collecter des preuves pour les demandes de dé‑listage.

Task 6 — Search Postfix logs for suspicious volume spikes

cr0x@server:~$ sudo zgrep -h "postfix/smtp" /var/log/mail.log* | awk '{print $6}' | cut -d= -f2 | sort | uniq -c | sort -nr | head
  4821 status=sent
   118 status=deferred
    22 status=bounced

Ce que cela signifie : Beaucoup d’envois réussis. Cela correspond à une activité sortante réelle, pas à une simple usurpation.

Décision : pivotez vers « qui a envoyé » (utilisateur authentifié, IP d’origine, logs de soumission). Si le volume est nul, cessez de chasser des fantômes MTA et corrigez DMARC.

Task 7 — Identify authenticated SMTP users (submission abuse)

cr0x@server:~$ sudo zgrep -h "sasl_username=" /var/log/mail.log* | awk -F'sasl_username=' '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -nr | head
  913 payroll@yourdomain.com
  112 notifications@yourdomain.com
   10 helpdesk@yourdomain.com

Ce que cela signifie : Une boîte spécifique domine les envois via SMTP authentifié.

Décision : désactivez immédiatement ce compte, changez le mot de passe, révoquez les sessions et examinez l’historique des connexions. Ensuite vérifiez s’il s’agit d’un expéditeur métier réel (les systèmes de paie le sont souvent) ou d’un attaquant.

Task 8 — Trace one message queue ID to see destinations and timing

cr0x@server:~$ sudo postqueue -p | head
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
A1B2C3D4E5*     2048 Mon Jan  4 08:55:12  ap@yourdomain.com
                                         user1@example.net
                                         user2@example.org

cr0x@server:~$ sudo postcat -q A1B2C3D4E5 | sed -n '1,80p'
*** ENVELOPE RECORDS ***
message_size:            2048
sender: ap@yourdomain.com
*** MESSAGE CONTENTS ***
From: "Accounts Payable" <ap@yourdomain.com>
Subject: Updated remittance advice
Date: Mon, 04 Jan 2026 08:55:11 +0000

Ce que cela signifie : C’est effectivement dans votre file d’attente. Ce n’est pas de l’usurpation ; votre système l’envoie.

Décision : contenir en mettant en pause la sortie ou en retenant la file si nécessaire, puis isoler le compte ou l’application source.

Task 9 — Stop Postfix outbound temporarily (containment lever)

cr0x@server:~$ sudo postfix stop
postfix/postfix-script: stopping the Postfix mail system

Ce que cela signifie : Vous avez arrêté le MTA. C’est brutal mais efficace si votre serveur est la source.

Décision : n’utilisez ceci que si vous avez confirmé que votre hôte envoie du courrier abusif et que vous pouvez tolérer une coupure. Sinon, restreignez en périphérie (pare‑feu, limites de débit, désactivation de comptes) pour éviter des dégâts collatéraux.

Task 10 — Check for open relay behavior (the classic “nope”)

cr0x@server:~$ swaks --to victim@example.net --from spoof@yourdomain.com --server mail.yourdomain.com
=== Trying mail.yourdomain.com:25...
=== Connected to mail.yourdomain.com.
<= 220 mail.yourdomain.com ESMTP Postfix
=> EHLO server
<= 250-mail.yourdomain.com
=> MAIL FROM:<spoof@yourdomain.com>
<= 250 2.1.0 Ok
=> RCPT TO:<victim@example.net>
<= 554 5.7.1 Relay access denied
=> QUIT
<= 221 2.0.0 Bye

Ce que cela signifie : Le relais est refusé. Bien. Si vous aviez vu 250 2.1.5 Ok pour RCPT vers un domaine externe sans auth, vous auriez un relai ouvert.

Décision : s’il est ouvert, corrigez immédiatement les restrictions de relais. S’il est fermé, arrêtez de blâmer le MTA pour du courrier forgé que vous n’avez pas envoyé.

Task 11 — Validate TLS and submission ports exposure

cr0x@server:~$ sudo ss -lntp | grep -E ":(25|465|587)\s"
LISTEN 0 100 0.0.0.0:25   0.0.0.0:* users:(("master",pid=1123,fd=13))
LISTEN 0 100 0.0.0.0:587  0.0.0.0:* users:(("master",pid=1123,fd=15))

Ce que cela signifie : SMTP et la soumission écoutent sur toutes les interfaces. Cela peut être correct, ou « pourquoi faisons‑nous cela ».

Décision : si la soumission (587/465) est exposée sur Internet, assurez‑vous d’une authentification forte, de limites de débit et de l’AMF sur les comptes. Si vous n’avez pas besoin de soumission externe, restreignez via pare‑feu/VPN.

Task 12 — Pull recent successful logins for a suspected mailbox (generic IMAP auth logs)

cr0x@server:~$ sudo zgrep -h "imap-login: Login:" /var/log/mail.log* | grep "payroll@yourdomain.com" | tail -5
Jan  4 08:41:02 mail dovecot: imap-login: Login: user=<payroll@yourdomain.com>, method=PLAIN, rip=198.51.100.88, lip=203.0.113.10, mpid=22101, TLS
Jan  4 08:43:19 mail dovecot: imap-login: Login: user=<payroll@yourdomain.com>, method=PLAIN, rip=198.51.100.88, lip=203.0.113.10, mpid=22144, TLS

Ce que cela signifie : Connexions répétées depuis une même IP distante. Peut être un utilisateur légitime, peut être un attaquant.

Décision : corrélez avec les emplacements connus des utilisateurs / egress VPN. Si c’est suspect, révoquez les sessions et réinitialisez les identifiants. N’attendez pas que les RH « confirment si c’était eux » pendant que le spam continue.

Task 13 — Confirm DMARC aggregate reports are arriving (mailbox health)

cr0x@server:~$ sudo mailq | head
Mail queue is empty

Ce que cela signifie : Votre file locale n’est pas bloquée, mais cela ne prouve pas que les rapports DMARC sont traités. C’est un contrôle de bon sens, pas un tour d’honneur.

Décision : si vous dépendez des rapports pour la visibilité, assurez‑vous que la boîte réceptrice est monitorée et a assez de quota. Une télémétrie DMARC qui rebondit silencieusement, c’est un détecteur de fumée avec des piles mortes.

Task 14 — Quick DNS propagation check from multiple resolvers

cr0x@server:~$ dig @1.1.1.1 +short TXT _dmarc.yourdomain.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s; pct=100"
cr0x@server:~$ dig @8.8.8.8 +short TXT _dmarc.yourdomain.com
"v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100"

Ce que cela signifie : Différents résolveurs voient des enregistrements différents — propagation ou DNS en split‑brain. Tant que cela ne converge pas, votre application est incohérente.

Décision : ne déclarez pas « corrigé » tant qu’Internet voit encore l’ancienne politique. Examinez l’hébergement DNS, les TTL et si plusieurs enregistrements TXT existent.

Task 15 — Check for multiple DMARC TXT records (breaks evaluation)

cr0x@server:~$ dig TXT _dmarc.yourdomain.com +noall +answer
_dmarc.yourdomain.com. 300 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com"
_dmarc.yourdomain.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:old@yourdomain.com"

Ce que cela signifie : Deux enregistrements DMARC. Beaucoup de récepteurs considèrent cela comme une permerror et peuvent ignorer DMARC complètement.

Décision : supprimez l’enregistrement en trop. Un seul enregistrement DMARC par domaine. Toujours.

Blague #1 : L’authentification des e‑mails est le seul système de sécurité où « pass » peut toujours signifier « fail », et tout le monde hoche la tête comme si c’était normal.

Trois mini-récits d’entreprise depuis le terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne dans les services financiers a commencé à recevoir des plaintes : des fournisseurs recevaient des e‑mails « nouveaux coordonnées bancaires » depuis le domaine de l’entreprise. L’équipe IT a fait le geste sensé : chercher dans les logs sortants. Rien. Ils ont déclaré, confiants, « nous n’avons pas été piratés. »

Ils avaient à moitié raison et complètement tort. Les attaquants usurpaient le domaine visible From: et utilisaient une infrastructure d’envoi jetable. L’entreprise avait SPF et DKIM « configurés », mais DMARC était p=none. Les systèmes récepteurs étaient laissés à deviner s’ils devaient livrer, et beaucoup ont deviné « oui » parce que le message semblait professionnel et ne déclenchait pas leurs filtres de contenu.

La mauvaise hypothèse était subtile : « Si nous ne l’avons pas envoyé, nous ne pouvons pas l’arrêter. » Vous ne pouvez pas empêcher les gens de forger votre nom dans des en‑têtes SMTP, mais vous pouvez rendre la livraison de ces forgeries coûteuse. DMARC existe précisément pour ça.

Une fois passés à p=quarantine puis à p=reject, les plaintes ont chuté fortement. Quelques systèmes légitimes ont cassé — un ancien fournisseur de facturation ne signait pas DKIM et n’envoyait pas depuis une IP dans SPF. Ce nettoyage était de toute façon en retard.

Le post‑mortem a été franc : l’incident n’était pas une « compromission e‑mail », c’était une « faiblesse de politique ». La correction n’a pas été un miracle SOC ; c’était un enregistrement TXT DNS et une semaine d’inventaire fournisseurs.

Mini-récit 2 : L’optimisation qui a mal tourné

Une entreprise SaaS a décidé de « simplifier » les e‑mails en routant tout le courrier sortant via une seule plateforme tierce. Un include SPF, un sélecteur DKIM, un endroit pour gérer les templates. La migration a fonctionné, la délivrabilité s’est améliorée, et tout le monde est passé à autre chose.

Six mois plus tard, une vague de phishing a frappé leurs clients avec une authentification parfaite. SPF passait. DKIM passait. DMARC passait. Les messages étaient envoyés via cette plateforme tierce, en utilisant des clés API valides qui avaient fui depuis un artefact CI. Ce n’était pas exactement la faute du fournisseur. L’entreprise avait traité les clés API comme de la configuration, pas comme des identifiants de production.

L’erreur d’optimisation était la centralisation sans confinement. Ils avaient supprimé la diversité (multiples expéditeurs), mais aussi retiré les contrôles de blast radius. Toutes les fonctions e‑mail — réinitialisations, factures, marketing, support — partageaient une « clé dieu ». Lorsqu’elle a fuité, les attaquants ont obtenu la crédibilité de leur meilleur expéditeur.

La récupération a pris des jours : faire tourner les clés, réparer l’hygiène CI, séparer transactional vs marketing, implémenter des clés par service avec permissions limitées, et ajouter des limites de débit et une détection d’anomalies. L’ironie : la « simplification » a transformé un incident gênant en un événement de réputation.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une organisation de santé avait une routine que personne n’aimait : revue mensuelle des rapports DMARC et registre d’autorisation des fournisseurs. C’était fastidieux. Ça produisait des feuilles de calcul. Ça faisait soupirer en réunion.

Puis un attaquant a tenté de les usurper pendant une panne régionale, en envoyant un e‑mail « utile » demandant aux patients de confirmer des données personnelles. Le DMARC de l’organisation était déjà en p=reject avec un alignement strict pour le domaine organisationnel. Les messages usurpés ont échoué DMARC et ont été rejetés par de nombreux gros fournisseurs avant d’atteindre les boîtes de réception.

Ils ont quand même reçu quelques signalements — captures d’écrans depuis des systèmes marginaux et quelques transferts — mais l’ampleur n’a jamais atteint le niveau « pont d’incident ». Ce qu’ils ont fait : vérifier leurs données agrégées DMARC et confirmer le motif de l’attaque : beaucoup d’échecs depuis de nouvelles plages IP, aucune activité sortante correspondante.

La pratique ennuyeuse a payé deux fois : une application stricte a réduit la livraison, et la télémétrie de base a facilité la classification de l’événement comme usurpation, pas compromission. Ils n’ont donc pas perdu une journée à faire tourner tous les mots de passe de l’entreprise « au cas où ».

Confinement : arrêter l’hémorragie d’abord

Le confinement varie selon la classification, mais l’état d’esprit est le même : réduire rapidement le débit de l’attaquant, sans détruire les preuves dont vous aurez besoin pour prouver ce qui s’est passé.

Si c’est une compromission de boîte mail (le plus urgent)

• Désactivez le compte ou bloquez la connexion. Ne commencez pas par « demander à l’utilisateur ». Les utilisateurs dorment ou se défendent ; les attaquants ne le font pas.
• Révoquez les sessions et les jetons. Les réinitialisations de mot de passe sans révocation des jetons sont du théâtre.
• Supprimez les règles de boîte malveillantes (classique : transfert automatique, suppression à la réception, « marquer comme lu »).
• Arrêtez les envois depuis cette identité via règles de transport/politique, ou bloquez temporairement les destinataires externes.
• Préservez des échantillons : en‑têtes complets, MIME brut, horodatages et IDs de message.

Si c’est un abus d’expéditeur tiers

• Faites tourner les clés API, puis invalidez les anciennes. Si vous ne pouvez pas invalider les anciennes clés, considérez que vous ne pouvez pas contenir.
• Limitez les permissions (clés séparées pour transactional vs marketing vs support ; restrictions par application).
• Limitez le débit sortant par clé et par IP, et alertez sur les anomalies.

Si c’est de l’usurpation

• Déplacez DMARC de none → quarantine rapidement si vous pouvez tolérer quelques faux positifs. Utilisez pct=25 comme montée progressive si nécessaire, mais limitez dans le temps.
• Vérifiez que DKIM est activé pour chaque source légitime, surtout les CRM/plateformes marketing.
• Nettoyez les includes SPF. Supprimez les fournisseurs obsolètes. SPF est une liste blanche ; traitez‑la comme des règles pare‑feu.

Blague #2 : Si votre enregistrement SPF inclut cinq fournisseurs que vous n’avez jamais entendus, félicitations — vous avez inventé le « relai ouvert externalisé ».

Éradication et durcissement : faire en sorte que ça reste fixe

Le confinement achète du temps. Le durcissement empêche la même classe d’incident de réapparaître le trimestre suivant avec un autre nom d’expéditeur.

Verrouillez les identités et les chemins d’accès

• MFA partout, mais aussi : bloquez les protocoles d’auth legacy et les mots de passe d’app si possible. Les attaquants aiment les anciennes portes.
• Accès conditionnel pour les connexions risquées : voyage impossible, nouvel appareil, plages IP suspectes.
• Gouvernance des apps OAuth : restreindre les consentements, revoir les applications d’entreprise et surveiller les nouvelles autorisations.

Rendez la politique d’authentification exécutable

• DMARC en p=reject pour votre domaine organisationnel quand vous êtes prêts. Si vous ne pouvez pas atteindre reject, vous ne connaissez pas tous vos expéditeurs.
• Utilisez un alignement strict quand possible (adkim=s, aspf=s) pour réduire les abus par domaines ressemblants. Le mode relax est une étape, pas une destination.
• Séparez les domaines : utilisez un sous‑domaine pour le marketing en volume et gardez le domaine principal verrouillé. Les plateformes marketing se font compromettre ; ce n’est pas une prédiction, c’est de la physique.

Corrigez volontairement les cas limites liés au renvoi et aux listes

Les transferts souvent cassent SPF (car l’IP du forwarder n’est pas autorisée) et les listes de diffusion cassent souvent DKIM (car elles modifient le message). ARC aide, mais ne supposez pas que chaque récepteur l’utilise de façon cohérente.

• Pour les workflows critiques (factures, réinitialisations), évitez d’envoyer uniquement via des listes/forwarders comme unique chemin de livraison.
• Si vous exploitez des serveurs de listes, configurez‑les pour préserver l’authentification quand c’est possible et utilisez ARC si pertinent.

Construisez une détection qui ne dépend pas de la chance

• Alertez sur les pics sortants par utilisateur/app/clé API.
• Suivez les nouvelles règles de transfert et les nouvelles règles de boîte qui suppriment ou redirigent.
• Rétention des logs : assurez‑vous d’avoir assez d’historique pour répondre à « quand cela a commencé ? » sans deviner.

Récupération de réputation et de délivrabilité

Une fois que vous avez arrêté l’abus en cours, vous avez un second problème : Internet pense maintenant que vous êtes mal rangé. Sortir de la pénalité consiste surtout à prouver que vous êtes stable.

Stabilisez vos patterns d’envoi

• Réduisez temporairement le volume si possible (surtout le marketing). Les 48 premières heures après un incident sont celles où les filtres sont les moins tolérants.
• Envoyez du trafic propre et attendu : les messages transactionnels vers des destinataires engagés sont votre « battement cardiaque sain ».
• Supprimez les adresses mortes et cessez les rebonds répétés ; ce sont du poison pour la réputation.

Corrigez la source, puis adressez les listes noires

La demande de dé‑listage sans correction de la cause, c’est comme passer la serpillière pendant que le tuyau débite. Certaines listes vous re‑classeront rapidement, et la deuxième fois, c’est généralement plus long à résoudre.

Communiquez comme un adulte

• Informez les équipes internes de ce qui s’est passé et des changements : politique DMARC, verrouillage de comptes, restrictions fournisseurs.
• Fournissez aux clients une note courte et claire : « Nous ne demandons pas de réinitialisation de mot de passe par lien par e‑mail ; vérifiez le domaine et les indicateurs d’authentification. » Restez factuel.
• Ne faites pas de promesses excessives. Si vous dites « nous n’avons pas été piratés » sans avoir vérifié, vous misez la confiance sur une hypothèse.

Listes de contrôle / plan pas à pas

0–30 minutes : classifier et contenir

1. Collectez au moins un échantillon complet (raw .eml avec en‑têtes). Une capture d’écran n’est pas une preuve.
2. Vérifiez les traces/logs sortants : vos systèmes l’ont‑ils envoyé ?
3. Si oui : désactivez les comptes suspects et révoquez les jetons ; mettez la sortie en pause si besoin.
4. Si non : confirmez la politique DMARC ; préparez‑vous à passer en quarantine/reject.
5. Anoncez un canal d’incident avec un propriétaire et un décideur unique. Le chaos est le vrai malware.

Même jour : corriger les conditions habilitantes

1. Inventoriez les expéditeurs : M365/GWS, plateforme marketing, système de ticketing, alertes de monitoring, facturation, RH.
2. Activez la signature DKIM par expéditeur quand c’est possible.
3. Contraignez SPF : retirez les includes obsolètes ; assurez‑vous de respecter les limites de recherche DNS SPF.
4. Définissez DMARC en quarantine (optionnellement montez pct). Commencez à collecter les rapports si ce n’était pas le cas.
5. Auditez les apps OAuth et les consentements ; retirez les intégrations inconnues ou risquées.
6. Recherchez les règles de transfert et les règles de boîte suspectes.

Dans la semaine : rendre durable

1. Passez DMARC en reject pour le domaine org une fois l’alignement propre.
2. Séparez les domaines : transactional sur un domaine fortement contrôlé ; marketing sur un sous‑domaine avec politique claire.
3. Implémentez des limites de débit et des alertes d’anomalie sur les envois sortants.
4. Rédigez le runbook que vous auriez voulu avoir. Puis faites un exercice de table et regardez‑l’échouer (gentiment).

Erreurs courantes : symptôme → cause racine → correctif

« Nous avons SPF, alors pourquoi l’usurpation continue ? »

Symptôme : les destinataires voient votre domaine dans le From:, mais Authentication-Results montre SPF fail et DKIM none/fail, pourtant les messages sont livrés.

Cause racine : SPF ne vérifie que le domaine d’enveloppe, et sans application DMARC les récepteurs peuvent toujours livrer le courrier forgé.

Correctif : implémentez DMARC avec quarantine/reject, assurez la signature DKIM, et alignez SPF/DKIM avec le domaine visible From:.

« DMARC est en place, mais les récepteurs disent permerror »

Symptôme : DMARC échoue avec « permerror » dans les rapports ; l’usurpation continue.

Cause racine : plusieurs enregistrements DMARC TXT, tags malformés, ou enregistrements trop volumineux.

Correctif : assurez‑vous d’avoir exactement un enregistrement DMARC, validez la syntaxe et restez dans les limites DNS.

« DKIM passe parfois, échoue d’autres fois »

Symptôme : validation DKIM incohérente selon le récepteur ou le chemin.

Cause racine : systèmes d’envoi multiples avec sélecteurs/clés différents, problèmes de propagation DNS, ou intermédiaires modifiant le contenu (listes/pieds de page).

Correctif : standardisez DKIM par expéditeur, vérifiez le sélecteur DNS, arrêtez les modifications de corps de message et pensez à ARC pour les intermédiaires connus.

« Nous avons mis DMARC en reject et maintenant des mails légitimes manquent »

Symptôme : factures ou réponses helpdesk disparaissent ; les utilisateurs se plaignent.

Cause racine : fournisseur tiers légitime non inclus dans SPF et ne signant pas DKIM avec un domaine aligné.

Correctif : onboardez correctement le fournisseur : autorisez IPs ou include, imposez la signature DKIM avec votre domaine (ou utilisez un sous‑domaine), puis retestez avant d’augmenter l’application.

« Notre domaine est utilisé, mais notre serveur mail est propre »

Symptôme : pas de logs sortants ; pourtant beaucoup de plaintes.

Cause racine : usurpation pure combinée à DMARC faible (p=none) et/ou heuristiques réceptrices défaillantes.

Correctif : passez à DMARC quarantine/reject, publiez une politique claire et surveillez les rapports pour identifier les sources non autorisées restantes.

« Nous avons fait tourner les mots de passe, mais le spam continue »

Symptôme : le spam sortant persiste après réinitialisation de mot de passe.

Cause racine : l’attaquant utilise des sessions existantes, des refresh tokens OAuth ou des clés API, pas le mot de passe.

Correctif : révoquez les sessions/jetons, faites tourner les clés API et désactivez les applications d’entreprise ou consentements suspects.

« Nous avons bloqué le port 25 et le problème s’est arrêté… et nos e‑mails métier aussi »

Symptôme : l’action de confinement a causé des échecs sortants généralisés.

Cause racine : blocs réseau brutaux sans comprendre quels services dépendent de ce chemin (mails transactionnels, alertes, réinitialisations).

Correctif : préférez un confinement ciblé : bloquer des comptes/cles spécifiques, limiter les débits, restreindre les règles de relais ; gardez les chemins d’envoi critiques disponibles.

FAQ

1) Comment des attaquants peuvent‑ils envoyer « depuis mon domaine » si nous n’avons pas été piratés ?

Parce que l’en‑tête From: n’est que du texte à moins que les récepteurs n’appliquent l’authentification. L’usurpation est triviale ; empêcher la livraison nécessite l’application DMARC plus un bon alignement DKIM/SPF.

2) Devons‑nous immédiatement définir DMARC sur p=reject ?

Si vous êtes sûr de connaître tous les expéditeurs légitimes et qu’ils sont alignés, oui. Sinon, passez d’abord à p=quarantine et utilisez les rapports DMARC pour trouver les retardataires. Limitez la phase de quarantine dans le temps.

3) Quelle est la différence entre SPF « pass » et DMARC « pass » ?

SPF « pass » signifie que l’IP d’envoi est autorisée pour le domaine d’enveloppe. DMARC « pass » signifie que SPF ou DKIM a réussi et est aligné avec le domaine visible From:. L’alignement est l’essentiel.

4) Pourquoi les e‑mails transférés cassent‑ils SPF/DKIM ?

SPF casse car l’IP du serveur de transfert n’est pas autorisée à envoyer pour le domaine original. DKIM peut casser si le forwarder modifie le message. C’est pourquoi DMARC peut être douloureux pour les listes et pourquoi ARC existe.

5) Nous utilisons plusieurs fournisseurs. Comment éviter que SPF ne devienne un monstre ?

Privilégiez la signature DKIM par fournisseur et gardez SPF serré. Chaque include: est une relation de confiance. Surveillez aussi les limites de recherche DNS SPF ; trop d’includes peut causer un SPF permerror, ce qui est une panne auto‑infligée.

6) Comment savoir s’il s’agit d’une compromission de jeton OAuth ?

Cherchez des consentements d’app inhabituels, des connexions sans réinitialisation de mot de passe correspondante, et des envois persistants après changement de mot de passe. La révocation de jetons et la suppression d’apps sont des mesures de confinement clés.

7) Peut‑on arrêter l’usurpation sans DMARC ?

Vous ne pouvez pas arrêter la falsification ; vous ne pouvez qu’influencer le comportement des récepteurs. Sans application DMARC, vous comptez sur les heuristiques de chaque fournisseur. L’espoir n’est pas un contrôle.

8) Que devons‑nous envoyer aux clients pendant l’incident ?

Court, factuel et actionnable : quoi ignorer, comment vérifier les messages légitimes, ce que vous ne demanderez jamais, et un canal de support. Ne spéculerez pas sur la cause racine tant qu’elle n’est pas vérifiée.

9) Pourquoi le phishing a‑t‑il encore atterri dans certaines boîtes après que nous ayons mis p=reject ?

Délai de propagation, DNS en cache, récepteurs n’honorant pas DMARC de façon cohérente, ou le courrier ayant été transféré d’une manière qui altère l’évaluation. Vérifiez aussi les enregistrements DMARC multiples et les mauvaises configurations d’alignement.

Conclusion : prochaines étapes actionnables

Si votre domaine est utilisé pour du phishing, ne commencez pas par une réinitialisation générale des mots de passe et une prière. Commencez par classifier : a‑t‑il transité par vos systèmes ou pas ? Ensuite, contentez le bon niveau : identité, clé fournisseur, règles de relais MTA, ou application de politique.

Étapes pratiques pour aujourd’hui :

1. Obtenez un message brut avec en‑têtes complets et stockez‑le dans un endroit sain.
2. Vérifiez les preuves sortantes (trace fournisseur + logs MTA). Décidez : usurpation vs compromission vs relais.
3. Si usurpation : passez DMARC en quarantine maintenant, et planifiez reject après inventaire des expéditeurs.
4. Si compromission : désactivez le compte, révoquez jetons/sessions, supprimez les règles malveillantes, faites tourner les clés.
5. Dans la semaine : nettoyez SPF, assurez DKIM partout, et poussez DMARC en reject pour le domaine org.
6. Dans le mois : séparez les domaines, implémentez des alertes d’anomalies sortantes, et répétez ce runbook une fois.

L’objectif n’est pas la perfection. L’objectif est que la prochaine fois, votre pont d’incident dure 30 minutes, pas 30 heures — et que votre domaine cesse d’être un déguisement que n’importe qui peut porter.