L’e-mail resta un’infrastruttura critica della comunicazione aziendale. È ubiqua, interoperabile, a prova di vendor lock-in. Ed è proprio per questo che continua a essere bersaglio privilegiato per phishing, BEC (Business Email Compromise) e account takeover.

La novità utile è che l’ACN ha pubblicato un framework di autenticazione per la posta elettronica che rimette ordine nelle misure di base: non linee guida generiche, ma un percorso pratico che parte dalla triade SPF, DKIM e DMARC e arriva, con metodo, a un livello di protezione verificabile.

L’obiettivo non è “mettere un bollino”, ma governare il dominio: stabilire regole chiare su chi può inviare e-mail “a nome nostro”, firmare i messaggi in modo robusto e istruire i destinatari su cosa fare quando l’allineamento non torna.

In altre parole, trasformare l’identità di dominio da promessa implicita a controllo esplicito.

Cosa chiede davvero il framework

Il cuore è semplice:

1. SPF definisce “chi è autorizzato a spedire” per il dominio.
2. DKIM firma crittograficamente i messaggi con chiavi (oggi sensato usare 2048 bit) e selettori per piattaforma.
3. DMARC mette un cappello di governance: allineamento del dominio, policy di trattamento (monitoraggio, quarantena, rifiuto), telemetria tramite report.

Un chiarimento che evita aspettative sbagliate: DMARC non cifra i contenuti. Serve a verificare chi parla a nome del dominio e come trattare ciò che non è allineato. La cifratura del canale è un’altra partita: MTA-STS (con TLS-RPT) e, dove possibile, DANE per SMTP con DNSSEC alzano l’asticella contro downgrade e MITM. Sono piani complementari.

Analizziamoli nel dettaglio con alcuni esempi pratici.

SPF

Un solo record TXT per dominio, lookup totali < 10, niente “catene della felicità” di include:

v=spf1 include:provider-mail.example -all

DKIM

Chiavi 2048 bit, rotazione periodica, un selettore per ogni sorgente che invia: suite office, CRM, piattaforma marketing, ticketing, gateway.

Firmare “tutto ciò che parte a nome del dominio” riduce sorprese in fase di enforcement.

DMARC

Prevede un percorso in tre tappe.

1. Osservazione
   1. v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=s; aspf=s
2. Enforcement graduale (a step con pct=)
   1. v=DMARC1; p=quarantine; pct=50; adkim=s; aspf=s; rua=mailto:[email protected]
3. Protezione piena
   1. v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:[email protected]

MTA-STS

Relativo alla cifratura del canale.

Record DNS:

_mta-sts.dominio.it. TXT “v=STSv1; id=2025-08-01”

_smtp._tls.dominio.it. TXT “v=TLSRPTv1; rua=mailto:[email protected]”

Policy (HTTPS): https://mta-sts.dominio.it/.well-known/mta-sts.txt

version: STSv1

mode: enforce

mx: mail.dominio.it

max_age: 86400

BIMI

Utile per acquisire un bonus reputazionale.

Arriva dopo DMARC in enforcement; utile per fiducia percepita, non sostituisce alcuna misura di sicurezza.

PEC e posta “normale”: due binari diversi

La PEC ha valore legale e regole proprie. Ma la maggior parte delle conversazioni operative con clienti e fornitori scorre su canali ordinari: è lì che lo spoofing del dominio produce danni reputazionali e frodi.

Il Framework di autenticazione per la posta elettronica di ACN parla soprattutto a questo contesto. Confondere i piani può generare un falso senso di sicurezza.

Oltre i record: identità, accesso e persone

Autenticare il dominio è metà dell’opera. L’altra metà è proteggere gli account e ridurre la superficie d’attacco “umana”.

• MFA per tutti, prioritari admin e account con deleghe di invio (CRM/ERP).
• Modern Authentication: dismettere POP/IMAP legacy dove possibile.
• Conditional Access: geografia, postura del dispositivo, “impossible travel”.
• Awareness continua: riconoscere una e-mail sospetta e saperla segnalare vale quanto una buona policy DMARC.

Nella tabella sottostante una utile roadmap pragmatica (con criteri di uscita).

KPI che parlano al board

Più dei tecnicismi contano i risultati misurabili: percentuale di allineamento DMARC, tempo di onboarding di un nuovo mittente applicativo, tasso di messaggi respinti per spoofing dopo p=reject, errori TLS rilevati e risolti via TLS-RPT entro soglie concordate.

È il modo più trasparente per legare sicurezza e continuità del canale.

Risposte ai dubbi più comuni

A questo punto, è utile dare alcune risposte ai dubbi più comuni che potrebbero sorgere nella gestione aziendale della posta elettronica.

“Possiamo restare su p=none?”

Solo come fase di misura. Restarci stabilmente equivale a guardare i report senza mai governare il traffico.

“DMARC rompe le newsletter”

Se accade, è un segnale di configurazioni errate (domini non allineabili, buste di trasporto diverse, provider non firmanti). Si corregge con il fornitore e con un minimo di governance.

“MTA-STS serve davvero?”

Sì, perché introduce una politica verificabile sulla cifratura del canale e, con TLS-RPT, offre visibilità operativa sui problemi prima che li rilevino i destinatari.

Un accenno al perimetro regolatorio

Nel quadro NIS2, parlare di misure “adeguate e proporzionate” significa anche curare l’igiene del canale e-mail: autenticare, monitorare, cifrare, formare.

Il Framework di autenticazione per la posta elettronica di ACN si colloca in questa logica di operazionalizzazione: meno principi astratti, più pratiche verificabili.

Benefici tangibili nella gestione della posta elettronica

La sicurezza dell’e-mail non si risolve con un unico interruttore. È l’incontro tra identità di dominio governata da SPF/DKIM/DMARC, canale rafforzato da MTA-STS/TLS-RPT (e, quando possibile, DANE), accessi protetti da MFA e comportamenti allenati.

Il framework ACN offre un binario chiaro: percorrerlo con disciplina produce benefici tangibili, riduzione dello spoofing, migliore deliverability, meno rumore nelle caselle, più fiducia nell’intero scambio informativo.