Il 28% delle intrusioni cyber inizia con il phishing, che costa alle organizzazioni in media 4 milioni di euro. Abbiamo analizzato le prime 400 aziende italiane per fatturato e 900 aziende europee.

Nonostante la maggior parte abbia SPF e DMARC attivi, il 44% delle aziende italiane e il 32% di quelle europee presenta configurazioni di autenticazione errate che, se basate principalmente su SPF e DMARC, le espongono al rischio di spoofing delle email.

Avere SPF, DMARC e DKIM attivi non basta: occorre configurarli correttamente

Questi risultati mostrano un divario critico tra “abilitato” e “protetto”. Il problema più comune è DMARC impostato su monitoraggio (p=none), che raccoglie report ma non blocca le email falsificate.

Alcune organizzazioni possono disporre di ulteriori livelli di sicurezza email (gateway, filtri ecc.). Tuttavia, quando SPF e DMARC rappresentano la difesa primaria contro lo spoofing del dominio, queste configurazioni errate costituiscono una vulnerabilità significativa.

La nostra analisi si concentra sul livello di autenticazione email: le organizzazioni che si affidano esclusivamente a SPF e DMARC sono a rischio.

Ma c’è un problema ancora più grande: anche con una configurazione perfetta, le credenziali vengono comunque rubate. Il phishing potenziato dall’AI raggiunge tassi di click-through rate del 54%, 4,5 volte superiori ai tentativi tradizionali. Il 17% degli attacchi sfrutta account validi, utilizzando credenziali rubate per aggirare i controlli di sicurezza.

Per questo non basta la prevenzione: serve il rilevamento.

In questo articolo spiegheremo come SPF e DMARC lavorano insieme, presenteremo i risultati della nostra ricerca sulle configurazioni di sicurezza email in Europa, mostreremo come gli attaccanti sfruttano le configurazioni errate e analizzeremo perché anche una configurazione corretta non è sufficiente, illustrando come la tecnologia di reverse phishing consenta di intercettare gli attaccanti che utilizzano credenziali rubate.

Come funziona l’autenticazione email: SPF, DKIM e DMARC

Prima di analizzare i risultati della nostra ricerca, vediamo come funzionano i principali protocolli di autenticazione email e perché sono fondamentali.

SPF (Sender Policy Framework)

SPF consente ai proprietari di un dominio di indicare quali server di posta sono autorizzati a inviare email per conto del dominio. È pubblicato come record DNS di tipo TXT che elenca IP e host autorizzati.

Un esempio di record SPF è il seguente:

v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all

Questo record indica che solo i server di Microsoft 365 e Google Workspace possono inviare email per il dominio; tutte le altre vengono rifiutate.

In particolare, il server destinatario riceve un’email che dichiara di provenire da example.com, interroga il DNS per il record SPF e verifica se l’IP del mittente è autorizzato. SPF restituisce un risultato in base al meccanismo all:

• IP autorizzato → pass
• IP non autorizzato:
  • -all → fail
  • ~all → softfail
  • ?all o assente → neutral

Il punto chiave è che SPF da solo non blocca le email: si limita a restituire un risultato. Senza DMARC, i server riceventi possono interpretare i fallimenti SPF in modo diverso. È DMARC che applica una policy basata sui risultati SPF (e DKIM).

La parte critica è che un record SPF deve sempre terminare con un meccanismo all. In sua assenza, SPF restituisce risultati neutral, creando ambiguità e rendendo inefficace la valutazione DMARC.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC è il livello di policy che utilizza i risultati SPF per stabilire come gestire le email che falliscono l’autenticazione. È pubblicato come record DNS di tipo TXT.
Un esempio di record DMARC:

v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]

Questo record indica che le email che falliscono l’autenticazione vengono rifiutate, la policy è applicata al 100% dei messaggi e i report aggregati vengono inviati a [email protected].

In particolare, il server ricevente verifica il risultato SPF e controlla l’allineamento: SPF deve risultare pass e il dominio nell’header From deve corrispondere al dominio che ha pubblicato il record SPF.

Se l’allineamento fallisce, DMARC applica la policy configurata:

• p=none: solo monitoraggio, nessun blocco
• p=quarantine: le email vengono spostate in spam
• p=reject: le email vengono bloccate

Il meccanismo all di SPF influisce su DMARC nel seguente modo.Quando un IP non autorizzato invia un’email:

• SPF -all → fail → DMARC applica la policy
• SPF ~all → softfail → DMARC applica la policy
• SPF ?all o assente → neutral → DMARC applica la policy

La sfumatura importante è con DMARC correttamente configurato (p=reject o p=quarantine), tutti questi scenari portano allo stesso risultato: l’email viene bloccata o messa in quarantena. Tuttavia, il meccanismo all di SPF resta cruciale perché:

• offre difesa in profondità se DMARC è assente o impostato su p=none;
• alcuni server agiscono sui risultati SPF prima di valutare DMARC;
• -all fornisce il segnale più chiaro e forte, mentre ~all e ?all introducono ambiguità.

La parte critica è che DMARC deve essere impostato su p=reject o p=quarantine per bloccare realmente le email spoofate. Con p=none, DMARC raccoglie solo report e le email falsificate possono comunque arrivare nelle inbox. Se pct è inferiore a 100, solo una parte delle email è protetta.

Per una sicurezza ottimale, SPF e DMARC devono essere entrambi configurati correttamente.

Schema funzionamento DMARC + SPF.

Come SPF e DMARC lavorano insieme: un’analogia semplice

Pensate a SPF e DMARC come al sistema di sicurezza di un edificio.

SPF è la lista degli invitati: verifica se qualcuno è autorizzato, ma da solo non blocca nessuno. DMARC è la guardia di sicurezza: legge il risultato SPF e applica la policy. Con p=reject blocca chi non è autorizzato; con p=none osserva e registra, ma lascia passare.

Il flusso di autenticazione è il seguente:

Email in arrivo → Controllo SPF → Valutazione DMARC → Azione

Per una protezione efficace servono, quindi:

• SPF configurato correttamente con all:
  • -all → fail → segnale più forte, consigliato in produzione
  • ~all → softfail → accettabile durante rollout graduali
  • ?all o assente → neutral → segnale debole, non raccomandato
• DMARC con policy di enforcement:
  • p=reject → blocco completo
  • p=quarantine → invio in spam
  • p=none → solo monitoraggio
• DMARC pct=100 (default): percentuali inferiori sono accettabili solo durante rollout, ma vanno portate a 100%.

Il punto critico è cheSPF determina il risultato (fail, softfail, neutral), DMARC decide l’azione. Con DMARC correttamente configurato (p=reject o p=quarantine), lo spoofing viene bloccato indipendentemente dal tipo di all.

Tuttavia, SPF con -all fornisce difesa in profondità ed è essenziale se DMARC è assente o impostato su p=none. In quel caso, SPF diventa l’unica linea di difesa e un segnale forte può comunque portare alcuni server a bloccare l’email.

La nostra ricerca: analisi delle aziende europee

Volevamo capire quanto efficacemente le aziende europee implementino la sicurezza email. Abbiamo analizzato circa 400 tra le principali aziende italiane per fatturato e 900 aziende europee, esaminando le loro configurazioni SPF e DMARC.

La metodologia seguita è riportata di seguito:

• Selezione delle aziende da principali indici europei e directory aziendali.
• Identificazione dei domini principali e verifica dei record DNS.
• Analisi dei record SPF (presenza del meccanismo all, assenza di record multipli ecc.).
• Analisi dei record DMARC (policy di enforcement, pct=100 ecc.).
• Classificazione delle configurazioni errate per tipo e gravità.

Abbiamo utilizzato strumenti di scansione automatica per l’analisi dei record DNS, verificando poi manualmente tutti i risultati. L’attenzione si è concentrata sulle configurazioni critiche che espongono le aziende al rischio di spoofing email quando SPF e DMARC rappresentano il principale meccanismo di difesa.

Con una nota importante: l’analisi riguarda esclusivamente il livello di autenticazione email (SPF/DMARC). Le organizzazioni possono disporre di ulteriori livelli di sicurezza, ma se SPF e DMARC sono la difesa primaria contro lo spoofing del dominio, queste configurazioni errate costituiscono una vulnerabilità significativa.

I risultati evidenziano un divario critico tra “abilitato” e “protetto”.

Statistiche generali, Italia vs UE: il divario critico

Nonostante il 99% delle aziende italiane top abbia SPF abilitato e il 93% DMARC abilitato, solo il 58% applica una policy DMARC con enforcement.

Di conseguenza, il 44% delle aziende italiane top ha configurazioni di autenticazione email errate, esponendole al rischio di spoofing se SPF e DMARC sono la loro protezione principale.

Di seguito i numeri del confronto tra Italia e UE:

• Italia: 44% a rischio
• Media europea: 32% a rischio
• Differenza: +12 punti percentuali (38% più a rischio)

L’insight chiave è il seguente: il problema più comune sia in Italia che in Europa è DMARC impostato su p=none (solo monitoraggio, nessuna enforcement). Queste aziende raccolgono report sui tentativi di spoofing, ma le email falsificate continuano a raggiungere le inbox dei destinatari.

Cos’è lo spoofing del dominio

Lo spoofing del dominio si verifica quando un attaccante invia un’email che sembra provenire da un dominio legittimo (es. [email protected]), ma in realtà proviene da un server non autorizzato.

L’header From viene manipolato per far sembrare l’email autentica, pur essendo inviata da un server diverso.

Un simile attacco informatico è pericoloso perché:

• i destinatari vedono un dominio familiare e si fidano dell’email;
• gli attaccanti possono impersonare dirigenti, fornitori o partner;
• favorisce attacchi BEC, furto di credenziali e frodi;
• senza autenticazione email adeguata, il mittente non può essere verificato.

Una corretta autenticazione email può, però, prevenirlo nel seguente modo: SPF e DMARC lavorano insieme per verificare che le email che dichiarano di provenire dal vostro dominio siano inviate da server autorizzati. Configurati correttamente, possono bloccare le email spoofate prima che raggiungano le inbox.

Vediamo cosa succede a ogni livello di configurazione della sicurezza email, dalla mancanza di protezione alla protezione completa, riportando alcuni scenari di attacco email con SPF e DMARC a confronto.

Perché la prevenzione non basta: serve il rilevamento

Anche con SPF e DMARC perfettamente configurati, gli attacchi possono avere successo. I dati mostrano perché il rilevamento è fondamentale per fermare una vera e propria epidemia di furto di credenziali:

• 1,8 miliardi di credenziali rubate solo nella prima metà del 2025, con un aumento dell’800% rispetto al periodo precedente.
• Una volta compromesse, gli attaccanti possono inviare email legittime dal vostro dominio, bypassando completamente SPF e DMARC.

Secondo il Microsoft Digital Defense Report 2025:

• Il 17% di tutti gli attacchi utilizza account validi con credenziali rubate.
• L’80% degli attacchi da access broker si basa su metodi di compromissione delle credenziali.
• Il 28% delle violazioni inizia tramite phishing o social engineering.

Quando gli attaccanti usano credenziali rubate, inviano email da server autorizzati con autenticazione valida. SPF e DMARC passeranno, perché le email sono tecnicamente legittime, anche se inviate da chi ha rubato le credenziali.

La realtà del bypass

• Il 21% degli attacchi porta a Business Email Compromise (BEC), più frequente del ransomware (16%)
• Gli attacchi BEC spesso non sfruttano lo spoofing del dominio, ma:
  • Account fornitori compromessi: supply chain attack (3% delle violazioni).
  • Access broker: 368 identificati, con oltre 4.000 vittime in 68 settori e 131 paesi.
  • Device code phishing: 93% degli eventi nella seconda metà del 2024, consentendo il furto di token senza compromettere password.

Il fattore amplificazione AI

Email di phishing automatizzate da AI raggiungono un tasso di click-through del 54%, rispetto al 12% dei tentativi standard, 4,5 volte più efficace.

L’automazione AI può aumentare la redditività delle campagne di phishing fino a 50 volte, rendendo il furto di credenziali più efficace e scalabile che mai.

Il divario del rilevamento

La sicurezza email tradizionale si concentra sulla prevenzione: bloccare le email dannose prima che arrivino nelle inbox. Ma quando:

• gli attaccanti inviano email legittime usando credenziali rubate,
• account di fornitori vengono compromessi e usati contro la vostra organizzazione,
• campagne AI-driven inducono phishing con tassi di click del 54%,

serve una buona capacità di rilevamento per individuare questi attacchi anche quando la prevenzione fallisce.

Rilevare gli attacchi via email: il reverse phishing

Il Reverse Phishing fornisce un layer di rilevamento che intercetta gli attaccanti anche quando riescono a bypassare l’autenticazione email o rubare credenziali.

Reverse Phishing: catturare le credenziali rubate

Quando gli attaccanti ottengono credenziali, tramite phishing, data breach o infostealer, le testano spesso su vari portali di login per verificarne la validità.

La soluzione di Reverse Phishing di Tropico trasforma questo comportamento a vostro vantaggio.

Come funziona Reverse Phishing

• Decoy portals pubblici: Tropico crea portali realistici (email, VPN, ecc.) sotto il vostro sottodominio, ospitati su infrastruttura isolata, separata dai sistemi di produzione.
• Attirare i test delle credenziali: Quando gli attaccanti testano credenziali rubate sul vostro sottodominio, colpiscono i portali di Tropico invece dei sistemi reali.
• Cattura e verifica: Tropico registra i tentativi e li verifica con i vostri identity provider (Microsoft Entra, Okta, ecc.), confermando che si tratta di credenziali rubate e riducendo i falsi positivi.
• Alert in tempo reale: Non appena le credenziali vengono testate, i team di sicurezza ricevono alert immediati con informazioni operative per:
  • Revocare subito le credenziali compromesse.
  • Identificare gli account a rischio.
  • Agire preventivamente prima che gli attaccanti possano usare le credenziali sui sistemi reali.

Anche con SPF e DMARC perfettamente configurati, le credenziali possono essere rubate tramite phishing, data breach o altri vettori. Reverse Phishing intercetta gli attaccanti nel momento in cui testano le credenziali rubate, offrendo un rilevamento precoce che l’autenticazione email tradizionale non può garantire.

Difesa in profondità: prevenzione e rilevamento

Per garantire una efficace difesa in profondità è necessario intervenire sia in prevenzione sia nel rilevamento delle minacce.

Layer 1: prevenzione (SPF + DMARC)

• Configurare SPF correttamente con meccanismo -all
• Impostare DMARC su p=reject con pct=100
• Audit e aggiornamento regolare delle configurazioni
• Monitoraggio dei report DMARC per anomalie

Layer 2: rilevamento con Tropico

• Deploy di decoy portals pubblici sotto il vostro sottodominio per catturare tentativi di test delle credenziali
• Verifica delle credenziali rubate con i provider di identità (Entra, Okta) per eliminare falsi positivi
• Alert immediati quando gli attaccanti testano credenziali rubate
• Monitoraggio dei movimenti laterali con Honeypot Maze e degli accessi cloud con Cloud Tokens

Il risultato èuna strategia di sicurezza email completa che previene gli attacchi e rileva quelli che riescono a superare le difese.

Rilevamento e rimedio

Ecco, di seguito, una checklist rapida per verificare la propria configurazione.

DMARC Policy:

• ✅ p=reject o p=quarantine con pct=100 (o senza parametro pct)
• ❌ p=none → cambiare in p=reject o p=quarantine
• ❌ pct < 100 → impostare pct=100

SPF Record:

• ✅ Termina con -all (ideale) o ~all (accettabile)
• ❌ Termina con ?all o senza meccanismo all → aggiungere -all
• ❌ Record SPF multipli → consolidare in uno solo

Strumenti di verifica disponibili online:

• MXToolbox DMARC Checker
• SPF Record Checker

Best Practices

Configurazione:

• Iniziare con DMARC p=quarantine per monitorare l’impatto, poi passare a p=reject.
• Assicurarsi che SPF termini con -all per la protezione più forte.
• Controllare regolarmente i report DMARC per individuare fallimenti di autenticazione.
• Aggiornare i record SPF quando si aggiungono nuovi servizi email.

Rilevamento:

• Deploy di decoy portal con Reverse Phishing per catturare test di credenziali rubate.
• Monitorare credenziali compromesse e attività di login sospette.
• Considerare tecnologie di rilevamento se gestite dati sensibili o siete obiettivi ad alto valore.

Conclusione

La nostra analisi evidenzia un divario critico nella sicurezza email:

• La maggior parte delle aziende ha SPF e DMARC abilitati.
• Tuttavia, quasi metà delle aziende italiane e un terzo di quelle europee hanno configurazioni errate che le espongono allo spoofing email, se SPF e DMARC sono la protezione primaria.
• Il problema più comune è DMARC impostato su p=none (solo monitoraggio), che rileva ma non blocca le email spoofate.

Considerando che 1,8 miliardi di credenziali sono state rubate nella prima metà del 2025, anche una configurazione perfetta non basta.

La soluzione efficace, dunque, combina due livelli:

• Prevenzione: SPF configurato correttamente con -all e DMARC con p=reject e pct=100
• Rilevamento: Deploy di decoy portal con Reverse Phishing per intercettare gli attaccanti che testano credenziali rubate.

Riferimenti

1. FBI Internet Crime Report 2024: Federal Bureau of Investigation, Internet Crime Complaint Center (IC3), “2024 Internet Crime Report”, 2024. Documented $2,770,151,146 in total losses from Business Email Compromise (BEC) attacks in 2024.
2. Microsoft Digital Defense Report 2025: Microsoft Corporation, “Microsoft Digital Defense Report 2025”, 2025. Statistics on phishing attacks (28% of breaches initiated through phishing or social engineering), credential theft, AI-powered attacks, initial access methods, BEC attacks (21% vs 16% ransomware), access brokers (368 identified, affecting 4,000+ victims), device code phishing (93% occurred in second half of 2024), valid account abuse (17% of attacks), access broker attacks (80% use credential-based methods), and AI-automated phishing (54% click-through rates, 4.5x increase).
3. Flashpoint Global Threat Intelligence Index: 2025 Midyear Edition: Flashpoint, “Flashpoint’s Global Threat Intelligence Index: 2025 Midyear Edition”, 2025. Documented 800% spike in stolen credentials tied to infostealers, with 1.8 billion total credentials compromised in the first half of 2025, including over 1 billion emails, cookies, and passwords.
4. IBM Cost of a Data Breach Report: IBM Security, “Cost of a Data Breach Report”, 2024. Reported that phishing-related data breaches cost organizations an average of $4.80 million per breach.
5. PowerDMARC Italy DMARC Adoption Report 2025: PowerDMARC, “Italy DMARC & MTA-STS Adoption Report 2025”, 2025. Analysis of 693 Italian domains across nine key sectors, finding that 26% lacked DMARC records and only 16.7% enforced a “reject” policy.