Server di posta multidominio: architettura, isolamento e costi

Gestisci un server di posta multidominio per 30 domini di clienti. Ciascuno richiede un proprio MX, una chiave DKIM, un record SPF, una policy DMARC, regole di quarantena e un controllo della reputazione di invio. La domanda non è «un server solo può farcela?»: Postfix e Dovecot lo fanno da due decenni. La domanda è se la configurazione reggerà quando una campagna in uscita di un cliente danneggerà la reputazione del tuo IP condiviso.

Un server di posta multidominio è un'architettura adatta a molti operatori. Per altri, convinti di risparmiare rispetto a un servizio multitenant gestito, potrebbe essere la scelta sbagliata. Questa guida esamina l'architettura, le configurazioni che aiutano a separare i clienti, le tre modalità di cedimento dell'isolamento che emergono con la crescita e i costi da confrontare prima di preferire un server autogestito a un piano come TrekMail Agency.

Che cos'è davvero un server di posta multidominio

Un server di posta multidominio è un unico stack di trasporto che riceve e invia email per più domini sulla stessa infrastruttura. Un'istanza Postfix riceve per client1.com, client2.com e client3.com; un'istanza Dovecot conserva le caselle dei tre domini secondo le regole di isolamento configurate; una coda in uscita invia i messaggi con firma DKIM specifica per dominio.

Non è la stessa cosa di «hosting email multidominio» come espressione commerciale, che di solito indica un piano gestito nel quale aggiungere più domini allo stesso account di fatturazione. Il server multidominio è la realtà operativa sottostante: la configurazione concreta di Postfix e Dovecot che rende possibile quel piano. Puoi gestirlo sul tuo VPS oppure affidarti a un fornitore come TrekMail Agency, che si occupa dell'infrastruttura multitenant.

Tre architetture per gestire molti domini

Chi gestisce 10 o più domini tende a scegliere fra tre architetture. Ognuna bilancia diversamente costi, controllo e complessità operativa; contano sia i numeri sia il tempo disponibile del team tecnico. Scegliere in anticipo un modello adatto alla crescita può evitare una costosa riprogettazione dopo due anni, quando la soluzione iniziale non basta più.

Modello 1: un server di posta per dominio

L'architettura più semplice prevede un'istanza Postfix/Dovecot per ogni dominio cliente. Non ci sono clienti ospitati nello stesso stack da separare, ma restano da proteggere sistema operativo, rete e accessi amministrativi. Ogni dominio ha il proprio VPS, IP e profilo di reputazione. Può funzionare per 3-5 domini, ciascuno legato a un'attività significativa. A 20+ domini, aggiornamenti, monitoraggio e rinnovi dei certificati possono diventare onerosi, perché il lavoro cresce con il numero di server.

Modello 2: un server di posta multidominio multitenant

Il modello tipico di un'agenzia usa un unico stack Postfix + Dovecot per tutti i clienti, con virtual_mailbox_domains, chiavi DKIM per dominio e configurazione multitenant di Dovecot. Si amministra l'infrastruttura di un server per servire N domini. Come ordine di grandezza, i vantaggi economici possono emergere intorno a 10 domini; la gestione può diventare più impegnativa verso 200 domini, a seconda del carico. Alcuni operatori passano allora a un servizio gestito o suddividono i domini su più server secondo il profilo di reputazione.

Modello 3: multitenant gestito, acquistare o costruire

Molte agenzie scoprono che gestire internamente la posta multidominio richiede un impegno tecnico consistente, talvolta equivalente a un lavoro a tempo pieno, e che il personale costa più di un piano gestito. Nello scenario della fonte, TrekMail Agency costa $29 al mese, oppure $23.25/mo come equivalente mensile con fatturazione annuale, e prevede 1,000 domini, strumenti per la rotazione DKIM e la gestione SPF/DMARC, oltre a code in uscita per account. Queste non implicano isolamento per dominio né della reputazione IP. Verifica funzioni e condizioni attuali; il piano può evitare di scrivere configurazioni Postfix, non ogni attività amministrativa. Per il punto di pareggio, confronta il costo annuo del servizio con il valore delle ore tecniche necessarie, anche quando una sola ora di lavoro ha già un peso rilevante.

Postfix + Dovecot: lo stack di riferimento

Se gestisci direttamente il server, uno stack di riferimento nel 2026 è Postfix per il trasporto SMTP e Dovecot per l'accesso IMAP, l'archiviazione e la consegna LMTP. Gli esempi seguenti presuppongono Debian o Ubuntu LTS. I principi si possono adattare ad altre distribuzioni, ma i frammenti non sono una configurazione completa e vanno verificati rispetto alle versioni installate.

virtual_mailbox_domains e i file delle mappe

Postfix supporta i domini virtuali tramite la direttiva virtual_mailbox_domains. Invece di inserire i domini direttamente in main.cf, puoi conservarli in una mappa hash oppure, su scala maggiore, in un backend SQL o LDAP:

# /etc/postfix/main.cf
virtual_mailbox_domains = hash:/etc/postfix/vhosts
virtual_mailbox_maps    = hash:/etc/postfix/vmailbox
virtual_alias_maps      = hash:/etc/postfix/valias
virtual_transport       = lmtp:unix:private/dovecot-lmtp

Il file /etc/postfix/vhosts elenca i domini per i quali il server accetta posta, uno per riga nel formato della mappa hash: dominio come chiave e un valore appropriato, non un elenco di soli nomi. In questo esempio con consegna LMTP, /etc/postfix/vmailbox serve a verificare l'esistenza dei destinatari: il valore della mappa non determina il percorso effettivo di consegna, gestito da Dovecot. Il file /etc/postfix/valias gestisce gli alias, per esempio info@client1.com → real-person@client1.com.

Struttura delle directory multitenant in Dovecot

Dovecot può conservare le caselle in directory separate per dominio. Una struttura convenzionale è /var/vmail/<domain>/<user>/. Un esempio di configurazione è:

# /etc/dovecot/conf.d/10-mail.conf
mail_location = maildir:/var/vmail/%d/%n
mail_uid = vmail
mail_gid = vmail

%d rappresenta la parte del dominio e %n la parte locale dell'indirizzo. Conservare la posta di ogni utente sotto il relativo dominio semplifica backup e operazioni per cliente: puoi copiare con rsync i dati di un cliente senza selezionare quelli degli altri. Le directory separate, da sole, non costituiscono però una barriera di sicurezza; servono anche controlli di autenticazione, autorizzazione e accesso ai file.

LMTP per il passaggio da Postfix a Dovecot

Gli stack moderni usano spesso LMTP, Local Mail Transfer Protocol, per passare i messaggi da Postfix a Dovecot. Rispetto all'avvio di dovecot-deliver per ciascun messaggio, può ridurre il lavoro di creazione dei processi e permette di applicare le quote per destinatario se configurate. Dovecot deve ascoltare su un socket Unix accessibile a Postfix, con permessi adeguati.

SPF, DKIM e DMARC per dominio su larga scala

La parte più impegnativa non è necessariamente il trasporto, che Postfix gestisce da tempo. È mantenere corretti SPF, DKIM e DMARC per tutti i clienti e gestire il ciclo di vita delle chiavi DKIM in modo da limitare l'esposizione in caso di compromissione. Questa attività può assorbire molto lavoro nei sistemi autogestiti ed è uno degli aspetti da valutare in un servizio come TrekMail Agency.

SPF per dominio

Ogni dominio usato nell'identità SMTP cui si applica SPF deve avere una policy adeguata alle proprie sorgenti di invio. I record risiedono nel DNS dei domini, non nel server. Quando aggiungi un IP in uscita, aggiorna le policy dei domini interessati se autorizzano direttamente quell'IP; con un include correttamente gestito potrebbe bastare aggiornare la policy richiamata. Non è quindi sempre necessario modificare tutti i clienti. La modifica passa spesso dal loro fornitore DNS, al quale potresti non avere accesso. La procedura completa è nella nostra guida alla configurazione SPF.

DKIM per dominio e rotazione trimestrale

Su larga scala, DKIM può rendere costosa la gestione autonoma. Ogni dominio usa una propria coppia di chiavi: la privata firma i messaggi, la pubblica è nel DNS sotto un selettore specifico. Una rotazione trimestrale è una possibile policy, non un obbligo universale. Se la scegli, occorre pubblicare un nuovo selettore per ogni dominio ogni trimestre, verificarne la disponibilità e mantenere la vecchia chiave pubblica quanto necessario prima di rimuoverla. Per 100 domini, l'esempio comporta 400 aggiornamenti DNS all'anno se svolti manualmente. La guida alla configurazione DKIM illustra la procedura.

Report DMARC su larga scala

Gestire DMARC per dominio significa attribuire al cliente corretto i report aggregati, spesso file XML con cadenza giornaliera inviati dai destinatari che supportano e applicano il reporting. Non tutti i sistemi riceventi li inviano, né è garantita una cadenza identica. Analizzarli e ricavarne indicazioni utili, come un possibile spoofing o un mittente configurato male, può diventare un progetto tecnico a sé. La guida alla configurazione DMARC tratta l'analisi dei report.

Tre problemi di isolamento da prevedere

L'affidabilità del server multidominio dipende anche dall'isolamento dei clienti. Tre tipi di problema possono comprometterlo durante la crescita; spesso diventano visibili solo in seguito a un incidente. Prevedili in fase di progetto: intervenire mentre la consegna della posta è già in difficoltà è molto più complesso.

Problema 1: deterioramento della reputazione dell'IP condiviso

I clienti che inviano dallo stesso IP condividono parte del rischio reputazionale. Se uno avvia una campagna di contatto a freddo con liste poco curate, l'IP può essere segnalato e gli altri possono subire limitazioni presso Gmail o altri destinatari. Puoi assegnare IP distinti a clienti con esigenze giustificate, prevedendo riscaldamento e gestione della reputazione, oppure trattare l'abuso come un incidente che riguarda il pool. Ruotare IP per aggirare blocchi o controlli antispam non risolve la causa. Un solo cliente problematico può incidere sull'intera base di clienti che usa quel pool.

Problema 2: rallentamento dovuto alla coda condivisa

Quando la coda Postfix cresce, per esempio dopo una serie di risposte temporanee 4xx di un destinatario, anche gli invii degli altri clienti possono rallentare se le risorse sono condivise. Postfix permette limitazioni per destinazione, ma rimangono risorse globali da dimensionare. Con 50 domini, una newsletter da 500K messaggi di un cliente potrebbe ritardare per ore la posta transazionale degli altri, a seconda della configurazione e del carico.

Problema 3: autenticazione fra clienti diversi

Se il database di autenticazione Dovecot non distingue rigorosamente i domini, un utente del cliente A potrebbe essere confrontato con i dati del cliente B quando le parti locali coincidono. Occorre rendere consapevoli del dominio sia la validazione dei nomi sia le ricerche nel backend e l'autorizzazione. Impostare auth_username_format a %u, l'indirizzo completo, anziché a %n, la sola parte locale, può essere un elemento della soluzione per le versioni appropriate, non una correzione sufficiente da sola. Una riga di configurazione sbagliata può avere conseguenze gravi per gli utenti. L'analisi completa è nei rischi dell'hosting email multidominio.

Server autogestito o servizio gestito

La scelta fra acquistare e costruire dipende dal costo reale del tempo. Un server autogestito sembra economico contando solo VPS e banda; il risultato cambia aggiungendo le ore per ottimizzare Postfix, chiedere la rimozione dalle liste di blocco, ruotare chiavi DKIM e affrontare un possibile incidente di consegna alle 3 del mattino. Le tre soglie orientative seguenti aiutano il confronto, senza sostituire un preventivo concreto.

Negli scenari economici illustrati, il servizio gestito può essere conveniente a molte scale inferiori a 5,000 domini, ma contano carico, competenze e requisiti. Un'eccezione è la conformità che nessun fornitore disponibile soddisfa, per esempio la presenza fisica dei dati in una giurisdizione nella quale non opera. Anche in quel caso, spesso conviene ospitare direttamente il solo cliente con quel requisito e usare il servizio gestito per gli altri, invece di mantenere l'intero stack.

Che cosa offre concretamente il multitenant gestito

Un servizio gestito può evitarti di costruire quattro gruppi di strumenti: rotazione delle chiavi DKIM per dominio con tracciamento delle operazioni; procedure guidate SPF/DMARC e integrazioni DNS, se supportate e autorizzate; riscaldamento del pool IP e monitoraggio della reputazione; analisi dei report DMARC aggregati con segnali leggibili invece del solo XML. Ciascun gruppo può richiedere mesi di sviluppo interno. La fonte li presenta fra le funzioni di TrekMail Agency: verifica quali siano effettivamente disponibili e quali attività restino a tuo carico, senza presumere che una procedura guidata pubblichi automaticamente il DNS.

Confronto dei servizi multidominio gestiti

Se scegli di acquistare, fra i servizi da confrontare ci sono TrekMail, Migadu e Workspace per organizzazioni più grandi. Hanno modelli differenti. L'esempio seguente considera 50 domini clienti con circa ~10 caselle ciascuno, per 500 caselle totali: un possibile profilo di agenzia media. Prezzi e caratteristiche sono ipotesi riportate dalla fonte, non un listino attuale verificato. Per Workspace, aggiungere domini a un'organizzazione non crea automaticamente clienti isolati: verifica controllo dei domini e separazione amministrativa e dei dati.

Con queste ipotesi, TrekMail Agency risulterebbe circa 13× meno costoso del modello per dominio attribuito a Migadu e 240× meno costoso del modello per utente attribuito a Workspace. Sono rapporti illustrativi, non una prova universale di convenienza: il modello di fatturazione Migadu e le condizioni di tutti i piani vanno verificati. Il confronto fra pool IP condiviso e IP dedicati per dominio dipende dall'offerta reale e dal profilo di invio. Un IP dedicato può aiutare a separare la reputazione, ma richiede gestione e riscaldamento e non garantisce la consegna in posta in arrivo.

Quando conviene davvero gestire direttamente il server multidominio

Negli esempi precedenti il servizio gestito tende a essere conveniente. Ci sono però tre scenari in cui l'autogestione può avere senso nonostante l'impegno operativo. Riconoscere le eccezioni è importante quanto conoscere l'opzione abituale.

Primo scenario: requisiti normativi che nessun fornitore valutato soddisfa. Se i dati di un cliente devono restare fisicamente in una giurisdizione nella quale TrekMail, Migadu e le suite cloud considerate non operano, può essere necessario un sistema autogestito. Il costo operativo resta reale. Molte agenzie scelgono allora un modello ibrido: gestione diretta per quel cliente, servizio gestito per gli altri. Non serve necessariamente mantenere tutto lo stack per una sola eccezione.

Secondo scenario: IP dedicati per cliente con requisiti di invio non coperti dalle offerte disponibili. Alcuni operatori di newsletter ad alto volume o servizi transazionali possono avere un'esigenza concreta di separazione della reputazione. Molti piani multitenant usano pool condivisi, ma occorre controllare le alternative effettive. Se il profilo giustifica IP dedicati e un riscaldamento disciplinato, un VPS con IP separati per profilo reputazionale può essere adatto. Non è una necessità automatica: molti clienti che chiedono un IP dedicato non hanno un volume o un modello di invio che lo renda opportuno.

Terzo scenario: competenze interne già utilizzate per altre attività. Se hai già un tecnico della posta per ragioni indipendenti, il costo marginale di aggiungere la gestione multidominio potrebbe essere contenuto. Le ore non diventano però gratuite: verifica carico disponibile, reperibilità e costo opportunità prima di considerarle già assorbite.

Rafforzare la sicurezza del server di posta multidominio

Un server multidominio è un bersaglio prezioso: la sua compromissione può dare controllo sui flussi di posta di tutti i clienti ospitati. La lista seguente privilegia controlli che riducono concretamente il rischio rispetto a misure solo appariscenti, senza presentarsi come una garanzia di sicurezza.

La submission SMTP autenticata va offerta sulla porta 587 con STARTTLS oppure sulla 465 con TLS implicito, richiedendo una connessione TLS valida prima dell'autenticazione ed evitando credenziali in chiaro. La porta 25 rimane aperta per la posta in ingresso dagli altri server. Deve impedire relay non autorizzati e usi impropri come submission, non respingere indiscriminatamente la posta locale verso destinatari locali, che può essere legittima. Una configurazione che lascia la porta 25 come scorciatoia per invii non autorizzati amplia il rischio.

I limiti di invio per cliente possono ridurre il danno alla reputazione IP causato da una casella compromessa in 20 minuti, non impedirlo con certezza. Dimensiona limiti per casella e per ora, oltre a limiti per account e per giorno, sui comportamenti reali. Senza controlli, una password rubata potrebbe consentire 100K messaggi indesiderati prima dell'intervento del monitoraggio, secondo lo scenario illustrato. La fonte cita limiti TrekMail come 1,000 messaggi per casella al giorno e 6,000 per account al giorno su Starter, oppure 50 messaggi all'ora tramite submission SMTP su Nano. Verifica i valori attuali: sono lo stesso tipo di controllo da predisporre in uno stack Postfix autogestito, non una protezione completa.

Gli accessi amministrativi richiedono password robuste e 2FA. Anche la 2FA delle singole caselle resta importante: una casella compromessa può esporre dati e consentire il recupero di altri account. La 2FA amministrativa protegge un accesso con un raggio d'azione ancora più ampio, che può compromettere l'isolamento di tutti i clienti. Applica l'autenticazione aggiuntiva dove supportata e credenziali specifiche per le applicazioni IMAP quando previste, senza trascurare nessuno dei due livelli.

Lista operativa per gestire un server di posta multidominio

Se scegli l'autogestione, le attività giornaliere e settimanali contano quanto la configurazione iniziale. Postfix e Dovecot possono funzionare a lungo con una buona configurazione, aggiornamenti e manutenzione; è la disciplina operativa a mantenere affidabile lo stack multitenant. Ecco una lista concreta da adattare al contesto.

Ogni giorno: controlla la profondità della coda e il ritmo di invio per cliente. Un aumento improvviso a 10× il livello abituale può indicare una campagna o una compromissione: in entrambi i casi va esaminato. Controlla gli IP in uscita nelle liste di blocco con MX Toolbox o strumenti equivalenti. Verifica il completamento dei cron notturni, come rotazione dei log, acquisizione dei report DMARC e rotazione dei backup.

Ogni settimana: esamina i report DMARC aggregati disponibili per i domini dei clienti. Nuovi strumenti di newsletter, pagamenti o vendite possono aggiungere mittenti da autorizzare correttamente mediante SPF e DKIM, secondo l'identità usata. Controlla la crescita dello spazio per cliente: caselle oltre 30 GB, nello scenario di un piano tipico, possono richiedere una policy di archiviazione o una revisione del piano. Esamina i contatori delle connessioni IMAP Dovecot per cliente: avvicinarsi al limite configurato può causare sincronizzazioni intermittenti e richieste di assistenza.

Ogni trimestre: se la tua policy prevede questa cadenza, ruota le chiavi DKIM dei domini. La procedura illustrativa pubblica il nuovo selettore nel DNS del cliente, attende 48 ore, aggiorna la firma Postfix e mantiene il vecchio selettore per altre 48 ore prima di rimuoverlo. Questi intervalli non garantiscono la propagazione: verifica TTL, disponibilità del nuovo record e messaggi ancora in transito, prolungando la sovrapposizione se necessario. Con 100 domini, la fonte stima 8-12 ore di lavoro per trimestre e circa 40 ore all'anno per la sola gestione DKIM. Un piano come TrekMail Agency può automatizzarne una parte, secondo le funzioni effettivamente disponibili; la rotazione protegge le chiavi, non ripara da sola la reputazione.

Ogni anno: riesamina la gestione dei certificati SSL/TLS per SMTP e IMAP, esegui una verifica completa dei backup ripristinando la posta di un cliente in un'istanza Dovecot pulita e controlla i backend di autenticazione. La fonte usa certificati Let's Encrypt da 90 giorni come esempio; durata attuale e rinnovo automatico vanno verificati e monitorati durante l'anno, non solo in questa revisione. Possono restare necessari interventi manuali. Nei backend Dovecot possono accumularsi utenti obsoleti, come quelli di ex clienti i cui domini non sono più in Postfix ma che risultano ancora autorizzati ad autenticarsi.

Prossimi passi

Gestire direttamente un server multidominio è fattibile, ma può essere impegnativo. Postfix e Dovecot sono componenti consolidati; rotazione DKIM per dominio e analisi DMARC possono assorbire settimane di lavoro all'anno. Per molte agenzie il servizio gestito può convenire, purché il confronto includa requisiti, carico e attività che restano al cliente.

Nella fonte, TrekMail Agency costa $29 al mese, $23.25 come equivalente mensile con pagamento annuale, e prevede 1,000 domini × 1,000 caselle per dominio, 200 GB di spazio condiviso fra email e TrekMail Drive, strumenti di rotazione DKIM per dominio, editor Sieve per filtri personalizzati, assistenza dedicata, 100 alias per casella e importazione in blocco di 50 domini clienti mediante un CSV. Verifica disponibilità, quote e condizioni attuali: questi numeri non garantiscono che ogni combinazione sia sostenibile nello spazio incluso. La prova gratuita di 14 giorni richiede una carta, secondo la fonte. Il livello Nano gratuito, senza carta né periodo di prova nella descrizione originaria, prevede 10 domini × 10 caselle per esplorare il pannello prima di scegliere Agency. Per i rischi specifici dei domini, consulta anche la nostra guida all'hosting email multidominio. Confronto dei piani e prezzi attuali sono su trekmail.net/pricing.