Self-host un mail server su un VPS.
Mailcow, Mail-in-a-Box, iRedMail — e l'host che glielo permette.
Il self-hosting dell'email è più difficile di quanto dovrebbe essere nel 2026, e quasi tutta la difficoltà si trova in tre punti — porta 25 bloccata sulla maggior parte degli host, reputazione IP di partenza, record DNS che devono allinearsi perfettamente. Questa guida nomina i prerequisiti, confronta i tre stack seri e percorre il percorso della recapitabilità.
- 01
Tre muri prima di qualsiasi installazione: la porta 25 in uscita deve essere aperta, l'IP necessita di una cronologia di reputazione pulita, e il record PTR deve corrispondere all'hostname HELO. Senza tutti e tre, nessuno stack software consegnerà posta a Gmail.
- 02
L'host conta più del software. Il VPS NordBastion apre la porta 25 per default e imposta i record PTR dal pannello entro un'ora — la postura no-KYC significa che non c'è nessun passaggio di verifica dell'identità.
- 03
Scegliere lo stack secondo il proprio gusto operativo: Mail-in-a-Box (script, 2 GB, default), Mailcow (Docker, 6 GB, UI moderna), iRedMail (flessibile, manuale, per il veterano ops).
Tre muri. Colpirne uno qualsiasi e il resto della guida è sprecato.
La ragione per cui «basta installare un mail server» è un cattivo consiglio è che l'installazione è il 10% facile del problema. L'altro 90% sono prerequisiti a livello di infrastruttura che il software non può fare per lei. Confermare che tutti e tre siano soddisfatti prima di installare qualsiasi cosa.
Muro 1 — porta 25 in uscita. La consegna SMTP è TCP/25 dal proprio server all'MX del destinatario. La maggior parte degli hyperscaler e dei provider VPS budget blocca questo in uscita per default a livello di hypervisor per limitare lo spam. Testarlo prima: nc -zv smtp.gmail.com 25 — se la connessione va in timeout, l'host blocca la porta 25 e nessuna mail uscirà mai. Aprire un ticket chiedendo lo sblocco, o passare a un host che non lo blocca.
Muro 2 — reputazione IP. Verificare l'IP contro Spamhaus, SORBS, Barracuda e Cisco Talos (mxtoolbox.com/blacklists.aspx). Se appare su una qualsiasi lista, l'IP ha una storia precedente; la recapitabilità sarà scarsa finché non si richiede la rimozione o si cambia IP. Gli IP nuovi senza storia precedente vanno bene — partono nel bucket «mittente neutro / sconosciuto» che è il punto di partenza corretto.
Muro 3 — allineamento record PTR. Il PTR (DNS inverso) dell'IP del VPS deve corrispondere all'hostname HELO che Postfix annuncia. Se il server annuncia «mail.example.com» ma il PTR per l'IP dice «static-12-34-56-78.example-host.net», Gmail differirà o rifiuterà. Il PTR è impostato dal provider VPS sull'IP, non da lei sul dominio. La maggior parte dei provider espone un controllo nel pannello per questo; alcuni richiedono un ticket di supporto. NordBastion lo espone dal pannello.
Superare tutti e tre, e si è pronti per l'installazione. Non superarne anche solo uno, risolverlo prima.
Perché la maggior parte degli host blocca la porta 25. E l'angolo no-KYC.
L'SMTP in uscita è il preferito degli spammer. Un VPS compromesso con la porta 25 aperta può inviare 100.000 messaggi al giorno prima che qualcuno se ne accorga, e le denunce di abuso arrivano tutte nella casella di posta dell'host. Per tenere questo sotto controllo, la maggior parte dei provider VPS blocca la porta 25 in uscita al bordo della rete, oppure richiede una verifica dell'identità + accettazione dell'acceptable-use prima di sbloccarla per ogni cliente.
Quel modello si rompe per un host privacy-first. L'intera proposta di un VPS no-KYC è che i clienti non debbano identificarsi. Aggiungere un passaggio «ma per la porta 25 sì» sarebbe una contraddizione dottrinale. Quindi il settore degli host privacy si divide in due campi: host che rifiutano completamente la porta 25 (esclude il mail server self-hosted), e host che la aprono a tutti senza verifica dell'identità (la categoria più rara, la più interessante).
NordBastion appartiene al secondo campo. Ogni <a href="/it/vps/" class="text-nord-cyan border-b border-nord-cyan/40 hover:border-nord-cyan transition">VPS che forniamo</a> ha la porta TCP/25 in uscita aperta fin dal primo avvio. Nessuna verifica d'identità, nessuna accettazione di condizioni d'uso, nessun ticket di sblocco manuale. Gli abusi vengono monitorati sui pattern del traffico in uscita anziché sull'identità del cliente — un VPS che emette improvvisamente 10 volte il volume di riferimento viene segnalato, indipendentemente da chi possiede l'account. Il compromesso funziona perché le trappole antispam risiedono al livello del protocollo, non al livello dell'identità.
L'implicazione pratica: NordBastion + un IP nuovo pulito + un record PTR impostato dal pannello è la checklist dei tre muri superata in meno di un'ora. Il resto della guida è l'installazione vera.
I tre stack a confronto. Mailcow vs Mail-in-a-Box vs iRedMail.
Mail-in-a-Box. Un singolo script shell che trasforma un'installazione fresca di Ubuntu 22.04 in un mail server completo — Postfix, Dovecot, Roundcube webmail, contatti/calendario equivalenti a Nextcloud, SpamAssassin, guida DNS. I valori predefiniti sono sensati, l'interfaccia di amministrazione è minimale, il footprint delle risorse è di 2 GB RAM comodamente. La scelta migliore per chi vuole il risultato senza imparare Docker. Gli aggiornamenti arrivano al ritmo del progetto upstream, tipicamente due o tre l'anno.
Mailcow. Uno stack basato su Docker Compose — Postfix, Dovecot, Rspamd, ClamAV, SOGo, Nginx, MariaDB, Redis, Solr — con un'interfaccia di amministrazione web raffinata (2FA, ActiveSync, calendari, rubrica, quote mailbox). Richiede 6 GB di RAM come baseline pratica; comodo su 8. La scelta migliore per chi vuole una configurazione moderna e modulare con filtro antispam di primo livello e ActiveSync per dispositivi mobili. Rilasciato continuamente; il moby docker-compose.yml è incluso nel repository del progetto.
iRedMail. La scelta tradizionale — uno script shell che installa lo stack classico Postfix + Dovecot + Amavisd-new + ClamAV su Debian / Ubuntu / CentOS. L'interfaccia di amministrazione (iRedAdmin) è funzionale più che bella. La scelta migliore per l'operatore che ha già opinioni su ogni componente e vuole il controllo diretto dei file di configurazione. L'edizione Pro aggiunge un'interfaccia di amministrazione più ricca; l'edizione open-source è pienamente utilizzabile.
Cosa condividono tutti. Tutti e tre producono un mail server pienamente funzionale con SMTP / IMAP / submission / DKIM / SpamAssassin o Rspamd / webmail. Tutti e tre si basano sugli stessi meccanismi di recapitabilità a livello di protocollo (SPF / DKIM / DMARC / PTR). Tutti e tre richiedono la stessa manutenzione mensile. La scelta riguarda l'ergonomia, non la funzionalità.
I record DNS. Tutti e cinque, perfettamente, o niente.
La recapitabilità moderna delle email è condizionata da cinque record DNS. Se tutti e cinque sono corretti, si atterra nella casella di posta di Gmail e Outlook. Se ne manca uno o uno è a metà, si atterra nello spam — o peggio, si viene silenziosamente scartati al livello SMTP senza bounce.
1. MX (voce). example.com. MX 10 mail.example.com. — indica al mondo dove consegnare la posta per il dominio.
2. A (voce). mail.example.com. A [redacted-ip] — l'IP del proprio VPS mail.
3. PTR (inverso). [redacted-ip].in-addr.arpa. PTR mail.example.com. — impostato sull'IP presso il provider VPS. Deve corrispondere all'HELO. NordBastion: impostare questo dal pannello entro un'ora dalla provisioning del VPS.
4. SPF (voce). example.com. TXT "v=spf1 mx -all" — dichiara che solo gli host MX possono inviare posta per il dominio. Il -all (hard fail) è corretto nel self-hosting; ~all (soft fail) è la forma permissiva più vecchia da evitare.
5. DKIM (voce). default._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=<chiave-lunga-dall-admin-mailcow>" — la chiave pubblica che il ricevente usa per verificare la firma DKIM che il server aggiunge a ogni messaggio in uscita. La chiave privata rimane nel mail server; la metà pubblica va nel DNS.
6. DMARC (voce). _dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:[redacted-user]@[redacted-host]" — dice ai riceventi cosa fare con i messaggi che falliscono SPF/DKIM (rifiutare), e dove inviare i report aggregati. Iniziare con p=none per la prima settimana per monitorare, poi passare a p=reject.
Verificare l'intero stack con il controllo salute email di mxtoolbox.com dopo ogni modifica. Verde su tutta la linea è l'unico stato accettabile.
Recapitabilità. Gmail, Outlook, il warm-up.
Un IP nuovo, anche con DNS perfetti, parte nel bucket «mittente neutrale» presso Gmail e Outlook. Il primo mese è un esercizio di costruzione della reputazione. L'obiettivo è apparire esattamente come un piccolo mittente legittimo: volume basso, cadenza costante, autenticazione perfetta, destinatari che aprono e rispondono.
Settimana 1. Inviare mail solo ai propri account esterni (Gmail, Outlook, Yahoo, Proton). Leggere ogni messaggio nella casella del destinatario, contrassegnare «Non spam» se finisce nello spam, rispondere. La risposta è il segnale di reputazione che conta di più. Volume: 5–20 messaggi al giorno.
Settimane 2–4. Aggiungere una manciata di corrispondenti che rispondono naturalmente. Iscriversi a una o due mailing list che inviano al nuovo indirizzo (annunci tecnici, newsletter di progetto); l'engagement sulle comunicazioni in entrata da mittenti consolidati aiuta le comunicazioni in uscita. Volume: 50–200 al giorno.
Mesi 2–3. A questo punto l'IP ha un track record. Migrare la posta in entrata dal vecchio provider tramite inoltro SMTP in modo che il nuovo indirizzo inizi a ricevere traffico reale. Continuare a monitorare le liste DNSBL mensilmente. Al terzo mese, la recapitabilità è approssimativamente indistinguibile da un provider hosted.
Cosa uccide il warm-up. Invio in blocco il primo giorno. Invio a una lista contatti obsoleta con indirizzi inattivi (Gmail conta i bounce come un forte segnale negativo). Campagne newsletter. Ognuna di queste nella settimana 1 fa retrocedere l'IP di settimane. La disciplina è la pazienza, non la tecnica.
Manutenzione. Un'ora al mese, o si rompe.
Un mail server self-hosted non è «configura e dimentica» — l'ecosistema email si muove continuamente, e il costo di restare indietro è un degrado silenzioso della recapitabilità che si nota solo quando un amico dice «non ho mai ricevuto la tua email». La routine di manutenzione mensile è piccola ma non negoziabile.
Checklist mensile. (1) Controllo DNSBL — scansione blacklist mxtoolbox, richiedere la rimozione se presenti. (2) Verifica rinnovo certificati — Let's Encrypt dovrebbe rinnovarsi automaticamente ma verificare. (3) Esecuzione aggiornatore — Mailcow update.sh o aggiornamento MIAB oppure apt upgrade su iRedMail. (4) Scansione log — Rspamd / Postfix per tassi di rifiuto insoliti. (5) Verifica backup — ripristinare l'ultimo backup in una directory di prova e confermare che lo spool mail si decomprima correttamente.
Trimestrale. Ripristino completo del backup su un secondo VPS, verifica che il login alla webmail funzioni. Revisione delle regole SpamAssassin / Rspamd — i punteggi bayes derivano, riaddestrare su ham/spam recenti. Controllare i report aggregati DMARC per usi non autorizzati del dominio.
All'arrivo di una versione principale. Prima fare lo snapshot del VPS (pannello NordBastion: un clic). Prendere un backup fresco del database fuori server. Eseguire l'aggiornamento. Verificare l'invio SMTP, il recupero IMAP, il login alla webmail, la sincronizzazione mobile, ogni account sul server. Ripristinare tramite snapshot in caso di errore. Tempo: 30–60 minuti una o due volte l'anno.
Il punto di rottura. Le persone abbandonano il mail server self-hosted quando saltano tre mesi di aggiornamenti, poi arriva un cambiamento importante DSA / DMARC, poi la recapitabilità si degrada silenziosamente, poi un amico dice che i messaggi bounceano. Costruire l'ora mensile nel calendario dal primo giorno fa sì che il punto di rottura non arrivi mai.
Domande, con risposta.
Otto domande che emergono avviando e gestendo un mail server self-hosted nel 2026.
È ancora realistico il self-hosting delle email nel 2026?
Sì — ma solo se si comprendono i tre problemi strutturali e si accetta il costo operativo. Problema uno: la porta 25 in uscita è bloccata per default presso la maggior parte dei provider VPS e sbloccarla richiede una conversazione con il team commerciale. Problema due: lo spazio IP nuovo ha una reputazione di recapitabilità «fredda» che richiede settimane per scaldarsi presso Gmail e Outlook. Problema tre: il ciclo di manutenzione mensile (controlli DNSBL, rinnovo TLS, rimozione dalle blacklist) è non negoziabile. Con questi gestiti, l'email self-hosted è più sana nel 2026 di quanto non fosse nel 2020.
Quale stack scegliere — Mailcow, Mail-in-a-Box o iRedMail?
Mail-in-a-Box per il lettore che vuole «che funzioni». Uno script di installazione, valori predefiniti sensati, gira su 2 GB. Mailcow per il lettore «voglio un'interfaccia di amministrazione moderna e Docker»; richiede 6 GB, offre Rspamd, ActiveSync, SOGo e un'interfaccia di amministrazione web raffinata. iRedMail per il lettore «ho una stack specifica che voglio»; molto flessibile, molto manuale, la scelta del veterano. Tutti e tre producono un mail server pienamente funzionale; la scelta riguarda l'ergonomia, non il risultato.
Perché la porta 25 è bloccata sulla maggior parte dei provider VPS?
Perché gli spammer ne abusano. I provider hyperscaler e VPS budget bloccano la porta TCP/25 in uscita a livello di hypervisor o firewall per default per limitare le denunce di abuso — sbloccarla richiede l'apertura di un ticket di supporto, la verifica dell'identità e un'accettazione dell'«AUP per email». Gli host privacy-first che rifiutano la verifica dell'identità non possono offrire lo sblocco; gli host mainstream che offrono lo sblocco richiedono KYC. La combinazione «no-KYC E porta 25 sbloccata» è rara ed è il motivo per cui questa guida è su questo sito.
NordBastion sblocca la porta SMTP in uscita per i clienti del mail server?
Sì — la porta 25 in uscita è aperta su ogni VPS NordBastion senza richiedere un ticket di supporto. Non gestiamo un passaggio di verifica dell'identità prima di consentire SMTP, perché la postura no-KYC è la dottrina; gli abusi in uscita vengono monitorati sui pattern di traffico, non sull'identità del cliente. Questo è il differenziatore che rende davvero possibile un mail server self-hosted su un host privacy.
Cos'è un record PTR e perché la mia mail continua a essere rifiutata senza uno?
Un record PTR (pointer) è la ricerca DNS inversa del suo IP — la risposta alla domanda «a quale hostname appartiene questo IP?» Molti grandi provider di posta (Gmail, Microsoft, Yahoo) rifiutano la posta in entrata da server il cui PTR non corrisponde all'hostname HELO della conversazione SMTP. Il PTR si imposta sull'IP, non sul dominio — su un VPS ciò significa chiedere al provider VPS di impostare il PTR per il suo IP su mail.example.com. NordBastion imposta i record PTR su richiesta dal pannello entro un'ora.
Quanto tempo richiede il warm-up della reputazione IP?
Da due a sei settimane di traffico normale per uscire dal bucket «nuovo mittente» presso Gmail e Outlook, più a lungo se si invia raramente. Gli acceleratori sono: volume in uscita basso e costante (50–200 messaggi al giorno per la prima settimana, aumentare gradualmente), allineamento perfetto SPF + DKIM + DMARC su ogni messaggio, zero listing DNSBL, engagement dei destinatari (aperture e risposte). I fattori distruttivi sono: invio in blocco il primo giorno, record di autenticazione mancanti o non allineati, e invio a spam-trap.
Ho bisogno di un VPS dedicato per la posta o posso eseguirla insieme agli altri servizi?
Un VPS dedicato è fortemente consigliato. Il software per mail server (Postfix, Dovecot, Rspamd, ClamAV, il database, la webmail) ha un profilo specifico di RAM e storage, e la reputazione dell'IP è legata specificamente al traffico mail — co-locare con un exit relay Tor o un nodo Bitcoin è un invito ad avere l'IP in qualche lista indesiderata. Un secondo VPS a $5.90/mese è un'assicurazione economica.
Qual è il carico di manutenzione continuo?
Una checklist mensile: verificare che l'IP non sia su Spamhaus / SORBS / Barracuda DNSBLs (5 min — mxtoolbox.com); confermare che i certificati Let's Encrypt siano stati rinnovati (1 min); scansionare i log di Rspamd / Postfix per pattern insoliti (5 min); eseguire l'aggiornatore Mailcow / MIAB (10 min); verificare che l'ultimo backup si ripristini correttamente (15 min una volta al trimestre). Totale: un'ora al mese, con un'ora più intensa due volte l'anno quando arrivano versioni principali.
Porta 25 aperta, PTR dal pannello, nessun KYC, pagamento in crypto.
Mail-in-a-Box gira su Ravelin (2 vCPU, 4 GB, $5.90/mese). Mailcow vuole Iron (4 vCPU, 8 GB, $24.90/mese). Entrambi vengono forniti con la porta 25 già aperta.
Ultima revisione · 2026-05-20 · Fonti · Mailcow / Mail-in-a-Box / iRedMail documentazione upstream, Gmail Postmaster Tools, RFC 5321 / 6376 / 7489 · Cadenza · annuale
Anonymous VPS hosting in 2026 — the cluster.
This guide is one spoke of a larger series. The pillar walks the three privacy layers end to end — the sibling spokes below dive into the specifics.
Three independent layers — signup, payment, network — explained, legal context included, common mistakes flagged.
Bitwarden-compatible password vault under your own control.
Files, calendar, contacts, photos — owned, not rented.
A meta search engine that does not log you — because you own it.
What “no KYC” actually means — and what it does not.