Conviene ancora ospitare la posta nel 2026?

La risposta breve

Ospitare autonomamente la posta elettronica vale ancora la pena nel 2026, purché si separi il lavoro in due parti. Ricevere la propria posta sul proprio VPS comporta pochi rischi e funziona, perché si è il destinatario e nessuno deve fidarsi del proprio server. Inviare messaggi che i grandi provider di posta accettino è un’attività diversa e dipende dalla reputazione dell’indirizzo IP, che si eredita invece di costruirla.

La configurazione che adottano realmente gli amministratori esperti è ibrida. Il proprio server gestisce le caselle e l’archivio, mentre la posta in uscita passa attraverso un relay autenticato sulla porta 587. L’hosting completamente autonomo, in entrambe le direzioni, resta la scelta migliore in alcuni casi specifici, descritti verso la fine di questo articolo.

La parte più difficile dell'hosting autonomo della posta elettronica è la recapitabilità

Installare un mail server richiede un fine settimana di lavoro. Uno stack moderno fornisce SMTP (simple mail transfer protocol) per trasferire i messaggi, IMAP (internet message access protocol) per leggerli, il filtraggio dello spam e un'interfaccia webmail tramite un unico file Compose; la guida Installazione del mail server Mailcow su un VPS tratta questi aspetti. L'installazione non è la parte difficile.

La difficoltà inizia quando il server apre una connessione verso un sistema gestito da un'azienda che non ha mai sentito parlare di voi e gli chiede di recapitare un messaggio nella casella di posta di un utente. Il destinatario non ha alcun motivo per accettare. Prende la decisione in base a diversi segnali: la reputazione dell'indirizzo IP che si connette, la reputazione del dominio, l'autenticazione del messaggio e il modo in cui i suoi utenti hanno reagito in precedenza alla vostra posta. Un nuovo mittente non ha alcuna cronologia e l'assenza di cronologia non viene considerata neutra. Viene considerata un rischio. Di conseguenza, i primi messaggi finiscono nella cartella dello spam oppure vengono posticipati finché non si definisce un comportamento ricorrente.

Vedrete il rifiuto. Gmail invia un rifiuto permanente di questo tipo:

550-5.7.1 [203.0.113.5      19] Our system has detected that this message is
550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail,
550-5.7.1 this message has been blocked.

Microsoft ne invia uno diverso, che termina con un codice di blocklist variabile:

550 5.7.1 Unfortunately, messages from [203.0.113.5] weren't sent. Please
contact your Internet service provider since part of their network is on
our block list (S3150).

Controllate innanzitutto la prima cifra. Un codice che inizia con 4 è temporaneo, quindi il server conserva il messaggio e ritenta l'invio. Un codice che inizia con 5 è permanente, quindi il messaggio torna immediatamente al mittente come mancato recapito. Un posticipo 4xx che non viene mai rimosso indica un limite di velocità o di reputazione e può risolversi autonomamente. Un errore 5xx è una decisione definitiva e non si risolverà.

Perché la posta di un nuovo server finisce nella cartella spam?

Perché l'indirizzo IP non è nuovo. Non si riceve un indirizzo mai utilizzato. Il provider assegna un indirizzo riciclato dal proprio pool, insieme alla relativa cronologia. Se il precedente assegnatario ha inviato spam, il primo messaggio può essere rifiutato prima ancora di inviarne un secondo.

Controllate l'indirizzo prima di installare qualsiasi servizio. Le blocklist pubbliche rispondono tramite DNS, usando i quattro ottetti dell'indirizzo in ordine inverso:

sudo apt update && sudo apt install -y bind9-dnsutils netcat-openbsd swaks
dig +short 10.0.0.10.zen.spamhaus.org

Una risposta vuota indica che l'indirizzo non è presente nell'elenco. Una risposta contenuta in 127.0.0.0/8 indica invece che lo è; l'ottetto finale specifica quale elenco ha rilevato la corrispondenza. Questo test presenta però un problema: Spamhaus rifiuta le query provenienti dai grandi resolver pubblici, quindi la stessa ricerca eseguita tramite 8.8.8.8 restituisce 127.255.255.254 indipendentemente dallo stato effettivo. Quel codice indica che la query è stata rifiutata, non che l'indirizzo è presente nell'elenco. Eseguite la query tramite il resolver del vostro server oppure usate la ricerca web.

Un risultato pulito è necessario, ma non sufficiente. L'assenza dalle blocklist indica soltanto che, di recente, nessuno ha segnalato quell'indirizzo. Non conferisce una reputazione positiva, che è invece ciò che consente ai messaggi di arrivare nella posta in arrivo. La reputazione si costruisce inviando piccoli volumi di posta legittima nell'arco di alcune settimane.

Anche i server vicini sono rilevanti, perché alcuni destinatari valutano la reputazione di un intero blocco di rete anziché del singolo indirizzo. Se un altro cliente dello stesso intervallo /24 inizia a inviare spam, la consegna dei vostri messaggi può rallentare per associazione. Questa valutazione a livello di blocco spiega anche perché le segnalazioni di abuso arrivano nella casella di posta di un VPS per traffico che l'utente non ha mai inviato: la segnalazione segue l'intervallo di indirizzi.

Cosa verificare prima di iniziare: la porta 25 e il record PTR

La porta TCP 25 in uscita è quella più soggetta ad abusi su Internet, quindi molti provider di hosting la chiudono per impostazione predefinita sui nuovi account. Alcuni la aprono su richiesta. Altri la aprono quando l'account ha una certa anzianità e uno storico dei pagamenti. Altri non la aprono mai. Le policy variano da un provider all'altro e cambiano nel tempo. Non considerare quindi questo articolo, una vecchia discussione su un forum o una pagina promozionale di un provider come informazioni aggiornate. Chiedi e ottieni la risposta per iscritto prima di pagare.

Verifica il percorso direttamente dal server:

nc -vz gmail-smtp-in.l.google.com 25

Un percorso aperto restituisce succeeded! entro un secondo. Un percorso bloccato resta in attesa e poi va in timeout senza indicare il blocco, perché un pacchetto scartato senza risposta produce esattamente lo stesso effetto di un normale problema di rete.

Il secondo requisito è un record PTR, chiamato anche reverse DNS. I server riceventi prendono l'indirizzo IP che si è connesso, ne cercano il record PTR per ottenere un nome, quindi cercano quel nome per ottenere nuovamente un indirizzo. Quando i due indirizzi coincidono, si parla di forward-confirmed reverse DNS. È un controllo semplice che verifica che l'host connesso appartenga effettivamente al soggetto che dichiara di essere.

dig -x 203.0.113.5 +short
dig +short mail.example.com

Il primo deve restituire il nome host della posta. Il secondo deve restituire lo stesso indirizzo da cui hai iniziato. Solo il proprietario di un indirizzo IP può pubblicarne il record PTR. Questa configurazione deve quindi essere impostata dal provider oppure resa disponibile nel relativo pannello di controllo. Un record PTR mancante, o un record generico come 203-0-113-5.static.example-isp.net, è un forte segnale negativo, perché i server di posta reali hanno quasi sempre un nome corrispondente, mentre le fonti di spam massivo spesso non lo hanno.

Se il provider assegna anche IPv6 e il server lo preferisce, tutto quanto indicato sopra si applica anche all'indirizzo IPv6, e Gmail applica controlli più severi in questo caso. L'invio tramite IPv6 da un indirizzo privo di record PTR viene rifiutato con un messaggio che indica che il messaggio non rispetta le linee guida per l'invio tramite IPv6 relative ai record PTR e all'autenticazione. Se non puoi impostare un record PTR IPv6, invia solo tramite IPv4. In Postfix, usa smtp_address_preference = ipv4 per preferire IPv4 oppure inet_protocols = ipv4 per disabilitare completamente IPv6.

Le tre domande da porre a qualsiasi provider

1. La porta TCP 25 in uscita è aperta su un nuovo account? In caso contrario, qual è la procedura esatta e quali sono i tempi per aprirla?
2. Posso impostare il record PTR per il mio indirizzo IPv4 e per il mio indirizzo IPv6? Dove posso farlo?
3. Se il mio indirizzo risulta inserito in una blocklist a causa di un cliente precedente, mi sposterete su un indirizzo diverso?

Poni tutte e tre le domande prima di acquistare, non dopo. Un provider che risponde chiaramente alle prime due e risponde negativamente alla terza può comunque essere utilizzato, perché puoi verificare l'indirizzo il primo giorno e annullare il servizio. Un provider che non vuole rispondere per iscritto a nessuna di queste domande ti ha già indicato come sarà gestire la posta su quel servizio.

Cosa dimostrano realmente SPF, DKIM e DMARC

Tre record DNS dimostrano che un messaggio che dichiara di provenire dal tuo dominio è stato effettivamente inviato da un server autorizzato. Ognuno risponde a una domanda diversa, e il terzo funziona correttamente solo dopo aver compreso i primi due.

SPF (sender policy framework) è un record TXT che elenca i server autorizzati a inviare messaggi per il tuo dominio. Il destinatario lo verifica rispetto al mittente dell’envelope, cioè l’indirizzo indicato nel comando SMTP MAIL FROM. Questo indirizzo non corrisponde all’header From: visualizzato dal destinatario.

DKIM (domainkeys identified mail) aggiunge agli header del messaggio una firma crittografica che copre il corpo e un elenco scelto di header. La chiave pubblica corrispondente si trova nel DNS, sotto un selector scelto da te. Chiunque può quindi verificare che il messaggio provenga dal titolare della tua chiave privata e che non sia stato modificato durante il transito.

DMARC (domain-based message authentication, reporting and conformance) collega i due controlli precedenti al dominio presente nell’header From: visibile e indica ai destinatari come comportarsi quando il collegamento non è valido.

example.com.                  TXT  "v=spf1 mx -all"
mail._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
_dmarc.example.com.           TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Il concetto importante è l’allineamento. DMARC non supera il controllo solo perché SPF ha avuto esito positivo. Lo supera quando SPF o DKIM ha esito positivo e il dominio che ha superato il controllo coincide con quello presente nell’header From:. È qui che la posta inoltrata fallisce senza segnali evidenti: un relay che riscrive il mittente dell’envelope usando il proprio dominio ottiene comunque un pass SPF, ma il dominio che ha superato il controllo è quello del relay. Di conseguenza non è allineato e DMARC fallisce, a meno che sia presente e valida la tua firma DKIM. Firma i messaggi con una chiave pubblicata sotto il tuo dominio per risolvere il problema.

L’allineamento spiega anche il comportamento dell’inoltro. Quando una mailing list o un vecchio indirizzo universitario inoltra il tuo messaggio, il server di inoltro diventa l’indirizzo IP connesso. Questo indirizzo non è incluso nel tuo record SPF, quindi SPF fallisce presso il destinatario finale. DKIM continua a funzionare finché gli header firmati non vengono modificati. È DKIM il controllo che deve funzionare.

Pubblica p=none con un indirizzo di reporting rua=, quindi leggi i report aggregati per due settimane prima di rendere la policy più restrittiva. Questi report sono l’unico punto in cui puoi vedere i messaggi inviati a tuo nome che non hai inviato e l’unico modo per individuare il server di inoltro che avevi dimenticato. Passare direttamente a p=reject salta questo controllo e interrompe i messaggi legittimi senza lasciare traccia della causa.

Poi verifica l’intera catena end-to-end. Invia un messaggio a un account che controlli presso un grande provider e apri il sorgente completo:

swaks --to you@gmail.com --from postmaster@example.com --server 127.0.0.1
sudo journalctl -t postfix/smtp -f

swaks stampa la conversazione SMTP mentre avviene. La riga di log di Postfix relativa alla consegna termina con status=sent (250 2.0.0 OK ...) quando il server destinatario accetta il messaggio. In caso contrario, il log contiene il testo del rifiuto in forma integrale. È questa stringa che devi cercare. Nel messaggio consegnato, il sorgente completo contiene un header Authentication-Results: che indica ogni controllo con esito positivo o negativo e il dominio autenticato. Tutti e tre i controlli devono avere esito positivo e il dominio deve essere il tuo.

Come si individua un problema di reputazione?

Un feedback loop è un meccanismo con cui un provider di posta invia una copia del messaggio ogni volta che uno dei suoi utenti fa clic sul pulsante per segnalare lo spam. Senza feedback loop, il primo segnale di un problema è una consegna già fallita, con settimane di ritardo.

I programmi sono diversi e non tutti sono adatti a un singolo VPS con un solo indirizzo. Ad agosto 2026, Microsoft gestisce un servizio per indirizzo con dati e segnalazioni a cui il titolare dell'indirizzo può registrarsi; Yahoo offre un feedback loop per le segnalazioni associato al dominio di firma DKIM; Google pubblica dati aggregati sulla reputazione, non le singole segnalazioni, tramite una dashboard che resta vuota finché non invii un volume giornaliero significativo agli utenti del servizio. Leggi i termini aggiornati di ciascun programma prima di farvi affidamento, perché questi programmi cambiano e nessuno garantisce l'accesso.

I requisiti pubblicati da Google per i mittenti in massa, in vigore da febbraio 2024, sono la dichiarazione pubblica più chiara di ciò che oggi si aspetta un grande destinatario. Un mittente che invia più di 5,000 messaggi al giorno ad account Gmail personali deve autenticarsi con SPF e DKIM, pubblicare una policy DMARC, offrire un'opzione di annullamento dell'iscrizione con un solo clic per i messaggi inviati in massa e mantenere il tasso di segnalazioni come spam al di sotto dello 0.3 percento. La posta personale proveniente da un server di piccole dimensioni resta ben al di sotto di questa soglia, ma gli stessi segnali vengono analizzati a qualsiasi volume; il tasso di segnalazioni è l'unico dato che non puoi vedere senza un feedback loop.

La suddivisione che funziona: ricezione in self-hosting, inoltro in uscita

La ricezione è la parte che presenta quasi solo vantaggi. Nessuno deve fidarsi di te per accettare messaggi destinati al tuo dominio. Il record MX, cioè il record DNS che indica il mail exchanger del dominio, punta al tuo server; i mittenti si connettono a te e tutte le decisioni successive spettano a te: cosa conservare, per quanto tempo, come indicizzarlo e chi può cercarlo. Lo storage costa poco e un archivio che possiedi non può essere chiuso da una decisione automatizzata presa altrove. Il lavoro è concreto e circoscritto: mantenere aggiornato il filtro antispam, rinnovare i certificati TLS (transport layer security), mantenere i backup ed evitare che il disco si riempia.

Per la posta in uscita puoi invece affidarti a un relay per evitare il problema più complesso. Configura il server in modo che inoltri ogni messaggio in uscita a un relay autenticato sulla porta 587, invece di comunicare direttamente con Internet sulla porta 25. In Postfix, modifica main.cf:

relayhost = [smtp.relay.example]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

Scrivi le credenziali in /etc/postfix/sasl_passwd usando un editor, in modo che la password non venga mai salvata nella cronologia della shell. È una singola riga e l'host a sinistra deve essere scritto esattamente come appare in relayhost:

[smtp.relay.example]:587 username:password

sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd.db
sudo systemctl reload postfix

Dopo il reload, un messaggio inviato registra relay=smtp.relay.example[...]:587 e status=sent. Una riga di log che contiene SASL authentication failed indica che le credenziali non sono state accettate. La causa più comune è un hostname in sasl_passwd scritto in modo diverso da quello presente in relayhost, perché la ricerca utilizza una corrispondenza esatta della stringa.

Questa suddivisione funziona perché il relay gestisce indirizzi che hanno alle spalle anni di posta accettata e la gestione di quella reputazione costituisce la sua intera attività. Tu mantieni il dominio, le caselle di posta, l'archivio e la possibilità di cambiare servizio, perché cambiare relay richiede una sola riga di configurazione e un solo record DNS. Rinunci alla riservatezza della posta in uscita nei confronti del gestore del relay. Questo è il costo reale dell'accordo ed è meglio valutarlo consapevolmente anziché scoprirlo in seguito.

Un'ulteriore separazione va configurata il primo giorno. Tutto ciò che è bulk dovrebbe uscire da un sottodominio dedicato con una propria chiave DKIM: news.example.com per una newsletter e mail.example.com per la posta personale. La reputazione è associata al dominio mittente, quindi il tasso di reclami relativo a una newsletter Listmonk in self-hosting non può danneggiare anche la tua posta personale.

Quando il self-hosting completo è ancora la scelta giusta?

Volume. Il prezzo per messaggio dei relay è sostenibile per centinaia di messaggi al mese, ma non lo è più per milioni. A quel volume puoi permetterti indirizzi IP dedicati e il programma di warmup necessario per utilizzarli correttamente.

Giurisdizione. Quando una normativa o un contratto stabilisce che i messaggi non devono essere memorizzati sul disco di terzi, la qualità della consegna non è il fattore decisivo. Un relay semplicemente non è disponibile per te.

Controllo che non puoi acquistare. Regole di conservazione dei dati che rispecchiano la tua policy invece di un livello tariffario, un indirizzo per ogni servizio per individuare chi lo ha divulgato, filtri che eseguono il tuo codice e nessuna sospensione dell'account decisa da un sistema senza possibilità di ricorso.

Messaggi che non lasciano mai la tua rete. Gli alert e gli altri messaggi tra macchine non presentano alcun problema di deliverability, perché entrambe le estremità appartengono a te. Un server SMTP locale che consegna i messaggi nelle tue mailbox è la soluzione completa. È lo stesso modello alla base di assegnare a un assistente una mailbox self-hosted tramite MCP (model context protocol).

Se invii direttamente i messaggi in uscita, esegui il warmup dell'indirizzo. Inizia con un volume giornaliero ridotto verso destinatari che si aspettano i tuoi messaggi, aumentalo gradualmente nell'arco di diverse settimane e non inviare mai un picco improvviso da un indirizzo non ancora utilizzato. La reputazione si costruisce nel tempo attraverso messaggi accettati con poche segnalazioni, quindi un aumento improvviso da un indirizzo senza storico appare esattamente come un server compromesso e viene trattato come tale.

Qual è il costo del primo anno di gestione di un mail server?

La prima settimana è dedicata alla configurazione: pacchetti, record DNS, certificati TLS, primi messaggi di test e DMARC su p=none.

Dalla seconda alla sesta settimana arriva la parte che nessuno pianifica. Si leggono i report aggregati DMARC, si individua il problema di allineamento che non si sapeva di avere, si scopre il forwarder che interrompe SPF, quindi si sposta la policy su p=quarantine e successivamente su p=reject. Questa fase determina se il self-hosting diventerà un'attività ordinaria oppure qualcosa da gestire controvoglia.

Dopo questa fase, l'impegno si stabilizza a circa un'ora al mese: aggiornamenti dei pacchetti, verifica del rinnovo di un certificato invece di darlo per scontato, un test di ripristino dal backup, un controllo della crescita del disco e una verifica su una blocklist.

Poi arriva la settimana che non è possibile pianificare. Un indirizzo viene inserito in una blocklist per un'attività che non è stata eseguita. Un grande destinatario modifica una regola e i messaggi iniziano nuovamente a finire nella cartella spam. I messaggi in coda non sono messaggi persi: per impostazione predefinita, Postfix ritenta l'invio di un messaggio differito per cinque giorni, come stabilito da maximal_queue_lifetime = 5d, quindi un'interruzione di alcune ore comporta solo un ritardo nella consegna. Un'interruzione di una settimana comporta la perdita dei messaggi.

Un record MX di backup è una soluzione meno efficace di quanto sembri. I server mittenti ritentano già autonomamente per diversi giorni, quindi un server secondario che si limita ad accodare i messaggi aggiunge poco. Inoltre, un server secondario che accetta messaggi per il dominio senza sapere quali indirizzi esistono accetterà anche messaggi destinati a indirizzi inesistenti, quindi li restituirà a mittenti contraffatti. In questo modo il backup diventa una fonte di backscatter. È più utile investire il tempo nel monitoraggio e in un ripristino che sia stato realmente testato.

Valuta l'intero sistema con la domanda che applicheresti a qualsiasi altro componente del server: possederlo offre qualcosa che non puoi acquistare? Per le caselle di posta e l'archivio, la risposta di solito è sì. Per la consegna in uscita a destinatari esterni, di solito è no. È lo stesso criterio che consente di valutare il resto della lista delle cose che vale la pena gestire in self-hosting nel 2026.

FAQ

Posso ospitare autonomamente la posta elettronica se il provider del mio VPS blocca la porta in uscita 25?

Sì, per la ricezione e per l'invio tramite un relay. La posta in ingresso arriva alla porta 25 del server e un blocco in uscita non la influisce. La posta in uscita passa invece attraverso un relay autenticato sulla porta 587, che i provider non bloccano. Con la porta 25 chiusa non è possibile consegnare direttamente i messaggi agli altri server di posta, perché la consegna tra server avviene per definizione sulla porta 25. Esegui il test con nc -vz gmail-smtp-in.l.google.com 25. Un'attesa seguita da un timeout indica che la porta è bloccata.

Perché i miei messaggi finiscono nello spam anche se SPF, DKIM e DMARC passano tutti?

L'autenticazione dimostra chi ha inviato un messaggio. Non dimostra che il messaggio sia desiderato. Il superamento di tutti e tre i controlli porta il mittente da non identificato a identificato. Dopodiché il destinatario valuta la reputazione del tuo indirizzo IP e del tuo dominio, che un nuovo mittente non ha ancora. Costruiscila inviando per settimane piccoli volumi di messaggi attesi dai destinatari. Verifica quindi che il record PTR corrisponda al nome host della posta in entrambe le direzioni. Controlla anche che il contenuto non introduca penalizzazioni aggiuntive, ad esempio tramite URL shortener o un dominio di tracking non riconosciuto.

Mi serve un indirizzo IP dedicato per un server di posta self-hosted?

Per la consegna diretta della posta in uscita, sì. Un server di posta ha bisogno di un indirizzo il cui record PTR sia sotto il tuo controllo e la cui reputazione appartenga soltanto a te. Un indirizzo VPS è già dedicato in questo senso. Non puoi però controllare la sua cronologia né quella degli indirizzi vicini nello stesso blocco di rete. Se usi invece un relay per la posta in uscita, sono gli indirizzi del relay a determinare la reputazione. Il tuo indirizzo deve soltanto accettare le connessioni in ingresso.

È sicuro spostare il mio indirizzo principale su un server self-hosted?

Sposta il servizio per fasi, invece di eseguire un unico cut-over. Mantieni attiva la casella esistente, aggiungi il tuo server come seconda destinazione e inoltra una copia dei messaggi per alcune settimane. In questo periodo, leggi i report DMARC e verifica che la posta funzioni in entrambe le direzioni. Modifica il record MX soltanto dopo che i messaggi di prova sono arrivati correttamente per una settimana. Il problema più grave è un cut-over che perda i messaggi in ingresso, perché questa parte non può essere ricostruita.

Qual è la configurazione minima che mi permette di mantenere il controllo della posta?

Il tuo server per le caselle e l'archivio, con la posta in uscita affidata a un relay autenticato sulla porta 587. I dati e il dominio restano sotto il tuo controllo e il problema della reputazione viene eliminato. Se cambi scelta, il costo della modifica rimane contenuto: il relay richiede una sola riga di configurazione e una sola voce SPF, quindi in seguito puoi sostituirlo in un pomeriggio.