Falso allarme bomba in 6.000 scuole: analisi tecnica della mail e perché servono le intestazioni complete

L’11 novembre 2026 una mail firmata “Mikhail Andropov, leader del Vilayat di Misoginistan” ha annunciato un ordigno esplosivo in circa seimila scuole italiane, provocando evacuazioni da un capo all’altro del Paese. Online è circolato lo screenshot di uno di quei messaggi. Lo abbiamo guardato con l’occhio di chi lavora ogni giorno con server di posta, DNS e reti: cosa racconta, cosa non può raccontare e perché, per un’analisi seria, servirebbe la mail originale con le intestazioni complete.

Poco prima delle dieci di mercoledì 11 novembre migliaia di caselle di posta istituzionali delle scuole italiane hanno ricevuto lo stesso messaggio, con oggetto “Avviso di pericolo”. Secondo il Ministero dell’Istruzione e del Merito gli istituti raggiunti sono stati circa seimila; diverse fonti parlano di 6.300. Molti dirigenti hanno fatto uscire studenti e personale, altri, su indicazione delle forze dell’ordine, non lo hanno fatto. Nessun ordigno è stato trovato. La Procura di Genova ha aperto un fascicolo per procurato allarme, interruzione di pubblico servizio e minacce gravi, e le indagini sono affidate alla Polizia Postale e alla Digos.

Non è un episodio isolato. Il 2 novembre un messaggio simile era arrivato a circa 280 dirigenti scolastici, e lo stesso giorno dell’ondata italiana circa trecento scuole dell’Irlanda del Nord e un migliaio di istituti in Scozia hanno ricevuto un falso allarme identico. Nel Regno Unito una prima ondata risaliva al 19 ottobre.

In questo articolo non facciamo ipotesi su moventi politici o su presunte regie internazionali, che spettano a chi indaga. Ci limitiamo a quello che sappiamo fare: leggere una mail come la leggerebbe un sistemista, separare ciò che si vede da ciò che si suppone, e spiegare quali dati servirebbero per andare oltre.

Lo screenshot che è girato online

L’immagine che è circolata sui social è la stampa di un messaggio aperto in Outlook, fotografata o scansionata e poi condivisa con alcune parole del testo coperte da riquadri rossi. Nella versione che pubblichiamo abbiamo oscurato anche il nome del mittente e la parte locale del suo indirizzo, lasciando visibile il dominio: secondo le prime ricostruzioni giornalistiche l’account appartiene a un’ex studentessa, che in questa storia è con ogni probabilità una vittima e non una responsabile.

Già da questa immagine, senza alcun file originale, si possono fare diverse osservazioni.

Il mittente: un account di un’università di Taiwan

Il campo “Da” mostra un nome in caratteri cinesi tradizionali e un indirizzo sul dominio cloud.dyu.edu.tw. Il dominio appartiene alla Da-Yeh University, un ateneo privato di Taiwan, e la parte locale dell’indirizzo, una lettera seguita da cifre, ha tutto l’aspetto di una matricola. È il formato tipico delle caselle che gli atenei assegnano agli studenti.

Abbiamo interrogato il DNS pubblico del dominio. Il record MX di cloud.dyu.edu.tw punta a cloud-dyu-edu-tw.mail.protection.outlook.com: la posta degli studenti è quindi ospitata su Microsoft 365, Exchange Online. Lo stesso vale per il dominio dei destinatari, istruzione.it, il cui MX è istruzione-it.mail.protection.outlook.com. In altre parole il messaggio, con ogni probabilità, è passato da un tenant Microsoft 365 a un altro tenant Microsoft 365.

Davanti a un mittente così le strade tecniche sono due:

• Account compromesso: qualcuno è entrato nella casella dello studente, per esempio con credenziali raccolte da un infostealer e rivendute in qualche canale Telegram, e l’ha usata per spedire i messaggi. Il vantaggio per l’attaccante è evidente: le mail partono davvero dai server Microsoft dell’università, superano tutti i controlli di autenticazione e godono della buona reputazione di un dominio accademico.
• Spoofing: qualcuno ha scritto quell’indirizzo nel campo From: di un messaggio inviato da tutt’altro server, approfittando di una configurazione debole del dominio.

Le prime notizie diffuse dalla stampa, che parlano di un profilo compromesso di un’ex studentessa, vanno nella direzione della prima ipotesi. I record DNS del dominio aiutano a capire perché questa sia anche quella tecnicamente più plausibile.

SPF, DKIM e DMARC: cosa dice il DNS

Per difendere un dominio dalla falsificazione del mittente esistono tre strumenti, che lavorano insieme:

• SPF dichiara quali server sono autorizzati a spedire posta per il dominio;
• DKIM aggiunge una firma crittografica al messaggio, verificabile con una chiave pubblicata nel DNS;
• DMARC dice ai destinatari cosa fare quando SPF e DKIM non tornano, e soprattutto lega questi controlli all’indirizzo che l’utente vede nel campo From:.

Ecco cosa abbiamo trovato interrogando il DNS il 12 novembre 2026:

Il dominio dell’università ha un record SPF corretto e restrittivo: v=spf1 include:spf.protection.outlook.com -all, cioè “solo i server di Microsoft 365 possono spedire per me, tutto il resto va rifiutato”. Non abbiamo però trovato alcun record DMARC, né sul sottodominio cloud.dyu.edu.tw né sul dominio principale dyu.edu.tw, e nemmeno i selettori DKIM che Microsoft 365 usa per i domini personalizzati.

È una configurazione incompleta, piuttosto comune nel mondo accademico, ma da sola non basta a spiegare l’arrivo in massa dei messaggi. Un messaggio falsificato, spedito da un server qualunque, fallirebbe il controllo SPF con un “-all” netto, e Exchange Online, che riceve la posta del Ministero, applica una propria valutazione anti-spoofing anche in assenza di una politica DMARC del mittente. Difficilmente migliaia di messaggi falsificati sarebbero finiti tutti in posta in arrivo. Un account reale, invece, spedisce dai server Microsoft autorizzati e supera ogni verifica. Ecco perché l’ipotesi dell’account violato è di gran lunga la più probabile.

Dall’altra parte, il dominio istruzione.it è configurato in modo esemplare: SPF restrittivo, DKIM attivo e una politica DMARC p=reject. Ma questi controlli proteggono il dominio del Ministero dalla falsificazione, non le sue caselle dai messaggi in arrivo da un mittente legittimo che è stato compromesso. È il limite strutturale di tutti questi strumenti: verificano che un messaggio venga davvero da dove dice, non che chi lo ha scritto abbia buone intenzioni.

I destinatari in chiaro e l’invio a blocchi

Il secondo dettaglio che salta all’occhio è il campo dei destinatari. Nello screenshot ci sono 21 indirizzi, tutti visibili nel campo A:, senza alcuna copia nascosta. Venti sono caselle di scuole sul dominio istruzione.it, nella forma codice meccanografico più @istruzione.it: istituti comprensivi, istituti superiori e un circolo didattico, sparsi dal Friuli alla Sicilia.

Per chi ha un minimo di esperienza di invii massivi questo è un segnale chiaro: si tratta di un invio a blocchi, probabilmente una ventina di destinatari per messaggio, fatto con uno strumento semplice. Può essere uno script di poche righe che cicla su un elenco e spedisce un messaggio ogni tanto, o un programma di mailing commerciale. Mettere tutti i destinatari nel campo A: anziché in copia nascosta è un errore da principianti, perché rivela a ciascun destinatario l’elenco degli altri.

L’elenco delle scuole non richiede alcuna intrusione. I codici meccanografici e gli indirizzi istituzionali delle scuole sono dati pubblici, consultabili e scaricabili dal portale Open Data del Ministero e da Scuola in Chiaro. Basta uno scraping elementare per costruire una lista di migliaia di indirizzi. Non c’è quindi alcun bisogno di ipotizzare un accesso ai sistemi del Ministero, e infatti nulla nello screenshot lo suggerisce.

Un calcolo spannometrico aiuta a capire la scala. Seimila destinatari divisi in blocchi da venti fanno circa trecento messaggi. Exchange Online applica limiti di invio per casella, nell’ordine di qualche decina di messaggi al minuto e di alcune migliaia di destinatari al giorno: trecento messaggi possono partire da un solo account in una decina di minuti, oppure essere distribuiti su più account per dare meno nell’occhio. Quale delle due sia la verità lo direbbero le intestazioni dei messaggi ricevuti dalle diverse scuole, confrontate tra loro.

Il “canarino”: un indirizzo usa e getta in mezzo alle scuole

Tra le venti caselle istituzionali ce n’è una che non c’entra nulla: kapgqn8khh@tanpony.com. Una sequenza casuale di lettere e numeri su un dominio sconosciuto.

L’interpretazione più ragionevole è che si tratti di un indirizzo di controllo, quello che in gergo si chiama canarino: l’autore lo inserisce in ogni blocco per verificare in tempo reale che i messaggi partano, superino i filtri antispam e arrivino davvero a destinazione. È una pratica nota a chiunque abbia gestito campagne di posta, lecite o meno.

Abbiamo controllato anche questo dominio. tanpony.com è stato registrato presso Gandi il 1° ottobre 2026, sei settimane prima dell’ondata italiana e prima di quella britannica del 19 ottobre. Non risolve verso alcun sito web, ha un proprio server di posta, mail.tanpony.com, su un indirizzo IP di Hetzner a Helsinki, un record SPF che autorizza solo quel server e una politica DMARC p=none. È il profilo tipico dei domini che i servizi di posta temporanea registrano e fanno ruotare continuamente, ma è compatibile anche con un dominio messo in piedi dall’autore stesso per ricevere le proprie copie di controllo. Non abbiamo elementi per scegliere tra le due ipotesi.

In entrambi i casi, quell’indirizzo è un regalo per gli investigatori. Il registrar del dominio e il fornitore del server di posta sono società europee, e un servizio di posta temporanea, anche quando promette anonimato, conserva spesso per qualche tempo l’indirizzo IP di chi ha creato o letto la casella. Inserire quell’indirizzo in un invio di massa significa lasciare un collegamento diretto tra la campagna e una specifica infrastruttura, facilmente interrogabile con gli strumenti di cooperazione giudiziaria europea.

Codici e indirizzi che non tornano

Guardando con attenzione l’elenco dei destinatari emerge un dettaglio che non abbiamo visto segnalato altrove. In almeno tre casi il codice meccanografico scritto nel nome visualizzato non coincide con l’indirizzo email a cui il messaggio è stato spedito:

• “TOIC891300N – IC. STRAMBINO” è associato a toic89130n@istruzione.it;
• “VAIS0190CE – C. FACCHINETTI” è associato a vais01900c@istruzione.it;
• “VIC817029 – IC VICENZA 5” è associato a viic870009@istruzione.it.

Le spiegazioni possibili sono due, e portano in direzioni diverse. La prima è che l’elenco usato dall’autore contenga errori, per esempio perché ricostruito in modo maldestro da fonti diverse o passato attraverso un riconoscimento ottico dei caratteri: sarebbe un’altra conferma della natura artigianale dell’operazione. La seconda è che sia l’immagine circolata online a essere stata alterata: lo screenshot ha l’aspetto di una stampa fotografata e poi ritoccata, forse passata attraverso un programma di miglioramento delle immagini, e strumenti di questo tipo possono letteralmente inventare caratteri che non c’erano. Anche questo dettaglio, da solo, basta a dire che uno screenshot non è una prova e che per ogni analisi seria serve il messaggio originale.

Il testo: un modello scritto in inglese e tradotto

Anche il corpo del messaggio tradisce la sua origine. Senza riportare le frasi più violente, che non aggiungono nulla, alcuni indizi linguistici sono evidenti:

• l’apertura “Questo è Mikhail Andropov” è il calco letterale dell’inglese This is…, una formula che un madrelingua italiano non userebbe mai in un messaggio scritto;
• il testo parla di “un potente ordigno esplosivo” e subito dopo dice “l’ho posizionata”, al femminile: chi traduceva aveva in mente la parola bomba, cioè l’inglese bomb, e il traduttore automatico ha mescolato le due forme;
• il messaggio è identico, a parte la lingua, a quello arrivato alle scuole del Regno Unito: un modello unico, adattato alla lingua di destinazione.

La firma, “Mikhail Andropov, leader del Vilayat di Misoginistan”, è un collage: un cognome che richiama un ex capo del KGB, un termine, vilayat, preso dal lessico delle province dell’Isis, e un toponimo inventato che sembra uscito da una bacheca anonima di internet. Secondo la stampa la stessa sigla era già comparsa in falsi allarmi su voli di linea e in messaggi inviati a emittenti europee. Che dietro ci sia un singolo provocatore o un gruppo più strutturato, lo diranno le indagini.

Chi c’è dietro? Il profilo che emerge dai dettagli tecnici

Messi in fila, gli indizi tecnici disegnano un’operazione costruita con strumenti elementari:

• nessuna vulnerabilità nei sistemi del Ministero: gli indirizzi sono pubblici;
• nessuna infrastruttura sofisticata: un account di posta rubato, probabilmente uno o pochi, e un elenco ricavato da dati aperti;
• un invio a blocchi con i destinatari in chiaro, come farebbe uno script scritto in fretta;
• un indirizzo di controllo lasciato visibile a migliaia di destinatari;
• un testo tradotto automaticamente da un modello unico.

È il profilo tipico dello swatting via email: produrre il massimo del caos, evacuazioni, lezioni interrotte, titoli sui giornali, con un investimento quasi nullo. Componenti di questo tipo, credenziali rubate comprese, circolano in vendita o gratuitamente in molti canali Telegram e Discord dedicati al teppismo informatico e ai falsi allarmi.

Qui però occorre essere onesti su quello che non sappiamo. Che i singoli ingredienti siano rudimentali non significa necessariamente che dietro ci sia un ragazzino isolato. La campagna ha colpito più paesi a distanza di poche settimane, con un modello di testo comune e una sigla già usata in altri contesti: è compatibile anche con un attore che sceglie deliberatamente strumenti semplici, economici e sacrificabili. Sul piano dell’attribuzione, uno screenshot non permette di andare oltre. Gli errori di OPSEC sono però evidenti, e sono esattamente il tipo di errore che permette di risalire a chi ha premuto “Invio”.

Le tracce che restano: dove guardano gli investigatori

Ogni messaggio di posta lascia una scia di registrazioni in più punti della rete. In questo caso le principali sono quattro:

• Il tenant Microsoft 365 dell’università: i registri di accesso della casella compromessa riportano indirizzi IP, orari, dispositivi e applicazioni usati per collegarsi e per spedire. Sono i dati più preziosi, e sono in mano all’ateneo e a Microsoft.
• Il tenant Microsoft 365 del Ministero: la traccia dei messaggi (message trace) dice quanti messaggi sono arrivati, da quali server, in che ordine e con che ritmo.
• Il server di posta di tanpony.com: se è un servizio di posta temporanea, può aver registrato chi ha creato o consultato quella casella; se è un dominio dell’autore, il collegamento è ancora più diretto.
• Il registrar e il fornitore del server: dati di registrazione del dominio, pagamenti, indirizzi IP di accesso al pannello di gestione.

Incrociare questi registri è un lavoro che la Polizia Postale conosce bene, e che con la collaborazione delle aziende coinvolte può portare a risultati in tempi ragionevoli.

Perché servirebbe la mail originale con le intestazioni complete

Tutto quello che abbiamo scritto finora si basa su uno screenshot e su dati DNS pubblici. È un’analisi utile, ma necessariamente parziale. La quantità di informazioni contenute nelle intestazioni complete di un messaggio di posta è di un altro ordine di grandezza.

Per questo riteniamo che sarebbe utile, nel rispetto delle esigenze investigative, che la Polizia Postale, la Procura competente o gli stessi istituti scolastici diffondessero almeno uno dei messaggi ricevuti in formato originale, cioè il file .eml o il sorgente completo con tutte le intestazioni, oscurando se necessario i soli dati personali non pubblici. Gli indirizzi delle scuole sono già pubblici; i dati che servono per un’analisi tecnica sono quasi tutti informazioni sui server, non sulle persone.

Non è una curiosità da addetti ai lavori. La comunità tecnica italiana, fatta di sistemisti, gestori di posta, ricercatori e aziende di sicurezza, potrebbe aiutare a rispondere a domande concrete: da quanti account sono partiti i messaggi, con quale programma, a che ritmo, se ci sono altri canarini, se esistono collegamenti con le ondate precedenti in Italia e nel Regno Unito. Analisi indipendenti e pubbliche aiutano anche a smontare le ricostruzioni fantasiose che circolano in queste occasioni, e a dare alle scuole e agli enti indicazioni pratiche per riconoscere e gestire il prossimo messaggio di questo tipo.

Ecco le intestazioni che vorremmo vedere, e cosa ci direbbero:

• Received:: la catena dei server attraversati, con orari precisi. Distingue un invio dal tenant Microsoft dell’università da un invio da un server esterno, e misura i tempi di transito.
• Authentication-Results e ARC-Authentication-Results: l’esito di SPF, DKIM e DMARC e, su Exchange Online, la valutazione compauth. Chiuderebbero definitivamente la questione account compromesso o spoofing.
• X-MS-Exchange-CrossTenant-Id e le altre intestazioni CrossTenant: identificano il tenant Microsoft 365 di origine e il tipo di autenticazione del mittente.
• X-Forefront-Antispam-Report: contiene l’indirizzo IP che ha consegnato il messaggio ai server Microsoft del Ministero (CIP), il paese, il verdetto antispam e il punteggio di fiducia (SCL). Dice anche perché il messaggio non è stato fermato.
• Message-ID, Date e Thread-Index: confrontati tra scuole diverse, permettono di ricostruire la sequenza e il ritmo degli invii e di capire quanti account sono stati usati.
• X-Mailer, User-Agent e la struttura MIME: rivelano lo strumento usato per spedire, un client di posta, una libreria di uno script, un servizio di mailing, e spesso la lingua e le impostazioni di chi l’ha usato.
• Content-Language e la codifica del testo: indizi sull’origine del modello e del sistema di traduzione.

Cosa dovrebbero fare le scuole che ricevono un messaggio del genere

Al di là della gestione dell’emergenza, che spetta alle forze dell’ordine e ai protocolli di sicurezza di ciascun istituto, dal punto di vista informatico ci sono alcune regole semplici che aiutano chi indaga:

• Non cancellare il messaggio e non spostarlo nel cestino: va conservato così com’è nella casella.
• Non inoltrarlo come semplice inoltro, che perde le intestazioni originali, e non affidarsi a stampe o screenshot. Se viene richiesto, va esportato come file: in Outlook sul web si usa la voce per visualizzare l’origine o i dettagli del messaggio, in Outlook classico il messaggio si trascina sul desktop o si salva come file, e le intestazioni sono visibili in File, Proprietà, Intestazioni Internet.
• Non rispondere al mittente e non cliccare su eventuali collegamenti.
• Annotare l’orario esatto di ricezione e di lettura, e chi ha avuto accesso alla casella.
• Segnalare l’accaduto attraverso i canali indicati dal Ministero e alla Polizia Postale, mettendo a disposizione il file originale.

Una lezione per chi gestisce domini e caselle di posta

C’è infine una lezione che va oltre le scuole. In questa vicenda il punto debole non è stato il Ministero, ma una casella di posta di un’università dall’altra parte del mondo. Le credenziali rubate sono la materia prima di gran parte degli abusi di questo tipo, e chiunque gestisca un dominio di posta, un’azienda come un ente pubblico, dovrebbe chiedersi cosa succederebbe se una delle sue caselle venisse usata per spedire migliaia di messaggi:

• autenticazione a più fattori obbligatoria per tutte le caselle, comprese quelle di ex dipendenti ed ex studenti, che andrebbero disattivate quando non servono più;
• SPF, DKIM e DMARC configurati e mantenuti, con una politica DMARC che arrivi gradualmente a quarantine o reject e con l’analisi dei rapporti aggregati;
• limiti e allarmi sugli invii in uscita: una casella che in pochi minuti spedisce centinaia di messaggi a destinatari mai contattati prima deve far scattare un blocco automatico;
• monitoraggio degli accessi anomali per paese, orario e applicazione, e disattivazione dei protocolli di autenticazione obsoleti.

Conclusioni

Lo screenshot della mail che ha fatto evacuare migliaia di scuole racconta più di quanto sembri: un account universitario di Taiwan, con ogni probabilità violato, usato attraverso Microsoft 365 per spedire a blocchi; un elenco di destinatari ricavato da dati pubblici; un indirizzo di controllo su un dominio registrato poche settimane prima; un testo tradotto automaticamente da un modello unico già usato nel Regno Unito. Ingredienti semplici, economici e alla portata di chiunque, con errori che lasciano tracce precise.

Proprio per questo l’analisi non dovrebbe fermarsi a un’immagine. Diffondere il messaggio originale con le intestazioni complete, oscurando solo ciò che serve, permetterebbe alla comunità tecnica di dare un contributo concreto alle indagini e alla prevenzione. Nel frattempo, a scuole, enti e aziende resta il compito meno appariscente ma più utile: proteggere le proprie caselle, conservare correttamente i messaggi sospetti e configurare i propri domini in modo da non diventare, la prossima volta, il ponte di qualcun altro.

Se gestisci un dominio di posta e vuoi verificare la configurazione di SPF, DKIM e DMARC o mettere in sicurezza le caselle della tua organizzazione, anche con i nostri mail server aziendali gestiti, contattaci: è il nostro lavoro di tutti i giorni.

Fonti: ANSA, Sky TG24 e Open per la cronaca dell’11 novembre 2026 e delle ondate precedenti; interrogazioni DNS e WHOIS pubbliche eseguite dalla redazione il 12 novembre 2026.