Guida alle impostazioni IMAP, POP3 e SMTP dei principali provider

IMAP, POP3 e SMTP: la regola che evita metà degli errori

Quando si configura la posta, l’errore più comune è mischiare il ruolo dei protocolli. IMAP e POP3 servono per ricevere i messaggi, SMTP serve per inviarli. Sembra banale, ma in assistenza tecnica è ancora il punto da cui partono ticket inutili: password giusta, server giusto, ma protocollo sbagliato o porta incoerente con la cifratura.

La seconda regola è più pratica: i valori “del provider” non sono assoluti. Cambiano in base al dominio usato, al brand commerciale, al pannello di posta e, a volte, al tipo di account. Per questo conviene sempre distinguere tra parametri standard e parametri specifici del provider.

IMAP, POP3 e SMTP: cosa fanno davvero

IMAP mantiene la posta sul server e sincronizza stato, cartelle e letture tra più dispositivi. È la scelta corretta quasi sempre, soprattutto se leggi la mail da smartphone, client desktop e webmail insieme.

POP3 scarica i messaggi dal server sul client. È più semplice, ma oggi ha senso solo in casi specifici: archiviazione locale, caselle piccole, workflow vecchi o ambienti dove non serve sincronizzazione tra dispositivi. Se lo abiliti, devi decidere se lasciare una copia sul server o no.

SMTP gestisce l’invio. Il client si autentica sul server SMTP del provider, che poi recapita il messaggio verso il destinatario. Qui c’è il secondo errore classico: usare la porta 25 per il client. La 25 è storicamente usata tra server, non per l’utente finale, e molti provider la limitano o la filtrano.

Le porte standard e le cifrature che devi aspettarti

Le combinazioni più affidabili sono queste:

• IMAP: 143 con STARTTLS oppure 993 con TLS implicito
• POP3: 110 con STARTTLS oppure 995 con TLS implicito
• SMTP submission: 587 con STARTTLS
• SMTP legacy: 465 con TLS implicito, ancora usata da diversi provider

La scelta pratica è semplice: se il provider supporta la porta 587 con STARTTLS, usa quella per l’invio. È la combinazione più compatibile con client moderni e con il filtraggio di rete. La 465 resta valida dove documentata chiaramente dal provider. Per la ricezione, 993 e 995 sono in genere le opzioni più pulite perché evitano negoziazioni ambigue all’avvio.

Se hai un dubbio sulla cifratura, controlla il comportamento del client: TLS implicito significa che la connessione parte già cifrata. STARTTLS significa che si connette in chiaro e poi passa a TLS con un comando di upgrade. Non sono intercambiabili, e forzare un’impostazione sbagliata produce errori tipo handshake fallito o timeout sulla connessione.

Parametri da raccogliere prima di configurare un client

Prima di inserire valori a mano in Thunderbird, Outlook, Apple Mail o in un’applicazione, raccogli sempre questi dati:

1. Nome host IMAP/POP3/SMTP fornito dal provider.
2. Porta corretta per ciascun servizio.
3. Tipo di cifratura richiesto: nessuna, STARTTLS o TLS implicito.
4. Metodo di autenticazione supportato.
5. Nome utente richiesto: indirizzo completo, alias o username separato.
6. Eventuali limiti su invio, numero connessioni, app password o 2FA.

Il punto più trascurato è il nome utente. Alcuni provider vogliono l’indirizzo completo, altri vogliono un identificativo corto, altri ancora accettano entrambi ma solo in certi contesti. Se la password è corretta e l’autenticazione fallisce, questo è uno dei primi campi da verificare.

Valori tipici dei principali provider

Qui conviene essere precisi: i provider cambiano spesso interfaccia e documentazione, quindi i nomi degli host possono variare. L’approccio corretto è leggere sempre la pagina ufficiale del servizio attivo nel pannello cliente. Detto questo, in molti casi gli schemi ricorrenti sono questi:

• Gmail / Google Workspace: IMAP su 993, SMTP submission su 587, autenticazione con password dell’account o app password se la policy lo richiede.
• Microsoft 365 / Outlook: IMAP su 993, SMTP submission su 587, autenticazione moderna spesso obbligatoria; in ambienti legacy possono esserci restrizioni aggiuntive.
• iCloud Mail: IMAP su 993, SMTP su 587, spesso necessario generare una password specifica per app se la verifica a due fattori è attiva.
• Yahoo Mail: IMAP su 993, SMTP su 465 o 587 a seconda del client e della documentazione corrente, con frequente uso di app password.
• Provider hosting tradizionali: spesso IMAP 993, POP3 995, SMTP 587; i nomi host possono essere `mail.dominio.tld`, `imap.dominio.tld`, `smtp.dominio.tld` oppure un host del cluster mail.

Non fidarti di elenchi statici trovati in rete per i grandi provider: i dettagli cambiano, soprattutto su autenticazione e supporto a password normali. La verifica va fatta sul portale ufficiale o nel pannello di amministrazione dell’account, non in un vecchio screenshot.

Come verificare i parametri da terminale senza toccare il client

Quando qualcosa non funziona, la prima cosa utile è capire se il problema è di rete, di TLS o di autenticazione. Con pochi comandi puoi separare i casi senza aprire il client grafico.

Per testare la raggiungibilità della porta SMTP su 587:

nc -vz smtp.provider.tld 587

Atteso: connessione stabilita. Se vedi refused o timeout, il problema è prima dell’autenticazione: firewall, routing, filtro ISP o host errato.

Per vedere la negoziazione STARTTLS su SMTP:

openssl s_client -starttls smtp -connect smtp.provider.tld:587 -crlf

Atteso: certificato presentato dal server e catena TLS leggibile. Se il server chiude subito la sessione, spesso la porta non è quella giusta o il servizio richiede TLS implicito.

Per IMAP con TLS implicito:

openssl s_client -connect imap.provider.tld:993

Per POP3 con TLS implicito:

openssl s_client -connect pop.provider.tld:995

Se il certificato è valido ma l’autenticazione fallisce, il layer TLS è a posto e il problema si sposta su credenziali, app password, policy MFA o permessi dell’account.

Autenticazione: dove si rompe più spesso

La posta moderna non fallisce quasi mai per “server down” puro. Più spesso si rompe per autenticazione. I casi tipici sono tre.

1. Password dell’account non accettata: il provider blocca l’accesso da client esterni perché serve una password per app o autenticazione moderna.
2. Username errato: il client usa un alias, ma il server vuole l’indirizzo principale o il nome completo dell’account.
3. MFA non compatibile: il client non supporta il flusso moderno richiesto dal provider e resta fermo su login base.

Se gestisci più caselle su un hosting condiviso o su un server mail dedicato, controlla anche i limiti del provider: numero massimo di sessioni IMAP, throttling sull’invio, blocchi temporanei dopo troppi tentativi e restrizioni geografiche. Sono dettagli che raramente emergono nella UI del client, ma compaiono nei log del servizio o nel pannello di sicurezza dell’account.

Configurazione pratica in un client moderno

La configurazione manuale ha senso quando il rilevamento automatico fallisce o quando vuoi controllare ogni parametro. La sequenza corretta è questa:

1. Inserisci indirizzo email e password.
2. Se il client non trova i parametri, passa alla configurazione manuale.
3. Imposta IMAP su 993 con SSL/TLS o POP3 su 995 con SSL/TLS.
4. Imposta SMTP su 587 con STARTTLS, oppure 465 con SSL/TLS se documentato dal provider.
5. Abilita autenticazione SMTP con le stesse credenziali della posta in arrivo, salvo eccezioni del provider.
6. Verifica il nome utente esatto richiesto dal servizio.

Se il client offre la scelta tra “SSL/TLS” e “STARTTLS”, non usarli come sinonimi. Per 993 e 995 la scelta corretta è in genere SSL/TLS o TLS implicito; per 587 la scelta corretta è STARTTLS. Questa distinzione evita la classica situazione in cui la connessione sembra aprirsi ma l’autenticazione non parte mai.

Esempio di configurazione lato applicazione

Se stai configurando un’applicazione, un CRM o uno script, la stessa logica vale identica. Ecco un esempio generico di file di configurazione per un client SMTP:

mail_host = smtp.provider.tld
mail_port = 587
mail_encryption = starttls
mail_username = user@example.com
mail_password = <secret>

Qui il punto importante non è la sintassi, ma il trattamento del segreto. La password non va scritta in chiaro nel repository, né duplicata in più file senza controllo. Se l’ambiente lo consente, usa variabili d’ambiente, secret manager o file di configurazione con permessi stretti.

Se devi esporre un esempio in documentazione interna, redigi il segreto e mostra solo il formato del campo. Questo evita che un frammento copiato in produzione diventi un incidente di sicurezza.

IMAP o POP3: scelta tecnica, non religiosa

IMAP è quasi sempre la scelta migliore perché rispecchia il modo in cui oggi si usa la posta. Il messaggio resta sul server, la cartella Inviata resta coerente tra dispositivi, i flag di letto/non letto si sincronizzano e il backup lato server ha più senso operativo.

POP3 ha ancora una nicchia: ambienti molto semplici, utenti che vogliono una copia locale completa e nessuna dipendenza dalla cronologia server. Ma appena entrano in gioco più dispositivi, mobile e webmail, POP3 diventa un vincolo. Per questo, se non hai un motivo forte per usarlo, resta su IMAP.

Errori ricorrenti e come leggerli in fretta

• Connection refused: porta chiusa, servizio non in ascolto o firewall.
• Timeout: filtro di rete, host errato, problema di routing o blocco lato provider.
• Authentication failed: credenziali, app password, username o policy MFA.
• Certificate mismatch: host sbagliato rispetto al certificato presentato dal server.
• Cannot connect using SSL/TLS: porta e tipo di cifratura non coerenti.

La lettura corretta dell’errore accelera molto più di tentativi casuali. Se il TLS fallisce, non insistere sulla password. Se l’autenticazione fallisce ma il certificato è corretto, non cambiare la porta a caso. Ogni messaggio indirizza già il layer da controllare.

Checklist operativa prima di chiudere la configurazione

1. Host verificato sul portale del provider.
2. Porta coerente con il tipo di cifratura.
3. Username confermato con documentazione o pannello account.
4. Password/app password testata e aggiornata se c’è MFA.
5. Connessione verificata con un test TLS da terminale o dal client.
6. Invio e ricezione provati con un messaggio reale.

Se tutto funziona ma la posta non arriva, il problema non è più IMAP, POP3 o SMTP: va cercato nelle regole antispam, nel DNS del dominio, nei record SPF/DKIM/DMARC o nella reputazione del mittente. A quel punto il protocollo è solo il primo livello della catena.

In pratica, la configurazione corretta non consiste nel memorizzare una tabella di porte, ma nel capire il ruolo di ogni protocollo, verificare la cifratura richiesta e controllare l’autenticazione con metodo. Così si riducono i tempi di diagnosi e si evitano errori che, in produzione o su account aziendali, costano più di quanto sembri.