In breve: le mail rimbalzate mai inviate possono essere backscatter causato da spoofing, ma possono anche segnalare un invio autenticato da una casella, un sito o un dispositivo compromesso. Non basta guardare il campo From: conserva il bounce completo e confronta header, Message-ID, orario, Track Delivery e log SMTP prima di cambiare configurazioni.
Indice dei contenuti
Che cosa sono spoofing e backscatter
Nella posta elettronica il mittente visibile può essere falsificato. Uno spammer può inserire il tuo indirizzo nel campo From o nell’envelope sender senza conoscere la password della casella. Se un server destinatario accetta il messaggio e genera in seguito una notifica di mancata consegna, il bounce viene inviato all’indirizzo falsificato: questo ritorno indesiderato si chiama backscatter.
Il fenomeno è diverso dall’uso reale del tuo account. In un invio autenticato restano normalmente tracce nel server: utente cPanel, IP di origine, metodo di autenticazione, destinatario, Message-ID e risultato. Anche un sito compromesso può inviare posta tramite script PHP senza utilizzare la password della casella; per questo devono essere controllati sia il servizio email sia l’hosting web.
Mail rimbalzate mai inviate: segnali di compromissione
- Track Delivery mostra messaggi verso gli stessi destinatari e negli stessi orari indicati dai bounce.
- Compaiono autenticazioni SMTP da IP, paesi o client non riconosciuti.
- La cartella Posta inviata contiene messaggi estranei; l’assenza, però, non esclude un client SMTP o uno script.
- La coda di posta, i log o i report aumentano rapidamente.
- Il sito presenta file modificati, utenti amministrativi inattesi, plugin vulnerabili o form sfruttati per l’invio.
- Altri destinatari segnalano messaggi firmati DKIM e provenienti davvero dal tuo server.
Al contrario, bounce con destinatari casuali, header che indicano server esterni e nessuna corrispondenza nei log locali sono compatibili con lo spoofing. SPF, DKIM e DMARC aiutano i server riceventi a verificare il dominio, ma non impediscono materialmente a un aggressore di scrivere un indirizzo falso nel messaggio.
Controllare header e Track Delivery
- Salva il messaggio originale in formato EML oppure usa la funzione “Mostra originale”. Uno screenshot non contiene tutti gli header.
- Annota indirizzo destinatario, data, ora con fuso orario, oggetto, Message-ID e codice di errore SMTP.
- Negli header individua le righe
Received, leggendole dal basso verso l’alto per ricostruire il percorso. Non fidarti di una singola riga aggiunta dal mittente. - Apri cPanel → Email → Track Delivery e cerca il destinatario del messaggio originale, non soltanto l’indirizzo che ha ricevuto il bounce.
- Espandi i dettagli e confronta utente, Sender IP Address, Authentication, Sent Time, ID e risultato.
- Se Track Delivery non contiene l’evento, chiedi al provider una ricerca nei log Exim indicando un intervallo temporale ristretto e il Message-ID. Per altri casi di mancata consegna, consulta Gli errori più comuni delle mail.
Verificare caselle, sito e dispositivi
Caselle e client email
Controlla inoltri, filtri, autorisponditori e dispositivi configurati. Un vecchio telefono, un computer infetto o una password riutilizzata possono inviare senza lasciare copie nella Posta inviata del webmail. Se trovi attività non riconosciuta, conserva gli orari e sostituisci la password con una univoca e lunga. Se il problema dipende dal programma di posta, consulta Come risolvere i problemi di configurazione mail sul client di posta.
Sito web e script
Verifica log applicativi, moduli di contatto, plugin SMTP, cron e file modificati nello stesso intervallo. Un form privo di protezioni può essere abusato anche senza compromissione completa; malware o credenziali WordPress sottratte possono invece produrre campagne massive. Isola il sito in staging o manutenzione controllata se l’invio continua.
DNS e autenticazione del dominio
Controlla che SPF autorizzi soltanto i mittenti reali, che DKIM firmi la posta in uscita e che DMARC abbia allineamento e policy coerenti. Prima di irrigidire DMARC, analizza i report per non bloccare servizi legittimi come gestionali, newsletter o ticketing.
Mettere in sicurezza senza perdere prove
- Esporta header, bounce e log prima della loro rotazione.
- Cambia la password delle caselle coinvolte e di ogni account che riutilizzava la stessa credenziale.
- Revoca password applicative, sessioni e configurazioni non riconosciute; aggiorna i client autorizzati.
- Aggiorna CMS, plugin e temi, rimuovi software inutilizzato e scansiona i dispositivi.
- Blocca temporaneamente lo script o il form responsabile, mantenendo una copia per l’analisi.
- Monitora nuovi invii in Track Delivery e verifica che il volume torni alla normalità.
Errori da evitare
- Concludere che la casella è violata basandosi soltanto sul From del bounce.
- Eliminare i messaggi prima di salvare gli header completi.
- Cambiare soltanto la password email ignorando un sito che invia tramite PHP.
- Pubblicare header non oscurati: possono contenere indirizzi, IP e identificativi.
- Impostare subito una policy DMARC restrittiva senza censire tutti i mittenti legittimi.
- Rispondere al bounce o aprire allegati sospetti contenuti nel messaggio originale.
Domande frequenti
Un bounce prova che la mia casella è stata violata?
No. Può essere backscatter generato da un messaggio con mittente falsificato. La prova di un invio reale arriva dagli header coerenti e dai log SMTP del server.
Che cosa devo cercare in Track Delivery?
Cerca destinatario, orario e Message-ID; poi controlla utente cPanel, IP del mittente, autenticazione e risultato della consegna.
Devo cambiare subito la password?
Se i log mostrano autenticazioni o invii non riconosciuti, sì: conserva prima le prove, cambia la password con una univoca e revoca sessioni o configurazioni salvate sui dispositivi.
SPF e DMARC impediscono ogni messaggio falsificato?
Ridimensionano l’abuso del dominio e aiutano i destinatari a gestire i messaggi non autenticati, ma non impediscono a un aggressore di scrivere un indirizzo falso nel campo From.
Conclusione
Il punto decisivo è stabilire se il server Xlogic abbia realmente accettato l’invio. Header e log permettono di separare backscatter, abuso di una casella e invio da sito compromesso. Solo dopo questa distinzione ha senso intervenire su password, applicazione o record di autenticazione del dominio.