Routing email mal configurato: l'allarme Microsoft sullo spoofing interno (gennaio 2026)

⚡TL;DR

• Microsoft ha rivelato a gennaio 2026 che le configurazioni MX che puntano a servizi di terze parti (antispam, archiviazione) creano un punto cieco sfruttato dagli attaccanti per impersonare domini interni
• La piattaforma Tycoon2FA ha generato 13 milioni di email di phishing bloccate da Defender in un solo mese (ottobre 2025), sfruttando questo vettore combinato con attacchi AiTM
• Il trio SPF ~all + DKIM assente + DMARC p=none lascia passare il 100 % dei tentativi di impersonificazione tramite routing MX indiretto
• L'analisi forense degli header email rivela il meccanismo esatto: salti inattesi nella catena Received, spf=softfail, dkim=none, dmarc=fail action=none
• Il piano di correzione in 5 passaggi: DMARC progressivo verso p=reject, SPF -all, DKIM attivato, connettori di terze parti verificati, MX diretto verso Microsoft 365

A gennaio 2026, il team Microsoft Defender for Office 365 ha pubblicato un avviso che ha scosso i team di sicurezza: migliaia di organizzazioni che utilizzano Microsoft 365 erano vulnerabili a un'impersonificazione di identità interna, non a causa di un bug software, ma a causa della loro stessa configurazione DNS. Il meccanismo è semplice e devastante. Quando il record MX di un dominio punta a un servizio di terze parti (gateway antispam, soluzione di archiviazione, relay di filtraggio) invece di puntare direttamente a Microsoft 365, le email in entrata passano attraverso un intermediario che non ricalcola correttamente i risultati di autenticazione SPF, DKIM e DMARC. Gli attaccanti lo hanno capito e sfruttano questa falla su larga scala.

Non si tratta di uno scenario teorico. Microsoft ha documentato che la piattaforma di phishing-as-a-service Tycoon2FA ha generato da sola 13 milioni di email malevole bloccate da Defender nell'ottobre 2025. Queste email sfruttavano il routing MX indiretto combinato con tecniche di adversary-in-the-middle (AiTM) per rubare credenziali e cookie di sessione, anche da utenti protetti dall'autenticazione a più fattori. Le esche utilizzate imitavano reimpostazioni di password, messaggi HR e notifiche di documenti condivisi, inviati dall'indirizzo interno della vittima verso se stessa.

Questo articolo descrive il meccanismo tecnico di questo attacco, l'analisi forense degli header email che permette di rilevarlo, una diagnosi DNS in cinque minuti per sapere se il tuo dominio è vulnerabile e un piano di correzione completo.

Il contesto: cosa rivela l'avviso Microsoft di gennaio 2026?

Un problema di routing, non di protocollo

L'avviso di Microsoft non riguarda una vulnerabilità in SPF, DKIM o DMARC in sé. Questi protocolli funzionano esattamente come previsto. Il problema si trova nell'architettura di routing delle email.

In una configurazione standard, il record MX di un dominio punta direttamente ai server Exchange Online Protection (EOP) di Microsoft 365:

captaindns.com.  IN  MX  10  captaindns-com.mail.protection.outlook.com.

Con questa configurazione, Microsoft 365 riceve le email direttamente dal mittente. Valuta SPF verificando l'IP sorgente rispetto al record SPF del dominio dell'envelope. Valida la firma DKIM. Applica la policy DMARC. Ogni verifica avviene nel contesto corretto.

Ma migliaia di organizzazioni hanno un MX che punta a un servizio di terze parti:

captaindns.com.  IN  MX  10  mx.filtro-terze-parti.com.

Il servizio di terze parti riceve l'email, esegue il suo trattamento (antispam, archiviazione, analisi del contenuto), poi trasmette il messaggio a Microsoft 365. Il problema: quando Microsoft 365 riceve il messaggio, l'IP sorgente è quella del servizio di terze parti, non quella del mittente originale. Il contesto di autenticazione è cambiato.

Il meccanismo di attacco in dettaglio

L'attaccante sfrutta questa catena nel seguente modo:

Passaggio 1: ricognizione. L'attaccante interroga il MX del dominio bersaglio. Se il MX punta a un servizio di terze parti invece di *.mail.protection.outlook.com, il dominio è potenzialmente vulnerabile.

Passaggio 2: verifica della postura di autenticazione. L'attaccante verifica tre record DNS:

• _dmarc.captaindns.com: se la policy è p=none, i fallimenti DMARC non provocano alcuna azione
• captaindns.com (TXT SPF): se il meccanismo è ~all (softfail) invece di -all (hardfail), il fallimento SPF è tollerato
• Selettori DKIM comuni: se nessuna chiave DKIM è pubblicata, il campo dkim=none non attiva nulla

Passaggio 3: invio dell'email falsificata. L'attaccante invia un'email da un server che controlla. Inserisce lo stesso indirizzo nei campi From e To: ad esempio, contabilita@captaindns.com verso contabilita@captaindns.com. Questo "self-spoofing" dà l'impressione che il messaggio provenga da un collega interno.

Passaggio 4: transito attraverso il servizio di terze parti. Il MX del dominio instrada l'email verso il servizio di terze parti. Questo esegue un primo livello di filtraggio. Il problema: molti servizi di terze parti non verificano SPF/DKIM/DMARC affatto, oppure li verificano ma non propagano i risultati in modo utilizzabile da Microsoft 365.

Passaggio 5: consegna in Microsoft 365. Microsoft 365 riceve l'email dall'IP del servizio di terze parti. Senza il meccanismo Enhanced Filtering for Connectors (EFC), Exchange Online vede l'IP del terzo, non l'IP dell'attaccante. SPF passa (perché l'IP del terzo è nell'SPF del terzo) o fallisce in softfail. DKIM è assente. DMARC fallisce ma la policy p=none non provoca alcun blocco. L'email arriva nella casella di posta.

Perché "skip authentication" è il punto di rottura

Il problema fondamentale è la configurazione del connettore in entrata in Exchange Online. Quando un'organizzazione configura un connettore per ricevere email da un servizio di terze parti (Barracuda, Mimecast, Proofpoint, Sophos), la procedura guidata propone spesso di "fidarsi" dei risultati di autenticazione del terzo, o di "saltare l'autenticazione" per gli IP del connettore. In pratica, molti amministratori attivano questa opzione per evitare falsi positivi: se il terzo ha già verificato SPF/DKIM/DMARC, perché rifarlo?

Il problema: Exchange Online non verifica più l'autenticazione rispetto alla sorgente originale. Consuma gli header Authentication-Results inseriti dal terzo, o peggio, valuta SPF sull'IP del connettore (quella del terzo) invece dell'IP del mittente reale. L'header Authentication-Results visibile nella casella di posta riflette i risultati visti dal terzo, non quelli della sorgente reale.

Microsoft ha introdotto Enhanced Filtering for Connectors (EFC) per correggere questo problema. EFC chiede a Exchange Online di risalire la catena Received per identificare l'IP del mittente originale, saltando gli IP noti del servizio di terze parti (la "skip list"). Ma EFC non è attivato per impostazione predefinita. Le organizzazioni che non hanno configurato EFC, o che lo hanno configurato con una skip list incompleta, restano vulnerabili.

Il self-spoofing: l'email interna che non lo è

Il colpo di grazia di questo attacco è il self-spoofing. L'attaccante inserisce lo stesso dominio nei campi From e To: hr@captaindns.com invia a marco.rossi@captaindns.com. Per il destinatario, l'email sembra provenire da un collega. Ma il meccanismo è più insidioso: molte organizzazioni configurano regole di trasporto Exchange che trattano le email "interne" in modo diverso. Un'email il cui dominio From è un dominio interno può non ricevere il banner "Questa email proviene da un mittente esterno", non essere sottoposta agli stessi filtri antiphishing e essere visualizzata senza avviso visivo. L'attaccante sfrutta non solo la fiducia umana, ma anche le eccezioni di sicurezza configurate per le comunicazioni interne.

Il ruolo critico del servizio di terze parti

Il problema centrale è che il servizio di terze parti agisce come un "riciclatore" involontario di autenticazione. Quando ritrasmette il messaggio a Microsoft 365, sostituisce il contesto di autenticazione originale:

• L'IP sorgente cambia. Microsoft 365 vede l'IP del servizio di terze parti, non quella dell'attaccante. La verifica SPF si esegue sull'IP errata.
• Gli header Authentication-Results del terzo non sono affidabili. Microsoft 365 non ha motivo di fidarsi dei risultati di autenticazione inseriti dal terzo.
• Il Return-Path può essere riscritto. Alcuni servizi di terze parti riscrivono l'envelope SMTP, confondendo ulteriormente le tracce.

Microsoft ha documentato che anche i servizi di terze parti che verificano correttamente SPF/DKIM/DMARC e inseriscono gli header corretti non risolvono il problema se Microsoft 365 non sa guardare oltre l'IP del terzo per trovare l'IP del mittente originale.

È esattamente il problema che risolve Enhanced Filtering for Connectors: permette a Exchange Online di "saltare" l'IP del terzo nella catena Received e di valutare l'autenticazione sull'IP reale del mittente.

Qual è l'ampiezza del problema?

Il routing MX indiretto non è una configurazione marginale. Secondo i dati pubblicati dai team di sicurezza di Microsoft, una proporzione significativa dei tenant Microsoft 365 utilizza un servizio di terze parti davanti a Exchange Online. Le ragioni sono molteplici e spesso storiche:

• Eredità della migrazione: molte organizzazioni sono migrate a Microsoft 365 da un hosting on-premise. Avevano già un servizio antispam di terze parti (Barracuda, Mimecast, Proofpoint, Sophos) e hanno conservato il routing esistente durante la migrazione.
• Requisiti normativi: certi settori (finanza, sanità, pubblica amministrazione) impongono un'archiviazione o un filtraggio delle email da parte di un servizio di terze parti certificato. Il routing MX indiretto è il mezzo tecnico abituale per soddisfare questo requisito.
• Strategia di difesa in profondità: alcuni team di sicurezza ritengono che sovrapporre due livelli di filtraggio (terze parti + Defender) offra una protezione migliore. È vero per il filtraggio antispam, ma il costo in termini di autenticazione è raramente misurato.
• Mancata conoscenza del rischio: prima dell'avviso di gennaio 2026, il legame tra routing MX indiretto e indebolimento dell'autenticazione email non era ampiamente documentato. La maggior parte delle guide di deployment dei servizi di terze parti non menziona l'impatto su SPF/DKIM/DMARC lato Microsoft 365.

Il risultato: organizzazioni che investono nella sicurezza email (acquisto di un servizio antispam premium, deployment di DMARC) si ritrovano paradossalmente più vulnerabili di quelle che utilizzano unicamente Defender con un MX diretto.

Tycoon2FA: la piattaforma PhaaS che sfrutta questa falla

Un servizio di phishing chiavi in mano

Tycoon2FA è una piattaforma di phishing-as-a-service (PhaaS) attiva da agosto 2023, identificata e documentata da Sekoia.io e dal Threat Intelligence Center di Microsoft. Funziona come un SaaS per cybercriminali: gli operatori pagano un abbonamento (circa 120 dollari al mese su canali Telegram dedicati) e ricevono in cambio un'infrastruttura completa di phishing con dashboard, template di email, pagine di login clonate e raccolta automatizzata delle credenziali. La barriera d'ingresso è quasi nulla: non è richiesta alcuna competenza tecnica, il kit fornisce tutto, dal dominio di phishing alla pagina di raccolta.

L'ampiezza dell'operazione è massiva. Secondo le stime consolidate dei team di Threat Intelligence di Microsoft e di Sekoia.io, Tycoon2FA genera più di 30 milioni di email di phishing al mese attraverso l'insieme dei suoi operatori. Microsoft ha riferito di aver bloccato il 62 % delle email di phishing dirette ai suoi utenti nel primo semestre 2025, ma il volume restante basta a compromettere migliaia di account. Nel marzo 2026, Europol ha tentato di smantellare l'infrastruttura di Tycoon2FA nell'ambito di un'operazione coordinata. La piattaforma era nuovamente operativa in 48 ore, avendo migrato i suoi server verso nuove giurisdizioni.

Ciò che distingue Tycoon2FA dai kit di phishing classici è la sua capacità di aggirare l'autenticazione a più fattori (MFA) tramite una tecnica di adversary-in-the-middle (AiTM).

Il meccanismo AiTM in dettaglio

Il funzionamento tecnico si basa su un reverse proxy trasparente. Il punto cruciale: l'MFA non protegge da questo attacco perché il proxy non intercetta il secondo fattore in sé. Intercetta il cookie di sessione emesso da Microsoft 365 dopo che l'utente ha completato con successo l'intera catena di autenticazione, MFA inclusa. La vittima si autentica normalmente, sulla vera infrastruttura Microsoft, ma il token di sessione viene catturato in transito.

Ecco lo svolgimento completo:

1. La vittima riceve un'email di phishing che impersona un dominio interno tramite il meccanismo di routing MX descritto in precedenza.
2. Il link nell'email passa attraverso una catena di reindirizzamenti. Microsoft ha documentato l'uso di reindirizzamenti tramite Google Maps (maps.google.com/url?q=...) per aggirare i filtri di reputazione. La tecnica è devastante: i filtri email ispezionano il dominio del link, vedono maps.google.com (un dominio affidabile con reputazione massima) e lasciano passare. Il parametro q= contiene l'URL reale della pagina di phishing, ma i filtri non decodificano sistematicamente i reindirizzamenti annidati. L'URL finale porta a una pagina di phishing ospitata su un dominio effimero.
3. La pagina di phishing agisce come un proxy trasparente verso la vera pagina di login di Microsoft 365. Il server Tycoon2FA si posiziona tra il browser della vittima e login.microsoftonline.com. Visivamente, la vittima vede un'interfaccia di login identica a quella di Microsoft, con il logo dell'organizzazione, i colori personalizzati e il branding Entra ID.
4. La vittima inserisce il suo identificativo e la sua password. Il proxy trasmette le credenziali a Microsoft 365 in tempo reale. Microsoft le valida normalmente.
5. Microsoft 365 richiede il secondo fattore (MFA). Il proxy ritrasmette la richiesta MFA alla vittima. La vittima inserisce il suo codice TOTP o approva la notifica push. Dal punto di vista di Microsoft, l'autenticazione è legittima.
6. Il proxy cattura il cookie di sessione. Una volta completata l'autenticazione, Microsoft 365 emette un cookie di sessione. Il proxy lo intercetta prima di trasmetterlo alla vittima. La vittima riceve un cookie valido e accede alla sua casella email normalmente, senza sospettare nulla.
7. L'attaccante usa il cookie di sessione rubato per accedere all'account da un altro browser, senza bisogno di ripassare l'MFA. Il cookie è valido per la durata della sessione (spesso 24 ore o più secondo la policy dell'organizzazione). L'attaccante può leggere le email, esfiltrare file da OneDrive, inviare email a nome della vittima e propagarsi lateralmente nell'organizzazione.

Le cifre documentate da Microsoft

I dati pubblicati da Microsoft nel suo bollettino di gennaio 2026 rivelano l'ampiezza dello sfruttamento:

Metrica	Valore
Email malevole bloccate da Defender (ottobre 2025)	13 milioni
Piattaforma PhaaS principale identificata	Tycoon2FA
Tecnica di aggiramento MFA	Adversary-in-the-middle (AiTM)
Tecnica di offuscamento URL	Reindirizzamenti Google Maps
Principali esche	Reimpostazione password, messaggi HR, documenti condivisi
Vettore di ingresso	Routing MX indiretto + SPF ~all + DKIM assente + DMARC p=none

Questi 13 milioni di email riguardano unicamente i messaggi bloccati da Defender. Le organizzazioni senza Defender for Office 365, o con configurazioni di filtraggio meno restrittive, non hanno beneficiato di questa protezione.

Le esche utilizzate

Le campagne Tycoon2FA documentate da Microsoft sfruttano scenari ad alta urgenza percepita:

• Reimpostazione password: "La tua password scade tra 24 ore. Clicca qui per rinnovarla." Il link porta alla pagina AiTM.
• Messaggi HR: "Nuovo documento da firmare per l'aggiornamento del tuo contratto." L'allegato o il link reindirizza alla pagina di phishing.
• Documenti condivisi: "Maria Rossi ha condiviso un file con te su OneDrive." L'email imita una notifica SharePoint legittima.
• Self-spoofing: nei casi più sofisticati, l'indirizzo From è identico all'indirizzo To. La vittima riceve un'email che sembra provenire da se stessa o da un collega dello stesso dominio.

Il self-spoofing è particolarmente efficace perché gli utenti si fidano delle email provenienti dal proprio dominio. Un'email da hr@captaindns.com ricevuta da un dipendente di captaindns.com non attiva alcun allarme umano.

Analisi forense degli header: rilevare l'attacco

Quando un'email sospetta arriva in una casella Microsoft 365, gli header contengono le prove del routing anomalo. Ecco come leggerli con un analizzatore di header email.

Esempio di header di un'email falsificata

Ecco un esempio realistico anonimizzato di header provenienti da un'email di phishing che sfrutta il routing MX indiretto. Tutti i segnali d'allarme sono presenti simultaneamente:

Return-Path: <bounce@malicious-relay.net>
Received: from mail-protection.captaindns.com (10.0.0.5) by
 exchange01.captaindns.com (10.0.0.10) with SMTP; Thu, 9 Jan 2026 08:15:23 +0000
Received: from gateway.thirdparty-filter.com (203.0.113.50) by
 mail-protection.captaindns.com with ESMTPS; Thu, 9 Jan 2026 08:15:21 +0000
Received: from unknown (198.51.100.77) by
 gateway.thirdparty-filter.com with SMTP; Thu, 9 Jan 2026 08:15:19 +0000
Authentication-Results: mail-protection.captaindns.com;
 spf=softfail (sender IP is 198.51.100.77) smtp.mailfrom=captaindns.com;
 dkim=none (message not signed);
 dmarc=fail action=none header.from=captaindns.com;
X-MS-Exchange-Organization-SCL: 5
From: Direzione HR <hr@captaindns.com>
To: marco.rossi@captaindns.com
Subject: Documento di policy HR da firmare - Azione richiesta

Analisi riga per riga

Return-Path: <bounce@malicious-relay.net>

Il Return-Path rivela l'indirizzo di rimbalzo reale. Il dominio malicious-relay.net non ha alcun legame con captaindns.com. Questa discrepanza tra il Return-Path e il From visualizzato (hr@captaindns.com) è il primo segnale d'allarme. In un'email legittima inviata da Microsoft 365, il Return-Path contiene il dominio dell'organizzazione o un sottodominio di protection.outlook.com. Qui appare l'infrastruttura dell'attaccante.

Catena Received (letta dal basso verso l'alto):

Received: from unknown (198.51.100.77) by
 gateway.thirdparty-filter.com with SMTP

Primo salto: l'email parte da un IP sconosciuto (198.51.100.77) identificato come unknown dal servizio di terze parti. È il server dell'attaccante. L'assenza di risoluzione DNS inversa (nessun hostname verificato) è un segnale forte: i server email legittimi hanno un record PTR configurato. L'uso di SMTP semplice (non ESMTPS) conferma che il mittente non supporta la cifratura TLS, il che è anomalo per un server aziendale nel 2026.

Received: from gateway.thirdparty-filter.com (203.0.113.50) by
 mail-protection.captaindns.com with ESMTPS

Secondo salto: il servizio di terze parti (gateway.thirdparty-filter.com) ritrasmette verso Exchange Online. È questo IP (203.0.113.50) che Microsoft 365 vede come sorgente. Il contesto di autenticazione viene valutato su questo IP, non su 198.51.100.77. Il servizio di terze parti ha accettato il messaggio e lo ha trasmesso.

Received: from mail-protection.captaindns.com (10.0.0.5) by
 exchange01.captaindns.com (10.0.0.10) with SMTP

Terzo salto: routing interno di Microsoft 365 verso la casella di posta. Gli indirizzi IP in 10.x.x.x confermano un routing interno. Questo salto è normale.

Authentication-Results: il triplo fallimento

Questa è la riga più rivelatrice, e contiene tre fallimenti simultanei:

• spf=softfail (sender IP is 198.51.100.77): l'IP sorgente reale (198.51.100.77, il server dell'attaccante) non è nell'SPF di captaindns.com. Con un meccanismo ~all, è un softfail, non un reject. Il softfail viene trattato come un avvertimento, non come un blocco.
• dkim=none (message not signed): nessuna firma DKIM è presente. L'attaccante non possiede la chiave privata DKIM di captaindns.com, quindi non può firmare. Il servizio di terze parti non ha aggiunto una firma. L'assenza di DKIM priva DMARC del suo secondo vettore di allineamento.
• dmarc=fail action=none: DMARC fallisce (né SPF né DKIM passano con allineamento di dominio). Ma action=none significa che la policy DMARC del dominio è p=none, quindi nessuna azione viene intrapresa nonostante il fallimento. L'email viene consegnata normalmente.

X-MS-Exchange-Organization-SCL: 5

Lo Spam Confidence Level (SCL) è a 5 su una scala da 0 a 9. Un SCL di 5 indica un livello di sospetto moderato. Per impostazione predefinita, Exchange Online mette in quarantena i messaggi con un SCL di 6 o superiore. Un SCL di 5 passa appena sotto la soglia di blocco predefinita. Defender ha rilevato segnali sospetti (fallimenti di autenticazione, Return-Path incoerente), ma non abbastanza per bloccare categoricamente con la configurazione attuale.

From e To sullo stesso dominio: self-spoofing

Il From mostra Direzione HR <hr@captaindns.com> e il To è marco.rossi@captaindns.com. Stesso dominio. In Outlook, l'utente vede un'email da "Direzione HR" con la foto e il titolo di lavoro associati a hr@captaindns.com nella rubrica. Il banner "Questa email proviene da un mittente esterno" può essere assente se l'organizzazione ha configurato eccezioni per i domini interni.

Subject: Documento di policy HR da firmare - Azione richiesta

L'oggetto combina due leve psicologiche: l'autorità ("Direzione HR", "policy HR") e l'urgenza ("Azione richiesta"). Questo tipo di esca è documentato da Microsoft come uno dei più efficaci nelle campagne Tycoon2FA.

Confronto con un'email legittima

Per contrasto, ecco gli header di un'email legittima inviata dalla stessa organizzazione:

Return-Path: <hr@captaindns.com>
Authentication-Results: mail-protection.captaindns.com;
 spf=pass (sender IP is 40.107.22.83) smtp.mailfrom=captaindns.com;
 dkim=pass (signature was verified) header.d=captaindns.com;
 dmarc=pass action=none header.from=captaindns.com;
X-MS-Exchange-Organization-SCL: 1
From: Direzione HR <hr@captaindns.com>
To: marco.rossi@captaindns.com

Le differenze sono nette: il Return-Path corrisponde al dominio From, SPF passa con un IP Microsoft (40.107.x.x), DKIM passa con una firma verificata, DMARC passa e l'SCL è a 1 (fiducia elevata). È il profilo tipico di un'email legittima.

Cosa rivela l'insieme

Combinando questi elementi, la diagnosi è chiara:

1. L'email non proviene dall'infrastruttura di captaindns.com (Return-Path su malicious-relay.net)
2. È transitata attraverso un servizio di terze parti che non ha bloccato l'impersonificazione
3. Triplo fallimento di autenticazione: SPF softfail, DKIM assente, DMARC fail senza conseguenze
4. L'SCL moderato indica che Defender ha dei dubbi, ma la configurazione attuale non permette il blocco
5. Il self-spoofing (stesso dominio in From e To) sfrutta la fiducia nelle comunicazioni interne

Per rilevare sistematicamente questo tipo di email, analizza i tuoi header con un analizzatore di header e cerca questi quattro marcatori: catena Received con salto inatteso da un IP sconosciuto, spf=softfail, dkim=none e dmarc=fail action=none.

Diagnosi in 5 minuti: il tuo dominio è vulnerabile?

Tre comandi DNS bastano per valutare la tua esposizione. Apri un terminale ed esegui le seguenti verifiche.

Verifica 1: dove punta il tuo MX?

dig MX captaindns.com +short

Risultato sicuro:

10 captaindns-com.mail.protection.outlook.com.

Il MX punta direttamente a Microsoft 365. Le email arrivano senza intermediari. L'autenticazione viene valutata sull'IP del mittente originale.

Risultato a rischio:

10 mx.filtro-terze-parti.com.
20 mx2.filtro-terze-parti.com.

Il MX punta a un servizio di terze parti. Tutte le email in entrata passano attraverso questo intermediario prima di raggiungere Microsoft 365. Se Enhanced Filtering for Connectors non è attivato, l'autenticazione viene valutata sull'IP del terzo.

Risultato misto (da verificare):

10 mx.filtro-terze-parti.com.
20 captaindns-com.mail.protection.outlook.com.

Il MX prioritario è il servizio di terze parti, ma Microsoft 365 è come backup. In funzionamento normale, tutto il traffico passa dal terzo. Il rischio è identico allo scenario precedente.

Verifica 2: qual è la tua policy DMARC?

dig TXT _dmarc.captaindns.com +short

Risultato vulnerabile:

"v=DMARC1; p=none; rua=mailto:dmarc@captaindns.com"

La policy p=none significa che i fallimenti DMARC vengono segnalati ma non viene intrapresa alcuna azione sulle email. Combinata con un routing MX indiretto, è una porta aperta.

Risultato parzialmente protetto:

"v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@captaindns.com"

La policy p=quarantine mette in spam le email che falliscono DMARC, ma pct=50 significa che solo la metà delle email è sottoposta a questa policy. L'altra metà viene trattata come se la policy fosse p=none.

Risultato protetto:

"v=DMARC1; p=reject; rua=mailto:dmarc@captaindns.com; ruf=mailto:dmarc-forensic@captaindns.com"

La policy p=reject chiede ai server di ricezione di rifiutare le email che falliscono DMARC. È la protezione massima.

Verifica 3: qual è il tuo meccanismo SPF terminale?

dig TXT captaindns.com +short | grep spf

Risultato vulnerabile:

"v=spf1 include:spf.protection.outlook.com ~all"

Il meccanismo ~all (softfail) indica che gli IP non elencati probabilmente non dovrebbero inviare per questo dominio, ma il risultato è un softfail, non un reject. I server di ricezione sono liberi di ignorarlo.

Risultato protetto:

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

Il meccanismo -all (hardfail) indica che qualsiasi IP non elencato è esplicitamente non autorizzato. I server di ricezione che rispettano SPF rifiuteranno queste email.

Matrice di vulnerabilità

MX	DMARC	SPF	DKIM	Livello di rischio
Terze parti	p=none	~all	Assente	Critico
Terze parti	p=none	-all	Assente	Elevato
Terze parti	p=quarantine	~all	Assente	Elevato
Terze parti	p=quarantine	-all	Attivo	Moderato
Terze parti	p=reject	-all	Attivo	Basso (se EFC attivato)
Diretto M365	p=reject	-all	Attivo	Minimo

Se il tuo dominio si trova nelle righe "Critico" o "Elevato", la correzione è urgente. Passa alla sezione successiva.

Piano di correzione in 5 passaggi

Passaggio 1: DMARC progressivo verso p=reject

Non passare mai direttamente da p=none a p=reject. L'escalation progressiva evita di bloccare email legittime di cui non conosci l'esistenza (newsletter, SaaS, CRM che inviano a nome del tuo dominio).

Fase 1: monitoraggio (2 settimane minimo)

_dmarc.captaindns.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@captaindns.com; ruf=mailto:dmarc-forensic@captaindns.com; fo=1"

L'opzione fo=1 richiede un rapporto forense per ogni fallimento individuale (SPF o DKIM), non solo quando entrambi falliscono. Analizza i rapporti aggregati (rua) per identificare tutte le sorgenti di invio legittime.

Fase 2: quarantena progressiva (2 settimane)

_dmarc.captaindns.com.  IN  TXT  "v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@captaindns.com"

Solo il 10 % delle email che falliscono DMARC viene messo in quarantena. Monitora i rapporti e le segnalazioni degli utenti.

Fase 3: quarantena completa (2 settimane)

_dmarc.captaindns.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@captaindns.com"

Il 100 % dei fallimenti viene messo in quarantena. Se non viene segnalato alcun falso positivo, passa alla fase successiva.

Fase 4: reject progressivo (1 settimana)

_dmarc.captaindns.com.  IN  TXT  "v=DMARC1; p=reject; pct=10; rua=mailto:dmarc-reports@captaindns.com"

Il 10 % dei fallimenti viene rifiutato, il resto resta in quarantena.

Fase 5: reject completo

_dmarc.captaindns.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@captaindns.com; ruf=mailto:dmarc-forensic@captaindns.com"

Protezione massima. Ogni email che fallisce DMARC viene rifiutata dal server di ricezione.

Il processo completo richiede circa 7-9 settimane. Non abbreviare le fasi: ogni periodo di osservazione rivela sorgenti di invio che avevi dimenticato. Un servizio di fatturazione SaaS, un vecchio strumento di marketing, un modulo di contatto che invia tramite un ESP non configurato nel tuo SPF.

Passaggio 2: SPF in hardfail (-all)

Sostituisci ~all con -all nel tuo record SPF:

captaindns.com.  IN  TXT  "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"

Prima di modificare, verifica che tutte le tue sorgenti di invio legittime siano incluse nel record SPF. Un hardfail combinato con una sorgente dimenticata bloccherà email legittime.

Punti di attenzione:

• Numero di lookup DNS: SPF consente un massimo di 10 lookup DNS ricorsivi. Ogni include: conta come un lookup, più quelli annidati. Oltre 10, il risultato è un permerror e la valutazione fallisce.
• Includi tutte le tue sorgenti: Microsoft 365, Google Workspace, ESP (Mailgun, SendGrid, Amazon SES), CRM (HubSpot, Salesforce), strumenti di ticketing.
• Testa prima di pubblicare: utilizza il nostro strumento di verifica DMARC per validare la tua configurazione prima di metterla in produzione.

Passaggio 3: attivare DKIM

DKIM è il pezzo mancante nella maggior parte delle configurazioni vulnerabili. Senza DKIM, DMARC può appoggiarsi solo su SPF per l'allineamento. Se SPF fallisce (il che avviene sistematicamente in uno scenario di routing indiretto), anche DMARC fallisce.

In Microsoft 365:

1. Accedi al portale Defender (security.microsoft.com)
2. Naviga a Email & collaboration > Policies & rules > Threat policies > Email Authentication Settings > DKIM
3. Seleziona il tuo dominio
4. Attiva "Sign messages for this domain with DKIM signatures"
5. Microsoft genera due record CNAME da pubblicare nel tuo DNS:

selector1._domainkey.captaindns.com.  CNAME  selector1-captaindns-com._domainkey.captaindns.onmicrosoft.com.
selector2._domainkey.captaindns.com.  CNAME  selector2-captaindns-com._domainkey.captaindns.onmicrosoft.com.

6. Pubblica i CNAME, attendi la propagazione DNS (generalmente da 15 a 30 minuti), poi valida nel portale Defender.

Con DKIM attivo, anche se SPF fallisce a causa del routing indiretto, DMARC può passare tramite l'allineamento DKIM, a condizione che il servizio di terze parti non modifichi il corpo del messaggio né gli header firmati.

Passaggio 4: verificare i connettori e attivare il filtraggio migliorato

Enhanced Filtering for Connectors (EFC) è la soluzione tecnica che Microsoft raccomanda per le organizzazioni che devono conservare un routing MX indiretto. EFC permette a Exchange Online di "guardare oltre" l'IP del servizio di terze parti per trovare l'IP del mittente originale nella catena Received.

Attivazione in Exchange Online:

1. Accedi all'Exchange Admin Center (admin.exchange.microsoft.com)
2. Naviga a Mail flow > Connectors
3. Identifica il connettore in entrata dal tuo servizio di terze parti
4. Nelle proprietà del connettore, attiva "Enhanced Filtering for Connectors"
5. Configura gli IP del servizio di terze parti da "saltare" (skip listing)

Una volta attivato EFC, Exchange Online risale la catena Received per trovare l'ultimo IP esterno prima del servizio di terze parti. La valutazione di SPF, DKIM e DMARC viene effettuata su questo IP, ripristinando il contesto di autenticazione corretto.

Punti di attenzione:

• Testa EFC in modalità audit prima di applicarlo in produzione
• Assicurati che gli IP del servizio di terze parti nella skip list siano aggiornati
• Verifica che il servizio di terze parti non riscriva gli header Received in modo da impedire a EFC di trovare l'IP sorgente

Passaggio 5: considerare un MX diretto verso Microsoft 365

La soluzione più radicale e più efficace è eliminare l'intermediario. Se il tuo servizio di terze parti è utilizzato per il filtraggio antispam, Microsoft Defender for Office 365 (piano 1 o piano 2) offre capacità equivalenti o superiori:

• Exchange Online Protection (EOP): incluso in tutte le licenze Microsoft 365, fornisce un filtraggio antispam e antimalware di base.
• Defender for Office 365 Piano 1: aggiunge Safe Links (riscrittura e analisi degli URL in tempo reale), Safe Attachments (detonazione in sandbox) e antiphishing.
• Defender for Office 365 Piano 2: aggiunge Threat Explorer, Automated Investigation and Response (AIR), Attack Simulation Training e Threat Trackers.

Se il servizio di terze parti è utilizzato per l'archiviazione o la conformità, esistono soluzioni di archiviazione che funzionano a valle (journal rules) senza richiedere un routing MX indiretto.

Per passare a MX diretto:

captaindns.com.  IN  MX  10  captaindns-com.mail.protection.outlook.com.

Elimina le vecchie voci MX che puntano al servizio di terze parti. Aggiorna il tuo SPF se necessario. Verifica che i tuoi connettori Exchange Online siano configurati correttamente.

Oltre l'autenticazione email: la questione dell'MFA

Il routing MX indiretto apre la porta al phishing. Ma l'avviso Microsoft ricorda che Tycoon2FA non si limita a rubare password. La piattaforma ruba sessioni autenticate, aggirando l'MFA. La correzione del routing email non basta se il tuo MFA resta vulnerabile agli attacchi AiTM.

Perché l'MFA classico non protegge più

L'MFA basato su codici TOTP (app di autenticazione come Microsoft Authenticator in modalità codice, Google Authenticator) o notifiche push è vulnerabile ai proxy AiTM. Il meccanismo è strutturale: il codice TOTP è un segreto condiviso tra l'utente e il server. Se un proxy si posiziona tra i due, cattura il codice in transito e lo riproduce immediatamente. La notifica push è ancora più facile da sfruttare: il proxy innesca la richiesta di autenticazione sul vero server, l'utente approva sul suo telefono e il proxy cattura il cookie di sessione risultante.

Questo non significa che l'MFA sia inutile. Protegge sempre dal credential stuffing, dagli attacchi a dizionario e dalle fughe di database. Ma contro il phishing AiTM, serve una soluzione resistente al phishing.

FIDO2 e passkey: l'unica soluzione resistente al phishing

Le chiavi FIDO2 (YubiKey, Feitian, Google Titan) e le passkey (implementate in Windows Hello, Apple iCloud Keychain, Android) offrono una resistenza nativa al phishing. Il meccanismo si basa sul binding all'origine (origin binding):

1. Durante la registrazione, la chiave FIDO2 o la passkey viene legata a un dominio preciso (ad esempio, login.microsoftonline.com).
2. Durante l'autenticazione, il browser verifica automaticamente che il dominio della pagina corrisponda al dominio registrato. Se la pagina è un proxy di phishing su login-microsoftonline.attacker.com, il browser rifiuta di inviare le credenziali.
3. Nessun segreto condiviso da intercettare. L'autenticazione utilizza un meccanismo challenge-response basato su una coppia di chiavi asimmetriche. Anche se l'attaccante intercetta lo scambio, non può riprodurlo.

Un proxy AiTM non può aggirare questo meccanismo: il browser verifica l'origine a un livello che il proxy non può falsificare. È la ragione per cui Microsoft, Google e Apple spingono collettivamente l'adozione delle passkey dal 2024.

MFA number matching come soluzione intermedia

Se il deployment di FIDO2/passkey non è immediato, attiva come minimo il number matching in Microsoft Authenticator. Invece di un semplice "Approva / Rifiuta", l'utente deve inserire un numero a due cifre mostrato sulla schermata di login. Questa misura non protegge da un proxy AiTM sofisticato (il proxy può mostrare il numero), ma blocca gli attacchi MFA fatigue (bombardamento di notifiche push) e aggiunge una frizione che riduce il tasso di successo degli attacchi.

Attivazione in Entra ID:

1. Accedi al Microsoft Entra Admin Center (entra.microsoft.com)
2. Naviga a Protection > Authentication methods > Microsoft Authenticator
3. Nella scheda Configure, attiva "Require number matching for push notifications"
4. Applica a tutti gli utenti o a un gruppo pilota

La priorità resta il deployment di FIDO2/passkey per gli account con privilegi elevati (amministratori, dirigenti, team finanziari), poi l'estensione progressiva a tutti gli utenti.

Il ruolo di ARC nelle catene di relay

Il protocollo ARC (Authenticated Received Chain) è stato progettato precisamente per risolvere il problema della perdita di contesto di autenticazione durante il transito attraverso intermediari. ARC permette a ogni relay di firmare i risultati di autenticazione che ha osservato, creando una catena di fiducia verificabile.

In teoria, se il servizio di terze parti implementa ARC correttamente:

1. Il servizio di terze parti riceve l'email e valuta SPF/DKIM/DMARC
2. Aggiunge un set di header ARC (ARC-Authentication-Results, ARC-Message-Signature, ARC-Seal) documentando i risultati osservati
3. Microsoft 365 riceve l'email e verifica la catena ARC
4. Se la catena ARC è valida e proviene da un mittente ARC affidabile, Microsoft 365 può utilizzare i risultati di autenticazione originali invece dei propri risultati (che sono distorti dal routing indiretto)

In pratica, l'efficacia di ARC dipende da due condizioni: il servizio di terze parti deve implementare ARC (il che non è sistematico), e Microsoft 365 deve fidarsi del mittente ARC (configurabile nel portale Defender). Senza queste due condizioni, ARC non cambia nulla.

Microsoft raccomanda ARC come soluzione complementare, ma non come sostituto di Enhanced Filtering for Connectors o del passaggio a MX diretto.

Sorveglianza e risposta in caso di incidente

La messa in sicurezza del routing email non è un progetto una tantum. Gli attaccanti adattano le loro tecniche, le configurazioni evolvono e nuovi servizi di invio vengono aggiunti regolarmente. Una sorveglianza attiva è necessaria per rilevare rapidamente qualsiasi regressione o tentativo di sfruttamento.

Configurare gli avvisi in Microsoft Defender

Microsoft Defender for Office 365 permette di creare avvisi personalizzati che rilevano i pattern di attacco descritti in questo articolo:

Avviso sui fallimenti DMARC ricorrenti: Nel portale Defender (security.microsoft.com), accedi a Email & collaboration > Explorer. Filtra su DMARC = fail e action = none per il tuo dominio. Se osservi un volume anomalo di fallimenti DMARC senza azione, è il segnale che la tua policy p=none viene sfruttata. Configura un avviso automatizzato per essere notificato quando il volume supera una soglia (ad esempio, più di 50 fallimenti DMARC al giorno per un dominio interno).

Avviso sul self-spoofing: Cerca email dove il campo From contiene un dominio interno ma il Return-Path contiene un dominio esterno. Questo pattern è caratteristico del self-spoofing. In Exchange Online, una regola del flusso di posta (transport rule) può rilevare questa condizione e aggiungere un avviso visivo al messaggio o metterlo in quarantena.

Monitoraggio dei rapporti DMARC aggregati: I rapporti DMARC aggregati (inviati all'indirizzo rua) contengono i risultati di autenticazione di tutte le email inviate a nome del tuo dominio. Analizzali almeno una volta alla settimana. Un picco improvviso di fallimenti da IP sconosciuti indica una campagna di impersonificazione in corso. Strumenti gratuiti come DMARC Analyzer, Postmark DMARC o i rapporti aggregati di Microsoft permettono di visualizzare questi dati senza elaborazione manuale.

Cosa fare se rilevi un attacco in corso?

Se identifichi email di phishing che sfruttano il routing MX indiretto contro il tuo dominio:

1. Attiva immediatamente EFC se non lo hai già fatto. È la misura più rapida per ripristinare il contesto di autenticazione corretto.
2. Porta DMARC a p=quarantine come minimo, anche senza l'escalation progressiva raccomandata. In una situazione di attacco attivo, il rischio di falsi positivi è secondario rispetto al rischio di compromissione.
3. Blocca gli IP sorgente identificati negli header Received tramite le regole del flusso di posta di Exchange Online o tramite il servizio di terze parti.
4. Informa gli utenti interessati. Se sono state consegnate email di self-spoofing, gli utenti devono sapere che non devono cliccare sui link né aprire gli allegati.
5. Verifica le connessioni sospette nei log di audit di Entra ID. Se l'attacco AiTM è riuscito a catturare cookie di sessione, vedrai connessioni da IP insoliti poco dopo la consegna delle email di phishing.
6. Revoca le sessioni attive degli account potenzialmente compromessi tramite Entra ID (Revoke Sessions). Forza un cambio password e una riautenticazione MFA.

Automatizzare il rilevamento a lungo termine

Per le organizzazioni con un volume significativo di email, l'automatizzazione del rilevamento è indispensabile. Microsoft Sentinel (il SIEM cloud di Microsoft) può ingerire i log di Exchange Online e attivare playbook automatizzati alle seguenti condizioni:

• Volume anomalo di email con dmarc=fail action=none per un dominio interno
• Email in entrata dove il dominio From è un dominio interno ma l'IP sorgente non è nella lista degli IP autorizzati
• Connessioni Entra ID da un IP geograficamente incoerente nei minuti successivi alla consegna di un'email sospetta

Queste automatizzazioni trasformano un rilevamento reattivo ("abbiamo trovato un'email sospetta") in un rilevamento proattivo ("il sistema ha isolato l'email e bloccato l'account prima che l'utente cliccasse").

Checklist di messa in sicurezza completa

Ecco la checklist consolidata per mettere in sicurezza il tuo dominio contro il vettore di attacco documentato da Microsoft. Ogni elemento è classificato per priorità.

Priorità critica (settimana 1)

• Verificare il tuo MX: dig MX captaindns.com +short
• Verificare la tua policy DMARC: dig TXT _dmarc.captaindns.com +short
• Verificare il tuo meccanismo SPF terminale: dig TXT captaindns.com +short
• Se MX indiretto + DMARC p=none: attivare Enhanced Filtering for Connectors immediatamente
• Attivare DKIM per il tuo dominio in Microsoft 365

Priorità alta (settimane 2-4)

• Iniziare l'escalation progressiva di DMARC verso p=quarantine
• Sostituire SPF ~all con -all dopo inventario delle sorgenti di invio
• Verificare i connettori in entrata in Exchange Online
• Verificare la configurazione IP della skip list per EFC
• Attivare il number matching in Microsoft Authenticator

Priorità media (mesi 2-3)

• Continuare l'escalation DMARC verso p=reject
• Valutare la migrazione verso un MX diretto verso Microsoft 365
• Iniziare il deployment di FIDO2/passkey per gli account con privilegi
• Configurare i mittenti ARC affidabili se il routing indiretto viene mantenuto
• Mettere in atto un monitoraggio regolare dei rapporti DMARC aggregati

Priorità bassa (trimestre successivo)

• Estendere FIDO2/passkey a tutti gli utenti
• Eliminare il routing MX indiretto se non necessario
• Automatizzare l'analisi dei rapporti DMARC con uno strumento dedicato
• Formare gli utenti a riconoscere le email di phishing

Cosa cambia l'avviso Microsoft per la tua organizzazione

L'avviso di gennaio 2026 non ha rivelato un bug. Ha messo in luce un punto cieco architetturale che gli attaccanti sfruttano su larga scala. La combinazione routing MX indiretto + SPF softfail + DKIM assente + DMARC p=none è una configurazione che migliaia di organizzazioni utilizzano senza sapere che è vulnerabile.

La correzione non è una patch software. È un lavoro di configurazione DNS e architettura email. Alcune organizzazioni correggeranno in un giorno (attivare DKIM, passare SPF a hardfail, attivare EFC). Altre avranno bisogno di diversi mesi per migrare il loro MX e deployare FIDO2.

Le tre azioni immediate:

1. Fai la diagnosi adesso. I tre comandi dig della sezione diagnosi richiedono 30 secondi. Saprai immediatamente se il tuo dominio è nella zona critica.
2. Attiva Enhanced Filtering for Connectors se il tuo MX punta a un terzo. È la correzione più rapida con il miglior rapporto impatto/sforzo.
3. Attiva DKIM. È il pezzo che manca nella maggior parte delle configurazioni vulnerabili. Con DKIM attivo, DMARC può passare anche quando SPF fallisce a causa del routing indiretto.

L'obiettivo finale è semplice: il tuo dominio deve essere protetto da SPF -all, DKIM attivo e DMARC p=reject. Non è un ideale teorico, è la baseline che Google, Yahoo e Microsoft richiedono ai mittenti dal 2024. L'avviso di gennaio 2026 ricorda che le email finiscono in spam quando questa baseline non viene raggiunta, e peggio, che gli attaccanti sfruttano attivamente i domini che non la rispettano.