IP di hosting condiviso in blacklist: cosa potete risolvere e cosa no
Quando l'IP di un hosting condiviso finisce in blacklist, il primo compito è stabilire chi controlla quell'IP e su quale lista si trova esattamente, con quale codice di risposta. Poi sistemate tutto ciò che dipende da voi e inviate al vostro provider di hosting le prove della verifica, così che possa intervenire. Su un IP condiviso la causa potrebbe essere un altro cliente, e per alcune liste solo il proprietario della rete può richiedere la rimozione.
Anche un IP di VPS o cloud appena assegnato può risultare "in blacklist" fin dal primo giorno, a causa della storia di un utente precedente oppure perché l'intervallo è elencato come uno che non dovrebbe inviare posta direttamente. In ogni caso, la decisione sulla rimozione spetta sempre al gestore della lista.
Questa guida si basa sulle pagine ufficiali di Spamhaus, AWS, Google Cloud e Microsoft Azure aggiornate a novembre 2026. Restrizioni e procedure cambiano, quindi verificate la formulazione attuale prima di agire. Per un quadro più ampio dei bounce legati alle blacklist, vedete la nostra guida sulle email bloccate dalle blacklist.
Per prima cosa: quale IP e quale lista
"Il mio server è in blacklist" può significare cose molto diverse, e la soluzione dipende dai dettagli. Rispondete a tre domande prima di fare qualsiasi altra cosa.
- Quale IP invia davvero la vostra posta? L'IP che ospita il sito web non è necessariamente quello che consegna le email. Leggete il messaggio di bounce, che spesso riporta l'IP rifiutato, e controllate gli header Received di un messaggio che avete inviato per confermare l'indirizzo reale in uscita.
- Chi controlla quell'IP? Su un hosting condiviso è un indirizzo condiviso con altri clienti. Su un server dedicato, una VPS o un'istanza cloud è assegnato a voi, anche se l'intervallo circostante appartiene comunque al provider. Il vostro piano di hosting o il pannello di controllo vi diranno se la posta in uscita usa un indirizzo condiviso.
- Su quale lista si trova? Le liste differiscono per significato e per chi può risolvere il problema. Inserite l'IP nel nostro blacklist checker per vedere tutte le principali liste in una volta, e annotate i nomi delle liste e i codici di risposta.
Una volta ottenute queste tre risposte, di solito diventa chiaro se si tratta di qualcosa che potete risolvere da soli, di qualcosa che deve risolvere il provider o di un segnale che conviene cambiare del tutto il modo in cui inviate la posta.
Come leggere i risultati e i codici di risposta
Spamhaus ZEN (zen.spamhaus.org) è la lista IP combinata di Spamhaus. Un IP elencato restituisce un indirizzo nell'intervallo 127.0.0.x, e l'ultimo numero indica quale lista sottostante ha dato corrispondenza. Per gli IP di hosting condiviso e cloud, questi sono i codici che conviene distinguere:
| Codice di risposta | Lista | Che cosa significa di solito su hosting o cloud |
|---|---|---|
| 127.0.0.2 | SBL | L'IP è stato identificato come malevolo. Le richieste di rimozione devono provenire dall'ISP o dalla società di hosting che lo gestisce. |
| 127.0.0.3 | CSS | Elencato automaticamente per l'invio di posta di bassa reputazione. Eliminate la causa prima di richiedere la rimozione. |
| 127.0.0.4 | XBL | Segni di compromissione. Sospettate una macchina infetta o un sito abusato da qualche parte sull'IP. |
| 127.0.0.10 | PBL (gestita dall'ISP) | La rete ha contrassegnato l'intervallo come uno che non dovrebbe inviare posta direttamente. |
| 127.0.0.11 | PBL (gestita da Spamhaus) | Stesso significato di policy; l'auto-esclusione può essere possibile se soddisfate le condizioni. |
Una voce nella PBL non è un'accusa. È una dichiarazione di policy secondo cui la posta da questo indirizzo dovrebbe essere inviata, con autenticazione, a un server che la inoltra. Spamhaus incoraggia attivamente ISP e altre reti a elencare ogni intervallo che non dovrebbe inviare posta, e questo include esplicitamente i server web.
I codici 127.255.255.252, 127.255.255.254 e 127.255.255.255 sono errori, non listing. La FAQ di Spamhaus sull'uso delle DNSBL avverte inoltre che un resolver pubblico gratuito come Google Public DNS (8.8.8.8) nella maggior parte dei casi restituirà "non elencato", ed è per questo che strumenti diversi possono dare risultati discordanti. Nel dubbio, verificate il risultato sul reputation checker di Spamhaus. Per le procedure complete lista per lista, vedete come funziona la rimozione da Spamhaus.
Che cosa potete risolvere da soli e che cosa no
Quanto potete cambiare dipende da ciò per cui pagate.
| Tipo di hosting | Di solito potete risolvere | Di solito non potete risolvere |
|---|---|---|
| Hosting condiviso (IP condiviso) | Problemi all'interno del vostro account: password di caselle trapelate, un sito violato, un modulo di contatto abusato; SPF, DKIM e DMARC per il vostro dominio | Gli invii di altri clienti, l'IP in uscita stesso, le richieste di rimozione dalla SBL, reverse DNS e HELO del server |
| VPS o server dedicato | Configurazione del sistema operativo e del server di posta, reverse DNS e HELO coerenti, policy della porta 25 in uscita, rimozione del malware | Listing che coprono l'intero intervallo del provider (come le voci PBL gestite dall'ISP) e le policy di rete del provider |
| Istanza cloud | Tutto quanto sopra, più lo spostamento della posta in uscita su un servizio di invio esterno | Le restrizioni sulla porta 25 della piattaforma, che solo il provider può revocare |
Escludere il vostro account su un hosting condiviso
- Caselle compromesse. Esaminate i log di invio e le cartelle della posta inviata alla ricerca di raffiche di messaggi che non avete inviato. Se ne trovate, cambiate subito le password.
- Un sito web violato. Installazioni CMS e plugin non aggiornati sono un modo comune con cui gli attaccanti caricano script per l'invio di posta.
- Moduli abusati. I moduli di contatto la cui risposta automatica consente al visitatore di scegliere il destinatario o il testo possono trasformarsi in un cannone da spam.
- Qualità delle liste. Inviare a liste acquistate o a indirizzi che non hanno mai dato il consenso è un modo sicuro per danneggiare un IP condiviso per tutti, voi compresi.
Se nessuno di questi controlli porta a qualcosa, la causa probabile è qualcun altro sullo stesso indirizzo. La FAQ di Spamhaus sulla porta 25 lo dice senza mezzi termini: sui pool di IP condivisi, la maggior parte delle persone colpite da un listing non è quella con il dispositivo infetto. In tal caso il vostro compito è raccogliere le prove e consegnarle al provider.
Come segnalarlo al vostro provider di hosting
Spamhaus afferma che le richieste di rimozione dalla SBL devono essere inviate dall'ISP responsabile dell'IP elencato, e invita gli utenti comuni a rivolgersi al proprio ISP per la risoluzione. Per un cliente di hosting condiviso, quell'ISP è la vostra società di hosting. Un ticket di assistenza che dice soltanto "le mie email non arrivano" tende a rimbalzare da un reparto all'altro. Un ticket che include quanto segue di solito procede più rapidamente:
- L'IP di invio, confermato dagli header o dal bounce.
- La lista e il codice di risposta, per esempio zen.spamhaus.org che restituisce 127.0.0.2.
- Quando avete controllato e con che cosa, compreso ciò che mostrava il reputation checker ufficiale, se lo avete usato.
- Il testo del bounce, in particolare la riga in cui il server ricevente spiega il rifiuto.
- Che cosa avete già escluso, come il reset delle password e una scansione pulita del sito.
- Che cosa chiedete: un'indagine, una richiesta di rimozione al gestore della lista se opportuno, oppure lo spostamento della posta in uscita del vostro account su un IP diverso.
Un breve esempio:
Our outbound IP 192.0.2.10 returns 127.0.0.2 (SBL) on zen.spamhaus.org.
We confirmed this on the official Spamhaus checker at 10:00 UTC on 2026-11-03.
We have reset all mailbox passwords and found no unexpected files on our site.
Please investigate, request removal if appropriate, or advise whether our mail
can be sent from a different IP.Il provider potrebbe aver bisogno di tempo, e anche quando interviene, la decisione finale spetta al gestore della lista. Se avete posta che non può attendere, valutate l'opzione del relay descritta più avanti come soluzione parallela. Se non riuscite a capire dove sia il problema, potete anche chiederci aiuto.
Restrizioni sulla porta 25 e reverse DNS su VPS e cloud
Se gestite un vostro server di posta su una VPS o un'istanza cloud, potreste incontrare un problema prima ancora che entri in gioco una blacklist: molti provider limitano la porta TCP 25 in uscita, quella usata per la consegna della posta da server a server. La documentazione ufficiale di AWS, Google Cloud e Microsoft Azure dice quanto segue.
- Amazon EC2 (AWS). Per impostazione predefinita, EC2 consente il traffico in uscita sulla porta 25 solo verso indirizzi IPv4 privati; il traffico verso indirizzi IPv4 e IPv6 pubblici è bloccato. Potete richiedere la rimozione della restrizione. Per le email verso terzi, AWS consiglia di predisporre indirizzi Elastic IP e di assegnare loro record reverse DNS statici, osservando che ciò può aiutare a evitare che la posta venga contrassegnata come spam. Prima di creare il record inverso deve esistere un record DNS diretto (A) che risolva verso l'Elastic IP.
- Google Cloud (Compute Engine). Il traffico in uscita verso la porta TCP 25 su indirizzi IP esterni è bloccato per impostazione predefinita. Il blocco viene rimosso automaticamente quando Google Cloud stabilisce che un progetto è a basso rischio, e potete verificare lo stato di un progetto tramite un banner nelle pagine delle reti VPC o delle policy firewall nella console. SMTP su TLS sulle porte 465 e 587 è escluso dal blocco. Google consiglia di usare un provider email di terze parti affidabile, cosa che secondo Google migliora la reputazione del vostro IP.
- Microsoft Azure (macchine virtuali). La porta 25 in uscita è bloccata per ogni tipo di sottoscrizione diverso da Enterprise Agreement standard e Microsoft Customer Agreement for enterprise (MCA-E). Le sottoscrizioni Enterprise Dev/Test sono bloccate per impostazione predefinita, ma possono essere esentate tramite la diagnostica nel portale. I servizi di relay SMTP autenticato, di solito sulla porta 587, non sono soggetti a restrizioni per nessun tipo di sottoscrizione, e Microsoft li consiglia. Anche dove la porta 25 è aperta, Microsoft osserva che non c'è garanzia che i domini esterni accettino la posta.
Una porta 25 bloccata è un problema di consegna, non di reputazione, e aprire la porta non migliora in alcun modo la posizione del vostro IP. Se desiderate un'esclusione dalla PBL di Spamhaus per un indirizzo cloud o VPS, l'IP deve essere statico, eseguire effettivamente un server di posta in uscita, avere DNS diretto e inverso corretti ed essere assegnato a voi. Spamhaus richiede inoltre che la porta 25 in uscita sia chiusa per ogni altro dispositivo dietro di esso.
Passare a un IP dedicato o a un relay SMTP autenticato
Se un IP condiviso continua a essere penalizzato dai vicini, o il vostro provider cloud non apre la porta 25, cambiare il modo in cui inviate è spesso più pratico che inseguire le rimozioni.
Un relay SMTP esterno e autenticato
Invece di far consegnare la posta direttamente al destinatario dal vostro server, il server consegna ogni messaggio a un server di invio autenticato che lo recapita per vostro conto. È esattamente il modello che Spamhaus descrive per gli intervalli elencati nella PBL: ci si aspetta che la posta venga inviata con autenticazione a un relay, che può essere gestito dall'ISP di connessione o da un servizio di posta esterno. La FAQ di Spamhaus sulla porta 25 aggiunge che gli utenti finali dovrebbero usare le porte 587 o 465 con SMTP AUTH. Azure e Google Cloud consigliano entrambi relay autenticati o servizi email di terze parti, e Microsoft osserva che questi servizi vengono usati anche per mantenere la reputazione IP da cui dipende la consegna.
- Configurate il nome host del relay, la porta (di solito 587) e le credenziali come indicato dal vostro provider.
- Aggiornate il record SPF del vostro dominio per includere il relay e configurate per esso la firma DKIM. Vedete come configurare SPF, DKIM e DMARC.
- Controllate i limiti di invio del relay prima di spostarvi grandi volumi di posta.
Un IP dedicato
Un IP dedicato vi protegge dal comportamento degli altri clienti, ma non migliora automaticamente la reputazione. Le linee guida per i mittenti di Spamhaus elencano i fattori che influenzano la reputazione, tra cui il fornitore di servizi, il vicinato IP, l'infrastruttura dietro l'indirizzo e la storia dell'IP.
- I nuovi indirizzi sono sottoposti a controlli aggiuntivi. Le stesse linee guida indicano che i domini HELO senza storia di invio sono soggetti a filtraggio aggiuntivo, e che un IP o un hostname HELO cambiato va trattato come nuovo e riscaldato gradualmente. I servizi di warm-up che generano traffico artificiale sono vietati.
- Impostate un reverse DNS significativo. Spamhaus avverte che un reverse DNS generico o generato automaticamente sugli IP dedicati può danneggiare la reputazione.
- Controllate il nuovo IP prima di usarlo. Un indirizzo può portarsi dietro un listing dell'utente precedente, quindi verificatelo prima di iniziare a inviare.
Come evitare che si ripeta
- Allineate hostname, HELO e reverse DNS. La FAQ di Spamhaus sulla CSS indica che il DNS diretto del vostro IP dovrebbe corrispondere al valore HELO impostato sul server e che l'HELO dovrebbe essere un nome di dominio completo (FQDN). Cita valori come localhost.localdomain tra gli errori comuni.
- Limitate la porta 25 ai server di posta. Su una VPS che esegue anche altri carichi di lavoro, chiudete la porta 25 in uscita per tutto ciò che non è il vostro server di posta.
- Mantenete siti e account protetti. Aggiornate CMS e plugin, smettete di riutilizzare le password e attivate l'autenticazione a due fattori dove possibile.
- Rivedete le impostazioni della posta in uscita nel pannello di controllo. La FAQ sulla CSS descrive un'opzione di Plesk che inserisce il nome di ciascun dominio nel saluto SMTP. Avverte che, quando più domini sul server condividono un IP, la posta di alcuni o di tutti quei domini può essere contrassegnata come spam dai destinatari che usano la Spamhaus XBL, e che l'opzione va usata con estrema cautela. Controllate l'impostazione equivalente nel vostro pannello e seguite le indicazioni del provider o del produttore del pannello.
- Monitorate regolarmente. Un IP condiviso può cambiare stato a causa delle azioni di qualcun altro. Controllatelo periodicamente con il nostro blacklist checker e avvisate presto il provider quando qualcosa cambia.
Anche dopo una rimozione, i destinatari applicano i propri filtri, quindi il recapito potrebbe non riprendersi subito. I listing CSS di norma scadono circa tre giorni dopo l'ultimo rilevamento, ma l'IP viene elencato di nuovo se il problema viene ancora rilevato, e le auto-rimozioni sono limitate.
Presentiamo fornitori che si occupano di richieste di rimozione, consulenza e assistenza (a partire da JPY 50,000). La rimozione è decisa da ciascun gestore della lista e non può essere garantita.
Richiedi assistenzaQuesto sito può ricevere una commissione dai fornitori presentati. About
Domande frequenti
L'IP del mio hosting condiviso è in blacklist. Posso richiedere io la rimozione?
Dipende dalla lista. Per la Spamhaus SBL, le richieste di rimozione devono provenire dall'ISP o dalla società di hosting responsabile dell'IP. Su un indirizzo condiviso la causa può essere anche un altro cliente, quindi la strada normale è inviare al provider il risultato della verifica e il codice di risposta e chiedergli di occuparsene.
L'IP della mia VPS nuova è già nella PBL. C'è qualcosa che non va?
Non necessariamente. La PBL elenca gli intervalli che non dovrebbero inviare posta direttamente, e Spamhaus incoraggia le reti a includere i server web. Inviate tramite un relay autenticato oppure, se gestite un server di posta configurato correttamente su un IP statico con DNS diretto e inverso coerenti, valutate di richiedere l'esclusione.
La mia VM cloud non riesce a inviare nessuna email. È una blacklist?
Controllate prima la porta 25. Per impostazione predefinita AWS e Google Cloud bloccano la porta 25 in uscita verso indirizzi esterni, e Azure la blocca per la maggior parte dei tipi di sottoscrizione. Google Cloud e Azure documentano come alternativa l'invio autenticato su porte come la 587, e AWS consente di richiedere la rimozione della restrizione.
Un IP dedicato mi terrà fuori dalle blacklist?
Elimina il rischio dovuto agli altri clienti, ma nulla impedisce del tutto un listing. I nuovi IP senza storia possono subire filtri aggiuntivi, quindi riscaldateli gradualmente e impostate reverse DNS e HELO corretti.
Pagine ufficiali consultate
Le informazioni di questo articolo sono state verificate sulle pagine ufficiali indicate di seguito al momento della pubblicazione. Le policy e il funzionamento possono cambiare senza preavviso: prima di fare affidamento su un'informazione importante, consulti le pagine ufficiali.
- Spamhaus: Policy Blocklist (PBL)
- Spamhaus: Spamhaus Blocklist (SBL)
- Spamhaus FAQ: DNSBL Usage (return codes and public resolvers)
- Spamhaus FAQ: Combined Spam Sources (CSS)
- Spamhaus FAQ: Port 25 General Questions
- Spamhaus: Sender Guidelines
- AWS: Amazon EC2 service quotas (Restriction on email sent using port 25)
- AWS: Create a reverse DNS record for email on Amazon EC2
- Google Cloud: Sending email from an instance
- Google Cloud: VPC firewall rules (Blocked and limited traffic)
- Microsoft Learn: Troubleshoot outbound SMTP connectivity in Azure
Guide correlate
In lista su Spamhaus? Scopra in quale lista è (ZEN, PBL, XBL, CSS, SBL, DBL), cosa indicano i codici di ritorno e la procedura di rimozione per ciascuna.
Email bloccate da una blacklist? Legga il codice di errore, verifichi le cause nell'ordine giusto, capisca quali inserimenti contano e chieda la rimozione.
SPF, DKIM e DMARC con record DNS pronti, il limite di 10 lookup, chiavi a 2048 bit, un avvio sicuro con p=none e le regole di Gmail, Yahoo e Outlook.