Emails en spam après un piratage : le site est souvent la cause
Devis et confirmations de commande en indésirables : souvent le domaine a envoyé du frauduleux à votre insu. Relancer le serveur mail sans nettoyer le site n'arrange rien. Coupez la source, puis les listes, puis SPF/DKIM. Un test vers votre propre Gmail ne dit rien.
Le domaine a envoyé du frauduleux à votre insu. Relancer le serveur mail sans nettoyer le site n'arrange rien. Coupez la source, puis les listes, puis SPF/DKIM.
Le site d'abord, la « réchauffe » ensuite
Tant qu'un script, un cron ou un SMTP volé envoie, chaque devis légitime aggrave le score. Les gens inversent : ils ouvrent un ticket « délivrabilité », ils changent de prestataire mail, ils « réchauffent » — et le malware continue. L'ordre du guide emails tient : source, listes, authentification, attente. Pas l'inverse.
Un piratage n'est pas la seule cause (voisin d'IP, SPF cassé tout seul, volume newsletter brutal). Mais après un incident site, partez du principe que le domaine a servi jusqu'à preuve inverse (journaux). WP Mail SMTP, php mail().
Trois sources d'envoi à départager
(1) `mail()` / sendmail du compte d'hébergement (PHP à la racine, plugin). (2) SMTP du CMS (identifiant chez OVH, Brevo, Google). (3) Un relais propre (Brevo, Mailchimp) dont la clé API a été lue — campagnes que vous n'avez pas créées. Les journaux tranchent : IP d'émission, From, script. Traiter (2) en changeant le mot de passe dans WordPress sans le tourner chez le fournisseur ne suffit pas.
Lire les journaux d'envoi, pas l'antivirus Outlook
Demandez à l'hébergeur le journal d'envoi (exim, postfix, « email trace ») sur 7–14 jours : volume, destinataires, authentifié ou non, user PHP. Côté relais : logs Brevo / SES. Côté plugin : s'ils existent, exportez avant de vider. Cette pièce part chez Spamhaus. Journal d'envoi si l'hébergeur fait l'innocent.
Les codes 550 / 554 avec un nom de liste (Spamhaus, SORBS, Barracuda) orientent vers Spamhaus ou IP. Un 5.7.26 Microsoft oriente vers auth / réputation domaine.
- Volume horaire et pic.
- From / Return-Path.
- IP d'émission (web vs ailleurs).
- Mentions de listes dans les bounces.
Listes, IP, et domaine : trois réputations
Le domaine (Spamhaus DBL, URI) se soigne avec un constat et un formulaire. L'IP (SBL, PBL, listes d'opérateurs) peut être celle du voisin : nettoyer votre site ne suffit pas. L'authentification (SPF trop large, DKIM cassé) est un troisième levier. Traitez celui que les bounces nomment, pas « tout » au hasard. SPF DKIM DMARC.
Couper sans tuer le transactionnel pour toujours
Urgence : révoquer SMTP, désactiver `mail()` si l'hébergeur le permet, stopper les crons, couper les formulaires qui relancent. Les resets de mot de passe peuvent attendre une heure. Une newsletter « on est de retour » le jour J brûle la réputation restante. Rate limit : parfois l'hébergeur a déjà coupé ; ne demandez pas « rouvrez » sans constat.
SPF, DKIM, DMARC : recoller, pas durcir trop tôt
Remettez les enregistrements prévus par l'hébergeur mail. Un `p=reject` DMARC le soir de l'incident jette aussi vos vrais messages (DKIM pas encore recollé, un sous-domaine oublié). On durcit une fois le légitime authentifié et la source morte. Un pirate ignore souvent SPF — ou le casse en réécrivant la zone. Relisez la zone, pas seulement le « candide » d'un outil en ligne.
Ce que Gmail et Orange voient encore
Les opérateurs gardent une mémoire. Un retrait Spamhaus n'est pas un feu vert Orange. Postmaster Tools (Gmail), SNDS (Microsoft), les retours Orange/SFR : utiles après, pas à la place des journaux. Orange SFR Free.
Reprendre les devis sans brûler le reste
D'abord le transactionnel (devis, commandes) à petit volume, From stable, listes propres. La newsletter plus tard, éventuellement depuis un sous-domaine dédié. Pas de rattrapage de 50 000 mails le lundi. Newsletter vs transactionnel. Créer un compte pour un constat source + listes.
- Source d'envoi coupée, journaux exportés.
- Listes demandées avec constat.
- SPF/DKIM recollés, DMARC pas encore p=reject brutal.
- Reprise transactionnel d'abord.
From, Reply-To, et la boîte qui a l'air légitime
Le spam part souvent avec votre From exact (`devis@`, `commandes@`). Les clients répondent, tombent sur vous, et vous découvrez l'incident. Gardez ces réponses : elles datent. Un Reply-To vers une boîte pirate (ou un ticket Zendesk inconnu) est un second canal : relisez les en-têtes des messages qui vous sont signalés.
Après reprise, ne changez pas le From tous les deux jours « pour voir si ça passe ». La stabilité aide. Un alias neuf `nepasrepondre2@` a l'air d'une fuite. Recollez l'alias habituel une fois le secret tourné et les listes demandées.
Les règles de transfert et les délégués sur la boîte d'envoi : un pirate qui a lu le mot de passe SMTP a parfois aussi lu la boîte. Règles de transfert. 2FA, sessions sorties, règles listées. Sinon vos devis « propres » sont encore copiés.