SMTP, acronimo di Simple Mail Transfer Protocol, è il protocollo utilizzato per trasferire la posta elettronica in uscita. Dire semplicemente che “serve a inviare le email”, però, lascia fuori la parte più utile da capire: l’invio dal tuo client, il trasferimento tra server e l’accesso finale alla casella sono fasi diverse.
Quando premi Invia, infatti, il messaggio non passa direttamente dal tuo computer a quello del destinatario. Viene affidato a un’infrastruttura di posta, può attraversare altri server e solo alla fine raggiunge il sistema che gestisce la mailbox del destinatario.
È la stessa distinzione che emerge osservando il funzionamento generale della posta elettronica: il protocollo interviene nell’invio e nel trasferimento, mentre DNS, record MX e sistemi di accesso alla casella svolgono compiti differenti.
Capire questa separazione permette anche di interpretare correttamente termini come server SMTP, SMTP AUTH, porta 587, STARTTLS e relay senza considerarli sinonimi.
Cos’è SMTP e a cosa serve
SMTP è un protocollo applicativo progettato per il trasporto della posta elettronica. La specifica pubblicata nell’RFC 5321 descrive il dialogo tra client e server, i comandi utilizzati durante una transazione e il modo in cui un messaggio può essere inoltrato verso altri sistemi.
La sua funzione non è conservare la tua casella né sincronizzare le cartelle del programma di posta. Si occupa soprattutto di far avanzare un messaggio lungo il percorso di invio e trasferimento.
Cosa significa Simple Mail Transfer Protocol
Il nome è abbastanza descrittivo:
Simple Mail Transfer Protocol → protocollo semplice per il trasferimento della posta.
“Simple” non significa che l’infrastruttura moderna della posta elettronica sia semplice. Indica piuttosto la logica di base: due sistemi stabiliscono una connessione, si scambiano comandi e risposte e trasferiscono il messaggio secondo regole condivise.
Il vantaggio di uno standard comune è l’interoperabilità. Il sistema che spedisce e quello che riceve non devono utilizzare lo stesso software o appartenere allo stesso provider: devono essere in grado di comunicare secondo il protocollo previsto.
Invio, relay e accesso alla casella sono fasi diverse
Per capire davvero il meccanismo conviene separare tre momenti.
Submission: il messaggio viene affidato dall’utente o dall’applicazione all’infrastruttura che si occuperà della spedizione.
Relay: uno o più server trasferiscono il messaggio verso il sistema responsabile del dominio destinatario.
Accesso alla mailbox: dopo la consegna, il destinatario legge e gestisce il messaggio attraverso una webmail o un protocollo come IMAP.
Questa distinzione è importante perché il termine SMTP viene spesso usato genericamente sia per il collegamento del client alla posta in uscita sia per il trasferimento server-to-server. Sono scenari collegati, ma non equivalenti: cambiano ruolo, policy e porte utilizzate.
Server SMTP e server di posta in uscita
Quando un programma di posta chiede di inserire il server SMTP, normalmente sta chiedendo l’hostname del servizio al quale consegnare i messaggi in uscita.
Può essere un host fornito dal tuo provider email o dall’hosting. Non esiste però un nome universale come smtp.tuodominio.it: il valore corretto dipende dal servizio che gestisce l’account.
Inoltre, “server” non indica necessariamente una macchina fisica dedicata. È più utile pensarlo come un servizio software che accetta, elabora o inoltra transazioni di posta.
Come viene inviata un’email dal client al server destinatario
Il percorso concreto varia in base all’architettura del provider, ma il modello logico rimane abbastanza stabile.
Quando utilizzi un client configurato con un account di posta, il messaggio viene prima consegnato al servizio previsto per la submission. Da lì l’infrastruttura determina come raggiungere il dominio destinatario e avvia il trasferimento verso il server appropriato.
Dal client al Message Submission Agent
La distinzione formale tra invio dell’utente e relay è descritta nell’RFC 6409.
Il sistema che riceve il messaggio dal client viene normalmente indicato come Message Submission Agent, o MSA.
È il punto in cui hanno senso controlli specifici per l’utente che sta spedendo:
- autenticazione;
- policy del provider;
- autorizzazione all’invio;
- eventuali limiti;
- normalizzazioni previste nella fase di submission.
Se utilizzi una webmail, il browser non deve necessariamente comunicare direttamente tramite SMTP. Interagisce con l’applicazione web del provider; sarà l’infrastruttura del servizio a iniziare il processo di submission e trasporto.
Dal Mail Transfer Agent al dominio destinatario
Una volta accettato il messaggio per la spedizione, un Mail Transfer Agent deve individuare dove consegnarlo.
Prendiamo un indirizzo come:
La parte importante per il routing è il dominio example.net.
Il sistema consulta il DNS per individuare i server che gestiscono la posta destinata a quel dominio. In questo processo hanno un ruolo centrale i record MX, che puoi approfondire nella guida sul DNS e sui record MX.
Il percorso può essere schematizzato così:
mittente → MSA → MTA mittente → DNS/MX → MTA destinatario
Se esistono più record MX, la loro priorità aiuta il sistema a stabilire quali host tentare per primi.
Il messaggio può inoltre passare attraverso sistemi intermedi. Il trasferimento non deve quindi essere immaginato come una connessione obbligatoriamente diretta tra il computer del mittente e il server finale.
Coda e retry: cosa succede se la consegna non riesce subito
La consegna non è necessariamente immediata.
Un server può incontrare una condizione temporanea: destinazione momentaneamente indisponibile, problemi di rete, limiti temporanei o altre situazioni che suggeriscono di riprovare.
In questi casi il messaggio può essere conservato in coda e sottoposto a nuovi tentativi secondo le policy del sistema mittente.
Questo spiega perché un’email può arrivare qualche minuto dopo senza che l’utente debba premere nuovamente Invia.
Una condizione permanente è diversa: se il sistema determina che il messaggio non può essere recapitato nella forma corrente, può produrre una notifica di mancata consegna.
MSA, MTA e MDA: i ruoli dei server di posta
Parlare genericamente di “server di posta” è comodo, ma nasconde ruoli differenti.
Non tutte le implementazioni separano fisicamente questi componenti e lo stesso software può svolgere più funzioni. La distinzione resta utile perché permette di capire in quale fase del viaggio dell’email si trova il messaggio.
MSA: dove il client consegna il messaggio
L’MSA, Message Submission Agent, riceve normalmente i messaggi dagli utenti o dalle applicazioni autorizzate.
È il servizio che incontri quando configuri la posta in uscita nel client e inserisci parametri come:
- hostname;
- porta;
- modalità TLS;
- nome utente;
- metodo di autenticazione.
L’MSA lavora quindi sul confine tra l’utente e l’infrastruttura di trasporto.
MTA: come l’email passa da un server all’altro
Il Mail Transfer Agent svolge invece il ruolo di trasferimento.
Riceve un messaggio e determina verso quale altro sistema inoltrarlo. Per un dominio remoto può utilizzare le informazioni ottenute tramite DNS e record MX e aprire una nuova sessione verso il server successivo.
Il concetto decisivo è che submission e relay non sono la stessa operazione.
Il client consegna il messaggio a un servizio autorizzato; da quel momento sono gli MTA a occuparsi del percorso verso la destinazione.
MDA e mailbox: dove termina il trasporto
Una volta che il messaggio raggiunge l’infrastruttura corretta, deve essere reso disponibile nella mailbox del destinatario.
In un modello concettuale questa fase viene spesso associata a un Mail Delivery Agent, o MDA, che effettua la consegna locale verso la casella.
Il componente concreto varia da un sistema all’altro, ma il confine logico è utile: da questo punto in poi il problema non è più “come trasferisco la mail verso il dominio?”, bensì “come viene conservata e resa accessibile al destinatario?”.
È qui che protocolli come IMAP assumono un ruolo diverso.
Come dialogano client e server: i comandi principali
Una transazione non consiste nell’inviare un messaggio come un unico blocco privo di negoziazione. Client e server dialogano attraverso comandi SMTP e codici di risposta.
La sequenza effettiva può comprendere estensioni e controlli aggiuntivi, ma una transazione essenziale mostra bene il meccanismo.
HELO ed EHLO: come inizia la sessione
Dopo che il server ha accettato la connessione, il client si presenta.
Storicamente viene utilizzato HELO; nei sistemi moderni è normalmente più importante EHLO, perché introduce il modello Extended SMTP, o ESMTP, e permette al server di dichiarare le estensioni supportate.
Tra queste possono comparire, a seconda della configurazione:
- STARTTLS;
- AUTH;
- limiti di dimensione;
- estensioni MIME;
- altre capacità ESMTP.
Il client non dovrebbe quindi presupporre che ogni sistema offra esattamente le stesse funzioni.
MAIL FROM, RCPT TO e DATA
Una sessione semplificata può assomigliare a questa:
S: 220 mail.example.net ESMTP C: EHLO client.example.org S: 250 ... C: MAIL FROM:<[email protected]> S: 250 OK C: RCPT TO:<[email protected]> S: 250 OK C: DATA S: 354 Start mail input C: [intestazioni e contenuto del messaggio] C: . S: 250 Message accepted C: QUIT
MAIL FROM indica il mittente dell’envelope.
RCPT TO specifica un destinatario della transazione.
DATA comunica che il client vuole iniziare a trasmettere il contenuto del messaggio.
Il server risponde a ogni passaggio con codici che permettono al client di decidere come procedere.
Envelope e intestazioni dell’email non sono la stessa cosa
Uno dei dettagli più utili da conoscere è che envelope SMTP e intestazioni del messaggio appartengono a livelli differenti.
L’envelope viene utilizzato durante il trasporto e comprende informazioni come il reverse-path fornito tramite MAIL FROM e i destinatari indicati con RCPT TO.
Dentro il messaggio esistono invece header come:
From: To: Cc: Subject:
I due livelli normalmente sono coerenti, ma non devono necessariamente contenere gli stessi valori.
Questa distinzione diventa importante quando si analizzano bounce, forwarding, mailing list, SPF e problemi di autenticazione della posta.
Autenticazione e cifratura: SMTP AUTH, TLS e STARTTLS
La versione originaria del protocollo nasce in un Internet molto diverso da quello attuale. Autenticazione e cifratura sono state aggiunte attraverso estensioni e standard successivi.
Per questo conviene evitare di mettere nello stesso contenitore concetti differenti come SMTP AUTH, TLS, SPF e DKIM.
SMTP AUTH verifica chi può utilizzare il servizio
SMTP AUTH è un’estensione che consente a client e server di eseguire un processo di autenticazione.
La specifica è definita nell’RFC 4954.
In una normale configurazione di posta in uscita, l’autenticazione serve al provider per verificare che l’utente o l’applicazione siano autorizzati a utilizzare quel servizio di submission.
Non significa invece che il messaggio sia automaticamente autentico agli occhi di qualunque server destinatario.
Quello è un problema diverso, che coinvolge anche i sistemi di autenticazione del dominio.
STARTTLS e TLS implicito sono modalità differenti
TLS protegge la connessione tra due sistemi durante il trasferimento.
Con STARTTLS, client e server iniziano una sessione applicativa e, quando il server dichiara il supporto, negoziano il passaggio a TLS.
Con TLS implicito, invece, la negoziazione TLS inizia immediatamente all’apertura della connessione.
L’RFC 8314 registra il servizio submissions sulla porta 465 per la message submission con TLS implicito e descrive anche l’impiego di STARTTLS sulla 587.
Non è quindi corretto ridurre la questione a “465 vecchia e insicura, 587 nuova e sicura”. Entrambe possono essere utilizzate per una submission protetta quando client e server sono configurati correttamente e richiedono TLS.
TLS protegge il trasporto, non offre cifratura end-to-end
Un’altra distinzione importante riguarda ciò che viene effettivamente cifrato.
TLS protegge una connessione tra due endpoint del percorso.
Un messaggio può attraversare più sistemi e più connessioni. Ciascun hop può negoziare separatamente la propria protezione.
Questo modello non equivale alla crittografia end-to-end, nella quale il contenuto viene cifrato affinché soltanto gli endpoint autorizzati possano leggerlo.
L’uso di TLS migliora quindi la sicurezza del trasporto, ma non trasforma automaticamente una normale email in un messaggio E2EE.
Porte 25, 465, 587 e 2525: a cosa servono
Le diverse porte vengono spesso presentate come quattro alternative equivalenti tra cui scegliere. Non lo sono.
La differenza più importante è capire se stai configurando la submission di un utente oppure il relay tra server.
Per un approfondimento specifico trovi anche la guida Creativemotions dedicata alle porte SMTP.
| Porta | Ruolo principale | Protezione tipica | Stato |
|---|---|---|---|
| 25 | relay tra server | STARTTLS quando disponibile/configurato | servizio standard |
| 587 | message submission | STARTTLS | servizio submission registrato |
| 465 | message submission | TLS implicito | servizio submissions registrato |
| 2525 | fallback offerto da alcuni provider | dipende dal provider | non è una porta standard IANA per SMTP |
Le assegnazioni ufficiali possono essere verificate nel registro dei servizi e delle porte IANA.
Porta 25: relay tra server
La porta 25 è storicamente associata a SMTP ed è ancora fondamentale nel trasferimento MTA-to-MTA.
È quindi perfettamente normale trovarla nel traffico tra server di posta.
Ciò non significa che sia la scelta da utilizzare automaticamente quando configuri il client sul computer o un’applicazione che deve autenticarsi presso il proprio provider.
La message submission ha standard e policy specifici.
Porta 587: message submission con STARTTLS
La porta 587 è registrata per il servizio submission.
È ampiamente utilizzata dai provider per la consegna iniziale del messaggio da un client o da un’applicazione al sistema di posta.
Normalmente viene associata a STARTTLS e all’autenticazione richiesta dal servizio.
Il punto importante è non confondere la 587 con il relay server-to-server: la sua funzione standard è la message submission.
Porta 465: submission con TLS implicito
La porta 465 è registrata da IANA come submissions, cioè message submission over TLS.
La connessione TLS viene negoziata subito, prima dello scambio dei dati del protocollo applicativo.
Questa porta ha avuto una storia complessa e per questo molte guide continuano a descriverla semplicemente come una vecchia porta abbandonata.
La realtà corrente è più precisa: 465 è una porta standard per la submission con TLS implicito.
Porta 2525: perché alcuni provider la utilizzano
Alcuni servizi mettono a disposizione la 2525 come alternativa quando altre porte sono bloccate o difficili da utilizzare nell’ambiente del cliente.
Questo la rende una soluzione pratica in determinati contesti, ma non cambia il suo stato.
Non è il numero di porta standard registrato da IANA per smtp, submission o submissions.
Se il tuo provider la propone, puoi utilizzarla seguendo la sua documentazione. Non dovrebbe invece essere scelta perché una guida generica la presenta come configurazione universale.
SMTP, IMAP e POP3 non sono protocolli alternativi
SMTP, IMAP e POP3 vengono spesso mostrati nello stesso pannello di configurazione e questo può far pensare che siano tre modi alternativi per svolgere la stessa funzione.
Non è così.
Il primo risolve il problema dell’invio e del trasferimento della posta. IMAP e POP3 riguardano invece l’accesso ai messaggi conservati per l’utente.
Per entrare nel confronto completo puoi leggere la guida su POP3, IMAP e SMTP.
Invio e accesso alla mailbox sono compiti separati
In un normale client potresti avere contemporaneamente:
Posta in arrivo → IMAP Posta in uscita → SMTP
oppure, in configurazioni meno comuni:
Posta in arrivo → POP3 Posta in uscita → SMTP
Non devi quindi “scegliere SMTP oppure IMAP”.
Se utilizzi IMAP per leggere e sincronizzare la casella, continuerai ad avere bisogno del sistema previsto dal provider per inviare i messaggi.
Perché uno stesso account usa più protocolli
Lo stesso indirizzo email rappresenta un unico account dal punto di vista dell’utente, ma il client può utilizzare servizi differenti dietro le quinte.
IMAP mantiene lo stato della mailbox sincronizzato con il server.
La submission consegna invece i nuovi messaggi all’infrastruttura incaricata della spedizione.
La separazione permette a ciascun protocollo di risolvere un problema specifico.
Invio riuscito e deliverability non sono la stessa cosa
Uno degli errori più comuni è trasformare il corretto funzionamento del trasporto in una garanzia di consegna.
Un messaggio può essere trasferito correttamente senza che questo determini da solo se finirà nella Posta in arrivo, nello spam o verrà bloccato da una policy successiva.
La deliverability dipende da molti segnali esterni al puro meccanismo di invio.
SMTP AUTH non è SPF, DKIM o DMARC
SMTP AUTH risponde in sostanza alla domanda:
“questo client è autorizzato a utilizzare questo server per spedire?”
SPF, DKIM e DMARC affrontano invece aspetti differenti dell’autenticazione e della policy dei domini.
SPF permette di dichiarare quali sistemi sono autorizzati a inviare per un determinato dominio dell’envelope.
DKIM consente di applicare una firma crittografica al messaggio.
DMARC introduce policy e controlli di allineamento rispetto al dominio visibile nel campo From.
Configurare correttamente l’autenticazione del server di invio non sostituisce quindi la configurazione DNS necessaria per autenticare il dominio.
Email accettata dal server non significa email nella Posta in arrivo
Quando un server risponde positivamente a una transazione sta comunicando di aver accettato la responsabilità prevista in quel punto del percorso.
Questo non equivale a una promessa di inbox placement.
Dopo l’accettazione possono intervenire:
- filtri antispam;
- controlli reputazionali;
- policy del provider;
- regole della mailbox;
- autenticazione del dominio;
- analisi del contenuto e degli header.
Per questo un test di invio riuscito dimostra che il trasporto ha superato un certo passaggio, non che l’intera catena di deliverability sia perfetta.
Come trovare e verificare il server SMTP corretto
Quando devi configurare un client, un CMS o un’applicazione, la soluzione migliore non è cercare una tabella generica di server.
Devi identificare il provider che gestisce realmente la posta in uscita e utilizzare i parametri ufficiali previsti per il tuo account o piano.
Hostname, porta, TLS e autenticazione
I parametri tipici sono:
- hostname del server;
- porta;
- modalità TLS;
- autenticazione richiesta o meno;
- nome utente;
- password o altro metodo di autenticazione;
- eventuali restrizioni sull’indirizzo mittente.
La combinazione deve essere coerente.
Non basta, per esempio, scegliere la 465 e contemporaneamente impostare STARTTLS se il provider richiede TLS implicito su quella porta.
Allo stesso modo non ha senso utilizzare un hostname recuperato da una guida riferita a un altro servizio.
Dove recuperare le impostazioni ufficiali
L’ordine più sicuro è:
- documentazione ufficiale del provider;
- pannello di gestione dell’account email o dell’hosting;
- configurazione automatica fornita dal servizio;
- supporto tecnico del provider.
Evita di partire da parametri trovati in discussioni vecchie o da hostname “probabili”.
Provider e infrastrutture possono cambiare autenticazione, endpoint, policy e porte supportate.
Se il tuo caso riguarda un sito, trovi anche la guida specifica per configurare l’invio SMTP in WordPress.
Errori 4xx e 5xx: temporanei o permanenti?
I codici di risposta sono una delle informazioni più utili quando l’invio non funziona.
In termini generali:
4xx → condizione temporanea
Il sistema indica che la richiesta non può essere completata in quel momento, ma un tentativo successivo potrebbe avere successo.
5xx → condizione permanente
Il server sta segnalando che ripetere esattamente la stessa operazione difficilmente risolverà il problema.
Gli Enhanced Mail System Status Codes dell’RFC 3463 aggiungono informazioni più dettagliate nella forma:
classe.soggetto.dettaglio
Per esempio:
4.x.x → persistent transient failure 5.x.x → permanent failure
Quando compare un errore, non fermarti quindi al testo generico “SMTP error”.
Controlla almeno:
- codice numerico;
- eventuale enhanced status code;
- host che ha generato la risposta;
- fase in cui si è verificato il problema;
- destinatario interessato;
- indicazioni specifiche del provider.
Un 535 relativo all’autenticazione, un 550 restituito durante la gestione del destinatario e un timeout di connessione non rappresentano lo stesso problema e non richiedono la stessa soluzione.
Conclusione
SMTP diventa molto più semplice da capire quando smetti di considerarlo come un unico “server che manda le email”.
Prima avviene la submission: il client o l’applicazione consegna il messaggio al servizio autorizzato.
Poi avviene il relay: gli MTA trasferiscono il messaggio verso il dominio destinatario, utilizzando anche DNS e record MX per individuare l’infrastruttura corretta.
Infine il messaggio entra nel sistema che gestisce la mailbox, dove il trasporto lascia spazio ai meccanismi di accesso e gestione della posta.
Questa separazione chiarisce anche quale porta utilizzare. La 25 ha un ruolo centrale nel relay tra server; 587 e 465 appartengono alla message submission con due modalità TLS differenti; 2525 può essere un fallback fornito da alcuni servizi, ma non è una porta standard assegnata a questo protocollo.
Quando devi configurare un account, quindi, evita di scegliere i parametri per abitudine. Parti dalla documentazione del provider e verifica insieme hostname, porta, TLS e autenticazione.
E se un messaggio viene accettato dal server ma non arriva nella Posta in arrivo, cambia diagnosi: a quel punto il problema potrebbe non essere più il trasporto, ma autenticazione del dominio, reputazione, policy o deliverability.