Mon site WordPress envoie des spams ou des e-mails de phishing : que faire ?

Vous recevez soudainement des dizaines de messages de non-distribution, un client vous transfère un e-mail frauduleux envoyé en votre nom, votre prestataire SMTP signale une hausse inhabituelle des envois ou votre hébergeur bloque les e-mails PHP de votre site ? Ces signaux doivent être pris au sérieux, mais ils ne prouvent pas tous la même chose.

Un message qui affiche votre adresse ou votre nom de domaine dans le champ expéditeur peut avoir réellement été envoyé par WordPress, provenir d’un compte de messagerie compromis ou avoir été falsifié depuis une infrastructure extérieure. À l’inverse, l’absence de ces messages dans le dossier « Envoyés » ne permet pas d’écarter WordPress : un formulaire, une extension ou un script peut expédier des e-mails sans passer par votre boîte de réception.

La priorité consiste donc à identifier l’origine réelle des messages, à interrompre les envois abusifs sans casser inutilement les e-mails métier, puis à préserver les éléments utiles au diagnostic. Supprimer une extension au hasard, changer plusieurs réglages DNS ou envoyer des dizaines de messages de test peut compliquer l’analyse et aggraver les problèmes de délivrabilité.

Ce guide explique quoi faire lorsque WordPress semble envoyer des spams ou des e-mails de phishing, comment distinguer les principaux scénarios et quand demander un diagnostic de malware WordPress.

Un e-mail affichant votre domaine ne prouve pas que WordPress l’a envoyé

Le nom et l’adresse visibles dans un logiciel de messagerie ne suffisent pas à établir l’origine technique d’un message. Le champ expéditeur peut être falsifié, tandis qu’un envoi légitime ou malveillant peut passer par plusieurs infrastructures : serveur web, boîte professionnelle, relais SMTP, plateforme transactionnelle ou service marketing.

Pour comprendre ce qui s’est réellement passé, il faut rapprocher les en-têtes complets du message, les résultats d’authentification, les journaux disponibles et l’historique des services d’envoi.

Situation possible	Ce que l’on peut observer	Ce qu’il faut vérifier
Envoi depuis WordPress ou l’hébergement	Activité PHP, journaux d’envoi, formulaire détourné, fichier ou tâche exécutée sur le serveur	Fichiers, extensions, formulaires, tâches planifiées, journaux et comptes WordPress
Compte e-mail ou SMTP compromis	Messages visibles dans un tableau de bord SMTP, connexions inhabituelles, clé d’API ou identifiant utilisé	Sessions, comptes, mots de passe, clés d’API, règles de transfert et applications autorisées
Usurpation extérieure du domaine	Votre adresse apparaît comme expéditeur, mais le message ne transite pas par vos services habituels	En-têtes complets, SPF, DKIM, DMARC et infrastructure d’origine
Envoi légitime mal configuré	Boucle de notifications, formulaire qui génère trop de réponses ou extension qui renvoie plusieurs fois le même message	Historique des modifications, réglages des formulaires, automatisations et files d’attente

Cette distinction est essentielle. Mettre WordPress hors ligne ne corrige pas une boîte mail compromise. À l’inverse, modifier uniquement SPF ou DMARC ne supprimera pas un script malveillant présent sur l’hébergement.

Quels signaux indiquent des envois suspects ?

Le premier signal ne vient pas toujours de WordPress. Il peut apparaître dans votre messagerie, chez votre hébergeur, dans un service SMTP ou à travers le retour d’un client.

Des retours de non-distribution arrivent en masse

Vous recevez des messages automatiques indiquant que des e-mails adressés à des inconnus n’ont pas pu être remis. Il peut s’agir d’envois réellement effectués depuis l’un de vos services, mais aussi de retours générés à la suite d’une usurpation de votre adresse.

Conservez plusieurs exemplaires complets. Les objets, identifiants de message, serveurs traversés et résultats d’authentification permettent de comparer les cas.

Un client reçoit un message frauduleux en votre nom

Le message peut reprendre votre logo, votre signature, le nom d’un collaborateur ou une facture. Demandez au destinataire de conserver l’e-mail original plutôt que de transmettre uniquement une capture. Une simple capture montre le contenu visible, mais pas le chemin technique du message.

L’hébergeur bloque les e-mails PHP

Ce signal rend plus probable l’existence d’une activité sur l’hébergement, mais il ne désigne pas automatiquement WordPress ni le fichier responsable. Le site peut contenir plusieurs applications ou scripts. Si votre premier signal est une notification de l’hébergeur, consultez aussi le guide Mon hébergeur signale un malware ou suspend mon site WordPress : que faire ?.

Le prestataire SMTP détecte une hausse de volume

Une augmentation rapide du nombre d’e-mails, de destinataires, de rebonds ou de plaintes peut révéler l’utilisation abusive d’un identifiant SMTP, d’une clé d’API ou d’une intégration WordPress. Il faut comparer cette activité aux volumes habituels et aux fonctionnalités réellement utilisées par le site.

Les e-mails légitimes commencent à arriver dans les spams

Une dégradation soudaine de la délivrabilité peut suivre des envois abusifs, une mauvaise authentification du domaine, une hausse des plaintes ou un problème de réputation. Elle constitue un effet possible de l’incident, mais ne permet pas à elle seule d’en identifier la cause.

Les six scénarios à distinguer avant d’intervenir

1. Un formulaire est détourné sans compromission complète du site

Un formulaire de contact, d’inscription, de devis ou de mot de passe peut être automatisé par des robots. Selon sa configuration, il peut générer une notification interne, une confirmation envoyée au visiteur ou les deux.

Un volume important de soumissions peut alors produire de nombreux e-mails sans qu’un attaquant ait obtenu un accès administrateur. Le contrôle doit porter sur les journaux du formulaire, les destinataires, les champs utilisés, la protection anti-robot, les limites de fréquence et les réponses automatiques.

2. Une extension, un thème ou un script compromis envoie les messages

Un fichier injecté, une porte dérobée, une extension vulnérable ou un code ajouté dans le thème peut déclencher des envois depuis l’hébergement. Le comportement peut être continu, planifié ou activé uniquement à certaines heures.

Dans ce cas, bloquer temporairement les e-mails peut limiter l’impact, mais ne supprime pas le mécanisme qui les génère. Le diagnostic doit rechercher les fichiers, tâches, comptes et modifications permettant la persistance. Pour replacer ce signal dans un incident plus large, consultez aussi les symptômes fréquents d’un malware WordPress.

3. Les identifiants SMTP ou une clé d’API ont été exposés

De nombreux sites n’envoient plus directement par PHP : ils utilisent un relais SMTP ou une API. Si les identifiants sont stockés dans une extension, un fichier de configuration, un dépôt de code, une sauvegarde accessible ou un poste compromis, un tiers peut les utiliser depuis une autre machine.

Les journaux du prestataire d’envoi, les adresses IP, les clés utilisées et les dates de création des accès permettent de distinguer un envoi initié par WordPress d’un abus externe des mêmes identifiants.

4. Une boîte e-mail professionnelle est compromise

Un attaquant peut se connecter à une boîte e-mail, créer une règle de transfert, autoriser une application ou envoyer directement depuis le webmail. Les messages peuvent alors apparaître dans le dossier « Envoyés », mais ce n’est pas systématique selon la méthode employée.

Dans cette situation, le site WordPress peut être totalement sain. Il faut examiner l’historique des connexions, les sessions actives, les règles, les applications autorisées et les paramètres de récupération du compte.

5. Le domaine est usurpé depuis une infrastructure extérieure

Un tiers peut tenter d’afficher votre domaine comme expéditeur sans accéder à votre site ni à votre messagerie. L’analyse des en-têtes et des résultats SPF, DKIM et DMARC permet de déterminer si le message a été authentifié et s’il correspond à une source autorisée.

Une politique d’authentification correctement conçue réduit les possibilités d’usurpation acceptée par les destinataires, mais elle doit tenir compte de tous vos expéditeurs légitimes : messagerie, WordPress, CRM, facturation, newsletter et services transactionnels.

6. Une automatisation légitime boucle ou envoie trop de messages

Une mise à jour, une règle WooCommerce, une synchronisation CRM, une relance de commande ou une tâche planifiée peut générer des doublons. Le contenu n’est pas nécessairement frauduleux, mais le volume peut provoquer des blocages et dégrader la réputation d’envoi.

Il faut alors identifier l’événement déclencheur, interrompre la boucle, vérifier les destinataires et tester les notifications une par une avant de rétablir le fonctionnement normal.

Les actions prioritaires pendant la première heure

Période	Objectif	Actions prudentes
0 à 10 minutes	Conserver les preuves	Sauvegarder les messages originaux, les en-têtes, les erreurs, les captures et l’heure de découverte
10 à 20 minutes	Identifier le canal probable	Contrôler les tableaux de bord de l’hébergeur, de la messagerie et du SMTP sans modifier immédiatement la configuration
20 à 30 minutes	Limiter l’envoi actif	Suspendre uniquement le formulaire, le compte, la clé ou le flux identifié ; solliciter l’hébergeur si la source reste inconnue
30 à 45 minutes	Sécuriser les accès	Révoquer les sessions ou clés suspectes, activer la double authentification et modifier les accès depuis un appareil fiable
45 à 60 minutes	Mesurer l’impact	Vérifier les fonctions métier, les plaintes, les rebonds, les clients touchés et préparer le diagnostic

Si les envois suspects s’accompagnent d’une redirection, d’un compte administrateur inconnu, de pages modifiées ou d’une alerte de sécurité, appliquez également le protocole général Site WordPress piraté : que faire ?.

Quelles preuves conserver avant le nettoyage ?

Les informations disponibles au début de l’incident peuvent disparaître rapidement : rotation des journaux, purge des files d’attente, suppression d’un compte ou remplacement d’une clé. Conservez les éléments sans les publier ni les transmettre à des personnes non concernées.

• plusieurs e-mails originaux au format complet, pas seulement des captures ;
• les en-têtes complets et les résultats SPF, DKIM et DMARC ;
• les retours de non-distribution dans leur intégralité ;
• les objets, destinataires, expéditeurs visibles, liens et pièces jointes ;
• les dates, heures et fuseaux horaires ;
• les identifiants de message et, lorsqu’elles sont disponibles, les adresses IP d’origine ;
• les alertes de l’hébergeur, du SMTP, du webmail ou d’un service anti-spam ;
• les journaux d’envoi, de connexion, d’accès et d’erreurs ;
• les entrées de formulaires et les événements WooCommerce correspondants ;
• la liste des comptes administrateurs, intégrations et applications autorisées ;
• un relevé des enregistrements DNS liés à l’e-mail avant toute modification ;
• les changements récents apportés aux extensions, formulaires, automatisations ou services d’envoi.

Les en-têtes peuvent contenir des adresses e-mail, des noms de serveurs ou d’autres informations techniques. Ne les publiez pas intégralement sur un forum public sans les avoir expurgés.

Comment limiter les envois sans effacer les traces ?

La bonne mesure dépend du canal utilisé. Une action ciblée réduit l’impact tout en conservant les informations nécessaires.

Source probable	Mesure de confinement possible	Vigilance
Formulaire précis	Mettre temporairement ce formulaire hors service ou supprimer sa réponse automatique	Conserver les soumissions et vérifier les autres formulaires
Compte SMTP ou clé d’API	Suspendre ou révoquer l’accès suspect puis créer un nouvel accès limité	Préserver l’historique et répertorier les applications qui utilisent la clé
Boîte e-mail compromise	Révoquer les sessions, modifier le mot de passe et contrôler les règles	Agir depuis un appareil fiable et vérifier les moyens de récupération
Script PHP inconnu	Demander à l’hébergeur de limiter les envois sortants ou isoler le site	Ne pas supprimer les fichiers avant leur inventaire
Usurpation extérieure	Analyser l’authentification et ajuster progressivement la politique du domaine	Inventorier tous les expéditeurs légitimes avant de durcir DMARC

Consignez l’heure de chaque action. Cette chronologie permettra de vérifier si les envois se sont arrêtés après la suspension d’un compte, d’une clé, d’un formulaire ou de l’ensemble du service.

Ce qu’un diagnostic doit vérifier

Un diagnostic complet ne se limite pas à lancer un scanner. Il doit relier les messages observés au canal qui les a réellement produits.

1. Les e-mails originaux : chemin suivi, serveurs traversés, identifiants, résultats d’authentification et cohérence des dates.
2. Le mode d’envoi de WordPress : fonction native, SMTP, API, service transactionnel ou plusieurs canaux simultanés.
3. Les formulaires : destinataires, confirmations automatiques, protections anti-robot, limitations de fréquence et journaux.
4. Les extensions et thèmes : versions, provenance, modifications, fichiers ajoutés et vulnérabilités connues.
5. Le cœur WordPress et la base de données : intégrité des fichiers, comptes inconnus, code injecté, options et tâches planifiées.
6. L’hébergement : journaux web, erreurs PHP, files d’e-mails, tâches serveur, autres applications et accès techniques.
7. Les comptes SMTP et API : clés actives, adresses IP, volumes, sessions, permissions et applications connectées.
8. La messagerie professionnelle : connexions inhabituelles, règles de transfert, délégations, applications autorisées et double authentification.
9. Le domaine : SPF, DKIM, DMARC, alignement des expéditeurs et cohérence avec tous les services légitimes.
10. La réputation d’envoi : rebonds, plaintes, blocages, mise en spam et éventuelles listes de blocage.
11. Les postes administrateurs : appareils utilisés pour WordPress, l’hébergement, le webmail et les services d’envoi.

Un statut « e-mail envoyé » dans WordPress ne garantit pas sa remise au destinataire. Il peut seulement indiquer que le système a accepté de traiter la demande. Les journaux du relais et les retours du serveur destinataire restent nécessaires pour connaître le résultat réel.

SPF, DKIM et DMARC : leur rôle et leurs limites

Les mécanismes d’authentification du domaine sont essentiels pour améliorer la confiance accordée aux messages et limiter l’usurpation. Ils ne remplacent toutefois ni le nettoyage du site ni la sécurisation des comptes.

Mécanisme	Rôle principal	Ce qu’il ne résout pas
SPF	Indique quels serveurs sont autorisés à envoyer pour un domaine utilisé lors du transport	Ne détecte pas un site infecté et peut être insuffisant lorsqu’un message est transféré
DKIM	Ajoute une signature permettant au destinataire de vérifier qu’un domaine a signé le message et que le contenu signé n’a pas été modifié	Un compte ou une clé autorisée mais compromise peut encore signer des messages abusifs
DMARC	Vérifie l’alignement avec le domaine visible et indique comment traiter les messages non conformes, avec des rapports	Une politique mal préparée peut bloquer vos propres expéditeurs légitimes

Une fois l’incident maîtrisé, l’authentification doit être contrôlée message par message sur chaque canal légitime. L’objectif n’est pas seulement que les enregistrements DNS existent, mais qu’ils correspondent réellement aux services utilisés.

Quel impact sur la délivrabilité et la réputation du domaine ?

Des envois abusifs peuvent provoquer des rebonds, des plaintes, une limitation du débit, un classement en courrier indésirable ou un blocage temporaire. L’impact peut concerner l’adresse IP d’envoi, le domaine, un sous-domaine ou le compte utilisé.

La remise en état doit suivre un ordre logique :

1. interrompre les envois non autorisés ;
2. identifier et corriger la cause ;
3. révoquer les accès ou clés exposés ;
4. nettoyer et mettre à jour le site lorsque WordPress est concerné ;
5. vérifier l’authentification de chaque service d’envoi ;
6. rétablir les flux légitimes progressivement ;
7. surveiller les rebonds, plaintes et nouveaux signaux ;
8. contacter les prestataires concernés lorsqu’un blocage doit être réévalué.

Après le nettoyage et la remise en service, prévoyez une phase de sécurisation WordPress et de surveillance afin de détecter rapidement une reprise des envois ou une nouvelle utilisation des accès.

Il n’existe pas de délai universel de récupération. Il dépend du volume envoyé, de la durée de l’abus, des destinataires touchés, de l’infrastructure utilisée et des mesures prises. L’arrêt des envois indésirables ne signifie donc pas que la délivrabilité revient immédiatement à son niveau antérieur.

Les erreurs à éviter

Considérer le champ expéditeur comme une preuve

L’adresse visible peut être usurpée. Sans les en-têtes, les journaux et les résultats d’authentification, il est impossible de conclure que le message est parti de votre site.

Supprimer une extension et déclarer le problème résolu

L’extension peut être innocente, constituer seulement le point d’entrée ou avoir laissé d’autres éléments sur le serveur. À l’inverse, le problème peut provenir d’une clé SMTP exposée sans infection de WordPress.

Purger les journaux et la file d’attente trop tôt

Ces données peuvent contenir les horaires, destinataires, scripts, comptes et adresses IP nécessaires à l’analyse. Exportez-les ou demandez leur conservation avant toute purge.

Modifier SPF, DKIM et DMARC au hasard

Plusieurs changements simultanés rendent le diagnostic difficile et peuvent interrompre vos e-mails légitimes. Inventoriez les expéditeurs, sauvegardez les valeurs existantes et procédez par étapes.

Envoyer de nombreux messages de test

Un grand nombre de tests alors que le domaine est déjà limité peut augmenter les rebonds et brouiller les journaux. Utilisez quelques destinataires contrôlés et testez un flux à la fois.

Restaurer une sauvegarde sans corriger le canal d’envoi

La sauvegarde peut contenir la même configuration, le même compte SMTP ou une infection déjà présente. La restauration doit s’accompagner d’une analyse du point d’entrée et des accès.

Considérer le site sain dès que les envois s’arrêtent

Le blocage du service, l’expiration d’une clé ou une limite quotidienne peut interrompre les messages sans supprimer la cause. Vérifiez la persistance, les comptes et les tâches avant de rétablir tous les flux.

Les informations à transmettre pour accélérer le diagnostic

Préparez une demande structurée avec :

• l’URL du site et le domaine utilisé dans les e-mails ;
• le nom de l’hébergeur et du prestataire de messagerie ;
• le service SMTP ou transactionnel utilisé, s’il est connu ;
• deux ou trois messages originaux avec leurs en-têtes ;
• les retours de non-distribution et alertes reçues ;
• la date et l’heure du premier signal ;
• le volume estimé et les types de destinataires touchés ;
• les objets, liens ou pièces jointes utilisés dans les messages ;
• les formulaires, commandes ou automatisations actifs sur le site ;
• les blocages appliqués par l’hébergeur ou le prestataire d’envoi ;
• les changements récents et les actions déjà tentées ;
• l’impact sur les commandes, formulaires, comptes clients ou e-mails internes.

Ne transmettez pas vos mots de passe, clés d’API ou identifiants SMTP dans le formulaire initial. Les accès éventuels doivent être demandés séparément, limités et révoqués après l’intervention.

Questions fréquentes

Comment savoir si les e-mails sont réellement partis de WordPress ?

Il faut comparer les en-têtes complets avec les journaux de l’hébergeur, de WordPress et du prestataire SMTP. Le champ expéditeur visible ne suffit pas. Les serveurs traversés, les résultats SPF, DKIM et DMARC, l’identifiant du message et l’horaire permettent de relier l’e-mail à une infrastructure.

Pourquoi les messages ne figurent-ils pas dans le dossier « Envoyés » ?

Un formulaire, une extension, un script PHP, un relais SMTP ou une API peut envoyer un message sans utiliser l’interface de votre boîte e-mail. Il ne crée donc pas nécessairement une copie dans le dossier « Envoyés ».

Peut-on usurper mon domaine sans pirater mon site ?

Oui. Un tiers peut tenter d’afficher votre domaine comme expéditeur depuis un autre serveur. L’authentification du domaine et l’analyse des en-têtes permettent de distinguer cette usurpation d’un envoi réellement autorisé.

Dois-je désactiver tous les formulaires ?

Pas systématiquement. Désactivez en priorité le formulaire dont l’abus est confirmé ou probable et conservez ses journaux. Si l’origine reste inconnue et que les envois se poursuivent, une limitation plus large peut être nécessaire avec l’aide de l’hébergeur.

Faut-il changer immédiatement le mot de passe SMTP ?

Si l’accès SMTP est susceptible d’être compromis, il faut le suspendre ou le remplacer rapidement, depuis un appareil fiable. Avant cela, conservez si possible les journaux, l’identifiant de la clé, les dernières connexions et les applications qui l’utilisent afin de ne pas perdre la chronologie.

SPF, DKIM et DMARC suffisent-ils à arrêter les spams ?

Non. Ils servent à authentifier les sources et à définir le traitement des messages non conformes. Un site infecté ou un compte autorisé mais compromis peut toujours envoyer des messages authentifiés. Il faut corriger la cause technique et sécuriser les accès.

Pourquoi mes e-mails légitimes sont-ils encore bloqués après le nettoyage ?

La réputation du domaine ou de l’adresse IP peut rester dégradée, et certains prestataires peuvent maintenir une limitation. Vérifiez également que chaque flux légitime est correctement authentifié, que les volumes sont revenus à la normale et que les plaintes ont cessé.

Combien de temps faut-il pour retrouver une délivrabilité normale ?

Il n’existe pas de durée fixe. Elle dépend du volume abusif, des destinataires, des plaintes, du prestataire, de la réputation antérieure et de la qualité de la correction. Le suivi doit se faire sur plusieurs jours ou semaines selon la gravité.