Errore Server SMTP non risponde: diagnostica
Lerrore Server SMTP non risponde compare sui client quando non si riesce a stabilire una connessione TCP con il server di posta in uscita. In questa guida vediamo come isolare rapidamente la causa, distinguendo tra problemi di rete, firewall, certificato e disservizio reale.
Catena della connessione SMTP
Per inviare un messaggio il client deve: risolvere il DNS dellhostname, aprire una connessione TCP sulla porta (465/587), negoziare TLS, autenticarsi, trasmettere il messaggio. Lerrore puo verificarsi in qualunque punto, ma il client lo segnala in modo generico.
Procedura passo-passo
- Verifica se altri client (es. webmail) inviano correttamente: in tal caso il problema e locale.
- Apri Terminale o Prompt e digita ping mail.tuo-dominio.it.
- Verifica risoluzione DNS: nslookup mail.tuo-dominio.it.
- Testa la porta: telnet mail.tuo-dominio.it 465 o nc -zv mail.tuo-dominio.it 587.
- Se la porta non risponde, controlla il firewall locale e il router.
- Testa una porta alternativa (es. 587 se 465 e bloccata).
- Cambia rete (passare da Wi-Fi a hotspot mobile): se funziona, la rete iniziale blocca la porta.
- Verifica la versione TLS supportata dal client (TLS 1.2 minimo).
- Controlla scadenza certificato server (alcuni client rifiutano cert scaduti).
Verifica lato server
Se il problema sembra lato server, contatta il provider con: hostname, porta usata, ora dei tentativi, messaggio derrore esatto. Su Plesk lamministratore puo verificare lo stato di Postfix e la coda con postqueue -p.
Errori comuni e come risolverli
- Porta 25 bloccata da provider internet: usa 465 o 587.
- Firewall locale aggressivo: aggiungi eccezione per il client di posta.
- VPN aziendale: alcune VPN bloccano SMTP esterno; usa SMTP via VPN.
- DNS aziendale che non risolve: usa DNS pubblici (1.1.1.1, 8.8.8.8) per test.
- Versione TLS obsoleta nel client: aggiorna lapplicazione di posta.
Domande frequenti
D: Posso aspettare e riprovare?
R: Se il problema e transitorio si, ma se persiste oltre 1 ora indaga.
D: Funziona da casa ma non in ufficio?
R: Quasi sicuramente firewall o policy aziendale; coordinati con IT.
D: Devo cambiare provider?
R: Quasi mai; nella maggior parte dei casi il problema e di rete locale o configurazione client.
Connettivita dei port comuni
Le porte di posta tipiche sono: 25 (SMTP standard, spesso bloccato da ISP), 465 (SMTPS), 587 (SMTP submission con STARTTLS), 993 (IMAPS), 995 (POP3S). I provider internet residenziali spesso bloccano la 25 per ridurre lo spam: usa sempre 465 o 587 per linvio. Verifica con nc -zv server porta da terminale.
Le reti aziendali con firewall stretto possono bloccare anche 465 e 587. Coordina con lIT per sbloccare le porte verso il server di posta autorizzato. In alternativa, alcuni provider offrono interfacce HTTP/HTTPS per linvio (API REST), evitando del tutto problemi di porte SMTP. Brevo, SendGrid e Mailgun offrono tutti questa opzione.
Test automatici e monitoring
Strumenti come swaks (Swiss Army Knife for SMTP) permettono di simulare invii SMTP da terminale con controllo dettagliato di ogni parametro. Utile per diagnostica avanzata: testare autenticazione, TLS, header, contenuti. Soluzioni di monitoring come UptimeRobot o Better Stack offrono test periodici SMTP con alert in caso di failure.
Configura monitoring automatico per il tuo server SMTP: invio di un messaggio di test ogni 5 minuti verso una casella di controllo, alert se non arriva. Plesk integra strumenti di monitoring di base; soluzioni esterne offrono storia, grafici, dashboard. Lobiettivo e scoprire problemi prima dei clienti, mantenendo la qualità di servizio.
Strategie di troubleshooting strutturato
Un'approccio strutturato al troubleshooting accelera la risoluzione dei problemi. Il metodo classico e: definisci il sintomo, isola il componente, formula ipotesi, testa, conferma o passa allipotesi successiva. Per problemi email gli step iniziali sono: webmail funziona? Un'altro client ha lo stesso problema? Da unaltra rete?
Documenta i problemi risolti in una knowledge base interna: spesso lo stesso problema si ripresenta dopo mesi e ricordare la soluzione e prezioso. Tools come Notion, Confluence o un wiki interno facilitano la condivisione tra il team. Per problemi ricorrenti considera contromisure automatiche permanenti.
Tenere log dettagliati e una pratica essenziale. Plesk archivia log per Postfix e Dovecot; configura rotazione e retention per non perdere storia importante. Tool come Graylog o ELK Stack centralizzano log da più fonti, offrendo ricerca veloce e dashboard. Linvestimento in osservabilita ripaga ad ogni incidente.
Monitoraggio delle prestazioni
Le prestazioni del sistema di posta dipendono da molti fattori: hardware del server, configurazione Postfix/Dovecot, qualità della connessione internet, numero di caselle concorrenti. Plesk integra un dashboard con metriche fondamentali; per ambienti professionali consigliamo strumenti dedicati come Munin, Nagios o Zabbix.
Metriche chiave da monitorare: tempo di consegna medio dei messaggi in entrata e uscita, dimensione della coda Postfix, numero di connessioni IMAP attive, utilizzo CPU e memoria. Alert proattivi su anomalie permettono di intervenire prima che gli utenti se ne accorgano. Configura soglie ragionevoli basate su dati storici.
Per organizzazioni con vincoli rigorosi pubblica internamente i target di servizio (es. consegna entro 30 secondi, uptime 99.95%) e misura il loro raggiungimento. La trasparenza con i dipendenti sulle prestazioni del servizio email crea fiducia e facilita la giustificazione di investimenti in infrastruttura quando necessari.
Hai bisogno di aiuto?
Se hai dubbi sulla configurazione delle tue email, il team di G Tech Group puo aiutarti. Contattaci tramite il modulo di contatto.