Sicurezza e‑mail pratica: implementare DMARC, DKIM e SPF con Postfix e workflow di testing

Quando si introducono DMARC, DKIM e SPF, è più che una modifica dei DNS: è un progetto operativo che richiede inventario, progettazione MTA, strategia di firma, gestione dei report e rollback sicuri. Questo Runbook è rivolto ad amministratori, system engineer e operatori: procedure pragmatiche, comandi di verifica, insidie tipiche e una chiara strategia di fallback.

Introdurre DMARC DKIM SPF: breve chiarimento dei termini: SPF, DKIM, DMARC nella pratica

SPF (Sender Policy Framework) è un record DNS TXT che specifica quali server sono autorizzati a inviare per la Envelope‑From‑Domain; protegge principalmente contro lo spoofing diretto del Return‑Path. DKIM (DomainKeys Identified Mail) firma i messaggi criptograficamente; il destinatario verifica la firma rispetto a una chiave pubblica nel DNS. DMARC (Domain‑based Message Authentication, Reporting & Conformance) collega SPF e DKIM e controlla inoltre l‘Alignment, ossia se i domini verificati corrispondono al dominio visibile nel campo From:. Senza Alignment l’efficacia contro le frodi visive dell’indirizzo è limitata.

Requisiti e preparazione organizzativa

Prima di modificare i record, create un inventario completo di tutti i mittenti di posta: relay Postfix centrali, applicazioni (es. istanze Zammad), servizi cloud (M365, Google, strumenti di marketing), monitoring, alert di backup e fornitori esterni. Chiarite i permessi di scrittura DNS, la policy TTL (prima delle modifiche abbassare temporaneamente la TTL) e eventuali setup Split‑Horizon DNS che possono fornire risposte diverse internamente/esternamente.

Ordine raccomandato per il rollout

1. Attivare DMARC con p=none e RUA abilitati, per rendere visibili i mittenti reali.
2. Consolidare gli SPF: un record pulito per dominio, rispettare il limite di lookup.
3. Attivare DKIM su larga scala, idealmente firmando centralmente al relay (OpenDKIM).
4. Monitorare e poi indurire gradualmente DMARC: quarantine (eventualmente con pct) → reject.

SPF: regole pratiche e errori tipici

SPF è tecnicamente semplice, ma in ambienti estesi diventa rapidamente complesso. Regole importanti:

• Solo un record SPF‑TXT per dominio (più record causano PermError).
• Limitare i DNS‑lookup (massimo 10); evitare catene di include profonde.
• Documentare ogni include e verificare i mittenti di terze parti (newsletter, scanner).

SPF‑Beispiel

; SPF für example.tld
example.tld. 3600 IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.mailerprovider.net ~all"

SPF prüfen

dig +short TXT example.tld
# oder für vollständige Ausgabe
dig TXT example.tld +noall +answer

Se avete molti include, considerate lo SPF‑flattening con cautela o create subdomini di invio (es. mailer.example.tld) con propri record SPF.

DKIM con Postfix: OpenDKIM come Milter

In Postfix DKIM è tipicamente implementato tramite milter. OpenDKIM è uno strumento diffuso e stabile. Decidete: firma centralizzata al relay (unifica chiavi/rotazione) o distribuita per host (migliore assegnazione di responsabilità).

Strategia delle chiavi

Raccomandazione: RSA 2048 come minimo; 1024 è considerato obsoleto. Usate uno schema di selector con componente temporale (es. s2026q3) per la rotazione. Conservate le chiavi private in modo sicuro (permessi file, restrizioni di accesso) e fissate scadenze regolari per la rotazione.

OpenDKIM: installazione e configurazione di base

sudo apt-get update
sudo apt-get install -y opendkim opendkim-tools

; /etc/opendkim.conf (Auszug)
Syslog                  yes
SyslogSuccess           yes
Canonicalization        relaxed/simple
Mode                    sv
Socket                  local:/run/opendkim/opendkim.sock
KeyTable                /etc/opendkim/key.table
SigningTable            refile:/etc/opendkim/signing.table
InternalHosts           /etc/opendkim/trusted.hosts

sudo install -d -m 0750 -o opendkim -g opendkim /etc/opendkim/keys/example.tld
cd /etc/opendkim/keys/example.tld
sudo -u opendkim opendkim-genkey -b 2048 -s s2026q3 -d example.tld
sudo chown -R opendkim:opendkim /etc/opendkim/keys/example.tld
sudo chmod 0640 /etc/opendkim/keys/example.tld/s2026q3.private
# DNS prüfen
dig @1.1.1.1 +short TXT s2026q3._domainkey.example.tld

Integrazione Postfix

# /etc/postfix/main.cf (Ausschnitt)
milter_default_action = accept
milter_protocol = 6
smtpd_milters = unix:/run/opendkim/opendkim.sock
non_smtpd_milters = unix:/run/opendkim/opendkim.sock

Importante: durante la fase di introduzione impostare milter_default_action=accept, affinché i guasti del milter non blocchino la consegna.

DMARC: Attivare il reporting, inasprire la policy in seguito

Pubblicare il record DMARC come TXT in _dmarc.example.tld. Iniziare con p=none e un destinatario rua per raccogliere report aggregati e rendere visibili i problemi.

Record iniziale

_dmarc.example.tld. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.tld; adkim=r; aspf=r; fo=1; pct=100"

I report RUA sono file XML (spesso in ZIP) che contengono informazioni sui risultati SPF/DKIM, sugli indirizzi IP e sui volumi. Usare un parser (p.es. strumenti Open‑Source come pydmarc) o un collector esterno; prestare attenzione a storage, retention e alla protezione dei dati relativi agli indirizzi IP contenuti.

Comprendere l’allineamento

DMARC richiede che SPF o DKIM siano allineati con la From:-Domain visibile. Cause frequenti di fallimenti DMARC sono:

• Envelope‑From appartiene a un fornitore terzo, mentre From: riporta il dominio aziendale.
• DKIM firma con una d=‑Domain diversa dalla From:-Domain visibile.

Soluzioni: adattare l’Envelope‑From (p.es. tramite relay), firmare DKIM in modo che d= corrisponda alla From‑Domain, oppure inviare tramite sottodomini con un DMARC dedicato.

Workflow di testing: misurabile e controllato

Un approccio iterativo protegge dallo spegnimento di sistemi legittimi. Modello operativo consigliato:

1) Baseline: DMARC p=none, 48–72 Stunden Reports

Raccogliere i dati RUA, catalogare gli indirizzi IP mittenti e i servizi. Segnalare le sorgenti non chiare e dare priorità alla loro verifica in base al volume e alla criticità.

2) Pulizia SPF

Ridurre gli includes, creare se necessario sottodomini di invio e testare dopo ogni modifica usando resolver pubblici.

3) Attivare DKIM ovunque

Verificare che tutti i percorsi produttivi passino attraverso l’hop che firma. Inviare mail di test da ogni applicazione e controllare gli header dal lato destinatario.

4) Quarantine con controllo pct

_dmarc.example.tld. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@example.tld; adkim=r; aspf=r; pct=50"

Aumentare gradualmente la severità della policy e monitorare le caselle Canary (Gmail, M365) nonché il backlog di supporto.

5) Reject

Impostate p=reject solo quando tutti i mittenti legittimi sono stabilmente allineati e potete rispondere tempestivamente ai ticket di supporto. Pianificate SLA chiari per analisi e rollback.

Comandi pratici per test e diagnostica

Per l’invio di mail di test è utile swaks (Swiss Army Knife SMTP); con questo potete verificare se vengono generate le firme:

# Beispiel: Testmail via lokalen Relay
swaks --to test@example.org --from zammad@example.tld --server localhost:25 --header "Subject: DKIM Test"

# DKIM/Header prüfen (auf Empfänger oder lokalen Mailbox-Store)
grep -i "DKIM-Signature|Authentication-Results" /var/mail/testuser | sed -n '1,80p'

Controlli DNS:

dig @1.1.1.1 TXT s2026q3._domainkey.example.tld
dig @8.8.8.8 TXT _dmarc.example.tld +noall +answer
# Über TCP testen, falls große TXT-Records Probleme machen
dig @1.1.1.1 TXT s2026q3._domainkey.example.tld +noall +answer +tcp

Controllo del report RUA (estrarre lo ZIP e formattare):

unzip -p report-12345.zip | xmllint --format - | sed -n '1,200p'

Regole operative specifiche per Zammad

Le istanze Zammad inviano frequentemente mail critiche per il sistema (notifiche ticket, avvisi SLA). Verificate i seguenti punti:

• Configurate Zammad in modo che le mail in uscita transitino attraverso il relay Postfix centrale (Admin‑UI o systemsendmail). Questo garantisce la firma DKIM centrale e l’alignamento DMARC.
• Controllate From: vs Envelope‑From:. Zammad può per impostazione predefinita usare mittenti diversi; configurate domini mittente coerenti oppure utilizzate una mailer‑subdomain.
• Eseguite invii di ticket di prova e verificate gli header completi dal lato destinatario (Received, DKIM‑Signature, Authentication‑Results).
• Automatizzate controlli a campione: un job di monitoring che invia regolarmente testmail e verifica firma/Authentication‑Results riduce i rischi operativi.

Casi problematici e troubleshooting

DMARC fail nonostante SPF/DKIM pass

Spesso è dovuto alla mancanza di alignment. Verificate se DKIM d= corrisponde al dominio From o se il Return‑Path appartiene alla stessa dominio organizzativo.

DKIM pass con alcuni Provider, fail con altri

Spesso la causa è la distribuzione DNS: split‑horizon, troncamento dei TXT o caching. Testate con diversi resolver pubblici e via TCP per individuare problemi di frammentazione.

Guasto del Milter

sudo systemctl status opendkim --no-pager
sudo ss -xlpn | grep opendkim
journalctl -u opendkim -n 200 --no-pager
journalctl -u postfix -n 200 --no-pager

Durante la fase di introduzione gli errori del Milter non dovrebbero bloccare la consegna (milter_default_action=accept), mentre in fase operativa vanno monitorati e risolti.

Forwarding, mailing list e ARC

SPF spesso fallisce con il semplice inoltro perché il forwarder non è incluso nel vostro record SPF. Due opzioni praticabili:

• Utilizzare DKIM — le firme generalmente sopravvivono meglio all’inoltro.
• Supportare Authenticated Received Chain (ARC) — ARC è un meccanismo basato su header che documenta l’autenticità attraverso mailing list/forwarder e aiuta i destinatari ad accettare messaggi legittimi nonostante risultati SPF/DKIM negativi.

ARC è particolarmente utile in ambienti con molte mailing list o inoltri interni.

Sicurezza, gestione delle chiavi e igiene operativa

Le chiavi DKIM private sono segreti aziendali: proteggete i file, limitate i permessi sui file e mettete al sicuro i backup. Documentate le date di rotazione e testate i cambi di chiave in una zona di staging. Implementate un change‑control per le modifiche DNS (Git + CI per i file di zona o un deployment DNS guidato da ticket).

Piano di rollback concreto (breve e operativo)

1. Se si verificano interruzioni critiche nella consegna, impostate rapidamente DMARC su p=none:

# Beispiel: neuer DMARC-Record
_dmarc.example.tld. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.tld; adkim=r; aspf=r; pct=100"

# DNS-Änderung prüfen
dig @1.1.1.1 TXT _dmarc.example.tld +noall +answer
# Postfix/OpenDKIM Status prüfen
sudo systemctl status postfix opendkim --no-pager

Avviate quindi l’analisi delle cause: quali mittenti hanno fallito, quali servizi sono stati interessati, e documentate le lezioni apprese nel vostro Change‑Log.

Manutenzione a lungo termine e monitoraggio

Pianificate revisioni regolari: analizzare i report RUA (es. settimanale), rotazione delle chiavi DKIM semestrale, inventario SPF trimestrale. Automatizzate gli alert per aumenti improvvisi di volume o di tassi di errore nei report DMARC.

Conclusione

Introdurre DMARC, DKIM e SPF è un progetto operativo: inventario, governance DNS, strategia di firma centralizzata, workflow di testing e percorsi di rollback chiari sono determinanti. Iniziate con il reporting DMARC, razionalizzate SPF, attivate DKIM sul relay e irrobustite DMARC gradualmente. Documentazione, monitoraggio e manutenzione regolare rendono la misura efficace nel tempo — particolarmente per applicazioni come Zammad, che inviano notifiche critiche.

DMARC, DKIM & SPF: esercizio, monitoraggio e automazione

Una volta stabilita la tecnologia di base, è la gestione operativa continua a determinare il successo. Cambiate la prospettiva da progetto una tantum a servizio permanente: governance DNS, alta disponibilità del milter, pipeline RUA, ciclo di vita delle chiavi e automazione del rollback sono aree operative da pianificare per tempo.

Provider DNS e gestione delle modifiche

• Prestate attenzione ai limiti del provider per le API‑call e al rate‑limiting negli upload delle zone; altrimenti i deploy automatizzati possono fallire o causare incoerenze di TTL.
• Usate TTL brevi prima di modifiche importanti (es. 300s) e rialzateli dopo aver verificato la stabilità.
• Testate la consegna dei record TXT tramite diversi resolver pubblici e via TCP per rilevare la troncatura.

Alta disponibilità e gestione delle chiavi

Gestite il signer DKIM come componente ad alta disponibilità: disaccoppiate gli hop di Postfix con milter TCP/inet o tramite un proxy centrale. Le chiavi private devono risiedere in un key‑store sicuro o in un HSM; predisponete un playbook di emergency rotation documentato (pubblicare un nuovo selector, commutare le firme, rimuovere la chiave vecchia solo dopo la finestra di test).

Pipeline RUA & integrazione SIEM

I report RUA sono dati grezzi — costruite una pipeline automatizzata: Collector (E‑Mail o API) → Parser/Normalizer → database a serie temporali & SIEM. Regole che dovrebbero generare alert immediati: aumento improvviso di DMARC‑fails, nuove IP mittenti con alto volume, o fallimenti ricorrenti per sottodomini critici. Prestate attenzione alla protezione dei dati: gli IP nei report sono rilevanti come dati personali e richiedono politiche di retention adeguate.

Reti di sicurezza operative

• Destinatari canary: un piccolo set di provider differenti (Gmail, M365) come sistema di allerta precoce.
• Milter‑Circuit‑Breaker: alerting automatico in caso di timeout ripetuti del milter; finché milter_default_action=accept è impostato, garantisce una fase di fallback sicura.
• Infrastructure as Code: modifiche DNS tramite GitOps (Pull Request, Review, CI) riducono gli errori umani e consentono un rapido ripristino.

Questi elementi operativi rendono il progetto resiliente: riducono i ticket di supporto, prevengono interruzioni di servizio per software aziendale personalizzato come Zammad e creano una storia delle modifiche chiaramente auditabile.

Per questo ambito sono importanti anche Postfix DKIM e i record SPF. L’articolo inquadra questi aspetti in modo comprensibile e mostra cosa conta nella pratica quotidiana.