Come configurare i record DKIM, SPF e DMARC per un server Zimbra

DKIM, SPF e DMARC risolvono tre diverse problematiche relative all'autenticazione delle email in uscita, e un'implementazione affidabile di Zimbra richiede che funzionino in sinergia. SPF comunica ai destinatari quali sistemi sono autorizzati a inviare email utilizzando il dominio dell'intestazione. DKIM aggiunge una firma crittografica associata al dominio. DMARC verifica se un'identità SPF o DKIM valida corrisponde al dominio visibile nell'intestazione "Da" del messaggio, quindi pubblica una policy di gestione e reporting.

Un dettaglio importante relativo agli standard attuali è il seguente: a ottobre 2026, la specifica attiva del protocollo DMARC è la RFC 9989 , pubblicata a maggio 2026. Questa sostituisce la precedente RFC 7489 e modifica alcuni dettagli di implementazione, tra cui la dicitura "storico" del vecchio pcttag e l'introduzione del ttag "testing". Questo è importante se si sta copiando un esempio DMARC precedente da una guida Zimbra o da un tutorial DNS.

Cosa serve prima di modificare il DNS

È necessario avere accesso amministrativo alla shell di un MTA Zimbra, accesso alla zona DNS pubblica autorevole per il dominio di invio e un elenco completo di tutti i sistemi che inviano legittimamente email utilizzando tale dominio. Questo elenco può includere il server Zimbra, un relay o uno smart host, piattaforme di marketing, sistemi di ticketing, applicazioni cloud e qualsiasi servizio di posta per il ripristino di emergenza.

Un equivoco comune è che pubblicare i record solo per l'host Zimbra sia sempre sufficiente. È sufficiente solo quando Zimbra è effettivamente l'unico mittente autorizzato. SPF viene valutato rispetto all'identità SMTP e DMARC può rivelare mittenti di terze parti dimenticati una volta che l'applicazione è abilitata. Azione: inventariare tutte le sorgenti in uscita prima di pubblicare una policy SPF o DMARC restrittiva.

Passaggio 1: Genera la chiave DKIM in Zimbra

Zimbra include l' zmdkimkeyutilutility per la firma DKIM a livello di dominio. La documentazione ufficiale di Zimbra indica di eseguirla su un server MTA. Per aggiungere i dati DKIM per un dominio che non li possiede già, passare all'account Zimbra ed eseguire:

su - zimbra
/opt/zimbra/libexec/zmdkimkeyutil -a -d example.com

Il comando memorizza i dati DKIM nella voce di dominio LDAP di Zimbra e stampa il selettore e il record TXT pubblico necessari per la pubblicazione. La documentazione di Zimbra sulla firma DKIM descrive anche -qcome interrogare i dati DKIM esistenti, -ucome aggiornarli e -rcome rimuoverli.

Nelle installazioni Zimbra moderne, il valore esatto del selettore visualizzato potrebbe differire dagli esempi online. Il selettore non deve essere una parola fissa come defaulto zimbra; utilizzare esattamente il selettore visualizzato dal proprio server. Azione: copiare l'intero record della chiave pubblica dall'output del comando anziché ricostruirlo manualmente.

Passaggio 2: Pubblicare il record DKIM TXT

I verificatori DKIM cercano la chiave pubblica nel DNS con un nome costruito dal selettore e ._domainkey. Il meccanismo è definito nella RFC 6376. In termini pratici per i provider DNS, il record di solito ha questo aspetto:

Se inserire solo YOUR_SELECTOR._domainkeyo per intero YOUR_SELECTOR._domainkey.example.comdipende dal pannello di controllo DNS. Alcuni provider aggiungono automaticamente il nome della zona. Azione: visualizza in anteprima il nome del record completo finale nel tuo provider prima di salvare in modo da non creare accidentalmente ...example.com.example.com.

Passaggio 3: Creare un record SPF TXT per il dominio mittente

L'SPF viene pubblicato come record DNS TXT sul dominio di cui si desidera descrivere l'autorizzazione all'invio. La RFC 7208 richiede record TXT per l'SPF e afferma che più record SPF con lo stesso nome proprietario generano un errore permanente. In altre parole, non creare un secondo v=spf1record TXT solo perché si aggiunge un altro servizio di posta.

Se il tuo server Zimbra invia direttamente da un indirizzo IPv4 pubblico stabile, un esempio minimo è il seguente:

v=spf1 ip4:203.0.113.10 -all

Se tutti gli host a cui fanno riferimento i record MX del tuo dominio sono mittenti in uscita legittimi, potresti usare mx; se un servizio di terze parti pubblica un dominio di inclusione SPF, potresti aver bisogno di un include:meccanismo. Il record esatto è specifico per l'implementazione, quindi non esiste una singola stringa SPF di Zimbra universalmente corretta.

Un altro errore comune è presumere che ~allsia sempre più sicuro di -all. La vera questione è se il tuo inventario di mittenti autorizzati sia completo. Un qualificatore rigoroso -allè ragionevole quando lo è. Azione: autorizza ogni mittente legittimo in un unico record SPF, verificalo in produzione, quindi scegli il qualificatore finale allin base a tale evidenza.

Mantieni SPF ragionevolmente semplice. RFC 7208 limita a 10 i meccanismi e i modificatori che attivano le ricerche DNS durante la valutazione; il superamento del limite può comportare permerror. Azione: conta gli include e altri meccanismi di espansione DNS prima di aggiungere un altro fornitore.

Passaggio 4: Pubblicare prima DMARC in modalità di monitoraggio

La politica DMARC è pubblicata all'indirizzo _dmarc.example.com. Un primo tentativo prudente è il seguente:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

p=noneRichiede ai destinatari di non modificare la gestione in base alla policy DMARC durante la raccolta dei dati. L' ruaindirizzo richiede report aggregati; il formato corrente dei report aggregati è specificato da RFC 9990. Utilizzare una casella di posta o un servizio di reporting in grado di elaborare i report DMARC anziché una casella di posta personale non presidiata.

Non copiare ciecamente pct=10esempi pct=25di implementazione simili da articoli più vecchi. RFC 9989 è considerato pctstorico perché l'esperienza operativa ha mostrato un'applicazione incoerente. Lo standard attuale utilizza t=yper testare il comportamento quando necessario. Azione: iniziare con p=nonee analizzare i report; non fare affidamento sul campionamento percentuale come meccanismo di sicurezza.

Passaggio 5: Verificare tutti e tre i record nel DNS pubblico

Dopo che il provider DNS ha pubblicato i record, è possibile interrogarli dall'esterno del server autorevole o da un resolver che accede al DNS pubblico. Ad esempio:

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

Per SPF, verificare che esista una sola risposta TXT che inizia v=spf1con quel nome proprietario. Per DKIM, verificare che il selettore corrisponda esattamente al valore attualmente memorizzato da Zimbra. Per DMARC, verificare che esista un singolo record di policy DMARC utilizzabile con il nome previsto.

La propagazione DNS dipende dal provider, dal TTL e dalla cache del resolver. Una modifica che appare immediatamente su un nameserver autorevole potrebbe essere ancora memorizzata nella cache altrove. Azione: eseguire un test con almeno un resolver pubblico indipendente prima di attribuire la colpa a Zimbra per una risposta obsoleta.

Passaggio 6: Invia un messaggio reale e verifica l'allineamento dell'autenticazione

Invia un messaggio dal dominio Zimbra a una casella di posta di un provider diverso e analizza le intestazioni complete del messaggio. Un risultato positivo dovrebbe normalmente mostrare una firma DKIM e/o un risultato SPF validi, oltre a un risultato DMARC positivo poiché almeno un'identità autenticata corrisponde al dominio del mittente visibile.

È qui che emerge un altro equivoco: DMARC non richiede sia SPF che DKIM per superare il test. Richiede un'identità SPF allineata o un'identità DKIM allineata. La RFC 9989 definisce l'allineamento rilassato come predefinito per entrambi aspf, adkimsebbene sia possibile richiedere un allineamento rigoroso con s. Azione: esaminare Authentication-Resultse identificare esattamente quale meccanismo sta fornendo il superamento del test DMARC allineato.

Fase 7: Passare dal monitoraggio all'applicazione delle norme solo dopo che le segnalazioni sono state corrette.

Una volta che i dati DMARC mostrano che i mittenti legittimi si autenticano e si allineano correttamente, è possibile modificare la policy in p=quarantineo eventualmente p=reject. Nello standard attuale, none, quarantine, e rejectesprimono la valutazione del proprietario del dominio sull'utilizzo non autenticato, ma i destinatari mantengono comunque la discrezionalità nella gestione locale.

Non trattatelo p=rejectcome un'ottimizzazione della deliverability. DMARC è principalmente un sistema di autenticazione e controllo degli abusi di dominio; non rende automaticamente attendibile la posta desiderata né garantisce la consegna nella casella di posta. Azione: rendete l'applicazione di DMARC una decisione di sicurezza basata su una copertura di autenticazione allineata, non una promessa di tassi di consegna più elevati.

Passaggio 8: Ruotare le chiavi DKIM senza eliminare immediatamente il vecchio record DNS

Per aggiornare i dati DKIM di un dominio, Zimbra documenta:

/opt/zimbra/libexec/zmdkimkeyutil -u -d example.com

Il comando crea dati DKIM aggiornati e produce una nuova voce DNS. Zimbra consiglia specificamente di lasciare il precedente record TXT nel DNS per un certo periodo di tempo, in modo che i messaggi firmati con la chiave precedente possano ancora essere verificati mentre sono in transito o in coda. Azione: pubblicare prima il nuovo selettore, verificarlo e mantenere temporaneamente il selettore precedente prima di rimuoverlo.

Guida rapida: cosa dimostra ogni record

Verifiche specifiche di Zimbra da effettuare

Le linee guida di Zimbra sulla protezione della posta elettronica indicano che il DKIM deve essere generato per ogni dominio e pubblicato nel DNS pubblico di ciascun dominio. Documentano inoltre i problemi di allineamento che possono verificarsi con determinate persone o con il comportamento degli autorisponditori nelle configurazioni meno recenti. Questi dettagli sono specifici per determinate situazioni e non universali: se la tua implementazione utilizza alias, persone, relay o una riscrittura insolita dell'envelope-from, testa separatamente questi percorsi dei messaggi.

Per un'installazione Zimbra multidominio, ripetere la configurazione DKIM e la pubblicazione DNS per ogni dominio di invio. Anche SPF e DMARC sono policy di dominio; non dare per scontato che un record su un dominio ospitato copra automaticamente un altro dominio non correlato. Azione: creare una piccola matrice di test per ogni dominio e ogni rotta in uscita prima di abilitare l'applicazione rigorosa di DMARC.

Lista di controllo per la convalida finale

• Esiste esattamente un record SPF che inizia con v=spf1per ogni dominio di invio.
• Il record SPF include ogni rotta in uscita autorizzata e rimane entro i limiti di elaborazione DNS di SPF.
• Zimbra firma le email in uscita con il selettore memorizzato per quel dominio.
• La chiave pubblica DKIM corrispondente è visibile nel DNS pubblico sotto selector._domainkey.
• Il record DMARC TXT è pubblicato all'indirizzo _dmarc.domaine utilizza la sintassi corrente.
• I messaggi di test esterni mostrano un allineamento SPF o DKIM superato e, di conseguenza, anche un DMARC superato.
• I report aggregati vengono esaminati prima di passare dalla fase di monitoraggio a quella di quarantena o di rifiuto.
• I vecchi selettori DKIM vengono mantenuti temporaneamente durante la rotazione e rimossi solo al termine della finestra di transizione.

Se questi controlli hanno esito positivo, il server Zimbra non si limita a pubblicare tre record DNS, ma presenta una catena di autenticazione coerente che i destinatari remoti possono convalidare. Questa distinzione è più importante del copiare una stringa di esempio da una guida, perché le corrette sorgenti SPF, il selettore DKIM e la tempistica di applicazione DMARC dipendono da come la posta elettronica effettivamente esce dall'organizzazione.