51 06/04/2026 07/04/2026 10 min

Obiettivo operativo

Se hai un secondo server con PostfixAdmin, il punto non è solo far partire la posta, ma allineare identità del dominio, firma DKIM e policy DMARC senza rompere il flusso di consegna. La sequenza corretta è: preparare il DNS, generare le chiavi, pubblicare i record, attivare la firma lato MTA, poi validare con test reali e con i log.

Per evitare errori da laboratorio che poi diventano incidenti in produzione, conviene trattare la modifica come un change controllato: prima osservazione, poi attivazione, infine verifica. Se il dominio invia già mail da un altro server, l’introduzione del secondo nodo deve essere compatibile con il record SPF e con la gestione delle chiavi DKIM per ciascun dominio.

Architettura minima da avere chiara

SPF, DKIM e DMARC risolvono problemi diversi:

  • SPF dice quali IP sono autorizzati a spedire per un dominio.
  • DKIM firma il messaggio con una chiave privata sul server e pubblica la chiave pubblica nel DNS.
  • DMARC impone una policy e richiede allineamento tra From, SPF e/o DKIM.

Su un secondo server PostfixAdmin, il rischio tipico è questo: aggiungi un nuovo relay o una nuova macchina per l’uscita, ma dimentichi di aggiornare SPF; oppure attivi DKIM ma il selettore non è coerente; oppure imposti DMARC troppo aggressivo prima che tutti i mittenti legittimi siano allineati. Il risultato sono rimbalzi, quarantena o spam placement.

Assunzione di lavoro: il dominio è gestito da PostfixAdmin, il server usa Postfix come MTA e hai accesso ai record DNS del dominio. Se usi un pannello DNS separato, le modifiche vanno fatte lì, non nel solo PostfixAdmin.

Preparazione: cosa verificare prima di toccare DNS

Prima di cambiare qualsiasi record, raccogli questi dati:

  • IP pubblico del secondo server di invio.
  • Hostname SMTP usato in HELO/EHLO, ad esempio mail2.example.com.
  • Domini che invieranno posta da quel server.
  • Eventuali selettori DKIM già esistenti per gli stessi domini.

Controlla anche il TTL dei record DNS, perché se stai facendo un rollout graduale conviene abbassarlo prima del cambio. Per esempio, un TTL di 300 secondi è più gestibile di 3600 durante la fase di test.

Se il secondo server deve inviare per più domini, tieni separati i selettori DKIM e non riusare la stessa chiave per tutto senza motivo. Tecnicamente funziona, ma la rotazione e la diagnosi diventano più scomode.

SPF: autorizzare il nuovo server

Il record SPF va aggiornato nel DNS del dominio. Se il dominio già ha un record, non devi crearne un altro: va modificato quello esistente. Un dominio deve avere un solo record SPF.

Esempio concettuale:

v=spf1 ip4:203.0.113.10 ip4:203.0.113.20 include:_spf.provider.tld -all

Qui l’IP del secondo server è 203.0.113.20. Se usi un relay esterno, puoi avere anche un include, ma attenzione ai limiti di lookup DNS previsti da SPF. Se la catena è troppo complessa, rischi errori di permutazione e fallimenti di validazione.

Verifica rapida del record pubblicato:

dig +short TXT example.com

Atteso: una sola stringa SPF valida, con il nuovo IP presente. Se vedi due record SPF distinti, va corretto subito. Se il DNS è distribuito su più provider, controlla la zona effettivamente autorevole, non solo la copia locale.

Se il secondo server invia anche posta di sistema o notifiche applicative per più domini, valuta se conviene usare un sottodominio dedicato all’outbound, ad esempio mail.example.com, e un return-path coerente. Questo aiuta anche con DMARC e con il tracciamento dei bounce.

DKIM: chiave per il secondo server PostfixAdmin

Con PostfixAdmin il punto centrale è la disponibilità della chiave privata sul server e della chiave pubblica nel DNS. La modalità esatta dipende dall’integrazione che hai installato: opendkim, Rspamd, Amavis o altro. Il principio non cambia.

Se il tuo stack usa OpenDKIM, il flusso è questo:

  1. Generi una coppia di chiavi per dominio o per selettore.
  2. Pubblici la chiave pubblica nel DNS come record TXT.
  3. Configuri il server perché firmi i messaggi in uscita con la chiave privata.

Esempio di selettore:

mail._domainkey.example.com

Record DNS atteso:

mail._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

La chiave privata non va mai pubblicata e non va condivisa tra server se non hai una ragione operativa precisa. Se il secondo server deve firmare per lo stesso dominio del primo, puoi usare lo stesso selettore solo se sei certo che la chiave privata sia identica e gestita in modo coerente; in pratica, è più pulito usare un selettore dedicato al secondo nodo.

Con OpenDKIM, i punti da allineare sono quattro: mapping dominio-selettore, percorso della chiave privata, socket di firma verso Postfix e record DNS pubblicato. Se uno solo di questi non combacia, la firma fallisce o il messaggio passa senza firma.

Verifica utile lato server:

opendkim-testkey -d example.com -s mail -vvv

Atteso: chiave trovata, DNS leggibile, firma valida. Se il comando segnala che il record non esiste, il problema è DNS o selettore. Se segnala permessi negati sulla chiave privata, il problema è filesystem o ownership.

Se usi Rspamd al posto di OpenDKIM, il concetto resta identico: definisci la chiave privata per dominio o selettore, abiliti la firma in uscita, pubblichi il TXT nel DNS e verifichi che il messaggio esca con header DKIM-Signature. Cambiano i file e i path, non la logica.

DMARC: policy, allineamento e rollout graduale

DMARC non firma i messaggi: decide cosa fare quando SPF e/o DKIM non sono allineati con il dominio visibile nel campo From. Per questo motivo va introdotto dopo SPF e DKIM, non prima.

Per partire in modo sicuro, usa una policy di monitoraggio:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s"

Con p=none non blocchi la posta, ma ricevi i report aggregati. Questo ti permette di vedere se il secondo server, i servizi terzi o le app interne stanno inviando con identità non allineate. I parametri adkim=s e aspf=s impongono allineamento stretto; se vuoi una fase iniziale meno rigida, puoi partire con allineamento rilassato e stringere dopo aver verificato i mittenti.

Quando i report mostrano che tutto è allineato, puoi passare a una policy più severa:

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=25"

oppure, solo a regime:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Il rollout graduale con pct è utile se il dominio ha più sorgenti di posta, perché riduce il blast radius di una configurazione incompleta. Se noti mail legittime finite in spam o respinte, torna temporaneamente a p=none o abbassa pct mentre correggi l’allineamento.

Per la raccolta report, usa una mailbox dedicata e monitorata, ad esempio dmarc@example.com o un alias verso un sistema di analisi. Evita di usare una casella personale non presidiata, perché i report XML diventano presto rumore e perdi visibilità.

Configurazione lato Postfix sul secondo server

Una volta pronti DNS e chiavi, il secondo server deve effettivamente firmare i messaggi in uscita e presentarsi con un hostname coerente. In pratica, Postfix deve consegnare i messaggi al milter o al signer configurato e usare un myhostname sensato.

Controlli minimi da fare:

  • myhostname coerente con il nome pubblico del server.
  • Firma DKIM attiva per i domini coinvolti.
  • HELO/EHLO non generico o non interno.
  • Eventuale smtp_tls_security_level coerente se il server inoltra verso relay esterni.

Se il server è gestito da PostfixAdmin ma la firma è demandata a un componente esterno, il punto non è PostfixAdmin in sé: è la catena di consegna. Devi verificare che il messaggio generato dal dominio corretto passi nel flusso previsto e che non esca dal server senza firma.

Verifica utile lato coda e log:

postqueue -p
journalctl -u postfix -n 100 --no-pager

Atteso: nessun accumulo anomalo in coda e nessun errore ripetuto di milter, socket o permessi. Se vedi righe tipo firma non applicata, socket irraggiungibile o reject per policy, il problema è nel collegamento tra Postfix e il signer.

DNS completo: record da avere per un dominio

Per un dominio che invia dal secondo server, il quadro minimo è questo:

  • Record SPF nel dominio principale.
  • Record DKIM per ogni selettore usato.
  • Record DMARC su _dmarc.
  • Record MX solo se il server riceve anche posta, non solo se invia.
  • Record A/AAAA per l’hostname SMTP usato in HELO/EHLO.

Se il secondo server invia soltanto, non confondere il ruolo di outbound con quello di MX. Puoi avere un server di sola uscita senza esporlo come server di ricezione pubblica, purché il DNS e la rete siano coerenti con il flusso di invio.

Per controllare rapidamente la pubblicazione dei record:

dig +short TXT example.com
dig +short TXT mail._domainkey.example.com
dig +short TXT _dmarc.example.com

Atteso: SPF presente una sola volta, DKIM con chiave pubblica completa, DMARC con policy scelta. Se il record DKIM viene troncato o spezzato male, la firma non verrà validata dai destinatari.

Verifica end-to-end con una mail reale

Dopo la pubblicazione dei record e l’attivazione della firma, invia una mail di test verso una casella esterna che mostri gli header completi. L’obiettivo non è solo “arriva”, ma vedere SPF, DKIM e DMARC passare.

Controlla questi elementi negli header:

  • Received-SPF con esito pass o equivalente.
  • DKIM-Signature presente e validata.
  • Authentication-Results con dmarc=pass, se il destinatario lo espone.

Se hai accesso alla riga di comando sul server, puoi anche generare un test locale del record DKIM e controllare la risoluzione DNS, ma la verifica finale va fatta con un messaggio reale perché DMARC dipende dall’allineamento percepito dal destinatario.

Se la mail arriva ma finisce in spam, non fermarti al solo SPF pass: guarda allineamento, reputazione IP, HELO, reverse DNS, consistenza del From e presenza di firma DKIM valida. Un SPF pass senza DKIM o con DMARC non allineato non ti garantisce una buona deliverability.

Errori tipici sul secondo server

I problemi più frequenti sono sempre gli stessi:

  1. Record SPF duplicato invece di uno solo aggiornato.
  2. Chiave DKIM pubblicata con selettore sbagliato.
  3. Chiave privata non leggibile dal processo che firma.
  4. DMARC impostato su reject troppo presto.
  5. Hostname SMTP incoerente con il reverse DNS o con il nome del server.

Se qualcosa non torna, torna alla catena minima: DNS autorevole, chiave pubblica corretta, chiave privata presente, Postfix collegato al signer, messaggio di test con header verificabili. In pratica, non andare subito a cambiare tre componenti insieme: isola il layer che sta fallendo.

Rollout sicuro e manutenzione

La sequenza più robusta per un secondo server è questa:

  1. Abbassa il TTL dei record coinvolti.
  2. Pubblica SPF aggiornato con il nuovo IP.
  3. Genera e pubblica DKIM con selettore dedicato.
  4. Attiva la firma sul secondo server.
  5. Lascia DMARC in p=none finché i report non mostrano allineamento.
  6. Alza la policy DMARC solo dopo verifica stabile.

Per la manutenzione, pianifica una rotazione periodica delle chiavi DKIM e conserva la possibilità di tenere temporaneamente attivi due selettori, così da non interrompere la validazione durante il cambio. È una soluzione pratica quando hai più server o quando il secondo nodo viene introdotto in produzione senza fermare il traffico.

Se il secondo server viene usato come espansione stabile dell’infrastruttura, documenta per ogni dominio: IP autorizzati in SPF, selettore DKIM attivo, chiave privata associata, policy DMARC e mailbox di report. Senza questa mappa, la diagnosi di un problema di deliverability diventa lenta e fragile.

Esempio di set minimo per un dominio

Per chiudere, un set concettuale coerente può essere questo:

example.com. IN TXT "v=spf1 ip4:203.0.113.10 ip4:203.0.113.20 -all"
mail._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Con questo assetto hai autorizzazione SPF, firma DKIM e monitoraggio DMARC pronti per un rollout controllato sul secondo server PostfixAdmin. Assunzione: il secondo server è un nodo di invio aggiuntivo e non sostituisce completamente il precedente senza verifica di deliverability.