IT
Contatto

2026-08-10 · Ibida Black Level S.L.

DMARC spiegato: perché la sua email è vulnerabile e come risolverlo in 24h

Perché la maggior parte delle medie imprese resta con un DMARC debole, com'è fatta una configurazione funzionante e un piano di 24 ore fino a p=reject senza rompere l'email.

DMARC spiegato: perché la sua email è vulnerabile e come risolverlo in 24h

Il DMARC è uno dei controlli di cybersicurezza più economici alla portata di una media impresa europea. Implementarlo bene non richiede di acquistare una licenza, né di allestire nuova infrastruttura, né di assumere, né di ottenere un certificato di conformità. Implementarlo male costa lo stesso. La differenza tra i due è un paio di giorni di disciplina operativa.

Apriamo ogni incarico OSINT difensivo con una verifica di DMARC, SPF e DKIM sui domini principali del cliente. Nel 2025 e nella prima metà del 2026, la tipica media impresa europea che abbiamo analizzato aveva almeno uno di questi tre controlli mal configurato. Il caso più frequente era un DMARC in p=none dal giorno in cui era stato pubblicato, senza nessuno a monitorare i report aggregati che doveva generare.

Questo articolo è un piano operativo per passare da "abbiamo il DMARC sulla carta" a "siamo protetti al livello che la direttiva si aspetta". Diamo per scontato che la sua azienda usi Microsoft 365 o Google Workspace come piattaforma principale; i passaggi sono equivalenti in entrambi i casi, con dettagli propri di ciascun fornitore quando differiscono.

Cosa fa il DMARC e cosa non fa

DMARC è l'acronimo di Domain-based Message Authentication, Reporting and Conformance. È una politica espressa in un record TXT del DNS che indica ai server riceventi cosa fare con un messaggio che dichiara di provenire dal suo dominio ma fallisce i controlli SPF o DKIM sottostanti. La politica può essere none (solo monitorare), quarantine (spostare nella posta indesiderata) o reject (rifiutare la consegna).

Il DMARC non cifra la sua email, non impedisce che i suoi account vengano compromessi per riutilizzo di credenziali e non la protegge da messaggi inviati da domini simili. Protegge la recapitabilità e l'autenticità dell'email realmente inviata dal suo dominio e rende il suo dominio molto difficile da falsificare su larga scala.

Per la frode del CEO o BEC, la minaccia via email più costosa per le medie imprese europee negli ultimi anni, il DMARC in p=reject taglia uno dei quattro pretesti più comuni: il messaggio che dichiara di provenire dal dominio del CEO stesso, non da uno simile.

Perché la maggior parte delle medie imprese è in p=none

La ragione raramente è l'ignoranza. La ragione è la paura di rompere l'email. Passare da p=none a p=quarantine o p=reject può, se fatto male, far finire email legittime nella posta indesiderata o farle rifiutare. La dirigenza tende a ricordare il giorno in cui una notifica del consiglio è finita nello spam con più vividezza del giorno in cui una fattura fraudolenta non è arrivata.

La soluzione a quella paura è il report aggregato. Il tag rua del DMARC chiede ai server riceventi di inviare report giornalieri che riassumono chi ha provato a inviare email dal suo dominio e se SPF e DKIM sono passati. Con due settimane di quei report può costruire un quadro completo di ogni mittente legittimo da autorizzare, prima di irrigidire la politica.

Il fix in 24 ore, ora per ora

Diamo per scontato che lei abbia già pubblicato un record DMARC in p=none con una rua funzionante. In caso contrario, la prima azione è farlo e attendere due settimane. Il piano seguente si applica alla seconda fase.

Ora 0 - 4 · Inventario dei mittenti legittimi

Raccolga gli ultimi 14 giorni di report aggregati. Classifichi gli IP di origine in quattro gruppi:

1. La sua piattaforma email principale (M365 o Google Workspace).

2. Le sue piattaforme transazionali e di marketing (AWS SES, Mailgun, SendGrid, Mailchimp, Acumbamail, la sua stessa istanza Auctimail se la ha).

3. I suoi strumenti di supporto e CRM che inviano email a suo nome (Zendesk, HubSpot, Intercom, Front).

4. Fonti sconosciute.

Il quarto gruppo è il lavoro. Ogni IP lì è o un mittente legittimo non documentato o un tentativo di spoofing. Tracci ciascuno. Le sorprese più comuni sono: un server applicativo on-premise ereditato che continua a inviare fatture tramite un relay dimenticato, uno strumento HR contrattualizzato l'anno scorso da un team senza coordinarsi con l'IT e un consulente esterno che ha configurato il suo dominio nel proprio client di posta perché nessuno gli ha detto di non farlo.

Ora 4 - 8 · Pulizia dello SPF

Il suo record SPF è un elenco di mittenti che autorizza. Lo modifichi in modo che:

Uno SPF pulito per una media impresa su Google Workspace, AWS SES e HubSpot si legge più o meno così: v=spf1 include:_spf.google.com include:amazonses.com include:_spf.hubspot.com -all. Qualsiasi cosa sostanzialmente più complessa è sintomo di deriva accumulata.

Ora 8 - 12 · Verifica del DKIM

Per ogni mittente legittimo che supporti la firma DKIM a suo nome, verifichi che il selettore sia pubblicato e che la chiave pubblica sia attuale. Microsoft 365 usa selector1 e selector2. Google Workspace usa un selettore configurabile, tipicamente google. AWS SES usa tre record CNAME che puntano alla sua infrastruttura di firma DKIM.

La verifica è semplice: invii un messaggio di prova da ogni piattaforma a una casella che esponga le intestazioni grezze (mailtester.com, casella di prova di dmarcian.com, o un account Gmail con "mostra originale" attivo) e verifichi spf=pass e dkim=pass per l'allineamento rilevante.

Se qualche mittente legittimo non supporta il DKIM a suo nome, ha una decisione strategica. O accetta che quei messaggi falliranno l'allineamento DMARC (e chiede al mittente di aggiornarsi oppure lo sostituisce), oppure mantiene la politica in p=quarantine invece di p=reject finché non colma la lacuna. Abbiamo smesso di raccomandare la seconda opzione; i fornitori che nel 2026 non firmano con DKIM a suo nome sono fornitori da cui dovrebbe allontanarsi.

Ora 12 - 16 · Passaggio a p=quarantine, pct=100

Aggiorni il record DMARC a p=quarantine; pct=100; rua=mailto:dmarc-reports@suodominio.com; ruf=mailto:dmarc-failures@suodominio.com; sp=quarantine; adkim=s; aspf=s. I flag stretti (adkim=s; aspf=s) non sono sempre necessari; la modalità rilassata di default è accettabile per la maggior parte delle medie imprese. Ciò che conta è impegnarsi in un'azione di quarantena reale e monitorare.

Sorvegli i report aggregati delle 24 ore successive. Se un mittente legittimo non identificato comincia a fallire, lo aggiunga alla configurazione SPF o DKIM prima di passare al punto successivo.

Ora 16 - 24 · Passaggio a p=reject

Aggiorni il record DMARC a p=reject; pct=100; rua=...; ruf=...; sp=reject; adkim=s; aspf=s. Comunichi alla sua dirigenza che l'email che falsifica il suo dominio verrà rifiutata dai server riceventi che rispettano il DMARC, il che include essenzialmente l'intera popolazione dei grandi fornitori di posta.

Fissi un appuntamento in calendario a 14 giorni per rivedere di nuovo i report aggregati alla ricerca di qualche mittente legittimo che il cambiamento abbia rotto. A quel punto le sorprese tendono a essere piccole e facili da risolvere.

Su BIMI

BIMI (Brand Indicators for Message Identification) è un controllo complementare che permette al suo logo verificato di apparire accanto ai messaggi autenticati nei client di posta compatibili. Richiede DMARC in p=quarantine o p=reject con pct=100, un SVG verificato del logo e un Verified Mark Certificate emesso da un'autorità autorizzata.

Per una media impresa, BIMI è un complemento, non una necessità di sicurezza. L'ordine onesto è prima DMARC, poi BIMI, e solo se l'esposizione del brand giustifica il costo del certificato e l'onere operativo di mantenere il VMC.

Trabocchetti onesti

> "Abbiamo misurato il tempo da un DMARC p=none a una postura p=reject operativa nelle medie imprese, quando il lavoro è svolto da un singolo ingegnere con copertura esecutiva. La mediana è di 28 ore. Lo scopo del piano di 24 ore è che il secondo giorno sia di rifinitura, non di panico." — Nota sul campo IBL, 2026

Cosa facciamo in IBL

Il nostro sprint DMARC è un incarico fisso: due giorni di lavoro, uno di monitoraggio e uno di rifinitura. Il deliverable è il record DMARC operativo, il record SPF, la documentazione della configurazione DKIM, un inventario di ogni mittente autorizzato e un runbook di una pagina per l'ingegnere che sosterrà il controllo d'ora in poi.

Se desidera parlare della sua attuale postura DMARC, scriva a info@ociria.com. Rispondiamo entro un giorno lavorativo.

Ibida Black Level S.L. è una società di consulenza boutique di cybersicurezza con sede a Málaga e team operativo in Romania. Lavoriamo con medie imprese europee che preferiscono l'onestà tecnica al confezionamento commerciale. Siamo stati fondati nel 2026; non ci inventiamo una storia più lunga.

Letture correlate

Tag: dmarc, spf, dkim, sicurezza-email, anti-spoofing, bec, conformità