Exchange Online rallenta e blocca i server Exchange 2016 e 2019 obsoleti da settembre 2026: come funziona il Transport Enforcement

Il team di Exchange ha annunciato il 2 settembre 2026 l’innalzamento della versione minima per Exchange 2016 ed Exchange 2019 nel flusso di posta ibrido. Dalla seconda settimana di settembre 2026, Exchange Online richiede ai server che inviano messaggi tramite un connettore in ingresso di tipo OnPremises almeno il livello dell’ultimo aggiornamento di sicurezza pubblico di ottobre 2025. Tutto ciò che è inferiore viene rallentato e successivamente bloccato. In breve: chi non ha applicato patch ai propri server ibridi da ottobre 2025 perderà gradualmente, nelle prossime settimane, la consegna della posta verso Exchange Online. E il prossimo innalzamento della soglia, che Microsoft prospetta per i prossimi mesi, sarà superiore a qualsiasi aggiornamento disponibile pubblicamente: a quel punto soddisferanno il requisito soltanto i clienti del programma ESU a pagamento o gli ambienti con Exchange Server Subscription Edition (SE).

L’annuncio in sé è breve. Il suo significato pratico deriva dal sistema di enforcement che Microsoft ha costruito gradualmente dal 2023: quali risposte SMTP vedrà il vostro server, come verificare lo stato nell’Admin Center e tramite PowerShell e quali opzioni restano durante la transizione fino alla fine del programma ESU nell’ottobre 2026.

Cosa si applica dalla seconda settimana di settembre 2026

La nuova soglia minima corrisponde agli aggiornamenti di sicurezza del 14 ottobre 2025. È stato l’ultimo Patch Tuesday in cui Microsoft ha reso pubblicamente disponibili aggiornamenti per Exchange 2016 ed Exchange 2019; tutte le SU da dicembre 2025 sono disponibili solo tramite il programma ESU.

Per Exchange 2019 CU14 esiste anch’essa una SU di ottobre 2025 (KB5066368, build 15.2.1544.36). Tuttavia, nel contributo Microsoft è indicata esplicitamente CU15 SU5 come versione minima; CU14 non è più uno stato consigliato dalla pubblicazione di CU15 nel febbraio 2025. Pianificate quindi anche il passaggio a CU15 per CU14.

Sono importanti tre delimitazioni:

• È interessato solo il flusso di posta ibrido. Exchange Online verifica la versione dei server mittenti per i messaggi che arrivano tramite un connettore in ingresso di tipo OnPremises. Si tratta della classica configurazione ibrida creata da Hybrid Configuration Wizard. I messaggi che arrivano tramite un gateway di terze parti o un connettore di tipo Partner non passano attraverso questo enforcement.
• La versione viene letta dalle intestazioni. Un server Exchange scrive la propria build nella riga Received di ogni messaggio che inoltra (… with Microsoft SMTP Server … id 15.1.2507.61). Exchange Online valuta questa indicazione. Conta quindi il livello del server che consegna effettivamente il messaggio a Exchange Online, ossia in molti ambienti l’Edge Transport Server o il server Mailbox con il Send Connector verso *.mail.protection.outlook.com.
• Exchange SE non è interessato. L’enforcement si applica a Exchange 2016 ed Exchange 2019; Exchange Server SE supera ogni soglia minima finché riceve regolarmente le patch.

Contesto: il Transport Enforcement dal 2023

L’annuncio di settembre non è una nuova misura, bensì il livello successivo di un sistema che Microsoft ha presentato nel marzo 2023 con il titolo «Throttling and Blocking Email from Persistently Vulnerable Exchange Servers to Exchange Online». Microsoft definisce «persistently vulnerable» qualsiasi server Exchange che abbia raggiunto la fine del supporto o rimanga privo di patch per vulnerabilità note. L’obiettivo è proteggere i destinatari di Exchange Online dai messaggi provenienti da server potenzialmente compromettibili e, al contempo, esercitare pressione sugli operatori affinché applichino patch o spengano i server.

Il sistema è stato attivato progressivamente per versione:

Per Exchange 2016 ed Exchange 2019, finora la soglia minima riguardava livelli «significantly behind on security updates». La novità è che Microsoft porta il limite all’ultimo aggiornamento pubblico, interessando così per la prima volta server che meno di un anno fa erano ancora completamente aggiornati.

I livelli di escalation

L’enforcement opera in tre funzioni, che Microsoft chiama «reporting», «throttling» e «blocking». Non appena un server scende sotto la soglia minima, inizia un ciclo di 90 giorni. I livelli descritti nell’articolo introduttivo del 2023:

Le due risposte sono, testualmente:

450 4.7.230 Connecting Exchange server version is out-of-date;
connection to Exchange Online throttled for n mins/hr.

550 5.7.230 Connecting Exchange server version is out-of-date;
connection to Exchange Online blocked for n mins/hr.

La differenza è determinante per l’operatività. In caso di 450, Exchange Online rifiuta temporaneamente la connessione; il server on-premises mantiene il messaggio nella propria coda e riprova. Gli utenti inizialmente notano solo ritardi; in Queue Viewer o in Get-Queue cresce la coda verso il Send Connector per Exchange Online con stato Retry e il messaggio 4.7.230 come LastError. Con 550, invece, il rifiuto è definitivo: il mittente riceve un NDR con il codice 5.7.230 e il messaggio è perso, salvo che venga inviato nuovamente. Poiché all’inizio il blocco è attivo solo per alcuni minuti all’ora, il comportamento appare dapprima sporadico: una parte dei messaggi arriva, un’altra fallisce con NDR. Chi osserva un simile schema nel Message Tracking dovrebbe verificare innanzitutto la versione, prima di cercare problemi di rete o certificati.

L’annuncio non specifica se Microsoft avvierà il ciclo completo di 90 giorni dalla seconda settimana di settembre per la nuova soglia minima o se inizierà già da un livello successivo. L’articolo introduttivo precisa che il sistema, dopo una pausa, continua dal livello precedentemente raggiunto. Non fate quindi affidamento su 30 giorni di tolleranza.

Report nell’Exchange Admin Center e tramite PowerShell

Exchange Online elenca i server on-premises rilevati, con relativa versione, in un report dedicato: nell’Exchange Admin Center, in Reports, Mail flow, report sui server Exchange on-premises connessi obsoleti («out-of-date connecting on-premises Exchange servers»). Per ciascun server, il report mostra la build rilevata, se è sotto la soglia minima e a quale livello di enforcement si trova.

Le stesse informazioni sono fornite da Exchange Online PowerShell:

Connect-ExchangeOnline
Get-OnPremServerReportInfo

Il report conosce solo i server che consegnano effettivamente messaggi a Exchange Online. Un server di gestione senza flusso di posta o una macchina con i soli Management Tools non vi appare. Questo è irrilevante per l’enforcement, ma non per la sicurezza: anche questi sistemi necessitano delle SU.

Sospendere l’enforcement: 90 giorni all’anno

Per gli ambienti che non riescono a raggiungere rapidamente la soglia minima, Microsoft offre una sospensione. Può essere attivata per un totale di 90 giorni all’anno, in un’unica soluzione o in più periodi:

Get-TenantExemptionInfo -BlockingScenario UnpatchedOnPremServer

New-TenantExemptionInfo -BlockingScenario UnpatchedOnPremServer `
  -NumberOfDays 30

Due caratteristiche della sospensione sono importanti nella pratica. In primo luogo, alla sua scadenza l’enforcement prosegue dal livello in cui era stato fermato; la sospensione non reimposta il ciclo di 90 giorni. In secondo luogo, non esiste alcun cmdlet per terminare anticipatamente una sospensione in corso: chi imposta 90 giorni e completa le patch dopo due settimane ha esaurito il contingente annuale. Create quindi la sospensione per il periodo più breve possibile ed estendetela se necessario.

Inoltre, la sospensione è una soluzione solo per la soglia minima attuale. Se Microsoft innalzerà il limite tra alcuni mesi oltre l’ultimo aggiornamento pubblico, un contingente esaurito non sarà più d’aiuto.

Perché il prossimo innalzamento è la vera scadenza

Exchange 2016 ed Exchange 2019 sono fuori supporto dal 14 ottobre 2025. Microsoft ha poi introdotto due periodi ESU a pagamento: il periodo 1 fino ad aprile 2026, il periodo 2 da maggio a ottobre 2026. Con l’annuncio del periodo 2, il 15 aprile 2026, il team di Exchange ha chiarito che non ci saranno ulteriori proroghe. Le SU da dicembre 2025 ad agosto 2026 (l’ultima è la build 15.2.1748.49 per 2019 CU15 e 15.1.2507.72 per 2016 CU23) sono disponibili esclusivamente per i clienti ESU e non vengono offerte pubblicamente per il download.

Ne deriva la seguente situazione:

• Oggi un server con la SU di ottobre 2025 soddisfa la soglia minima, con o senza ESU.
• Al prossimo innalzamento la soglia minima sarà, secondo Microsoft, superiore al livello di ottobre 2025. Senza un contratto ESU non esiste un modo legale per raggiungere quel livello. Il flusso di posta ibrido di questi server verrà quindi rallentato e bloccato, indipendentemente da quanto correttamente sia gestito il resto dell’ambiente.
• Il 31 ottobre 2026 termina anche il periodo 2. Dopo tale data non ci saranno più SU per Exchange 2016 ed Exchange 2019, per nessuno. Al più tardi il successivo innalzamento dopo quello prossimo interesserà quindi anche i clienti ESU.

Il programma ESU acquista dunque, nel migliore dei casi, pochi mesi. L’unico livello permanente accettato dall’enforcement è Exchange Server SE. Microsoft ha inoltre annunciato che Exchange SE CU2, previsto per la seconda metà del 2026, interromperà la coesistenza con Exchange 2016 ed Exchange 2019: l’installazione si interromperà se nell’organizzazione vengono trovati server più vecchi. La migrazione è quindi necessaria non solo per il flusso di posta, ma anche per poter continuare a installare aggiornamenti per SE.

Per gli ambienti che mantengono Exchange on-premises solo per gestire gli attributi in una configurazione ibrida, l’alternativa è rimuovere l’ultimo server: da Exchange 2019 CU12, gli attributi dei destinatari possono essere gestiti con i Management Tools senza un server Exchange in esecuzione. In questo caso non esiste più flusso di posta on-premises e l’enforcement non è più pertinente.

Determinare il livello di versione

Get-ExchangeServer mostra in AdminDisplayVersion solo la CU, non la SU. È affidabile la versione del file ExSetup.exe oppure Exchange Health Checker, che segnala anche i passaggi manuali mancanti. Per una rapida panoramica di tutti i server:

Get-ExchangeServer | ForEach-Object {
  $path = "\\$($_.Name)\C$\Program Files\Microsoft\Exchange Server\V15\bin\ExSetup.exe"
  [pscustomobject]@{
    Server  = $_.Name
    Version = (Get-Item $path).VersionInfo.ProductVersion
  }
}

Se la versione è inferiore a 15.2.1748.39 (2019 CU15) o a 15.1.2507.61 (2016 CU23), il server scenderà sotto la soglia minima dalla seconda settimana di settembre.

Procedura consigliata

1. Inventariare il livello come descritto sopra, inclusi Edge Transport Server e server di gestione.

2. Verificare il report in Exchange Online. Get-OnPremServerReportInfo mostra quali server Exchange Online vede effettivamente e se è già attivo un livello di enforcement. Confrontate l’elenco con l’inventario: i server che non vi compaiono non inviano tramite il connettore OnPremises.

3. Installare almeno la SU di ottobre 2025. KB5066367 (2019 CU15) e KB5066369 (2016 CU23) sono ancora disponibili pubblicamente nel Microsoft Download Center. Le SU sono cumulative; un server al livello di agosto 2025 può essere aggiornato direttamente a ottobre 2025. Per CU14, installate prima CU15. Dopo l’installazione, riavviate, controllate lo stato dei servizi ed eseguite nuovamente Health Checker.

4. Usare la sospensione solo come soluzione ponte. Se l’aggiornamento non riesce nella prima metà di settembre, create New-TenantExemptionInfo con una durata breve e non considerate la sospensione come riserva di pianificazione per il prossimo innalzamento.

5. Pianificare la migrazione a Exchange SE. Senza contratto ESU, il prossimo innalzamento è la scadenza inderogabile; con ESU, lo è il 31 ottobre 2026. Exchange 2019 CU15 può essere portato a SE tramite aggiornamento in-place; Exchange 2016 richiede il passaggio attraverso una nuova installazione di SE e lo spostamento delle cassette postali o dei ruoli. Chi usa Exchange solo per la gestione degli attributi rimuove l’ultimo server e continua a lavorare con i Management Tools.