1,352 25/03/2026 07/04/2026 8 min

Introduzione

Quando una mail parte ma finisce in spam, il problema raramente è solo il contenuto. Spesso manca una catena coerente tra DNS, firma, policy e comportamento del server SMTP.

Qui vediamo una configurazione da produzione per un server Linux con Postfix, opendkim e una sandbox di test separata. L’obiettivo è semplice: invii tracciabili, autenticazione allineata e coda controllata prima che i messaggi escano davvero verso i destinatari reali.

Note: l’esempio usa provider DNS generico e un relay SMTP dedicato. Se usi un servizio esterno per l’invio, i principi restano identici. Cambiano solo i record e il punto di uscita.

Prerequisiti

  • Un dominio gestito da te, con accesso ai record DNS.
  • Un server Linux con Postfix già installato.
  • Un utente root o privilegi sudo.
  • Un hostname completo, ad esempio mail.example.com.
  • Accesso ai log di sistema e alla coda mail.
  • Una casella sandbox, meglio se su un dominio separato.

Warning: non fare il primo invio di produzione direttamente da un IP nuovo con reputazione zero. Prima verifica che PTR, HELO, SPF, DKIM e DMARC siano allineati.

Step 1: definire il flusso SMTP prima di toccare i record DNS

La deliverability parte dal percorso di uscita. Devi sapere chi invia, da quale hostname, con quale IP e con quale identità nel dominio.

Su Postfix, imposta un nome coerente con il PTR dell’IP pubblico. Un mismatch tra reverse DNS e hostname rompe subito la fiducia dei filtri antispam.

postconf -e "myhostname = mail.example.com"
postconf -e "myorigin = example.com"
postconf -e "smtp_banner = $myhostname ESMTP"
postfix reload

# Output: Postfix ricaricato senza errori e banner SMTP coerente con mail.example.com

Controlla anche il reverse DNS presso il provider VPS o il cloud. Il PTR deve puntare all’host reale che invia la posta.

Note: se il server invia solo notifiche applicative, separa il dominio di invio da quello principale. Ad esempio mail.example.com per il servizio e example.com per il brand.

Step 2: pubblicare SPF con un solo punto di uscita

SPF dice quali server possono spedire per il dominio. È una allowlist. Se l’elenco è confuso, i destinatari vedono un rischio inutile.

Per una produzione pulita, evita record lunghi e duplicati. Mantieni un solo record SPF per dominio e includi solo i servizi realmente usati.

example.com. 3600 IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.mailprovider.net -all"

# Output: Record SPF pubblicato con un solo IP autorizzato e policy finale -all

Se il server invia da più IP, elencali tutti. Se usi un relay esterno, verifica il loro include ufficiale e non copiare stringhe trovate in vecchi ticket.

Warning: non usare ~all come soluzione permanente. È tollerante, ma in produzione lascia troppo margine a invii non autorizzati.

Step 3: configurare DKIM con chiave separata per ambiente

DKIM firma il messaggio e permette al destinatario di verificare che il contenuto non sia stato alterato. In produzione, la chiave privata deve stare solo sul server che firma.

Con opendkim, crea una coppia di chiavi dedicata. Usa un selettore chiaro, così puoi ruotarla senza interrompere tutto.

mkdir -p /etc/opendkim/keys/example.com
opendkim-genkey -b 2048 -d example.com -s s2026 -D /etc/opendkim/keys/example.com
chown -R opendkim:opendkim /etc/opendkim/keys/example.com
chmod 600 /etc/opendkim/keys/example.com/s2026.private

# Output: Chiave DKIM generata con selettore s2026 e permessi restrittivi sulla private key

Pubblica il record DNS generato dal file s2026.txt. Il nome deve essere del tipo s2026._domainkey.example.com.

Un esempio di configurazione minima di firma:

Domain example.com
Selector s2026
KeyFile /etc/opendkim/keys/example.com/s2026.private
Socket local:/run/opendkim/opendkim.sock
Mode sv
Canonicalization relaxed/relaxed

# Output: opendkim pronto a firmare con canonicalizzazione relaxed/relaxed

Note: relaxed/relaxed è spesso la scelta più robusta in ambienti reali. Riduce i falsi negativi causati da riscritture minori di header e body.

Step 4: allineare Postfix e opendkim senza esporre socket o permessi

Il punto delicato è il collegamento tra MTA e signer. Il socket locale deve essere accessibile solo ai processi corretti. Non aprire porte inutili.

Su un sistema con systemd, verifica che il servizio opendkim parta prima o insieme a Postfix. Poi collega il miltersocket in modo esplicito.

postconf -e "milter_default_action = accept"
postconf -e "milter_protocol = 6"
postconf -e "smtpd_milters = local:/run/opendkim/opendkim.sock"
postconf -e "non_smtpd_milters = $smtpd_milters"
postfix reload
systemctl restart opendkim

# Output: Postfix usa il socket locale di opendkim e i messaggi in uscita vengono firmati

Fai attenzione ai permessi della directory /run/opendkim. Se il socket non è leggibile da Postfix, la firma salta e la mail esce senza DKIM.

Warning: un milter_default_action = tempfail può bloccare il traffico se opendkim cade. In produzione è più sicuro partire con accept, poi rafforzare dopo il monitoraggio.

Step 5: scrivere DMARC per osservare prima e applicare dopo

DMARC collega SPF e DKIM al dominio visibile nel messaggio. È la policy che decide cosa fare quando l’allineamento fallisce.

Per il primo rilascio usa p=none. Ti serve osservabilità, non enforcement immediato. Poi alzi la policy quando i report mostrano che tutto è stabile.

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com; adkim=s; aspf=s; fo=1; pct=100"

# Output: DMARC pubblicato in modalità monitoraggio con allineamento stretto

Note: adkim=s e aspf=s richiedono allineamento stretto. È utile quando vuoi evitare sottodomini usati in modo disordinato.

Se il tuo ecosistema è ancora in assestamento, puoi iniziare con allineamento rilassato. L’importante è decidere una strategia e non cambiare parametri ogni settimana.

Step 6: testare gli header in sandbox, non in inbox reale

Il test migliore è quello che non rovina la reputazione. Usa una sandbox dedicata, ad esempio una casella su un dominio di staging o un servizio di test SMTP.

Invia un messaggio con header chiari. Devi poter leggere Received, Authentication-Results, DKIM-Signature e Message-ID.

swaks --to test@sandbox.example.net \
  --from noreply@example.com \
  --server 127.0.0.1 \
  --header "Subject: DKIM test 2026-03" \
  --body "Test deliverability from production-like setup"

# Output: 250 2.0.0 Ok: queued as ... e messaggio ricevuto nella sandbox

Dopo la consegna, apri gli header completi. Cerca righe simili a queste:

Authentication-Results: sandbox.example.net;
 spf=pass smtp.mailfrom=example.com;
 dkim=pass header.d=example.com;
 dmarc=pass header.from=example.com

Se uno dei tre esiti fallisce, fermati. Non è il momento di aumentare il volume. È il momento di correggere l’allineamento.

Step 7: controllare la queue prima che diventi un problema di reputazione

La coda mail è il primo indicatore operativo. Se si riempie, spesso il server sta tentando di inviare verso un host lento o rifiutando per policy temporanee.

In produzione, la queue va osservata con una frequenza fissa. Non aspettare il ticket del reparto commerciale.

mailq
postqueue -p
postqueue -f

# Output: Coda vuota o in diminuzione dopo il flush, senza batch bloccati

Per un controllo più utile, automatizza una soglia. Ad esempio, segnala se la queue supera 200 messaggi o se un singolo destinatario genera troppi deferred.

postqueue -p | awk '/^[A-F0-9]/ {count++} END {print count+0}'

# Output: Numero di messaggi presenti in coda

Warning: una queue alta non significa sempre colpa del tuo server. Può essere il destinatario che risponde con 4xx temporanei. La differenza la fanno i log e il motivo del deferred.

Step 8: leggere i log e capire i fallimenti reali

La deliverability si diagnostica sui log, non sulle impressioni. Cerca il codice SMTP, il relay usato e l’eventuale motivo di rifiuto.

Su sistemi con journald, la lettura diretta è rapida. Filtra per postfix e per il messaggio specifico.

journalctl -u postfix -u opendkim --since "30 min ago" | tail -n 80

# Output: Log recenti con eventuali 4xx, 5xx, problemi di firma o code deferred

Se vedi status=sent ma il messaggio non arriva, il problema è spesso fuori dal tuo server. A quel punto servono header completi, reputazione IP e controlli sul destinatario.

Verifica finale

La verifica finale deve chiudere il cerchio. Non basta che la mail parta. Deve autenticarsi, arrivare in sandbox e mostrare coerenza tra DNS e header.

  • Il PTR dell’IP coincide con il nome del server.
  • SPF contiene solo i mittenti autorizzati.
  • DKIM firma con chiave privata locale e selector stabile.
  • DMARC riceve report e parte da policy osservativa.
  • I messaggi in sandbox mostrano spf=pass, dkim=pass e dmarc=pass.
  • La queue resta sotto soglia e non accumula deferred inutili.

Per un controllo rapido, invia una mail di prova a una casella che mostri gli header completi. Se vuoi essere più rigoroso, conserva un campione di header per ogni release del server mail.

Troubleshooting

Errore 1: 454 4.7.1 Temporary authentication failure

Causa: il milter non risponde o il socket DKIM non è accessibile da Postfix.

Fix:

ls -l /run/opendkim/opendkim.sock
systemctl restart opendkim postfix
postconf -n | grep -i milter

# Output: Socket presente, servizi riavviati e milter configurato correttamente

Errore 2: 550 5.7.23 SPF validation failed

Causa: il record SPF non include l’IP reale di uscita oppure ci sono più record TXT SPF.

Fix:

dig +short TXT example.com

# Output: Un solo record SPF visibile e coerente con l’IP che invia

Errore 3: dmarc=fail reason=alignment

Causa: il dominio nel From: non coincide con quello usato da SPF o DKIM.

Fix:

postcat -q QUEUEID | sed -n '1,40p'

# Output: Header From e domini firmati verificati sul messaggio in coda

Note: se l’allineamento fallisce solo per alcuni messaggi, spesso il problema sta nell’applicazione che genera email diverse, non nel MTA.

Conclusione

Una buona deliverability non nasce da un singolo record DNS. Nasce da coerenza tra infrastruttura, firma, policy e controllo della coda.

Se vuoi portarla a livello produzione vero, il prossimo passo concreto è attivare i report DMARC, salvare gli header di ogni test e automatizzare un controllo giornaliero della queue.

RFC 7208 SPF e RFC 6376 DKIM restano le basi. In pratica, però, vince chi li applica con disciplina operativa e monitoraggio continuo.