Il protocollo SMTP trasporta le tue email dal client o dall’applicazione fino al server del destinatario, e ogni connessione passa attraverso una porta precisa. Per l’invio da un client di posta o da uno script, usa la porta 587 con STARTTLS come impostazione predefinita. La porta 465 funziona in TLS implicito e resta un’alternativa altrettanto valida. La porta 25 serve al trasferimento tra server e nella maggior parte dei casi risulta bloccata dai provider di accesso e dagli hosting cloud. La porta 2525 risolve il problema quando la 587 viene filtrata da una rete terza. Verificare quale porta usare richiede un solo comando e meno di 2 minuti.
Le 4 porte SMTP e il loro uso reale
Ogni porta corrisponde a un ruolo preciso nella catena di invio, fissato dagli standard del protocollo. La porta 25 è la porta storica del protocollo, riservata al trasferimento da server a server (MTA a MTA): un server di posta che inoltra un messaggio verso un altro server di posta passa da lì, mai un client di posta o un’applicazione che invia un’email. La porta 587 è stata standardizzata nel 2007 (RFC 4409, poi sostituita dalla RFC 6409) specificamente per l’invio autenticato, con una cifratura attivata dopo la connessione tramite il comando STARTTLS. La porta 465 ha una storia più travagliata. Assegnata negli anni ’90 per SMTP su SSL, è stata considerata obsoleta per quasi 20 anni a favore della 587, per poi essere ufficialmente riabilitata. La RFC 8314, pubblicata dall’IETF nel gennaio 2018, reintegra la porta 465 come porta ufficiale di invio in TLS implicito e la presenta come la direzione tecnica raccomandata a lungo termine, davanti alla 587.
La RFC 8314 definisce l’uso del testo in chiaro come superato per l’invio e l’accesso ai messaggi, e raccomanda la cifratura fin dall’apertura della connessione invece della sua attivazione durante lo scambio (IETF, gennaio 2018).
La porta 2525 non è oggetto di alcuna standardizzazione IETF. Serve come soluzione di riserva quando una rete filtra la 587 e la 25, e la maggior parte dei router email commerciali la supporta, senza però che questa porta sia garantita presso tutti i provider.
STARTTLS o TLS implicito: la differenza concreta
STARTTLS apre la connessione in chiaro, poi il client invia il comando STARTTLS per passare a un canale cifrato prima di scambiare credenziali e contenuto del messaggio. Il TLS implicito cifra fin dalla prima stretta di mano TCP: nessun dato circola in chiaro, nemmeno durante la negoziazione. La RFC 8314 giustifica questa scelta con il rischio di intercettazione durante la breve finestra in chiaro che precede il comando STARTTLS, una finestra che un intercettore attivo sulla rete può sfruttare per forzare una connessione non cifrata. Un client mal configurato può inviare una password SMTP senza protezione se il server non rifiuta i tentativi senza STARTTLS.
Perché la porta 25 è bloccata in uscita
Il blocco è volontario: rientra in una politica contro lo spam in uscita. I provider di accesso francesi per il grande pubblico (Orange, Free, SFR, Bouygues Telecom) filtrano le connessioni in uscita sulla 25 dai loro router per impedire alle macchine compromesse del proprio parco di inoltrare spam direttamente verso Internet. Il ragionamento è identico lato cloud: secondo la documentazione ufficiale di AWS, il traffico in uscita sulla porta 25 è bloccato di default per tutte le istanze EC2 e le funzioni Lambda, salvo richiesta esplicita di sblocco approvata tramite un ticket di supporto. OVHcloud applica una restrizione comparabile su parte del proprio catalogo di hosting condiviso. Il fallimento è sistematico. Un’applicazione ospitata su un VPS o su un router per il grande pubblico che tenta di inviare direttamente sulla porta 25 fallisce indipendentemente dalla qualità della sua configurazione DNS o del suo contenuto. La soluzione non è aggirare questo blocco, ma inviare il messaggio sulla 587 o sulla 465, porte che queste stesse reti lasciano aperte.
Quale porta usare in base al proprio provider
La tabella seguente elenca solo le porte accettate in invio. Per l’indirizzo esatto del server del tuo provider, consulta la nostra guida per trovare il server SMTP della propria posta.
| Provider | Porte accettate | Nota |
|---|---|---|
| Gmail | 587, 465 | 587 raccomandata da Google, autenticazione obbligatoria su entrambe |
| Outlook / Microsoft 365 | 587 | 465 non supportata dal relay SMTP Microsoft 365 |
| Yahoo | 587, 465 | L’autenticazione a 2 fattori impone una password per app |
| Virgilio / TIM Mail | 587, 465 | 465 in SSL/TLS o 587 in STARTTLS secondo il client, entrambe supportate su smtp.virgilio.it |
| Libero Mail | 465 | SSL diretto su smtp.libero.it, porta consigliata dal provider |
| TIM (Telecom Italia) | 587 | Porta consigliata da Telecom, altre porte possibili secondo la configurazione di sicurezza del client |
| Aruba | 587, 465 | 587 STARTTLS o 465 SSL/TLS su smtp.aruba.it, autenticazione sempre richiesta |
| OVHcloud | 465, 587 | 465 in SSL diretto, 587 in STARTTLS a seconda dell’offerta mail |
| Ionos | 587, 465 | 587 STARTTLS raccomandata come prima scelta dall’editore |
Verificare se una porta SMTP è aperta
Bastano due comandi per verificare che una porta risponda prima di modificare una configurazione alla cieca. Con OpenSSL installato, lancia openssl s_client -connect smtp.esempio.com:587 -starttls smtp da un terminale. Una risposta che inizia con 220 seguito dal nome del server conferma che la porta è in ascolto e accetta la negoziazione STARTTLS. Senza OpenSSL, telnet è sufficiente per un test di base: telnet smtp.esempio.com 587. Un output che mostra 220 mail.esempio.com ESMTP ready significa che la connessione TCP si stabilisce. Se il prompt resta vuoto per diversi secondi e poi si chiude, la porta è filtrata da qualche parte tra la tua macchina e il server, spesso da un firewall locale o da un router per il grande pubblico. Questo test richiede meno di 2 minuti ed evita di indovinare alla cieca quale elemento della catena blocca realmente l’invio.
Capire gli errori di connessione SMTP
3 messaggi ricorrono più spesso quando un invio fallisce. Ognuno indica una causa diversa.
- Connection timed out: la connessione TCP non va mai a buon fine. La porta è bloccata da un firewall, da un router dell’ISP o da una regola di sicurezza cloud ancora prima di raggiungere il server di posta. Prova un’altra porta (587 se la 25 fallisce, 2525 se fallisce anche la 587) invece di modificare le credenziali.
- Connection refused: la macchina target risponde ma nulla è in ascolto su quella porta precisa. Il server SMTP esiste ma il servizio non è configurato su quel numero di porta o gira su un’altra interfaccia di rete. Verifica la porta realmente aperta con il comando openssl visto sopra prima di cambiare la configurazione del client.
- Must issue a STARTTLS command first: il server richiede una cifratura e il client tenta di inviare credenziali in chiaro. Il parametro da correggere è la sicurezza lato client, STARTTLS sulla 587 o SSL/TLS sulla 465. Il numero di porta resta corretto.
Un messaggio di errore che menziona un ritardo o un rifiuto riguarda quasi sempre la porta o il firewall, mai il contenuto dell’email. Se invece parla di autenticazione o cifratura, il problema è nel parametro di sicurezza della connessione, non nel numero di porta. Questa distinzione evita di riconfigurare SPF, DKIM, DMARC o il contenuto del messaggio quando il problema si trova un livello più in basso, a livello di trasporto.
Se il tuo server resta filtrato nonostante una porta correttamente aperta lato client, passare da un relay SMTP aggira il blocco senza toccare la tua infrastruttura.
La porta giusta apre la connessione. Non garantisce nulla sul resto del percorso: messaggi che partono normalmente ma finiscono nella cartella spam indicano l’autenticazione del dominio mittente e la pulizia della lista di contatti inviata.
