Il “debito di sicurezza delle e-mail”: l’indicatore di sicurezza informatica che nessuno misura

Ogni team di sicurezza riporta con sicurezza una serie di dati: tentativi di phishing bloccati, rilevamenti di malware, accessi falliti, credenziali compromesse, tempo medio di risposta. Ciò che quasi nessuno riporta è il lavoro che avrebbe dovuto essere completato mesi fa e che continua a essere rinviato allo sprint successivo.

A quell’arretrato va dato un nome che vale la pena usare: debito di sicurezza delle e-mail — ovvero i problemi irrisolti relativi all'autenticazione, alla proprietà e alla configurazione che si accumulano nell'infrastruttura di posta elettronica e che diventano sempre più costosi da risolvere man mano che l'organizzazione cresce attorno ad essi.

L'e-mail è particolarmente efficace nel raccoglierli. Una nuova piattaforma SaaS inizia a inviare messaggi a tuo nome. Un record DNS viene modificato durante una migrazione. Un sottodominio “temporaneo” rimane attivo. Un fornitore continua a inviare credenziali di accesso molto tempo dopo la conclusione del progetto. Preso singolarmente, ogni caso sembra una questione risolvibile in cinque minuti.

Come si presenta effettivamente il “debito di sicurezza delle e-mail”

Il concetto prende spunto dal concetto di “debito tecnico” utilizzato nello sviluppo del software. Si prende una scorciatoia per risolvere il problema di oggi, lasciando al sé futuro il conto da pagare per la manutenzione.

I sistemi di posta elettronica raccolgono rapidamente queste scorciatoie, poiché l’infrastruttura di invio non appartiene quasi mai a un unico team. Il reparto Marketing gestisce la piattaforma delle campagne. Il reparto Risorse Umane gestisce lo strumento di reclutamento. Il reparto Assistenza gestisce il sistema di ticket. Gli sviluppatori integrano due o tre API per le email transazionali. Al reparto IT spetta invece il compito di mantenere i record DNS che tengono insieme l’intero sistema.

Sintomi tipici:

• Servizi di invio sconosciuti che continuano a utilizzare il tuo dominio;
• Meccanismi SPF residui derivanti da una migrazione conclusasi due anni fa;
• Chiavi DKIM che rimandano a servizi che nessuno usa più;
• Politiche DMARC in modalità di monitoraggio senza un proprietario chiaro;
• Sottodomini temporanei che non sono mai stati riesaminati;
• Fornitori terzi che mantengono l'accesso alla funzione di invio anche dopo la scadenza del contratto.

Nessuno di questi eventi fa scattare un incidente il giorno stesso in cui si verifica. Ed è proprio per questo che sopravvivono.

L'autenticazione diventa sempre più complessa col passare del tempo

Configurare SPF, DKIM e DMARC su un dominio nuovo di zecca è davvero semplice. La parte difficile è mantenere tutti e tre correttamente configurati nel corso degli anni, nonostante i continui cambiamenti dell'infrastruttura.

Prendiamo ad esempio gli SPF. Si parte con Google Workspace e un unico fornitore di servizi di marketing. Poi il reparto vendite aggiunge una piattaforma, quello delle assunzioni ottiene un proprio sistema e il reparto tecnico integra un’API di posta elettronica. Il numero di record cresce, ma quelli obsoleti vengono raramente rimossi allo stesso ritmo — ed è così che i domini finiscono per raggiungere i limiti di ricerca, pubblicando record SPF duplicatio subendo errori SPF che nessuno riesce a spiegare. Ottenere la sintassi SPF correttamente una volta è facile; mantenerla corretta è una questione di manutenzione.

DKIM segue lo stesso ciclo di vita. Le chiavi appartengono a mittenti specifici, e i mittenti cambiano. Un selettore pubblicato può rimanere tecnicamente valido anche molto tempo dopo che il servizio a cui si riferisce è stato ritirato dalle operazioni quotidiane, e DKIM inizia a dare errori per motivi sepolti in un ticket del 2023.

È qui che i report DMARC dimostrano la loro utilità. I report aggregati mostrano quali sistemi stanno effettivamente inviando e-mail a nome del tuo dominio — non quelli che pensi lo stiano facendo. Leggere questi report trasforma le deviazioni invisibili in un elenco su cui puoi intervenire, e PowerDMARC ti offre una visione d’insieme di DMARC, SPF e DKIM in un’unica schermata, invece di costringere il tuo team a gestire ogni record come un’attività DNS isolata.

Questo cambia la prospettiva della domanda. “Il DMARC è abilitato?” non è una domanda utile. Lo è invece: “Conosciamo tutti i servizi che attualmente inviano messaggi a nome del nostro dominio, e ciascuno di essi è ancora autorizzato a farlo?”.

Il problema del mittente sconosciuto

Esiste comunque un certo “debito di sicurezza delle e-mail” anche quando ogni record è tecnicamente corretto.

Immaginate una piattaforma per webinar autorizzata due anni fa. Il dipendente che l’ha configurata se n’è andato. L’account non viene utilizzato da mesi. Eppure è ancora in grado di inviare e-mail autenticate tramite il dominio aziendale.

Dal punto di vista di un hacker, “vecchio” non significa “innocuo”. Un account dimenticato è una via d’accesso sicura al tuo ambiente di posta elettronica che nessuno tiene d’occhio.

Una corretta verifica del mittente risponde a sei domande pratiche:

• Da quale sistema proviene questa e-mail?
• A quale squadra appartiene l'account?
• Quale dominio o sottodominio utilizza?
• Supera i controlli di allineamento SPF e DKIM?
• Quando è stato utilizzato legittimamente per l'ultima volta?
• Chi ha l'autorità di rimuoverlo?

Quest'ultima domanda tende a causare più ritardi dell'intera indagine tecnica. Individuare un mittente superfluo richiede pochi minuti. Ottenere l'autorizzazione per disattivarlo può richiedere settimane.

L'autenticazione delle e-mail non copre l'intero attacco

Un altro tipo di debito si manifesta quando un’azienda si aspetta che un singolo meccanismo di controllo risolva un problema che esula dal suo ambito di competenza.

L'applicazione delle regole DMARC rende molto difficile lo spoofing diretto dei domini. Tuttavia, non blocca tutti i messaggi di phishing. Gli autori degli attacchi ricorrono a domini simili, account di terze parti compromessi, allegati dannosi e pagine convincenti per il furto di credenziali.

A quel punto, il problema va ben oltre l’autenticazione del mittente. Una volta che un file o un link dannoso raggiunge il dispositivo di un utente, si fa affidamento sul rilevamento degli endpoint, sulla protezione del browser, sul filtraggio degli URL o su un soluzione antivirus di nuova generazione per intercettare ciò che è riuscito a passare.

Questa ripartizione delle responsabilità è più importante di quanto solitamente si pensi. Un’organizzazione può applicare rigorosamente le regole DMARC e tuttavia lasciare gli utenti esposti al rischio nel momento stesso in cui cliccano su un link. Un’altra può investire ingenti somme in strumenti per gli endpoint, mentre una dozzina di servizi dimenticati continuano ad avere l’autorizzazione a inviare email considerate affidabili dal proprio dominio. Il “debito di sicurezza” delle email tende a risiedere proprio in questo divario tra le due situazioni.

Perché questo dato compare raramente in un dashboard

Non esiste un'unità di misura standard per il “debito di sicurezza” delle e-mail, il che rende molto più difficile riportarne i dati rispetto al tasso di clic nei casi di phishing o al valore dell’MTTR.

Una diapositiva trimestrale potrebbe mostrare che il 98% della posta legittima supera l'autenticazione. È rassicurante, ma non dice nulla sui quattro account SaaS abbandonati che possono ancora inviare messaggi autenticati. Allo stesso modo, raggiungendo p=reject sul proprio dominio principale non significa che l’ambiente più ampio sia pulito. Sottodomini, mittenti di terze parti e errori DMARC irrisolti rientrano tutti al di fuori di quella cifra principale.

Una dashboard più trasparente tiene traccia delle attività non risolte, non solo di quelle portate a termine con successo:

• Mittenti non identificati;
• Servizi autorizzati senza titolare attivo;
• I casi di autenticazione fallita non sono ancora stati oggetto di indagine;
• Le piattaforme inattive possono ancora inviare;
• Domini rimasti in modalità di monitoraggio oltre il periodo concordato.

Anche l’età va inserita in quella tabella di controllo. Un mittente scoperto ieri è oggetto di indagine. Lo stesso mittente che nove mesi dopo non è ancora stato identificato è un debito.

Assegnare un ciclo di vita a ogni eccezione

I programmi di sicurezza della posta elettronica raramente si bloccano per motivi gravi. Si bloccano a causa di eccezioni temporanee, fogli di calcolo obsoleti, ticket abbandonati e documenti che nessuno vuole toccare perché non è chiaro a chi appartengano.

La soluzione è tutt’altro che affascinante: a ogni mittente non identificato o eccezione di autenticazione viene assegnato un responsabile, una motivazione documentata e una data di revisione. Questo semplice cambiamento rende nuovamente visibile l’infrastruttura trascurata.

Puoi iniziare con ciò che è già stato pubblicato. Controlla la tua configurazione attuale, verifica il tuo dominio tramite un strumento di analisi dei dominie infine utilizza i report DMARC per confrontare ciò che è autorizzato con ciò che viene effettivamente inviato.

Questo indicatore non sarà mai perfettamente oggettivo, né è necessario che lo sia. Il suo valore è di natura pratica. I mittenti obsoleti, i record non aggiornati, le implementazioni DMARC incomplete e le lacune tra la protezione della posta elettronica e quella degli endpoint smettono di essere considerati semplice rumore di fondo e iniziano a essere visti come attività a cui è possibile dare priorità. È proprio questo il senso di definire il “debito di sicurezza della posta elettronica”: ciò che viene misurato viene pianificato.

FAQ

Che cos’è il “debito di sicurezza delle e-mail”? Il "debito di sicurezza della posta elettronica" è l'accumulo di problemi irrisolti relativi all'autenticazione, alla proprietà e alla configurazione nell'infrastruttura di posta elettronica di un'organizzazione: meccanismi SPF obsoleti, chiavi DKIM associate a servizi non più attivi, politiche DMARC bloccate in modalità di monitoraggio e mittenti di terze parti di cui nessuno è responsabile né che vengono controllati.

Come si misura il “debito di sicurezza” delle e-mail? Monitorare gli elementi irrisolti piuttosto che quelli risolti con successo: mittenti non identificati, servizi autorizzati senza proprietario, errori di autenticazione non indagati, piattaforme inattive a cui è ancora consentito inviare messaggi e domini lasciati in modalità di monitoraggio oltre una scadenza concordata. Aggiungere l'anzianità di ciascun elemento, poiché è proprio il tempo trascorso senza una risoluzione a distinguere un'indagine in corso da un vero e proprio debito.

Il raggiungimento del valore p=reject in DMARC significa che non si hanno “debiti di sicurezza” relativi alla posta elettronica? No. L’applicazione del DMARC sul dominio principale impedisce lo spoofing diretto di quel dominio, ma i sottodomini, i servizi di invio di terze parti e gli errori di autenticazione non risolti possono rimanere tutti non gestiti, nascosti dietro una metrica di riferimento apparentemente pulita.

• Informazioni su
• Ultimi messaggi

Ahona Rudra

Esperto di sicurezza dei domini e della posta elettronica presso PowerDMARC

Ahona è la Marketing Manager di PowerDMARC, con oltre 5 anni di esperienza nella scrittura di argomenti di cybersecurity, specializzata in sicurezza dei domini e delle e-mail. Ahona ha conseguito una laurea in Giornalismo e Comunicazione, consolidando la sua carriera nel settore della sicurezza dal 2019.

Ultimi messaggi di Ahona Rudra (vedi tutti)

• Email di phishing generate dall'IA: come verificare le email scritte dall'IA prima di fidarsene - 31 agosto 2026
• Il “debito di sicurezza delle e-mail”: l’indicatore di sicurezza informatica che nessuno misura - 31 agosto 2026
• PowerDMARC nominata leader nel settore dei software DMARC per il 13° trimestre consecutivo - 28 agosto 2026