# Rinvii 451 4.7.500 di Microsoft: un playbook per i mittenti

URL canonico: https://brew.new/it/blog/microsoft-451-4-7-500-deferrals-playbook
Autore: Thomas Park
Pubblicato: 2026-10-05
Aggiornato: 2026-10-05

Un rinvio (deferral) di Microsoft è un rifiuto SMTP temporaneo, cioè una risposta che inizia con 4, che un server di Outlook.com o di Microsoft 365 restituisce quando in quel momento non accetta il tuo messaggio. Il tuo server dovrebbe tenerlo in coda e riprovare. Il più noto è `451 4.7.500 Server busy. Please try again later`, e lo stesso codice può voler dire “i tuoi invii sembrano sospetti” oppure “Microsoft sta avendo una giornataccia”.

Il 4 settembre 2026 voleva dire la seconda cosa, e almeno un operatore esperto ha passato la mattinata a inseguire la prima. Ecco come distinguerle.

## Punti chiave

- Leggi prima l’host. `*.olc.protection.outlook.com` è la posta personale di Outlook.com, `*.mail.protection.outlook.com` è un tenant di Microsoft 365. Documentazione diversa, escalation diversa.
- Un 4xx significa mettere in coda e riprovare: la RFC 5321 indica almeno 30 minuti tra un tentativo e l’altro, per almeno 4-5 giorni. Un 5xx significa fermarsi: le policy di Microsoft vietano di riprovare.
- Se tutti i tuoi IP ricevono lo stesso codice da Microsoft nello stesso minuto mentre con Gmail e Yahoo va tutto bene, sospetta di Microsoft e controlla mailop prima di cambiare qualcosa.
- Dal 5 maggio 2025 Outlook.com applica i requisiti SPF, DKIM e DMARC ai domini che inviano più di 5.000 messaggi al giorno. Un `550 5.7.515` tocca sempre a te risolverlo.
- Registra subito gli IP di invio in SNDS e JMRP. L’accesso a SNDS scade dopo 10 mesi, a meno che tu non rinnovi l’attestazione.
- Non insistere con i tentativi, non passare a IP nuovi e non escludere i contatti con invii rinviati.

## Prima di tutto, scopri con quale Microsoft stai parlando

Microsoft gestisce due sistemi di ricezione distinti.

**Outlook.com** è la posta personale: `outlook.com`, `hotmail.com`, `live.com` e `msn.com`, con host MX come `hotmail-com.olc.protection.outlook.com`. Ha il [sito Postmaster di Outlook.com](https://substrate.office.com/ip-domain-management-snds/Postmaster/Troubleshooting), SNDS per la reputazione e un proprio modulo di supporto per i mittenti.

**Microsoft 365** (Exchange Online) ospita le caselle di posta aziendali. La posta per `acme.com` va a `acme-com.mail.protection.outlook.com`. Gli errori sono documentati su [Microsoft Learn](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online), i blocchi passano da `sender.office.com` e sono gli admin del destinatario a decidere come il loro tenant tratta i tuoi messaggi.

Il nome di dominio non ti dice quale dei due stai raggiungendo. La risposta sì. In questa riga di log [pubblicata su mailop](https://www.mail-archive.com/mailop@mailop.org/msg27209.html) il 4 settembre, l’host `relay=` è un tenant di Microsoft 365:

```text
relay=xxxx-com.mail.protection.outlook.com[52.101.10.16]:25, dsn=4.7.500,
status=deferred (host xxx-com.mail.protection.outlook.com[52.101.10.16] said:
451 4.7.500 Server busy. Please try again later from [199.89.3.6]. (S77714)
[BN2PEPF000055E1.namprd21.prod.outlook.com 2026-09-04T10:28:53.346Z ...]
(in reply to end of DATA command))
```

## Decodifica la risposta

Leggi il codice di base (`451`), il codice di stato esteso (`4.7.500`) e il sottocodice tra parentesi, come `(S77714)`. Microsoft non pubblica i sottocodici S, ma se molti mittenti segnalano lo stesso nello stesso momento, è un segnale.

| Risposta | Dove | Cosa dice la documentazione di Microsoft | Prima mossa |
|---|---|---|---|
| `451 4.7.500 Server busy. Please try again later from [IP]. (S77714)` | Microsoft 365 | Learn elenca 4.7.500-699 come “Access denied, please try again later”: attività sospetta, invio temporaneamente limitato. | Lascia che la coda riprovi. Prima verifica quanto è esteso il problema. |
| `451 4.7.500-699 (ASxxx)` | Microsoft 365 | Throttling dell’IP quando l’IP che si connette “ha cambiato le sue precedenti abitudini di invio, inviando un volume molto più alto”. | Rallenta la crescita dei volumi. Si risolve “nell’arco di qualche giorno”. |
| `451 4.7.650 ... temporarily rate limited due to IP reputation (S775)` | Outlook.com | Non compare nella tabella pubblicata da Microsoft. | Riduci volumi e connessioni simultanee, poi controlla SNDS. |
| `451 4.7.652 ... exceeded the maximum number of connections (S3115)` | Outlook.com | Non compare nella tabella. Il testo indica la causa. | Apri meno connessioni. |
| `421 RP-001`, `RP-002`, `RP-003` | Outlook.com | Superati i limiti di frequenza, di frequenza per connessione e di connessioni, “legati alla reputazione dell’IP o del dominio”. | Rallenta gli invii, poi controlla SNDS. |
| `550 5.7.515 Access denied, sending domain [domain] does not meet the required authentication level.` | Outlook.com | Il dominio invia più di 5.000 messaggi al giorno e non soddisfa i requisiti SPF, DKIM e DMARC. | Correggi autenticazione e allineamento. |
| `550 5.7.1 ... part of their network is on our block list (S3150)` | Outlook.com | Blocco sul tuo IP o sul tuo intervallo di IP. | Smetti di inviare da quell’IP e apri un ticket. |
| `550 SC-001`, `SC-004`, `OU-002` e simili | Outlook.com | Rifiuti per policy legati a contenuti, reputazione o segnalazioni di spam. SC-004 rimanda a JMRP. | Trova la causa prima di riprendere. |
| `550 5.7.606-649 Access denied, banned sending IP [IP]` | Microsoft 365 | L’IP è nell’elenco dei mittenti bloccati. | Richiedi la rimozione su `sender.office.com`. |
| `550 5.7.511 Access denied, banned sender` | Microsoft 365 | Richiede un’indagine manuale. | Inoltra l’NDR (il rapporto di mancato recapito) a `delist@microsoft.com`. |

Fonti: il [riferimento sugli NDR di Exchange Online](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online), l’[articolo sugli ASxxx](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/fix-error-code-451-4-7-500-699-asxxx-in-exchange-online), la tabella dei codici del sito Postmaster e l’[articolo su 550 5.7.515](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com) di Microsoft; Al Iverson su [S775](https://www.spamresource.com/2026/02/microsoft-rate-limiting-issues.html) e [S3115](https://www.spamresource.com/2025/07/microsoft-says-too-many-connections.html); Twilio SendGrid sui [blocchi S3140/S3150](https://support.sendgrid.com/hc/en-us/articles/38465017420955-Troubleshooting-Microsoft-Delivery-Issues-With-Error-550-5-7-1-S3140-S3150-Blocks).

### Il 4 o il 5 ti dice cosa fare

Le [Sender Best Common Practices di M3AAWG](https://www.m3aawg.org/sites/default/files/document/M3AAWG_Senders_BCP_Ver3-2015-02.pdf) dicono che dopo un errore temporaneo “il mittente dovrebbe chiudere la connessione e aprirne una nuova più tardi”, e che i mittenti non devono mai trattare un errore temporaneo come permanente. Le [policy per i mittenti](https://substrate.office.com/ip-domain-management-snds/Postmaster/Policies) di Microsoft, sui 5xx: “il mittente non deve tentare di ritrasmettere quel messaggio a quel destinatario”.

Un 451 non è un rimbalzo. Se la tua piattaforma o uno script lo trattano come tale, correggi prima questo.

## Un incidente di Microsoft o la tua reputazione?

Le indicazioni di Microsoft su 4.7.500 ti invitano a guardare i tuoi invii. Di solito è giusto, ma non sempre.

### Com’è andato il 4 settembre 2026

Qboxmail [ha scritto su mailop](https://www.mail-archive.com/mailop@mailop.org/msg27208.html) che il problema “è iniziato alle 9:47 CEST su tutti i nostri IP contemporaneamente”, con i sottocodici S77714, S77717 e S77719. La [pagina di stato](https://poppulo1.statuspage.io/incidents/w0671ycn23fw) di Poppulo ha riportato l’ID dell’incidente di Microsoft, EX1467029, con inizio alle 11:19 BST.

Secondo la [ricostruzione di emailexpert del 10 settembre](https://emailexpert.com/microsofts-ten-days-three-exchange-online-incidents-three-causes/), un operatore ha dato la colpa a dei tagli della fibra finché One.com, Qboxmail, Mailjet e Poppulo non hanno segnalato gli stessi codici su ogni IP di invio e in ogni regione. Microsoft ha attribuito la colpa prima a un modello antispam, poi a una regola di throttling ancora attiva durante il ripristino. emailexpert non ha trovato alcun report pubblico post-incidente. Un altro guasto, legato all’autenticazione (MO1465074), è durato circa 67 ore, dal 31 agosto al 3 settembre. Il nostro [report di settembre](/it/blog/state-of-email-september-2026) racconta quei dieci giorni.

### Cinque controlli prima di agire

1. **Quanto è esteso il problema.** I problemi della piattaforma colpiscono ogni IP, dominio e flusso di invio nel giro di pochi minuti. I problemi di reputazione di solito iniziano su uno solo.
2. **Gli altri provider.** Se Gmail, Yahoo e Apple accettano normalmente e altri mittenti segnalano lo stesso codice di Microsoft, la causa è probabilmente Microsoft.
3. **Le tue ultime 72 ore.** Un picco di volume, un nuovo IP, una lista importata, una modifica al DNS o un invio di riattivazione vanno sistemati in ogni caso.
4. **Chiedi in giro.** Controlla l’archivio di mailop e le pagine di stato. Un admin di Microsoft 365 può aprire **Health > Service health** (lo stato dei servizi), dove la [Issue history](https://learn.microsoft.com/en-us/microsoft-365/enterprise/view-service-health), la cronologia dei problemi, riporta gli incidenti pubblicati sul tuo tenant negli ultimi 7 o 30 giorni. È lì che Poppulo ha trovato EX1467029.
5. **SNDS.** Se è verde e senza blocchi mentre i rinvii si accumulano, il problema probabilmente non è tuo.

| Segnale | Indica Microsoft | Indica te |
|---|---|---|
| Tempistica | Tutti gli IP iniziano nello stesso minuto | Un solo IP o dominio, o un aumento graduale |
| Altri provider | Normali | In peggioramento anche loro, o segnalazioni di spam in aumento |
| Altri mittenti | Stesso codice su mailop e sulle pagine di stato | Nessun altro ne parla |
| Tue modifiche recenti | Nessuna | Salto di volume, nuovo IP, nuova lista |
| SNDS | Verde, nessun blocco | Giallo o rosso, segnalazioni di spam, “Blocked” |
| Codice | 4.7.500 con un sottocodice segnalato anche da altri | RP-00x, 4.7.650, 5.7.515, S3150 |

![Un diagramma di flusso decisionale per le risposte di Microsoft: i codici 5xx portano a correggere l’autenticazione, al portale di rimozione dall’elenco o a un ticket di supporto; i codici 4xx portano a verificare se c’è un incidente, poi ad aspettare che passi oppure a rallentare gli invii e controllare SNDS.](/images/blog/microsoft-451-4-7-500-deferrals-playbook-flowchart.png)

*Come gestire una risposta di Microsoft, in base alla documentazione di Microsoft e ai report sull’incidente di settembre 2026.*

## SNDS e JMRP: configurali prima che ti servano

[Smart Network Data Services](https://substrate.office.com/ip-domain-management-snds/snds) (SNDS) è il portale gratuito di Microsoft sulla reputazione di ogni IP verso Outlook.com. Le [FAQ di SNDS](https://substrate.office.com/ip-domain-management-snds/SNDS/FAQ) elencano cosa mostra per ogni IP autorizzato:

- **Filter result** (risultato del filtro). Verde significa meno del 10% di messaggi classificati come spam, giallo dal 10% al 90%, rosso oltre il 90%.
- **Complaint rate** (tasso di segnalazioni), cioè il rapporto tra segnalazioni di spam e destinatari. Più del 30% degli IP resta sotto lo 0,3%, “un buon obiettivo a cui puntare”.
- **Comandi RCPT rispetto ai destinatari dei messaggi** (RCPT commands e message recipients). Un forte scarto indica liste non aggiornate.
- **IP status** (stato dell’IP): Blocked, Bot o Junked.

I dati “potrebbero non essere presenti per gli IP che hanno inviato meno di 100 messaggi in quel giorno”. Per ottenere l’accesso, richiedi un IP, un intervallo o un ASN: SNDS invia un link agli indirizzi che trova tramite DNS inverso (`postmaster@`, `abuse@`) o RDAP. Non sono previste richieste manuali.

SNDS è stato rilanciato a giugno 2026. Al Iverson [ha fatto notare il 19 giugno](https://www.spamresource.com/2026/06/snds-and-jmrp-in-transition.html) che i return path di JMRP non identificano più in modo affidabile campagna e destinatario, quindi codifica queste informazioni altrove. Secondo la home page di SNDS (aggiornata il 22 settembre), l’accesso scade 10 mesi dopo l’approvazione o la migrazione, con tre promemoria. Mettilo in calendario.

Il [Junk Mail Reporting Program](https://substrate.office.com/ip-domain-management-snds/Postmaster/Services) (JMRP), a cui ci si iscrive da SNDS, ti rimanda ogni messaggio che un utente di Outlook.com contrassegna come posta indesiderata, spesso “in appena 72 ore” dall’iscrizione. Rimuovi da ogni lista chi ha segnalato i messaggi e iscrivi i nuovi IP man mano che li aggiungi. Sugli IP condivisi che non puoi registrare, chiedi al tuo provider cosa monitora.

## Supporto ai mittenti e rimozione dalla lista

**Outlook.com.** Il modulo di supporto nella [pagina di troubleshooting del sito Postmaster](https://substrate.office.com/ip-domain-management-snds/Postmaster/Troubleshooting) richiede un account Microsoft, copre solo i quattro domini personali e “non garantisce” la consegna. Twilio SendGrid (consiglio di un fornitore) suggerisce di includere il tuo dominio, gli IP, una descrizione del flusso di invio, il testo del rimbalzo e gli screenshot di SNDS, di rispondere alla prima risposta automatica chiedendo un’escalation e di richiedere la tua quota di volume e una revisione del Volume-Based Limit.

**Microsoft 365.** Per `5.7.606-649`, usa il [portale di rimozione dall’elenco](https://learn.microsoft.com/en-us/defender-office-365/external-senders-use-the-delist-portal-to-unblock-yourself) (delist portal) su `sender.office.com`: un indirizzo e un IP per visita, con conferma via email. La rimozione “potrebbe richiedere fino a 24 ore o più”. Per `5.7.511`, invia l’NDR via email a `delist@microsoft.com` e aspettati una risposta entro 48 ore.

Per un throttling ASxxx non esiste rimozione dall’elenco. Se l’azienda destinataria filtra la posta in entrata tramite un servizio di terze parti prima di Microsoft 365, l’articolo di Learn dice che un connettore configurato dai suoi admin elimina il throttling. Altrimenti si risolve man mano che costruisci uno storico.

## Nuovi tentativi, throttling e crescita graduale

**Riprova secondo un calendario.** La [RFC 5321, sezione 4.5.4.1](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.5.4.1) dice che “l’intervallo tra i tentativi DOVREBBE essere di almeno 30 minuti” e che il tempo prima di rinunciare “in genere deve essere di almeno 4-5 giorni”, con due tentativi nella prima ora, poi uno ogni due o tre ore. Non accorciarlo per un invio urgente.

**Rallenta per destinazione.** M3AAWG dice che i server riceventi si aspettano un adeguamento “come processo complessivo per tutte le email che ricevono dallo stesso indirizzo IP”. Quando Microsoft rinvia, rallenta tutto ciò che va a quella famiglia di MX (Outlook.com o Microsoft 365).

**Tieni d’occhio le connessioni.** La policy di Outlook.com dice che i mittenti “non devono aprire più di 500 connessioni simultanee” senza un accordo preventivo. È un tetto massimo, e un `4.7.652 (S3115)` significa che hai superato il tuo.

**Fai crescere gradualmente nuovi IP e domini.** Secondo Microsoft, un nuovo IP “può aspettarsi di andare completamente a regime entro un paio di settimane o prima”, a seconda di volume, accuratezza della lista e segnalazioni di spam. I nuovi IP coperti da un record SPF esistente ereditano una parte della reputazione del dominio. Parti dai contatti che hanno interagito di recente.

## Cosa non fare

- **Insistere con i tentativi.** Svuotare la coda ogni pochi minuti accumula connessioni su un IP che Microsoft vuole rallentare, e ti fa guadagnare un 4.7.652.
- **Cambiare IP per aggirarlo.** I nuovi IP non hanno reputazione e hanno più probabilità di avere problemi, e distribuire la posta su IP nuovi è esattamente ciò che fanno gli spammer snowshoe.
- **Riprovare dopo un 5xx.** Microsoft lo vieta, e dopo “più risposte di mancato recapito” devi smettere di inviare a quel destinatario.
- **Escludere i contatti con invii rinviati.** L’indirizzo è ancora valido.
- **Inviare di nuovo ai destinatari rinviati.** I loro messaggi sono ancora in coda: invieresti dei duplicati.
- **Modificare il DNS in preda al panico.** Cambiare SPF o DKIM nel mezzo di un incidente aggiunge un secondo problema, a meno che tu non abbia ricevuto un `5.7.515`.

Per l’allineamento DMARC e il passaggio da `p=none` a una policy applicata, consulta la nostra [guida alla deliverability](/it/blog/email-deliverability). Per continuare a far arrivare reimpostazioni della password e ricevute, la nostra [guida alle email transazionali](/it/blog/transactional-emails) spiega come spostarle su un dominio dedicato.

## Come appare in Brew

Brew gestisce l’infrastruttura di invio e ripete i tentativi dopo gli errori temporanei, quindi non devi mai regolare code o limiti di connessione. Ecco cosa vedi:

- **Eventi Consegna ritardata.** Un rinvio registra un evento Consegna ritardata (`delivery_delayed`), e il destinatario passa da accettato a in ritardo, poi a consegnato o rimbalzato. In **Eventi**, cerca “consegna ritardata”, poi digita `@hotmail.com` o `@outlook.com` per restringere a Outlook.com (i filtri per dominio si combinano con una O logica; i destinatari di Microsoft 365 usano i propri domini). L’evento dice che il messaggio è in attesa, non perché.
- **Dettagli dei rimbalzi.** I Metadati di un evento Rimbalzata contengono il tipo di rimbalzo e il messaggio del provider.
- **Conteggi tramite l’API.** La [panoramica delle statistiche](https://docs.brew.new/api-reference/public-v1/analytics/brand-overview-totals-rates-timeseries) restituisce `deliveryDelayed` e `pending` accanto alle email consegnate e rimbalzate. `get_email_analytics` fa lo stesso tramite MCP.
- **Esclusioni che rispettano i 4xx.** Rimbalzi permanenti e segnalazioni di spam portano subito all’esclusione. I rimbalzi temporanei (soft bounce) solo dopo tre nell’arco di 30 giorni.
- **Crescita graduale.** L’[Invio graduale](https://docs.brew.new/create-emails/send-options#gradual-send) divide un invio di grandi dimensioni in lotti percentuali orari o giornalieri, che puoi mettere in pausa se Outlook.com inizia a rinviare.
- **Salute del dominio.** La scheda Deliverability di ogni dominio assegna un punteggio da 0 a 100 su posizionamento in inbox, reputazione, autenticazione, contenuti e configurazione di invio, disponibile anche tramite lo strumento MCP `get_domain_health`. Un test di posizionamento in inbox (10 crediti) raggiunge inbox di test su Gmail, Outlook, Yahoo, Apple e altri provider.

I webhook di consegna e i dati di SNDS o JMRP non sono ancora disponibili in Brew (i conteggi per provider si ottengono dall’API degli eventi con `groupBy=recipientDomain`), quindi per la reputazione usa i portali di Microsoft. Durante un sospetto incidente di Microsoft, noi lasceremmo stare l’invio e guarderemmo Consegna ritardata trasformarsi in Consegnata.

## Domande frequenti

### Cosa significa 451 4.7.500 Server busy da Outlook o Microsoft 365?

È un rifiuto temporaneo di Microsoft 365 (Exchange Online), elencato come “Access denied, please try again later” dopo un’attività sospetta. Di solito è cambiato il tuo modo di inviare, ma il 4 settembre 2026 si trattava di un incidente di Microsoft (EX1467029). Lascia che il tuo server riprovi e verifica se lo vedono anche altri mittenti.

### Per quanto tempo Microsoft continuerà a rinviare le mie email?

Microsoft dice che il throttling basato sulle abitudini di invio si risolve “nell’arco di qualche giorno” man mano che costruisci uno storico, e che la rimozione dall’elenco può richiedere fino a 24 ore o più. Continua a riprovare per almeno 4-5 giorni, come raccomanda la RFC 5321, e la maggior parte della posta rinviata verrà comunque consegnata.

### Cos’è 550 5.7.515 e come si risolve?

Outlook.com rifiuta la posta dei domini che inviano più di 5.000 messaggi al giorno senza rispettare le sue regole di autenticazione, applicate dal 5 maggio 2025. SPF e DKIM devono superare il controllo, il dominio deve pubblicare DMARC (basta `p=none`) e SPF o DKIM devono essere allineati con il dominio From.

### Devo prendere un nuovo indirizzo IP se Microsoft blocca il mio?

No. Microsoft dice che i nuovi IP non hanno reputazione e hanno più probabilità di avere problemi. Risolvi la causa, chiedi la rimozione dall’elenco e torna a far crescere gradualmente i volumi sull’IP che hai.

### I rinvii di Microsoft contano come rimbalzi?

No. M3AAWG dice che i mittenti non devono trattare un 4xx come permanente. Diventa un rimbalzo solo se i tentativi si esauriscono o il server restituisce un 5xx. In Brew un rinvio compare come evento Consegna ritardata, e i contatti vengono esclusi solo dopo ripetuti rimbalzi temporanei.