Tra giovedì 12 e venerdì 13 novembre 2026 Microsoft 365 ha attraversato un incidente globale che ha interessato in particolare Exchange Online, con conseguenze sull’accesso alle caselle, sui flussi di posta e su diversi servizi Microsoft 365 dipendenti dalla piattaforma email.

L’episodio ha riaperto una discussione importante: per garantire la continuità operativa sarebbe sufficiente predisporre un sistema di posta alternativo con un MX secondario?

La risposta è più complessa di quanto possa sembrare.

Un’infrastruttura email alternativa può certamente aumentare la resilienza della singola organizzazione. Ma la Business Continuity end-to-end dipende anche dalla capacità di clienti, fornitori, partner e provider di continuare a operare.

Cosa è successo a Microsoft 365

Microsoft ha gestito l’incidente principalmente attraverso gli identificativi EX1550543, relativo a Exchange Online, e MO1550821, relativo ai servizi Microsoft 365 dipendenti da Exchange Online.

Le prime segnalazioni ufficiali dell’incidente Exchange Online risalgono alle 17:17 circa, ora italiana, del 12 novembre. Successivamente Microsoft ha indicato che il problema poteva interessare utenti in diverse regioni del mondo.

Durante l’incidente alcuni utenti hanno riscontrato difficoltà o impossibilità nell’accesso alle caselle attraverso Outlook sul Web, Outlook desktop, dispositivi mobili e API.

L’impatto non si è limitato alla posta elettronica. Le dipendenze da Exchange Online hanno prodotto conseguenze anche su alcune funzionalità di Microsoft Teams, Microsoft Graph, Copilot, Defender, Purview, Planner, To Do, SharePoint e Intune.

L’incidente ha mostrato quanto servizi apparentemente separati possano in realtà dipendere dalla stessa infrastruttura tecnologica.

Non si è fermato tutto Microsoft 365

È importante evitare una semplificazione.

Non è corretto affermare che durante l’incidente si sia fermato completamente Microsoft 365 o che tutta la posta elettronica mondiale sia diventata indisponibile.

L’incidente ha avuto una portata internazionale ed è stato centrato principalmente su Exchange Online e sui servizi che dipendevano da esso.

Alcune funzionalità indipendenti da Exchange Online hanno continuato a funzionare. Ad esempio, le principali funzionalità di chiamata e chat di Teams risultavano generalmente disponibili, mentre potevano essere interessati calendari, inviti e modifiche delle riunioni.

La causa tecnica preliminare

Secondo le informazioni preliminari comunicate da Microsoft, il problema sarebbe stato collegato a una condizione introdotta durante un precedente ampliamento della capacità di rete, manifestatasi successivamente in seguito a una modifica dell’infrastruttura.

Durante l’incidente alcuni server sono diventati indisponibili, aumentando il carico sui sistemi rimasti operativi. Microsoft ha inoltre riferito problemi relativi a un processo responsabile della creazione delle connessioni sicure, che in determinate condizioni poteva essere sovraccaricato.

Le attività di mitigazione hanno incluso:

• redistribuzione del traffico;
• riavvio e ripristino dei server;
• limitazione selettiva di alcuni flussi;
• aumento della capacità disponibile;
• rollback di modifiche di rete;
• applicazione di interventi correttivi sui componenti coinvolti.

Microsoft ha inoltre indicato che, sulla base delle verifiche effettuate, non risultavano evidenze di un attacco informatico.

Il paradosso dell’MX secondario

Di fronte a un’interruzione di questo tipo, una delle soluzioni che viene spesso proposta è quella di predisporre un secondo sistema di posta elettronica pubblicato attraverso un record MX alternativo.

Tecnicamente il principio è corretto.

Nel protocollo SMTP, il server con il valore numerico MX più basso viene normalmente preferito. Se quel server non è raggiungibile, il sistema mittente può tentare la consegna utilizzando gli altri MX disponibili.

Un’infrastruttura secondaria può quindi aumentare significativamente la resilienza.

In funzione dell’architettura adottata può:

• accettare la posta quando il sistema principale non è disponibile;
• conservare i messaggi in coda attraverso meccanismi di store-and-forward;
• inoltrare successivamente i messaggi verso il sistema principale;
• fornire un relay di posta alternativo;
• in architetture più evolute, mettere a disposizione caselle e interfacce alternative;
• ridurre la dipendenza operativa dal provider principale.

Ma questo significa avere Business Continuity?

Qui nasce il vero problema.

Immaginiamo che la nostra azienda abbia investito in una piattaforma email completamente indipendente.

Microsoft 365 diventa indisponibile, ma noi possiamo continuare a inviare email.

Tecnicamente siamo più resilienti.

Ma cosa succede se il nostro cliente utilizza lo stesso provider che in quel momento è indisponibile?

Oppure se il fornitore al quale dobbiamo inviare un ordine non può accedere alla propria casella?

O ancora, se il messaggio viene correttamente accettato da un server SMTP ma rimane in coda per ore prima di poter essere consegnato?

Se io posso inviare una mail ma il destinatario non può riceverla, posso davvero parlare di Business Continuity?

La risposta dipende da quale livello di continuità stiamo misurando.

Quattro livelli diversi di continuità

1. Continuità interna

I dipendenti riescono a comunicare tra loro, accedere alle informazioni e coordinare le attività?

Un sistema alternativo può garantire un livello significativo di continuità interna.

2. Continuità del servizio email aziendale

L’organizzazione continua ad accettare, conservare e inviare messaggi?

Un MX secondario, un relay indipendente o una piattaforma alternativa possono migliorare sensibilmente questo livello di resilienza.

3. Raggiungibilità end-to-end

Il messaggio raggiunge effettivamente la casella del destinatario?

A questo punto entrano in gioco infrastrutture che non controlliamo:

• provider del destinatario;
• DNS;
• gateway di sicurezza;
• sistemi antispam;
• server SMTP;
• code di posta;
• infrastrutture cloud;
• sistemi di autenticazione.

Il fatto che il nostro server abbia accettato o inviato correttamente un messaggio non significa necessariamente che il destinatario lo abbia già ricevuto.

4. Continuità del processo di business

Questo è probabilmente il livello più importante.

L’ordine è stato acquisito? Il pagamento è stato autorizzato? La spedizione è partita? Il cliente ha ricevuto l’informazione urgente? Il tecnico ha ricevuto la richiesta di intervento?

Una mail correttamente accodata può rappresentare un successo dal punto di vista tecnico, ma contemporaneamente un fallimento dal punto di vista del processo aziendale.

Se una comunicazione doveva produrre un’azione entro trenta minuti e viene consegnata il giorno successivo, il sistema email può aver funzionato correttamente secondo le logiche SMTP, ma il processo di business potrebbe comunque essersi interrotto.

La Business Continuity non coincide con l’uptime di un singolo sistema.

Quindi un MX secondario è inutile?

Assolutamente no.

Sarebbe altrettanto sbagliato arrivare alla conclusione opposta.

SMTP è stato progettato proprio per gestire indisponibilità temporanee attraverso code, retry e store-and-forward.

Un sistema email secondario può quindi:

• evitare il rifiuto immediato dei messaggi;
• conservare comunicazioni durante l’indisponibilità del sistema principale;
• ridurre il backlog sul provider primario;
• permettere comunicazioni verso destinatari che utilizzano infrastrutture ancora operative;
• supportare le comunicazioni interne;
• facilitare un recupero ordinato al termine dell’incidente.

La conclusione corretta non è quindi:

“L’MX secondario risolve il problema.”

Ma neppure:

“L’MX secondario non serve.”

La conclusione tecnicamente più corretta è:

Un’infrastruttura email alternativa riduce alcuni rischi specifici, ma non elimina le dipendenze esterne del processo di comunicazione.

Quanto siamo ormai dipendenti dal cloud?

I dati Eurostat aiutano a comprendere la dimensione del fenomeno.

Nel 2025 il 52,7% delle imprese dell’Unione Europea con almeno dieci addetti utilizzava servizi cloud a pagamento.

In Italia la percentuale raggiungeva il 75,6%.

Tra le imprese europee che acquistavano servizi cloud, l’85,2% utilizzava servizi di posta elettronica nel cloud.

Il cloud non rappresenta quindi più un’infrastruttura accessoria. È diventato parte integrante dei processi operativi delle aziende.

Business Continuity e supply chain digitale

Anche ENISA evidenzia quanto la continuità operativa e le dipendenze da terze parti siano diventate centrali nella gestione del rischio.

Nel rapporto NIS Investments 2025, basato su 1.080 professionisti appartenenti a organizzazioni europee dei settori NIS ad alta criticità:

• il 49% indicava Business Continuity e Disaster Recovery tra le aree NIS2 più difficili da implementare;
• il 37% indicava il supply-chain risk management;
• il 47% considerava gli attacchi alla supply chain e le compromissioni di terze parti tra le principali preoccupazioni future.

Il problema, quindi, non riguarda soltanto la disponibilità della nostra infrastruttura.

Riguarda la disponibilità dell’intero ecosistema dal quale dipendono i nostri processi.

Quanto può costare un’interruzione?

Secondo le analisi di Uptime Institute, il 57% degli intervistati stimava in oltre 100.000 dollari il costo dell’ultimo outage rilevante.

Circa un outage su cinque avrebbe invece prodotto costi superiori al milione di dollari.

Eppure, secondo le rilevazioni citate, soltanto una parte delle organizzazioni include sistematicamente nei propri risk assessment anche i rischi sistemici e quelli derivanti dalle terze parti.

La resilienza è una proprietà dell’ecosistema

Ogni organizzazione può e deve investire nella propria resilienza.

Ad esempio attraverso:

• MX e relay alternativi;
• canali di comunicazione indipendenti;
• Business Impact Analysis;
• procedure operative manuali;
• piani di Business Continuity periodicamente testati;
• Disaster Recovery;
• gestione del rischio dei fornitori;
• monitoraggio indipendente dei servizi;
• strategie di uscita e portabilità;
• canali alternativi come telefono, portali e sistemi di messaggistica indipendenti.

Ma un processo interaziendale è composto da più organizzazioni, più provider, più infrastrutture e soprattutto più persone.

La resilienza della singola impresa riduce il rischio individuale.

La resilienza diffusa di clienti, fornitori, partner e provider riduce invece la probabilità che un problema locale si trasformi in una interruzione dell’intero processo di business.

Cybersecurity e Business Continuity sono una responsabilità condivisa

Questo non significa sostenere che, se non investono tutti, nessuno possa essere resiliente.

Ogni organizzazione può aumentare autonomamente la propria capacità di resistere, continuare a operare e recuperare dopo un incidente.

Ma la continuità end-to-end di un processo condiviso aumenta quando anche gli altri soggetti dell’ecosistema adottano livelli adeguati di:

• cybersecurity;
• ridondanza;
• Business Continuity;
• Disaster Recovery;
• gestione delle terze parti;
• canali alternativi di comunicazione.

Possiamo rendere resiliente la nostra infrastruttura. Ma per rendere resiliente un processo dobbiamo considerare anche tutte le organizzazioni e le tecnologie dalle quali quel processo dipende.

La domanda che dovremmo porci dopo il disservizio Microsoft 365

L’incidente Microsoft 365 del 12–13 novembre non dimostra che il cloud sia inaffidabile.

Dimostra piuttosto che anche infrastrutture progettate con elevati livelli di resilienza possono diventare punti comuni di dipendenza per migliaia di organizzazioni.

Per questo, quando progettiamo la Business Continuity, forse dovremmo smettere di porci soltanto questa domanda:

“Il mio sistema è disponibile?”

E iniziare a porcene una più importante:

“Il processo complessivo, dal mittente fino alla decisione aziendale finale, può continuare a funzionare quando uno dei suoi attori principali non è disponibile?”

Fonti e approfondimenti

• Microsoft Service Health – comunicazioni relative agli incidenti EX1550543 e MO1550821 e agli impatti su Exchange Online e Microsoft 365.
• Cisco ThousandEyes – osservazioni indipendenti sulla portata internazionale dell’incidente e sui problemi di connettività rilevati.
• RFC 5321 – Simple Mail Transfer Protocol – funzionamento SMTP, priorità MX, code, retry e meccanismi di store-and-forward.
• Eurostat – ICT usage in enterprises 2025 – dati sull’adozione dei servizi cloud da parte delle imprese europee.
• ENISA – NIS Investments 2025 – Business Continuity, Disaster Recovery e supply-chain risk management.
• Uptime Institute – Annual Outage Analysis – analisi dell’impatto economico e operativo degli outage.
• Banca Centrale Europea – indicazioni sui rischi derivanti dalla concentrazione dei cloud provider e dalle dipendenze da terze parti.
• NIST – framework e linee guida relative a contingency planning, Business Impact Analysis e resilienza organizzativa.