E-mail in ritardo ed errore Server Busy in Exchange Online: capire il problema e risolverlo

L’errore Server Busy in Exchange Online, quasi sempre nella forma «451 4.7.500 Server busy. Please try again later», non è un guasto in senso stretto: è un rifiuto temporaneo. Microsoft 365 chiede al server mittente di ripassare più tardi perché l’indirizzo IP che si presenta ha cominciato all’improvviso a inviare molta più posta del solito. I messaggi alla fine arrivano, con minuti o ore di ritardo. La correzione definitiva passa quasi sempre da un connettore in ingresso configurato come si deve, dopo aver verificato che Microsoft non segnali un incidente dal suo lato.

In breve: la soluzione rapida

• Annotate il codice completo riportato nell’avviso di ritardo o nei log del server mittente: 451 4.7.500-699, 4.7.850-899 e 432 4.3.2 non indicano la stessa cosa.
• Aprite l’interfaccia di amministrazione di Microsoft 365, Integrità > Integrità dei servizi, e guardate la riga Exchange Online.
• Avviate una traccia dei messaggi nell’interfaccia di amministrazione di Exchange: Flusso di posta > Traccia messaggi.
• Nessun incidente dichiarato e ritardi limitati a un’origine precisa (server locale, gateway di filtraggio, applicazione): create o correggete il connettore in ingresso corrispondente.
• Chiedete ai mittenti di non rispedire i messaggi a ripetizione: peggiora la limitazione.

Riconoscere il problema

Gli utenti si lamentano perché le e-mail provenienti dall’esterno arrivano una, due, a volte sei ore dopo l’invio. I messaggi interni, invece, sono istantanei. Non si perde nulla, tutto finisce per arrivare, spesso a blocchi. I mittenti, dal canto loro, ricevono un avviso del tipo «Delivery is delayed» (recapito in ritardo), senza alcun rifiuto definitivo.

Nei log del server di invio o nel rapporto di mancato recapito, la risposta di Microsoft 365 assomiglia a una di queste righe.

La prima cifra è la chiave di lettura. Un codice che inizia per 4 è temporaneo: il server mittente deve riprovare, e lo farà da solo. Un codice che inizia per 5 è definitivo: il messaggio viene respinto e non tornerà senza un intervento.

Perché compare l’errore Server Busy in Exchange Online

Exchange Online protegge la propria piattaforma condivisa con un meccanismo che Microsoft chiama limitazione per indirizzo IP (IP throttling). Ogni server che consegna posta ha una sua storia. Finché invia volumi coerenti con il passato, tutto passa. Quando comincia a inviarne molti di più, o quando si presenta per la prima volta con una portata elevata, il servizio diffida e gli risponde di ripassare più tardi. È una forma di greylisting: un periodo di prova durante il quale un mittente senza precedenti viene trattato con prudenza.

Un server legittimo riprova secondo un calendario crescente, pochi minuti all’inizio e poi intervalli sempre più lunghi. Un bot che invia spam, di norma, non riprova affatto. Il filtro quindi funziona, ma il suo effetto collaterale è noto: la posta legittima accumula ritardo mentre l’indirizzo si costruisce una reputazione.

L’insidia è che questa protezione scatta molto spesso per una questione di configurazione e non di volume reale. Tre situazioni tornano di continuo.

La prima riguarda le organizzazioni ibride. Il server Exchange locale, la multifunzione o l’applicazione gestionale inoltrano posta verso Microsoft 365. Senza un connettore in ingresso che identifichi quell’origine come vostra, tramite il certificato o l’indirizzo IP, Exchange Online la tratta come un qualunque sconosciuto su Internet e la limita.

La seconda riguarda i gateway di filtraggio. Se il record MX punta a un servizio antispam di terze parti che poi inoltra a Microsoft 365, tutta la posta in arrivo dell’azienda giunge da una manciata di indirizzi IP. Visto da Microsoft, è un afflusso anomalo da un’unica origine.

La terza dipende da un vero cambiamento di volume: migrazione di cassette postali, campagna di invii massivi, applicazione fuori controllo, account compromesso.

Il codice 432 4.3.2 risponde a un’altra logica. Protegge una singola cassetta postale, non il servizio: una cassetta può ricevere soltanto 3.600 messaggi all’ora, sommando tutte le origini, e un solo mittente può occupare al massimo un terzo di quel tetto. Le cassette postali condivise che raccolgono gli avvisi di monitoraggio lo raggiungono regolarmente.

Prima di cominciare

Serve un account con un ruolo di amministrazione di Exchange per la traccia dei messaggi e i connettori. La consultazione dell’integrità dei servizi è aperta anche a ruoli più ristretti, tra cui l’amministratore dell’help desk.

Raccogliete tre elementi prima di toccare qualsiasi cosa: un esempio di e-mail arrivata in ritardo con le intestazioni complete, il testo esatto dell’errore visto da un mittente e l’ora approssimativa in cui sono iniziati i ritardi. Gli orari negli strumenti Microsoft sono in UTC, ricordatevi di convertirli.

Non modificate il record MX né i connettori esistenti in pieno orario di lavoro senza aver annotato la configurazione attuale. Un errore a questo livello trasforma i ritardi in rifiuti.

Soluzione 1: leggere l’intestazione e il codice di errore

Da fare per prima cosa. Nessun rischio, dieci minuti.

1. Recuperate le intestazioni di un messaggio in ritardo

In Outlook aprite il messaggio, poi File > Proprietà: le intestazioni Internet sono nella parte bassa della finestra. Copiatele per intero.

2. Passatele nell’analizzatore di Microsoft

Incollatele nello strumento Message Header Analyzer (mha.azurewebsites.net). Presenta ogni passaggio del messaggio in forma di tabella, con il tempo trascorso in ciascuna tappa. Le righe Received si leggono dal basso verso l’alto: la più bassa è la partenza, la più alta l’arrivo nella cassetta postale.

3. Individuate dove si è perso il tempo

Se il ritardo si colloca prima della prima riga che cita un server Microsoft (nomi in outlook.com o protection.outlook.com), il messaggio ha atteso presso il mittente o su un gateway intermedio, tipicamente perché veniva rifiutato temporaneamente. Se il ritardo compare tra due server Microsoft, il rallentamento è interno al servizio e non potete farci nulla: è un caso da integrità dei servizi e da supporto.

4. Guardate l’autenticazione

La riga Authentication-Results riporta l’esito di SPF, DKIM e DMARC. Un spf=fail o un dmarc=fail sulla posta dei vostri partner non spiega un ritardo, ma spiega le messe in quarantena che gli utenti scambiano spesso per ritardi.

Soluzione 2: verificare l’integrità dei servizi

Da usare sempre prima di modificare la configurazione.

1. Aprite la pagina di integrità

Nell’interfaccia di amministrazione di Microsoft 365 (admin.microsoft.com) andate in Integrità > Integrità dei servizi (Health > Service health). Una riga Exchange Online contrassegnata da un incidente o da un avviso fornisce un identificativo, una descrizione dell’impatto e aggiornamenti regolari.

2. Distinguete tra incidente e avviso

Un incidente indica l’interruzione critica di una funzione principale. Un avviso (advisory) indica un problema che tocca una parte degli utenti mentre il servizio resta disponibile, spesso a intermittenza. I ritardi di recapito finiscono quasi sempre tra gli avvisi, e per questo passano inosservati se si guardano soltanto le segnalazioni in rosso.

3. Se l’interfaccia di amministrazione è irraggiungibile

Consultate status.cloud.microsoft, la pagina di stato pubblica, e l’account @MSFT365Status su X.

4. Segnalate il problema se non è in elenco

Il pulsante Segnala un problema (Report an issue) della pagina di integrità permette di far emergere un’anomalia non ancora censita. Quando lo fanno più organizzazioni, l’indagine parte prima.

Se un evento in corso descrive ritardi sulla posta in arrivo, il vostro lavoro si ferma qui: informate gli utenti e seguite gli aggiornamenti. Altrimenti proseguite.

Soluzione 3: tracciare i messaggi interessati

Da usare per misurare l’ampiezza del problema e individuare l’origine. Nessun rischio.

1. Avviate la traccia

Nell’interfaccia di amministrazione di Exchange (admin.exchange.microsoft.com) aprite Flusso di posta > Traccia messaggi (Mail flow > Message trace). Indicate un mittente o un destinatario colpito e un intervallo che copra l’inizio dei ritardi. Per dieci giorni o meno il risultato compare subito.

2. Leggete gli stati e gli eventi

Un messaggio nello stato In sospeso (Pending) è ancora in fase di tentativo. Nel dettaglio, l’evento Defer indica che il recapito è stato rinviato e verrà ritentato. Confrontate l’ora dell’evento Receive con quella di Deliver: se sono vicine mentre l’utente ha ricevuto il messaggio ore dopo l’invio, tutto il ritardo si è prodotto prima dell’ingresso in Exchange Online. È la firma di una limitazione alla porta.

3. Tenete presente ciò che la traccia non mostra

Un messaggio rifiutato temporaneamente in fase di connessione non è ancora stato accettato dal servizio. Può quindi mancare dalla traccia finché il server mittente non riesce a consegnarlo. Una traccia vuota non dimostra che non sia stato inviato nulla.

4. In PowerShell

Get-MessageTraceV2 -SenderAddress [email protected] -StartDate <data di inizio> -EndDate <data di fine>

Sostituite l’indirizzo e le due date con i vostri, nel formato data della sessione PowerShell. Il comando interroga al massimo dieci giorni per volta e restituisce 1.000 risultati per impostazione predefinita.

5. Richiedete un report esteso

Per ottenere l’indirizzo IP di origine e i dettagli di instradamento, scegliete il report di riepilogo avanzato (Enhanced summary report) o il report esteso (Extended report), forniti in CSV. La colonna dell’indirizzo IP vi dirà se i messaggi in ritardo passano tutti dalla stessa origine.

Soluzione 4: distinguere la limitazione di Microsoft da un difetto interno

È il passaggio di diagnosi che evita di correggere nel punto sbagliato.

Ponetevi quattro domande. I ritardi riguardano tutti i mittenti esterni o soltanto alcuni? La posta in ritardo transita sempre dallo stesso indirizzo IP? È cambiato qualcosa nell’instradamento subito prima dei primi ritardi: nuovo antispam, nuovo indirizzo IP pubblico, certificato rinnovato, migrazione? Nell’integrità dei servizi compare un incidente?

Tutti i mittenti, nessuna origine comune, incidente visibile: il problema è in casa Microsoft. Tutti i mittenti, un’origine comune che è il vostro gateway di filtraggio: il problema è da voi, manca un connettore. Solo qualche mittente: il problema è da loro, con un indirizzo IP di invio in periodo di prova o autenticato male. Soltanto la posta inoltrata dal server locale: connettore in ingresso assente o che non riconosce più il server.

Quest’ultimo caso merita due parole. Un connettore identifica il server o tramite il nome presente sul certificato TLS o tramite l’indirizzo IP. Basta cambiare provider Internet o rinnovare il certificato con un altro nome soggetto perché il connettore non riconosca più nulla, senza mostrare il minimo errore. La posta continua a partire, ma ormai viene trattata come anonima.

Soluzione 5: creare o correggere il connettore in ingresso

Da usare non appena l’origine dei ritardi è un server o un servizio sotto il vostro controllo. Rischio moderato: fate le prove fuori dalle ore di punta.

1. Per un server locale o un’applicazione

Nell’interfaccia di amministrazione di Exchange aprite Flusso di posta > Connettori (Mail flow > Connectors) e aggiungete un connettore con origine il server di posta elettronica dell’organizzazione (Your organization’s email server) e destinazione Office 365. Vengono proposti due metodi di identificazione. Microsoft consiglia la verifica tramite certificato: il nome soggetto del certificato presentato dal server deve corrispondere a un dominio che dichiarate. L’alternativa consiste nell’elencare gli indirizzi IP pubblici che appartengono esclusivamente alla vostra organizzazione.

2. Per un gateway di filtraggio di terze parti

Create un connettore di tipo organizzazione partner (Partner organization), limitato agli indirizzi IP o al certificato di quel fornitore. Microsoft precisa che questo connettore evita il greylisting che altrimenti colpirebbe il grande volume di posta proveniente da quell’origine.

3. Controllate ciò che esiste già

Se un connettore è già presente, confrontate gli indirizzi IP e il nome di certificato che si aspetta con ciò che il server presenta davvero. L’indirizzo IP visto da Microsoft compare nell’errore 451 stesso e nel report esteso della traccia.

4. Convalidate

Usate la procedura di convalida proposta al termine della creazione, poi inviate alcuni messaggi di prova. Verifica: nei log del server le risposte 451 scompaiono e la coda si svuota.

Soluzione 6: gestire la coda di un server ibrido

Da usare quando il server Exchange locale accumula messaggi.

1. Ispezionate le code

In Exchange Management Shell sul server locale:

Get-Queue -Server Mailbox01 -Exclude Empty

La colonna dell’ultimo errore riporta la risposta di Microsoft 365. Il Visualizzatore code (Queue Viewer), negli Strumenti di Exchange (Exchange Toolbox), offre la stessa vista in modalità grafica.

2. Rilanciate dopo la correzione

Una volta corretto il connettore, non serve aspettare il prossimo tentativo automatico:

Retry-Queue -Filter "Status -eq 'Retry'"

3. Verificate che il server non sia a sua volta saturo

Se è il server locale a rispondere «occupato» ai mittenti, la causa è interna: disco pieno, memoria insufficiente. Exchange in quel caso si protegge rifiutando temporaneamente le connessioni in ingresso. Liberate spazio sul volume che ospita le code prima di qualsiasi altra azione.

Soluzione 7: mettere ordine nell’autenticazione e nei volumi di invio

Da usare per ritardi e rifiuti in uscita, e per evitare che il dominio venga valutato male.

1. SPF

Il record di base per un dominio che invia soltanto da Microsoft 365 è:

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

Aggiungetevi le altre origini legittime. Attenzione al tetto di dieci ricerche DNS: oltre quella soglia SPF fallisce con un errore permanente e tutta la posta perde l’autenticazione.

2. DKIM e DMARC

Attivate la firma DKIM del dominio nel portale Defender (security.microsoft.com/authentication, scheda DKIM), dopo aver creato i due record CNAME selector1._domainkey e selector2._domainkey. Pubblicate poi un criterio DMARC.

3. Rispettate i limiti

Una cassetta postale di Exchange Online invia al massimo 30 messaggi al minuto e a 10.000 destinatari al giorno. All’organizzazione si applica anche un tetto complessivo di destinatari esterni, proporzionale al numero di licenze. I domini in onmicrosoft.com sono limitati a 100 destinatari esterni ogni 24 ore. Per gli invii massivi Microsoft rimanda a servizi specializzati.

4. Verificate che nessun account sia compromesso

Un volume in uscita che esplode senza motivo, un codice 5.1.8 o 5.7.705: cercate un account violato prima di qualsiasi altra ipotesi. La posta ritenuta dubbia esce da un gruppo di indirizzi IP ad alto rischio che molti destinatari rifiutano.

Che cosa può fare il mittente esterno

Poco, ed è bene dirglielo con chiarezza. Se rispedisce dieci volte lo stesso messaggio, aumenta il volume che ha fatto scattare la limitazione. Il suo server riproverà da solo. Può invece inoltrare il testo esatto dell’errore al proprio amministratore, che controllerà la coda, l’autenticazione SPF e DKIM del dominio e la reputazione dell’indirizzo IP di invio. Per un documento urgente, un altro canale resta l’unica soluzione immediata.

Che cosa dire agli utenti

Basta un messaggio breve: le e-mail provenienti dall’esterno stanno arrivando in ritardo, nessuna è andata persa, i messaggi interni non sono coinvolti, non serve chiedere ai corrispondenti di rispedire. Indicate un canale di riserva per le urgenze e l’ora del prossimo aggiornamento. Non annunciate un orario di ripristino che non dipende da voi.

Tabella riepilogativa

Se nulla funziona

Aprite una richiesta di assistenza dall’interfaccia di amministrazione di Microsoft 365, sezione Supporto (Support). Un ticket preparato bene viene gestito più in fretta. Allegate il testo integrale dell’errore con il riferimento tra parentesi, l’indirizzo IP di invio interessato, due o tre identificativi di messaggio presi dalla traccia, le intestazioni di un messaggio in ritardo, gli orari in UTC, lo schema dell’instradamento (MX, gateway, connettori) e il momento dell’ultima modifica all’infrastruttura.

Se l’errore riguarda un mittente esterno, tocca al suo amministratore intervenire: non potete far rimuovere una limitazione su un indirizzo IP che non vi appartiene.

Evitare che si ripeta

Documentate i connettori e inseritene il controllo nella procedura di rinnovo dei certificati e di cambio del provider. È la causa più frequente di ricaduta.

Iscrivetevi alle notifiche via e-mail dell’integrità dei servizi per Exchange Online, scegliendo un indirizzo esterno all’organizzazione: un avviso su un ritardo della posta spedito alla cassetta coinvolta arriva troppo tardi.

Aumentate il carico per gradi durante una migrazione o quando mettete in servizio un nuovo indirizzo IP di invio. Indirizzate gli avvisi di monitoraggio verso più cassette postali o verso un canale diverso dalla posta. Tenete infine d’occhio i report DMARC e la dimensione delle code del server locale.

Domande frequenti

Le e-mail in ritardo sono perse?

No, finché il codice inizia per 4. Il server mittente le conserva e riprova. Vengono abbandonate soltanto se i tentativi falliscono fino alla scadenza, il che genera un rapporto di mancato recapito.

Quanto dura una limitazione 451 4.7.500?

Senza interventi si attenua man mano che l’indirizzo IP si costruisce uno storico, e possono volerci alcuni giorni. Con un connettore adeguato cessa non appena questo viene riconosciuto.

Si può chiedere a Microsoft di rimuovere la limitazione?

Non esiste un pulsante per farlo. La risposta attesa è un connettore corretto. Il supporto può confermare la diagnosi.

Perché sono colpite soltanto le e-mail esterne?

La posta interna non attraversa il confine del servizio e non è sottoposta al controllo di reputazione degli indirizzi IP.

Server busy significa che i server di Microsoft sono sovraccarichi?

Di rado. La dicitura inganna: nella maggior parte dei casi è la vostra origine di invio a essere limitata, non il servizio a essere saturo.

Se l’errore Server Busy in Exchange Online continua a presentarsi, scrivete nei commenti il codice completo, la direzione del flusso colpito e l’architettura dell’instradamento: questi tre elementi bastano spesso a individuare il connettore difettoso.