WordPress invia email spam: come trovare e fermare la causa

Se WordPress invia email spam, la prima cosa da individuare è il canale usato per spedire. Un modulo di contatto abusato, una password SMTP rubata e uno script PHP malevolo richiedono interventi diversi. Il nome del mittente, da solo, non dimostra che il messaggio provenga dal sito.

Questa guida ti aiuta a raccogliere le informazioni da chiedere al provider, contenere l'invio e verificare il ritorno delle email legittime. Se l'hosting ha già disabilitato il sito, affiancala alla procedura per hosting sospeso per malware.

Prima distinzione: il tuo server ha davvero spedito?

Un'email ricevuta con il tuo indirizzo nel campo “Da” potrebbe essere una falsificazione del mittente. Anche ricevere notifiche di mancata consegna non prova automaticamente un invio dal tuo hosting.

Chiedi al provider un messaggio identificato nei suoi log, con orario e fuso, identificativo di coda e modalità di ingresso. Se usi un servizio email esterno, controlla anche il suo registro delle attività: il traffico potrebbe non attraversare il server web.

I record SPF, DKIM e DMARC aiutano nella gestione dell'autenticazione del dominio, ma non rimuovono codice malevolo né revocano una credenziale SMTP rubata. La documentazione cPanel distingue la recapitabilità delle email dalla prevenzione degli abusi.

Tre cause da distinguere

1. Un modulo legittimo viene usato per generare spam

Il sito potrebbe inviare notifiche o risposte automatiche ogni volta che un bot compila un form. Se il destinatario è ricavato da un campo libero, o il testo inserito viene ripetuto integralmente nella risposta, il modulo può diventare un veicolo di abuso.

Confronta l'orario degli invii con richieste e registrazioni del form. Verifica destinatari, messaggi automatici, limiti di frequenza e controlli lato server. La correzione può consistere nel contenere quel modulo e cambiare il suo comportamento, senza che sia stata dimostrata una compromissione del codice.

2. Viene usata una credenziale SMTP o una chiave del servizio email

Qui l'invio può avvenire anche da un computer esterno. Disabilitare il plugin SMTP di WordPress non impedisce necessariamente a chi possiede la password o la chiave di continuare a spedire.

Cerca accessi autenticati, indirizzi IP e attività della credenziale coinvolta. Revoca il segreto esposto, controlla gli altri sistemi che lo usano e aggiorna solo gli impieghi autorizzati. Se era salvato sul sito, indaga anche come sia stato ottenuto: la rotazione non spiega il punto d'ingresso.

3. Uno script sul server invia direttamente

Un file malevolo può spedire attraverso il mail server locale o collegarsi a un servizio esterno. Può trovarsi fuori dalla normale cartella dei plugin e non utilizzare le funzioni di WordPress.

Chiedi al provider quale account o processo ha originato il messaggio e se dispone del percorso dello script. Un eventuale header X-PHP-Script è un indizio da confermare con i log del server; può mancare e non va trattato come prova autonoma.

La ricerca va estesa all'account hosting, comprese copie di staging e vecchie installazioni. Se emergono eseguibili nei media, usa la guida ai file PHP in uploads.

Cosa guardare in cPanel

Se disponibile, apri Email > Track Delivery, chiamato anche Traccia consegna. Cerca messaggi nell'intervallo segnalato, includendo successi, fallimenti e invii differiti. Apri i dettagli di alcuni campioni.

Annota:

• data, ora e fuso del report;
• identificativo del messaggio, mittente e destinatario;
• esito e risposta del server destinatario;
• account o autenticazione indicati nei dettagli;
• eventuale servizio esterno usato dal sito.

La documentazione di Track Delivery precisa che il report dipende dai dati conservati in eximstats e può non essere disponibile. Un elenco vuoto non certifica l'assenza di spam. In quel caso chiedi una verifica dei log al provider.

Un modello di ticket utile al provider

Invia la richiesta dall'area assistenza autenticata. Non allegare password, chiavi API o contenuti personali delle email.

Avete segnalato invii spam relativi al mio account hosting. Potete fornire alcuni identificativi di coda, orari con fuso e modalità di origine dell'invio? Vorrei distinguere autenticazione SMTP, script locale e servizio esterno. Se disponibile, indicate l'account coinvolto, il percorso dello script e l'IP di autenticazione. Chiedo inoltre di preservare i log del periodo e di concordare un contenimento circoscritto alla sorgente individuata.

Se l'account ospita più siti, chiedi a quale percorso è attribuito l'invio. Il dominio scritto nel mittente potrebbe non coincidere con l'installazione responsabile.

Contieni l'abuso senza perdere le evidenze

Prima di rimuovere file o svuotare code conserva una copia verificata di file, database e log pertinenti. La copia del sito compromesso serve all'indagine; non è un punto di ripristino pulito.

Con il provider concorda il contenimento della sorgente: blocco della credenziale esposta, sospensione del modulo abusato o limitazione dell'account responsabile. Definisci anche quali notifiche aziendali resteranno ferme e chi le controllerà.

Non svuotare indiscriminatamente una coda che potrebbe contenere conferme d'ordine. Se il problema è uno script malevolo, conservarne una copia e impedirne l'esecuzione è solo una fase: occorre cercare il meccanismo che l'ha installato e le eventuali persistenze.

Evita di trasferire subito gli invii su un nuovo servizio SMTP. Potresti spostare l'abuso e compromettere un altro account. Per il lavoro sul sito segui il metodo di bonifica WordPress.

Verifica prima di riattivare tutti gli invii

Registra l'orario delle correzioni e confronta il comportamento successivo con quello precedente. Non basta che il plugin dichiari “email inviata”: anche la funzione ufficiale wp_mail() distingue l'esito della chiamata dalla ricezione effettiva.

Esegui pochi test verso indirizzi che controlli:

1. richiesta dal form e relativa risposta;
2. recupero password di un account di prova;
3. notifiche commerciali essenziali, in staging quando possibile;
4. corrispondenza tra test, log di invio e ricezione;
5. assenza di nuovi invii abusivi nei registri consultabili.

Controlla anche le richieste al form e le attività SMTP: un periodo senza invii potrebbe dipendere dal blocco ancora attivo. Se i log non permettono di attribuire la sorgente, riportalo esplicitamente.

Quando sono coinvolti file sospetti, accessi non autorizzati o invii ricorrenti, il servizio di bonifica malware affronta la causa con verifiche documentate.