Server di posta in uscita: una guida per una migliore deliverability

Invii una campagna importante. Potrebbe trattarsi di un aggiornamento di prodotto, un follow-up di assunzione, un annuncio per i donatori o una sequenza di vendita. Clicchi su invia, guardi la barra di avanzamento completarsi e poi inizia l’incertezza.

Le email sono arrivate? Sono finite nella posta in arrivo o sono state spinte nello spam, ritardate o rifiutate prima che qualcuno potesse vederle?

Quell’ansia viene solitamente attribuita al testo, all’oggetto o alla qualità della lista. Questi elementi contano. Ma c’è un altro aspetto che lavora dietro le quinte a cui molti utenti aziendali non pensano finché qualcosa non si rompe: il server di posta in uscita.

Se utilizzi Gmail, Outlook, Apple Mail, un CRM, un modulo web o uno strumento di mail merge, i tuoi messaggi hanno comunque bisogno di un sistema che prenda la tua email, la verifichi, la instradi e la consegni al provider di posta del destinatario. Se quella configurazione è errata, anche un’email scritta perfettamente può scomparire.

Una nota prima di ricercare strumenti in questo settore. Mail Merge for Gmail è un nome di prodotto altamente descrittivo, quindi è facile confonderlo con altri strumenti di mail merge per Gmail. Se stai esaminando informazioni online, verifica che la pagina si riferisca a quel prodotto specifico e non a un concorrente con un nome simile.

Perché le tue email spariscono

Un responsabile marketing invia un annuncio ai clienti lunedì mattina. All’ora di pranzo, le risposte sono inferiori al previsto. Nel pomeriggio, alcuni clienti dicono di non averlo mai ricevuto. Qualcuno controlla lo spam. Un’altra persona inoltra uno screenshot di un avviso di mancato recapito. Improvvisamente, quello che sembrava un problema di coinvolgimento si trasforma in un problema di consegna.

È solitamente qui che il server di posta in uscita entra nella storia.

Il tuo server in uscita è il sistema responsabile di prendere il messaggio che hai scritto e tentare di consegnarlo al provider di posta del destinatario. Se il server è configurato male, non è attendibile, è bloccato o mancano segnali di autenticazione chiave, il lato ricevente diventa sospettoso. Quel sospetto si manifesta spesso con il posizionamento nello spam, messaggi rifiutati o filtraggio silenzioso.

La parte confusa

La maggior parte degli utenti pensa che “l’ho inviata da Gmail” o “l’ho inviata dalla mia app di posta” sia tutta la storia. Non è così. La tua app è solo l’interfaccia. L’effettivo passaggio avviene attraverso l’infrastruttura del server.

Un modo semplice per pensarci è questo:

• La tua app di posta è la scrivania.
• Il server in uscita è lo sportello dell’ufficio postale.
• Il provider ricevente decide se accettare, ispezionare o rifiutare la posta.

Se lo sportello dell’ufficio postale non può provare chi sei, usa il percorso sbagliato o sembra sospetto, il tuo messaggio non si muove agevolmente.

Regola pratica: Se le email svaniscono senza un errore chiaro, non iniziare riscrivendo il messaggio. Inizia controllando il percorso di invio.

Ecco perché il lavoro sulla deliverability inizia spesso con la fiducia tecnica, non con modifiche creative. La reputazione del tuo dominio, i record di autenticazione e le impostazioni del server influenzano tutti il modo in cui i provider trattano la tua posta, se come comunicazione aziendale legittima o come possibile spoofing. Se desideri un’introduzione utile su quel livello di fiducia, vale la pena leggere questa guida sulla reputazione del mittente email.

Cosa significa nella vita reale

Quando le persone dicono “deliverability delle email”, solitamente parlano di una catena di decisioni:

1. Il server ricevente può connettersi al tuo server di invio?
2. Il tuo server sembra legittimo?
3. Il tuo dominio corrisponde ai suoi record di autenticazione?
4. Il contenuto sembra abbastanza sicuro da essere accettato?

Il server di posta in uscita si trova vicino all’inizio di quella catena. Se è configurato bene, tutto ciò che segue diventa più facile. Se è configurato male, le tue campagne iniziano con uno svantaggio.

Cos’è un server di posta in uscita

Pensa a un server di posta in uscita come all’ufficio postale digitale della tua email. Scrivi il messaggio in Gmail, Outlook, Apple Mail o un’altra app, ma quell’app ha comunque bisogno di un sistema di invio affidabile per trasportare il messaggio verso l’internet più ampio.

Quel sistema di invio segue l’SMTP, abbreviazione di Simple Mail Transfer Protocol. Secondo la spiegazione dei server email di Mailtrap, i server di posta in uscita si basano su SMTP, dove la comunicazione tra server di posta avviene prevalentemente sulla porta TCP 25, mentre l’invio autenticato dal client utilizza la porta 587 o la porta 465, garantendo una trasmissione sicura tramite crittografia TLS.

Un’immagine aiuta:

Il viaggio in cinque passaggi

Ecco cosa succede dopo aver cliccato su invia:

1. Crei il messaggio
   La tua app di posta impacchetta l’oggetto, il corpo, i destinatari e gli allegati.

2. La tua app si connette al server in uscita
   Questo è il primo passaggio. Il tuo dispositivo o software invia il messaggio al server di invio.

3. Il server controlla le basi
   Il sistema verifica che il messaggio sia formato correttamente e pronto per il trasferimento.

4. Il server trova il provider del destinatario
   Cerca dove dovrebbe andare la posta per quel dominio e instrada il messaggio verso l’esterno.

5. Il lato ricevente valuta il messaggio
   Il provider del destinatario decide se accettarlo, filtrarlo, metterlo in quarantena o rifiutarlo.

Ecco una breve spiegazione se preferisci il video:

Due lavori avvengono dietro le quinte

Il percorso di invio solitamente coinvolge due ruoli che sembrano tecnici ma sono facili da capire.

L’MSA gestisce l’invio

Il Mail Submission Agent, o MSA, è il primo punto di controllo. Accetta il messaggio dall’utente o dall’applicazione. La convalida iniziale avviene in questa fase. Il sistema controlla la formattazione e l’integrità degli allegati prima che il messaggio venga inoltrato.

Puoi pensare all’MSA come all’impiegato allo sportello dell’ufficio postale. Si assicura che il pacco sia etichettato correttamente prima che entri nel flusso della posta.

L’MTA gestisce la consegna

Il Mail Transfer Agent, o MTA, è la parte che instrada il messaggio verso il sistema di posta del destinatario. Comunica con altri server di posta e tenta di completare il passaggio.

Questo è più simile alla rete di consegna dietro lo sportello. Camion, percorsi, passaggi e smistamento a destinazione avvengono tutti qui.

Se la configurazione SPF, DKIM o DMARC del dominio di invio non è allineata, il sistema ricevente potrebbe rifiutare il messaggio prima ancora che una persona possa vederlo.

Perché le porte contano

Molti utenti non tecnici si trovano spesso bloccati. Sentono dire che “SMTP usa la porta 25” e presumono che sia l’impostazione da usare sempre. In pratica, non è così che funziona solitamente l’invio dal client.

• La porta 25 è principalmente per il relay da server a server
• La porta 587 è comunemente usata per l’invio autenticato dal client
• La porta 465 è usata anche per l’invio sicuro in molte configurazioni

Se stai inserendo le impostazioni di posta in uscita in un’app di posta, un plugin o un software aziendale, solitamente stai lavorando nella parte di invio dal client del processo, non nel livello di relay del server.

Tipi di server di posta in uscita

Non tutti i server di posta in uscita sono creati per lo stesso lavoro. Una piccola impresa solitamente si trova di fronte a tre scelte. Usare il server predefinito del proprio provider di posta, configurare il proprio server o inviare tramite un servizio di relay SMTP dedicato.

L’opzione giusta dipende da cosa stai inviando, quanto controllo ti serve e se il tuo team può gestire il rischio di deliverability.

Server dei provider

Questa è l’opzione più familiare. Se la tua azienda usa Gmail o Microsoft 365, stai già usando un ambiente di invio gestito dal provider. Ciò significa che l’infrastruttura, la sicurezza e la manutenzione del server sono gestite per te.

Per la maggior parte degli utenti aziendali, questo è il percorso più semplice perché:

• La configurazione è più leggera. Usi le impostazioni SMTP standard del provider.
• La fiducia è più forte. I grandi provider gestiscono un’infrastruttura di invio matura.
• La manutenzione è minore. Il tuo team non deve gestire un server di posta.

Questa è spesso la soluzione migliore per la normale comunicazione aziendale, l’outreach personalizzato e l’invio moderato di campagne da un account di lavoro.

Server auto-ospitati

Gestire il proprio server SMTP sembra allettante perché sembra di avere il controllo totale. In realtà, crea spesso un mal di testa per la deliverability.

I dati verificati mostrano che i relay SMTP auto-ospitati da IP residenziali o VPS non configurati vengono rapidamente inseriti nelle liste nere, con l’80% che non riesce a superare i controlli di base dei record PTR, mentre l’utilizzo di servizi SMTP di terze parti autenticati con un corretto allineamento produce tassi di consegna superiori al 95%.

Quel divario conta perché ai provider di posta in arrivo importa meno se “possiedi” il server e più se si fidano di esso.

Perché l’auto-hosting fallisce per molti team

Una configurazione auto-ospitata può fallire in diversi modi:

• Scarsa cronologia della reputazione. Un IP nuovo o poco affidabile non sembra automaticamente credibile.
• Mancanza di DNS inverso e allineamento. I server riceventi si aspettano che i controlli di identità tecnica corrispondano.
• Onere operativo. Qualcuno deve monitorare l’autenticazione, le regole di relay e la prevenzione degli abusi.

Un server SMTP auto-ospitato può ancora funzionare per email applicative limitate o uso interno. È solo raramente il percorso facile che le persone si aspettano, specialmente per le campagne.

Possedere il server di posta non garantisce il controllo sulla deliverability. Il provider ricevente prende comunque la decisione finale sulla fiducia.

Servizi di relay SMTP dedicati

La terza categoria è un servizio specializzato creato per inviare email in modo affidabile per tuo conto. Questi strumenti si concentrano sull’autenticazione, la gestione della reputazione, la visibilità della consegna e la conformità alle policy.

Questa opzione ha senso quando il tuo team ha bisogno di maggiore flessibilità di invio di quanto una casella di posta standard possa supportare comodamente, ma non vuole gestire un’infrastruttura di posta da zero.

Ecco il compromesso in termini semplici:

Opzione	Ideale per	Punto di forza principale	Rischio principale
Server del provider	Email aziendali quotidiane	Semplicità e fiducia	Limiti di invio del provider
Server auto-ospitato	Team tecnici con casi d’uso ristretti	Controllo totale dell’infrastruttura	Reputazione e rischio di rifiuto
Relay SMTP dedicato	Invio ad alto volume o operativo	Strumenti di deliverability gestiti	Complessità aggiuntiva della piattaforma

Cosa dovrebbero fare la maggior parte delle piccole imprese

Se sei una piccola impresa, una startup, un team di reclutamento o un organizzatore di eventi, l’impostazione predefinita più sicura è solitamente usare il server affidabile fornito con il tuo provider di posta, a meno che il tuo volume o flusso di lavoro non richieda chiaramente un relay dedicato.

Ciò evita la trappola comune di costruire una configurazione di invio che funziona tecnicamente ma ha prestazioni scarse in scenari pratici.

Impostazioni di configurazione comuni ed esempi

Quando un’app richiede le “impostazioni del server di posta in uscita”, sta chiedendo i dettagli necessari per connettersi al servizio SMTP del tuo provider. I campi possono sembrare intimidatori, ma ognuno ha uno scopo diretto.

Secondo la guida alla configurazione SMTP di Gmail di Heimdal, i servizi SMTP cloud di livello aziendale come Gmail usano smtp.gmail.com con porta 465 (SSL) o porta 587 (TLS), e una corretta configurazione SSL/TLS migliora la deliverability crittografando la trasmissione.

Cosa significa ogni campo

Nome del server

Questo è l’indirizzo del server di posta in uscita. Dice alla tua app dove inviare l’email per l’invio.

Per Gmail, è smtp.gmail.com.

Porta

La porta è la porta specifica che la tua app usa per connettersi. Qui, molte configurazioni vanno male.

Per Gmail, le scelte comuni sono:

• 465 per SSL
• 587 per TLS

Autenticazione

Ciò significa che la tua app deve accedere con un account email valido prima di poter inviare. Ciò impedisce al tuo dispositivo o sito web di agire come un relay aperto.

SSL o TLS

Questi livelli di sicurezza crittografano la connessione mentre il messaggio viene inviato. In parole povere, aiutano a prevenire l’intercettazione e riducono i problemi di fiducia durante l’invio.

Impostazioni comuni del server di posta in uscita

Provider	Server SMTP	Porta	Richiede SSL/TLS	Richiede Autenticazione
Gmail / Google Workspace	smtp.gmail.com	465 o 587	Sì	Sì
Microsoft 365 / Outlook.com	Usa il server SMTP pubblicato dal tuo provider	Solitamente impostazioni di invio sicuro dai documenti del provider	Sì	Sì
Apple iCloud Mail	Usa il server SMTP pubblicato dal tuo provider	Solitamente impostazioni di invio sicuro dai documenti del provider	Sì	Sì

Poiché i dettagli specifici del provider possono cambiare, conferma sempre il nome esatto del server e il metodo di invio accettato all’interno della documentazione dell’account per la casella di posta che stai configurando.

Un esempio in parole semplici

Supponiamo che tu stia collegando un modulo web o un client di posta desktop a un account Gmail.

Generalmente inseriresti:

• Server SMTP: smtp.gmail.com
• Nome utente: il tuo indirizzo Gmail completo
• Password: la password del tuo account o il metodo specifico per l’app, a seconda della sicurezza dell’account
• Porta: 587 o 465
• Crittografia: TLS o SSL

Se l’app ti offre entrambe le opzioni SSL e TLS, abbina la porta al metodo di sicurezza supportato dal provider.

L’errore più comune non è il nome del server. È scegliere la combinazione errata di porta e sicurezza.

Un rapido controllo della configurazione

Prima di dare la colpa al tuo contenuto, conferma queste basi:

• Il server corrisponde al provider. Non mescolare le credenziali Gmail con l’host SMTP di un altro provider.
• La porta corrisponde al tipo di crittografia. Una mancata corrispondenza causa spesso connessioni fallite.
• L’autenticazione è attivata. La maggior parte dei provider non inoltrerà posta da client non autenticati.
• Il nome utente è completo. Molti servizi richiedono l’indirizzo email completo, non solo la parte prima del simbolo @.

Questi quattro controlli risolvono un numero sorprendente di problemi di “non invia”.

Proteggere il tuo invio per una migliore deliverability

Se l’SMTP è il camion per le consegne, l’autenticazione è il controllo dell’identità alla banchina di carico. Senza di essa, i provider riceventi devono indovinare se la tua email è legittima. Non amano indovinare.

Ecco perché SPF, DKIM e DMARC contano così tanto. Insieme, agiscono come un sistema di passaporto digitale per la tua email.

Pensalo come un sistema di passaporto

Un provider di posta ricevente vuole rispondere a tre domande:

1. Questo server era autorizzato a inviare per questo dominio?
2. Il messaggio è stato alterato lungo il percorso?
3. Cosa dovremmo fare se i controlli falliscono?

È a questo che servono questi record.

SPF è il controllo dell’indirizzo di ritorno

SPF dice al lato ricevente quali server sono autorizzati a inviare per conto del tuo dominio.

Se il tuo dominio dice che solo determinati mittenti sono validi e il tuo messaggio proviene da un’altra parte, quella discrepanza solleva sospetti. SPF è come controllare se l’indirizzo di ritorno sulla busta appartiene a un luogo di spedizione approvato.

DKIM è il sigillo antimanomissione

DKIM aggiunge una firma che aiuta a dimostrare che il messaggio non è stato modificato durante il transito e che proveniva davvero da un mittente approvato.

È simile a un sigillo di ceralacca su un documento. Se il sigillo viene verificato, il destinatario può fidarsi dell’integrità del messaggio con maggiore sicurezza.

DMARC è la policy alla dogana

DMARC dice ai provider riceventi cosa fare quando i controlli SPF o DKIM falliscono. Ciò potrebbe significare monitorare, mettere in quarantena o rifiutare la posta sospetta a seconda della policy in vigore.

Questo è il regolamento che lega insieme il sistema.

Per una spiegazione più approfondita di come funzionano questi controlli nella pratica, leggi questa guida sull’autenticazione delle email.

Perché questo influenza il posizionamento nella posta in arrivo

L’autenticazione non è solo una casella di controllo della sicurezza. Modella direttamente la fiducia.

Quando il tuo dominio e il sistema di invio si allineano correttamente:

• I provider riceventi vedono un’identità coerente
• Lo spoofing è più difficile
• I filtri antispam hanno meno motivi per dubitare del messaggio

Quando non si allineano, anche le campagne legittime possono essere segnalate.

Altri due aspetti che le persone dimenticano

Crittografia durante l’invio

TLS conta perché protegge la connessione tra la tua app e il server in uscita. Ciò non garantisce magicamente il posizionamento nella posta in arrivo, ma supporta un percorso di invio più affidabile.

Ritmo di invio e limiti del provider

Anche un account ben autenticato può avere problemi se invia in modo troppo aggressivo per il tipo di account. I provider si aspettano modelli normali. Se il tuo comportamento di invio sembra improvvisamente rischioso, la fiducia può diminuire.

Le funzionalità native di mail merge di Gmail hanno anche il loro vincolo di throughput. Secondo l’analisi di GMass sul mail merge integrato di Gmail, il mail merge nativo di Gmail limita la capacità in uscita a circa il 75% del limite di invio giornaliero totale dell’account.

I record di sicurezza provano l’identità. Il comportamento di invio prova il giudizio. Hai bisogno di entrambi.

Come gli strumenti di mail merge usano i server in uscita

Molte persone presumono che uno strumento di mail merge invii tramite un server misterioso separato. In molti flussi di lavoro basati su Gmail, non è così che funziona.

Invece, lo strumento usa il percorso di invio del tuo account Google esistente. Ciò significa che il server in uscita dietro le quinte è legato all’account Gmail o Google Workspace che già usi, piuttosto che a un server autonomo sconosciuto che devi gestire da solo.

Ciò conta perché il messaggio mantiene il contesto della tua identità di mittente stabilita. Per gli utenti aziendali, questo è solitamente un punto di partenza migliore rispetto al tentativo di costruire una configurazione SMTP personalizzata da zero per l’outreach di routine.

Il vantaggio pratico

Supponiamo che un responsabile HR invii follow-up di colloquio da un account Google Workspace. O che un community manager invii promemoria di eventi tramite Gmail. Lo strumento di mail merge aiuta a personalizzare e organizzare quei messaggi, ma il livello di fiducia proviene comunque dall’account sottostante e dalla configurazione del dominio.

Ciò semplifica le cose:

• Nessun server separato da configurare
• Nessuna reputazione di relay extra da costruire da zero
• Nessuna necessità di mantenere l’infrastruttura di posta

Il compromesso è che il volume di invio rimane legato alle regole di Google. I dati verificati affermano che i server di posta in uscita per gli strumenti di mail merge basati su Gmail sono vincolati dai limiti giornalieri di Google di 1.500 destinatari al giorno per account personali standard e 2.000 per account Google Workspace premium, come discusso in questa discussione della community sui limiti di mail merge di Gmail.

Il punto chiave

Gli strumenti di mail merge possono rendere l’invio più efficiente, più personalizzato e più facile da tracciare. Ma non cancellano i fondamentali. I tuoi risultati dipendono ancora dalla reputazione del tuo account, dalla qualità della tua configurazione di autenticazione e dal fatto che il tuo volume di invio rimanga entro ciò che il provider si aspetta.

Una lista di controllo per la risoluzione dei problemi di invio

Quando l’invio si interrompe, l’approccio comune è saltare direttamente alla riscrittura dell’email. Quella è solitamente la prima mossa sbagliata. Inizia dal sintomo, poi abbinalo alla probabile causa a livello di server.

Se ricevi “connessione rifiutata”

La prima cosa da controllare è la porta.

I dati verificati affermano che la confusione tra porta 25 e 587 causa il 60% dei fallimenti SMTP in uscita per gli utenti non tecnici, perché la porta 25 è spesso bloccata dagli ISP, mentre la porta 587 con STARTTLS è richiesta dai moderni ESP per l’invio autenticato.

Prova questa rapida lista di controllo:

• Controlla l’impostazione della porta. Se la tua app sta usando la porta 25 per l’invio dal client, passa alla 587 se il tuo provider la supporta.
• Abbina la sicurezza alla porta. Usa il metodo di crittografia che il tuo provider si aspetta con quella porta.
• Conferma di stare configurando l’invio, non il relay. La maggior parte delle app aziendali necessita di impostazioni di invio autenticato.

Se vedi “autenticazione fallita”

Ciò solitamente significa che l’app non è riuscita a dimostrare di avere il permesso di inviare tramite l’account.

Guarda questi elementi:

• Verifica il nome utente. Usa l’indirizzo email completo se il provider lo richiede.
• Ricontrolla il metodo della password. Alcuni provider richiedono un flusso di accesso specifico per l’app.
• Assicurati che l’autenticazione sia abilitata. Se l’app ha una casella di controllo per l’autenticazione SMTP, solitamente dovrebbe essere attiva.

Se i messaggi vengono rifiutati come spam

Un messaggio rifiutato punta spesso ai segnali di fiducia, non solo alla formulazione.

Usa questo ordine:

1. Controlla l’allineamento SPF, DKIM e DMARC
2. Conferma che il dominio “Da” corrisponda alla tua configurazione di invio
3. Rivedi il tuo comportamento di invio recente

Se il posizionamento nello spam è diventato un problema ricorrente, questa guida su come evitare che le email finiscano nello spam è un pratico passo successivo.

Se raggiungi un limite di invio

Questo non è un bug del server. È solitamente un limite della policy del provider.

A quel punto, le tue opzioni sono operative, non tecniche:

• Riduci il volume giornaliero
• Dividi l’invio tra flussi di lavoro aziendali approvati
• Scegli strumenti e piattaforme adatti al tuo caso d’uso

Se il tuo team sta decidendo se una piattaforma dedicata sarebbe più adatta per campagne più ampie, questa rassegna che ti aiuta a confrontare le migliori piattaforme di email marketing può aiutare a inquadrare i compromessi.

Inizia dal percorso di invio, non dal testo dell’email. La maggior parte dei fallimenti di consegna lascia indizi nella configurazione.

---

Se desideri inviare campagne personalizzate tramite il tuo account Google esistente senza gestire tu stesso l’infrastruttura SMTP, Mail Merge for Gmail è costruito per quel flusso di lavoro. Consente ai team di inviare outreach personalizzato da Gmail utilizzando i dati di Google Sheets, tracciare aperture e clic, gestire le disiscrizioni e mantenere i report visibili all’interno del foglio di calcolo che il tuo team utilizza già.