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.
Indice degli argomenti
Cosa chiede davvero il framework
Il cuore è semplice:
- SPF definisce “chi è autorizzato a spedire” per il dominio.
- DKIM firma crittograficamente i messaggi con chiavi (oggi sensato usare 2048 bit) e selettori per piattaforma.
- 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.
- Osservazione
- v=DMARC1; p=none; rua=mailto:dmarc-rua@dominio.it; ruf=mailto:dmarc-ruf@dominio.it; fo=1; adkim=s; aspf=s
- Enforcement graduale (a step con pct=)
- v=DMARC1; p=quarantine; pct=50; adkim=s; aspf=s; rua=mailto:dmarc-rua@dominio.it
- Protezione piena
- v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:dmarc-rua@dominio.it
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:tlsrpt@dominio.it”
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).
| Fase | Obiettivo | Azioni chiave | Output / Criterio di uscita | Rischi da presidiare |
| 1. Inventario flussi | Sapere chi invia “a nome nostro” | Mappare suite office, CRM, ERP, marketing, ticketing, MFP/stampanti, terze parti | Elenco sorgenti con domini “Header-From” ed “Envelope-From” | Mittenti “ombra” che emergono solo in enforcement |
| 2. Igiene DNS & firma | Rendere firmabile e allineabile | Unico SPF (<10 lookup), DKIM 2048b per ogni sorgente, selettori dedicati | Tutti i mittenti firmati; SPF pulito e testato | Include eccessivi, sottodomini dimenticati |
| 3. DMARC osservazione | Misurare senza rompere | p=none, attivare RUA/RUF e parsing dei report | Telemetria affidabile, mappa mismatch/allineamenti | Assenza di monitoraggio → “volo cieco” |
| 4. Enforcement graduale | Iniziare a filtrare in sicurezza | p=quarantine con pct= 25→50→75→100, fix progressivi dei mittenti | Quarantena al 100% senza impatti legittimi | Forwarding, mailing list, mancanza di ARC |
| 5. Protezione piena | Bloccare spoofing di dominio | p=reject, allineamento adkim=s; aspf=s | Reject stabile, tasso di falsi positivi ~0 | Terze parti non conformi “last minute” |
| 6. Cifratura del canale | Ridurre downgrade/MITM | MTA-STS in enforce, TLS-RPT, valutare DANE+DNSSEC | Errori TLS in calo e visibilità tramite report | Certificati MX non allineati, DNS non pronto |
| 7. Operatività continua | Tenere il sistema “vivo” | Automazione parsing RUA/TLS-RPT, SLA per nuovi mittenti, rotazione chiavi | KPI costanti e onboarding < X giorni | Derive organizzative, debito tecnico |
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.
