376 miliardi di email hanno circolato ogni giorno nel mondo nel 2025, secondo il report Email Statistics Report 2024-2028 del Radicati Group. Ognuna di esse transita attraverso lo stesso dialogo testuale, rimasto in gran parte invariato dal 1982. SMTP (Simple Mail Transfer Protocol) è il protocollo che veicola un’email dal software del mittente fino al server del destinatario, basandosi su una serie di comandi brevi scambiati su una connessione TCP. Non si occupa né della ricezione né dell’archiviazione del messaggio, due compiti affidati ad altri protocolli.
Ciò che SMTP fa realmente si riduce a tre gesti: aprire una connessione verso il server corretto, trasmettere la busta che indica chi invia e a chi, poi consegnare il contenuto del messaggio. Il resto della catena si basa su livelli aggiunti in un secondo momento, ben dopo la pubblicazione del protocollo originale. Autenticazione e crittografia formano il primo strato; filtraggio antispam e smistamento in casella di posta, il secondo.
Il ruolo di SMTP nell’invio di un’email
Un’email attraversa quattro fasi prima di raggiungere una casella di posta e SMTP ne copre solo due. Il MUA, il software di posta che il mittente usa per scrivere il messaggio (Outlook, Gmail, Thunderbird), trasmette il messaggio a un MSA, il server che accetta l’invio dopo aver verificato l’identità del mittente. L’MSA passa poi il testimone a un MTA, che inoltra il messaggio di server in server fino a quello che ospita la casella del destinatario. Quest’ultimo server consegna infine il messaggio a un MDA, incaricato di depositarlo nella casella corretta. SMTP gestisce i due anelli centrali: l’invio da parte dell’MSA e il trasferimento da parte dell’MTA. Da notare che uno stesso software server (Postfix, Exim, Microsoft Exchange) svolge spesso entrambi i ruoli contemporaneamente, il che rende la distinzione meno netta nella pratica quotidiana ma non la fa scomparire negli scambi di comandi stessi.
RFC 5321 e RFC 5322: la busta e il messaggio
« The objective of the Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently. » RFC 5321, IETF, 2008.
Due standard distinti regolano un’email e la confusione tra i due spiega buona parte dei malintesi sulla deliverability. La RFC 5321 disciplina SMTP stesso: definisce i comandi, i codici di risposta e le regole di trasporto della busta. La RFC 5322, pubblicata nello stesso mese di ottobre 2008, disciplina un oggetto diverso: il formato del messaggio trasportato, con le sue intestazioni From, To, Subject, Date e Message-ID. Questa separazione risale al primissimo antenato del protocollo, la RFC 821, pubblicata nell’agosto 1982 da Jonathan Postel all’Information Sciences Institute dell’Università della California del Sud. È stata sostituita dalla RFC 2821 nel 2001, a sua volta sostituita dall’attuale RFC 5321 nel 2008. Da allora nulla ha richiesto una riscrittura completa del trasporto stesso, solo estensioni successive innestate sullo stesso scheletro di comandi.
La conseguenza concreta si riassume in un punto tecnico spesso ignorato: l’indirizzo dichiarato nel comando MAIL FROM (la busta, detta 5321.From) e l’indirizzo visualizzato nel campo From del messaggio (l’intestazione, detta 5322.From) non hanno alcun obbligo di corrispondere. Un servizio di gestione di mailing list, uno strumento di tracciamento campagne o un meccanismo di forwarding modificano legittimamente l’uno senza toccare l’altro. È proprio questo scarto che SPF verifica lato busta. DKIM e DMARC si concentrano invece sull’intestazione visibile dal destinatario, il che spiega perché i tre meccanismi si completano senza sovrapporsi.
Il dialogo SMTP, comando per comando
Apri una sessione in chiaro sulla porta di invio di un server mail e il dialogo somiglia a uno scambio di cortesie coreografato con estrema rigidità. Il server risponde prima con un codice 220, segno che accetta la connessione. Il client invia EHLO seguito dal proprio nome di dominio, il che annuncia la sua capacità di parlare la versione estesa del protocollo (ESMTP) e fa scattare in risposta l’elenco delle estensioni disponibili, SIZE per la dimensione massima del messaggio o AUTH per l’autenticazione, ad esempio. Segue poi MAIL FROM, che dichiara il mittente della busta; poi RCPT TO, ripetuto tante volte quanti sono i destinatari. Il comando DATA apre quindi la finestra di trasmissione del contenuto vero e proprio, terminata da una riga composta da un solo punto. Il client chiude educatamente con QUIT.
Ogni fase restituisce un codice numerico a tre cifre, un vero e proprio verdetto. Un codice che inizia con 2 significa successo (250 per un comando accettato). Un codice in 3 invita a proseguire, come il 354 che autorizza l’inizio del blocco DATA. Un codice in 4 segnala un fallimento temporaneo, da ritentare più tardi. Un codice in 5 chiude definitivamente la porta, senza possibilità di ritorno su quel messaggio. Questa griglia si riassume in quattro famiglie, non di più. Non è cambiata dalla prima specifica del protocollo, anche se il volume di email scambiate è stato moltiplicato per centinaia di volte dal 1982.
Invio poi trasferimento: il percorso in due fasi
L’invio e il trasferimento rispondono a logiche opposte. L’invio passa attraverso un MSA che richiede un’autenticazione (identificativo e password o token) prima di accettare il minimo messaggio: senza di essa, chiunque potrebbe usurpare un indirizzo di provenienza. Il trasferimento tra MTA, invece, non richiede tradizionalmente alcuna autenticazione di questo tipo. Questo vuoto storico, SPF, DKIM e DMARC lo colmano a posteriori, decenni dopo la stesura del protocollo originale.
Trovare il server SMTP della propria casella email
Il nome del server SMTP da inserire in un client di posta dipende dal provider di posta utilizzato e non da uno standard universale. Gmail, Outlook, OVH o un hosting condiviso pubblicano ciascuno i propri indirizzi server, con varianti a seconda che si tratti di un indirizzo professionale o di un account consumer e talvolta a seconda del paese di fatturazione dell’account. Questo parametro raramente si trova nello stesso punto da un’interfaccia all’altra, il che spinge molti utenti a cercarlo ogni volta che cambiano software di posta. Come trovare il server SMTP della propria casella email elenca questi indirizzi provider per provider, con la procedura per recuperarli quando non sono documentati.
Scegliere la porta SMTP
SMTP si basa storicamente su quattro porte: la 25 per il trasferimento tra server, la 587 per l’invio autenticato, la 465 per una connessione crittografata fin dall’apertura e la 2525 come alternativa quando un provider di accesso blocca le precedenti. La porta 25 in particolare resta chiusa di default sulla maggior parte delle connessioni residenziali e su molte reti aziendali, per limitare l’invio di spam da macchine compromesse a insaputa del proprietario. La scelta della porta corretta dipende quindi tanto dal software utilizzato quanto dalla rete da cui l’invio parte realmente. Come determinare la porta SMTP corretta descrive i casi d’uso di ciascuna a seconda del contesto di invio.
Passare da un relay SMTP
Un invio gestito da un server domestico espone a un problema di reputazione: un solo indirizzo mal configurato basta a far crollare la deliverability dell’intero dominio. La maggior parte delle aziende affida quindi l’invio a un relay SMTP esterno (Twilio SendGrid, Brevo, Amazon SES), che mette in comune un IP pool già riscaldato e gestisce l’IP warmup al posto loro. La scelta tra IP dedicato e IP condiviso dipende soprattutto dal volume inviato ogni mese. Il funzionamento di un relay SMTP descrive questi compromessi.
Autenticazione SMTP: AUTH, STARTTLS, SPF, DKIM, DMARC, BIMI
Il protocollo originale non prevedeva né crittografia né verifica dell’identità. Il comando AUTH, aggiunto in seguito, impone credenziali prima di accettare un invio. STARTTLS permette poi di far passare una connessione in chiaro a una connessione crittografata nel corso della sessione, piuttosto che aprire un canale crittografato fin dall’inizio. Una scelta progettuale che resta, ancora oggi, opportunistica piuttosto che obbligatoria su buona parte del parco server mondiale. Sopra questo livello di trasporto si sovrappone un tris diventato ormai generalizzato per la deliverability. SPF verifica che il server mittente sia autorizzato a inviare per quel dominio. DKIM firma crittograficamente il contenuto e DMARC decide la sorte di un messaggio che fallisce entrambi i controlli, fino al DMARC reject che rifiuta puramente e semplicemente l’email non conforme. Il dettaglio di SPF, DKIM, DMARC e BIMI spiega come questi livelli si articolano, con BIMI che aggiunge in fondo alla catena la visualizzazione di un logo verificato in alcuni client di posta. Il Postmaster Tools di Gmail resta, a oggi, lo strumento più consultato per osservare l’effetto reale di queste impostazioni sulla reputazione di un dominio.
Cosa SMTP non fa
SMTP si ferma alla consegna del messaggio sul server del destinatario. Non consulta mai una casella di posta e non archivia nulla da solo. La lettura, lo smistamento, la sincronizzazione tra dispositivi sono di competenza di IMAP e POP3, due protocolli che intervengono dopo che SMTP ha terminato il proprio lavoro.
Codici di risposta ed errori di invio
Un codice 550 restituito su un comando RCPT TO segnala un hard bounce: l’indirizzo non esiste o il server rifiuta definitivamente il messaggio. Un codice 421 o 450 corrisponde a un soft bounce, un fallimento temporaneo (casella piena, server non disponibile, limite di velocità raggiunto o filtro temporaneo attivo) che l’MTA mittente ritenterà automaticamente secondo il proprio calendario di deferral. Le versioni recenti del protocollo accompagnano spesso questo codice con un Enhanced Status Code a tre gruppi di cifre, 5.1.1 per un indirizzo inesistente ad esempio, che precisa la causa senza cambiare la natura del verdetto. Resta una trappola sui domini configurati come catchall: il server restituisce un 250 per qualsiasi indirizzo locale, anche una casella mai esistita, il che rende questo codice di successo ingannevole per chi vuole valutare la validità reale di un indirizzo. L’elenco completo dei codici di risposta SMTP e il dettaglio dei meccanismi di hard bounce e soft bounce aiutano a diagnosticare con precisione una campagna che si sta degradando. Un indirizzo non valido che accumula hard bounce danneggia la sender reputation dell’IP mittente ancor prima che entri in gioco un problema di autenticazione. Un controllo della lista prima dell’invio resta l’unico modo per sapere dove si trova realmente il danno.
Limiti ed evoluzioni del protocollo
SMTP è stato progettato per testo ASCII e indirizzi in caratteri latini, una scelta che di fatto escludeva gli alfabeti non latini dagli indirizzi email. L’estensione SMTPUTF8 corregge questo punto autorizzando indirizzi in unicode, ma la sua adozione resta marginale al di fuori di alcuni mercati asiatici. Altre due evoluzioni cercano di mettere in sicurezza il trasporto tra server, laddove STARTTLS resta facoltativo: MTA-STS (Mail Transfer Agent Strict Transport Security) impone la crittografia tramite una policy pubblicata via DNS e HTTPS, mentre DANE si basa direttamente su DNSSEC per autenticare il certificato del server destinatario. Meno dell’1% dei domini della top 1 milione pubblica una policy MTA-STS, un tasso più che raddoppiato tra il 2024 e il 2026 senza mai superare questa soglia (Uriports, 2026). Il paradosso sta nel peso dei grandi provider sul traffico reale: nei Paesi Bassi, uno studio Zivver di settembre 2025 misura che il 19,1% del volume di email passa già attraverso una connessione protetta MTA-STS, sostenuto quasi interamente da Gmail e Hotmail. DANE resta una curiosità tecnica: la sua adozione dipende da DNSSEC, un elemento che la maggior parte degli hosting non ha ancora implementato a monte, il che blocca il meccanismo ancor prima che abbia una possibilità di essere configurato lato cliente. Il protocollo progredisce ai margini, mai attraverso una sostituzione complessiva.
