L’Agenzia per la Cybersicurezza Nazionale ha pubblicato un framework tecnico operativo per la corretta autenticazione del mittente nelle comunicazioni email. Non si tratta di raccomandazioni generiche: è un documento che riguarda tutte le organizzazioni pubbliche e private, con implicazioni dirette in materia di sicurezza, conformità normativa e continuità operativa.

Perché la posta elettronica è ancora un punto critico

Il protocollo su cui si basa la posta elettronica — SMTP — è stato progettato decenni fa, quando la sicurezza delle reti non era una priorità. Non prevede, per sua natura, alcun meccanismo che verifichi l’identità del mittente né che garantisca l’integrità del messaggio durante il transito.

Il risultato pratico è che, in assenza di protezioni aggiuntive, chiunque potrebbe inviare email spacciandosi per un’altra organizzazione — fingendo di essere il tuo ente, la tua azienda, il tuo studio — senza necessità di accedere ad alcun account. I destinatari riceverebbero la comunicazione come se fosse autentica.

Non è uno scenario teorico. Secondo le stime più recenti, quasi una organizzazione italiana su quattro non è in grado di impedire tecnicamente che terzi inviino email fraudolente a suo nome.

Il documento ACN: cosa prevede

L’ACN ha pubblicato il Framework di Autenticazione per la Posta Elettronica, disponibile sul sito ufficiale dell’Agenzia. Il documento fornisce indicazioni operative per l’implementazione di tre protocolli standard a livello internazionale: SPF, DKIM e DMARC. Se configurati in modo coerente e monitorati nel tempo, permettono di autenticare il mittente, proteggere il dominio da usi fraudolenti e aumentare l’affidabilità delle comunicazioni in uscita.

I tre protocolli: cosa fanno e perché contano

SPF — Chi è autorizzato a inviare email per il tuo dominio?

SPF pubblica nel sistema DNS del dominio un elenco degli indirizzi IP abilitati a inviare messaggi a suo nome. Quando un’email viene ricevuta, il server di destinazione verifica se il mittente rientra tra quelli autorizzati. Se non lo è, si attiva la policy configurata.

Un errore frequente riguarda i servizi di terze parti: chi usa Microsoft 365 come client principale, ma invia anche notifiche automatiche tramite un CRM o un gestionale, deve includere tutte queste sorgenti nel record SPF. Una sola sorgente dimenticata è sufficiente perché quelle email vengano trattate con sospetto dai server riceventi.

DKIM — Il messaggio è integro e proviene da una sorgente autorizzata?

DKIM firma digitalmente i messaggi tramite crittografia a chiave pubblica/privata. Il server che riceve l’email può verificare la firma recuperando la chiave pubblica dal DNS del dominio mittente. In questo modo è possibile accertare che il contenuto non sia stato alterato durante il transito e che la firma provenga da una sorgente effettivamente autorizzata.

DKIM diventa particolarmente rilevante nelle organizzazioni che utilizzano più sistemi di invio — client di posta, newsletter, ticketing, piattaforme cloud — perché ogni sorgente deve essere configurata separatamente e in modo coerente.

DMARC — Come si gestiscono i messaggi che non superano i controlli?

DMARC unifica e governa SPF e DKIM. Permette al proprietario del dominio di stabilire cosa deve accadere alle email che non superano le verifiche di autenticazione, e soprattutto di ricevere report dettagliati su tutto ciò che avviene a suo nome: quali server inviano messaggi, quali passano i controlli, quali falliscono, con quale frequenza.

DMARC introduce inoltre il concetto di allineamento: verifica che il dominio visibile nel campo “Da:” corrisponda a quello autenticato via SPF o DKIM, intercettando anche le forme più sofisticate di impersonazione.

Non è solo una questione di sicurezza: c’è anche la recapitabilità

Questo è l’aspetto che le organizzazioni sottovalutano con più frequenza. I principali provider di posta — Gmail, Microsoft 365, Yahoo e altri — hanno progressivamente irrigidito i propri filtri antispam. Oggi valutano attivamente la presenza e la correttezza di SPF, DKIM e DMARC: un dominio privo di questi record, o con una configurazione incompleta, viene trattato come sospetto in modo automatico.

Il rischio concreto è che un’email inviata regolarmente dal proprio sistema — un preventivo, una risposta urgente, una comunicazione istituzionale — non venga recapitata al destinatario, o finisca nello spam giorni dopo, senza che il mittente riceva alcuna notifica di errore. Il problema avviene in silenzio, sul lato di chi dovrebbe ricevere.

Il collegamento con NIS 2 e il quadro normativo

Le linee guida ACN non sono un documento a sé stante. Le misure descritte si inseriscono nel contesto della Direttiva NIS 2, del Perimetro di Sicurezza Nazionale Cibernetica e del Regolamento Cloud ACN.

In questo quadro, la corretta configurazione della posta elettronica non è più soltanto una buona pratica tecnica: per molte organizzazioni diventa un requisito di conformità. In Italia sono già stati identificati oltre 21.000 soggetti obbligati dalla NIS 2, di cui almeno 5.000 classificati come essenziali. Per questi soggetti, verificare lo stato della propria infrastruttura email non è più rimandabile.

Le insidie più comuni nella configurazione

Pubblicare tre record DNS sembra semplice. In pratica, ci sono errori ricorrenti che portano a configurazioni solo apparentemente corrette:

• SPF ha un limite di 10 lookup DNS. Superarlo causa problemi su tutte le email in uscita: un errore frequente nelle organizzazioni che usano più servizi in parallelo.
• DKIM richiede la gestione di chiavi crittografiche che vanno protette, ruotate periodicamente e configurate per ogni sorgente di invio.
• Attivare subito p=reject senza una fase di monitoraggio preliminare può bloccare email legittime, creando disservizi immediati.
• L’inoltro automatico delle email può invalidare le verifiche SPF e DKIM se non gestito correttamente.
• Vecchi server, relay dimenticati, account configurati manualmente possono generare invii non coerenti con la configurazione dichiarata nel DNS, producendo errori silenziosi difficili da individuare.
• I report DMARC non monitorati rendono inutile gran parte dello strumento: è proprio lì che emergono tentativi di abuso del dominio, sorgenti dimenticate e configurazioni che nel tempo sono diventate incoerenti.

L’approccio raccomandato dall’ACN è graduale: partire con DMARC in modalità p=none, analizzare i report per alcune settimane, mappare tutte le sorgenti reali, poi passare progressivamente a p=quarantine e infine a p=reject solo quando la configurazione è stabile e verificata.

Cosa fare concretamente

Se hai un tecnico o un fornitore che gestisce la tua posta, è il momento di chiedere una verifica esplicita su questi punti:

1. Il record SPF è presente, aggiornato e rispetta il limite dei 10 lookup?
2. Tutte le sorgenti che inviano email per conto del dominio sono state mappate e incluse?
3. DKIM è configurato per ogni sorgente di invio, incluse le piattaforme esterne?
4. Esiste un record DMARC con una policy coerente con lo stato reale della configurazione?
5. I report DMARC vengono monitorati e interpretati regolarmente?
6. Esistono vecchi server, inoltri automatici o relay dimenticati che potrebbero generare invii non allineati?

Il fatto che la posta “funzioni” non equivale a una posta correttamente autenticata.

Se gestisci direttamente la tua infrastruttura, segui il percorso raccomandato dall’ACN: avvia DMARC in monitoraggio, analizza i flussi reali, verifica SPF e DKIM su tutte le sorgenti, chiudi relay e forwarding non necessari, poi passa gradualmente alle policy più restrittive.

In sintesi

Le linee guida ACN chiariscono un punto rimasto a lungo sottovalutato: la posta elettronica non è un servizio che “funziona o non funziona”, ma un’infrastruttura che deve essere configurata, monitorata e governata nel tempo.

SPF, DKIM e DMARC non sono più elementi opzionali: rappresentano oggi il livello minimo per garantire affidabilità delle comunicazioni, protezione del dominio e conformità normativa. Il vero rischio non è solo subire un attacco, ma non accorgersi che qualcosa non funziona correttamente — email che non arrivano, dominio usato da terzi, reputazione compromessa senza segnali evidenti.

Fonte ufficiale: ACN — Framework di Autenticazione per la Posta Elettronica

Questo articolo è ripreso con autorizzazione da Alchimie Digitali S.r.l., socio sostenitore del Centro Studi, ed è pubblicato con richiamo alla fonte originale: adigitali.it