Come configurare un server SMTP su Linux

Postfix come base: perché partire da qui

Se devi mettere in piedi un server SMTP su Linux, la scelta più lineare è quasi sempre Postfix. Non perché sia l’unico MTA valido, ma perché è stabile, leggibile e si presta bene a una configurazione minimale che puoi poi estendere con TLS, SASL, filtri antispam e integrazione con Dovecot o altri servizi. L’obiettivo non è “far inviare mail” e basta: l’obiettivo è esporre un servizio che accetti solo ciò che deve accettare, che non diventi un open relay e che lasci abbastanza tracce nei log da capire subito dove si rompe qualcosa.

In pratica devi decidere subito tre cose: chi può inviare, da dove può inviare e con quale identità. Se salti questi passaggi, ti ritrovi con un SMTP che funziona in laboratorio ma viene bocciato dai provider esterni o, peggio, abusato come relay. Qui sotto imposto un flusso tipico per un server Linux recente con Postfix come MTA, certificati TLS validi e autenticazione per i client che devono inviare posta in uscita.

1. Requisiti minimi e scelta del perimetro

Prima di toccare i pacchetti, verifica che il server abbia un nome host coerente con il dominio email e che il DNS sia già impostato. Un SMTP senza FQDN sensato o senza record corretti finisce spesso in spam o viene rifiutato in fase di handshake. Servono almeno:

Checklist iniziale: un hostname completo, un record A/AAAA valido, un record MX, SPF di base e un certificato TLS con CN/SAN coerente col nome usato dai client.

Se stai configurando un server per applicazioni interne o per invio autenticato da client, il disegno cambia poco: il punto non è aprire la porta 25 a chiunque, ma offrire submission su 587 con autenticazione e TLS, lasciando la 25 per la posta server-to-server. Questo separa bene i ruoli e riduce gli errori operativi.

2. Installazione dei pacchetti essenziali

Su Debian/Ubuntu puoi partire così; su altre distribuzioni i nomi cambiano poco, ma la logica resta identica. Installa Postfix e, se ti serve autenticazione SASL tramite Dovecot, prepara anche il relativo pacchetto. Per i test iniziali conviene avere a bordo anche gli strumenti base di diagnostica.

sudo apt update
sudo apt install postfix mailutils ca-certificates openssl

Durante il wizard di Postfix, la scelta più comune è “Internet Site” se il server deve ricevere e inoltrare posta direttamente, oppure “Satellite system” se tutto deve uscire tramite un relay esterno. Se hai dubbi, non improvvisare: un relay mal definito è il modo più rapido per produrre code bloccate o bounce incomprensibili.

Dopo l’installazione, verifica che il servizio sia attivo e che ascolti sulle porte attese:

systemctl status postfix --no-pager
ss -ltnp | grep -E ':(25|587)\b'

Se non vedi la porta 25, non saltare alle conclusioni: controlla prima la configurazione di `master.cf` e il firewall locale.

3. Configurazione di base di Postfix

Il file centrale è `

/etc/postfix/main.cf

Qui definisci identità, rete di ascolto, domini locali e regole di inoltro. Una configurazione di partenza ragionevole, da adattare al tuo dominio, può essere questa:

myhostname = mail.example.com
mydomain = example.com
myorigin = $mydomain
inet_interfaces = all
inet_protocols = all
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
mynetworks = 127.0.0.0/8 [::1]/128
home_mailbox = Maildir/

La direttiva `mydestination` merita attenzione: se metti dentro domini che non devi gestire localmente, Postfix proverà a trattarli come local delivery invece di inoltrarli correttamente. Per un server SMTP puro di invio, spesso questa lista va tenuta molto stretta. Se il server riceve anche posta locale, allora ha senso includere il dominio principale.

Per testare la sintassi senza rischiare di riavviare al buio:

sudo postfix check
sudo postconf -n

`postconf -n` è utile perché mostra solo le impostazioni non di default. Se il risultato è troppo scarno, hai probabilmente toccato poco; se è confuso, hai già troppi override e conviene ripulire prima di andare avanti.

4. TLS: cifrare il trasporto senza rompere il flusso

Il TLS non è un optional decorativo. Su SMTP moderno serve almeno per la submission autenticata, e spesso anche sul canale server-to-server quando il peer lo supporta. La regola pratica è semplice: certificato valido, chiavi con permessi corretti e nessun compromesso sul controllo del nome host.

Supponiamo che il certificato sia gestito da Let’s Encrypt o da una CA interna. Nel `main.cf` imposta i riferimenti ai file reali:

smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem
smtpd_tls_security_level = may
smtpd_tls_loglevel = 1
smtp_tls_security_level = may

Il livello `may` è spesso il punto di partenza giusto: abilita TLS quando disponibile senza bloccare tutto il traffico in caso di peer vecchi o mal configurati. Se il server serve solo client moderni e vuoi imporre cifratura sulla submission, puoi alzare il livello in `master.cf` sulla porta 587, non per forza globalmente.

Controlla i permessi del materiale TLS. La chiave privata non deve essere leggibile da utenti non autorizzati. Dopo il rinnovo del certificato, verifica che Postfix rilegga i file corretti senza puntare a path scaduti. Un errore classico è lasciare il servizio con un certificato vecchio mentre il renewal è già passato: lato client sembra tutto “quasi” funzionante, ma la fiducia del certificato cade.

5. Submission su 587 e autenticazione client

Per gli utenti o le applicazioni che devono inviare email, la porta da usare non è la 25 ma la 587. Qui entrano in gioco autenticazione e autorizzazione. Se hai Dovecot come provider SASL, puoi appoggiarti a lui senza reinventare meccanismi di login. In Postfix il blocco tipico in `master.cf` abilita la submission e forza alcune policy più strette rispetto al canale SMTP standard.

submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject

Questo è il punto dove si evitano gli open relay. La logica deve essere inequivocabile: o l’utente è autenticato, o la sessione viene rifiutata. Se devi permettere invio da una subnet interna senza login, fallo in modo esplicito e limitato, non allargando `mynetworks` in modo indiscriminato.

Se usi Dovecot per l’autenticazione, la parte di integrazione va tipicamente in due file: un socket SASL esposto da Dovecot e i parametri Postfix per puntarci. La configurazione può variare a seconda della distro, ma il principio resta lo stesso: Postfix delega il controllo credenziali a un backend dedicato, invece di gestire account locali sparsi.

Un controllo rapido è vedere se la porta 587 risponde e se il banner TLS è coerente:

openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com

Se il certificato non combacia con il nome usato nel test, hai un problema di identità, non di Postfix. In quel caso correggi il DNS o il certificato, non il sintomo.

6. DNS: SPF, DKIM, DMARC e reverse DNS

Un SMTP che invia mail senza DNS coerente è destinato a finire in coda spam o a essere rifiutato da provider severi. Il minimo sindacale è che il record MX punti al server giusto, che il reverse DNS del suo IP pubblico torni sullo stesso hostname e che SPF descriva chi è autorizzato a spedire per il dominio.

Per SPF una forma semplice può essere:

example.com. IN TXT "v=spf1 ip4:203.0.113.10 -all"

Se il server firma la posta con DKIM, aggiungi un selettore e pubblica la chiave pubblica nel DNS. Il punto qui non è solo “mettere la firma”, ma mantenere la corrispondenza tra chiave privata, selettore e record DNS. Una rotazione fatta male rompe la deliverability in silenzio: il messaggio parte, ma il destinatario lo degrada o lo rifiuta.

DMARC completa il quadro e ti dà segnalazioni utili, soprattutto se imposti una policy inizialmente prudente. Non partire subito con `reject` se non hai telemetria: meglio osservare i report e capire se esistono altri sistemi che inviano per conto del dominio.

7. Firewall e porti realmente necessari

Apri solo ciò che serve davvero. Per un setup standard: 25 per SMTP tra server, 587 per submission autenticata, eventualmente 465 se hai client legacy che richiedono SMTPS implicito. Evita di esporre altre superfici senza motivo.

sudo ufw allow 25/tcp
sudo ufw allow 587/tcp
sudo ufw status verbose

Se usi `firewalld`, la logica è equivalente. Il controllo da fare non è solo “la porta è aperta”, ma “il servizio risponde dal segmento giusto”. Un firewall troppo permissivo compensa male un `mynetworks` sbagliato; uno troppo restrittivo ti farà perdere tempo sui falsi negativi. Prima verifica il listener, poi la policy di rete, poi l’eventuale NAT o security group del cloud.

8. Test funzionali: invio locale, relay e log

Prima di dichiarare il lavoro finito, fai tre test distinti: invio locale, invio autenticato via 587 e consegna verso un destinatario esterno. Non basta che il comando ritorni “queued”: devi seguire la coda e i log fino alla consegna o al bounce.

echo "Test SMTP" | mail -s "SMTP check" postmaster@example.com
mailq
sudo tail -f /var/log/mail.log

Su sistemi con journald, il path può essere diverso e i log possono stare nel journal invece che in `

/var/log/mail.log

`. In quel caso usa:

journalctl -u postfix -f

Se vedi messaggi come “connect to mx… timed out”, il problema è a valle di Postfix: DNS, routing, firewall o reputazione del server remoto. Se invece ricevi “relay access denied”, la policy di submission o `mynetworks` non è coerente con il tipo di invio che stai tentando.

9. Integrazione con Dovecot o Maildir per le caselle locali

Se il server non deve solo spedire ma anche consegnare posta a caselle locali, Maildir è una scelta pratica perché si integra bene con IMAP e riduce alcuni problemi di locking. Lato Postfix basta impostare `home_mailbox = Maildir/` e far sì che il sistema utente abbia la struttura corretta.

mkdir -p /home/utente/Maildir/{cur,new,tmp}
chown -R utente:utente /home/utente/Maildir

Se usi Dovecot per IMAP/POP3, assicurati che la directory Maildir sia quella attesa e che i permessi non consentano letture indesiderate. Qui l’errore tipico non è tecnico ma operativo: Postfix consegna, Dovecot legge da un altro path, e l’utente vede la casella vuota.

10. Hardening minimo senza complicare il mantenimento

Un server SMTP esposto su Internet va trattato come servizio sensibile. Disabilita ciò che non usi, limita i domini locali, tieni aggiornati i pacchetti e controlla periodicamente i log di autenticazione. Se il server accetta login, il rischio non è solo brute force: è anche abuso di credenziali già compromesse altrove.

Misure sensate e poco invasive:

• forzare TLS sulla submission;
• limitare l’invio autenticato ai soli account necessari;
• abilitare rate limit o protezioni lato fail2ban se i log mostrano attacchi ripetuti;
• tenere separati gli account applicativi dagli account umani;
• verificare periodicamente SPF, DKIM e DMARC dopo ogni modifica DNS.

Se il server è in cloud, controlla anche i security group o le ACL del provider. È frequente che il problema non sia Postfix ma una regola di rete che blocca la 25 in uscita o in ingresso. In questi casi il sintomo è la coda in attesa e i timeout verso gli MX remoti.

11. Errori che si vedono spesso sul campo

Ci sono alcuni guasti ricorrenti che vale la pena riconoscere subito. Il primo è il certificato errato: hostname del server e nome nel certificato non coincidono, e i client moderni rifiutano la sessione o mostrano warning. Il secondo è l’open relay involontario, quasi sempre causato da `mynetworks` troppo ampio o da restrizioni SASL incomplete. Il terzo è il DNS incompleto: MX presente ma reverse assente, oppure SPF sbagliato rispetto all’IP realmente usato per spedire.

Un altro caso classico è il server che riceve ma non consegna. Qui il primo controllo non è “Postfix è in ascolto?” ma “la coda sta crescendo?” e “cosa dice il log della consegna?”. Se la coda resta piena, il problema può essere un MX remoto irraggiungibile, un firewall in uscita o una reputazione IP pessima. Non serve cambiare dieci parametri alla cieca: bisogna leggere il motivo preciso del defer.

12. Sequenza di validazione finale

Quando hai completato la configurazione, fai una validazione ordinata invece di fidarti del solo riavvio del servizio. La sequenza minima è questa:

1. verifica la sintassi con `postfix check`;
2. controlla i parametri effettivi con `postconf -n`;
3. conferma l’ascolto sulle porte con `ss -ltnp`;
4. prova il handshake TLS con `openssl s_client -starttls smtp`;
5. invia una mail di test e segui i log fino alla consegna;
6. controlla SPF/DKIM/DMARC da un dominio esterno o con strumenti di test dedicati.

Se uno di questi passaggi fallisce, non andare avanti. La regola pratica è correggere il primo punto rotto e ripetere il test, perché i problemi a cascata rendono il debug molto più lento.

13. Una configurazione tipo da cui partire

Per chiudere, ecco il profilo minimo che uso come base di partenza nei contesti semplici: Postfix come MTA, submission su 587 con TLS obbligatorio, autenticazione via SASL, DNS coerente, firewall stretto e log consultabili. È una base sobria, ma proprio per questo si mantiene bene nel tempo. Ogni requisito extra — antispam, aliasing complesso, relay condizionali, integrazione con più domini — va aggiunto dopo, non prima.

Se vuoi evitare sorprese, documenta almeno tre cose: chi può inviare, quale certificato è in uso e dove finiscono i log. Sono dettagli banali solo finché non devi recuperare un guasto alle tre di notte. A quel punto fanno la differenza tra un fix in pochi minuti e una caccia al problema tra DNS, policy di relay e file di configurazione sparsi.