# Aplazamientos 451 4.7.500 de Microsoft: guía para remitentes

URL canónica: https://brew.new/es/blog/microsoft-451-4-7-500-deferrals-playbook
Autoría: Thomas Park
Publicado: 2026-10-05
Actualizado: 2026-10-05

Un aplazamiento de Microsoft es un rechazo SMTP temporal (una respuesta que empieza por 4) que envía un servidor de Outlook.com o de Microsoft 365 cuando no quiere aceptar tu mensaje en ese momento. Tu servidor debe conservarlo y volver a intentarlo. El más conocido es `451 4.7.500 Server busy. Please try again later`, y ese mismo código puede significar “tus envíos parecen sospechosos” o “Microsoft está teniendo un mal día”.

El 4 de septiembre de 2026 significaba lo segundo, y al menos un operador de correo con experiencia se pasó la mañana persiguiendo lo primero. Así puedes distinguirlos.

## Puntos clave

- Lee primero el host. `*.olc.protection.outlook.com` es el correo personal de Outlook.com, y `*.mail.protection.outlook.com`, un tenant de Microsoft 365. Documentación distinta, vía de escalado distinta.
- Un 4xx significa poner en cola y reintentar: el RFC 5321 pide al menos 30 minutos entre intentos, durante al menos 4 o 5 días. Un 5xx significa parar. Las políticas de Microsoft prohíben reintentarlo.
- Si todas tus IP reciben el mismo código de Microsoft en el mismo minuto mientras Gmail y Yahoo funcionan con normalidad, sospecha de Microsoft y revisa mailop antes de cambiar nada.
- Desde el 5 de mayo de 2025, Outlook.com exige SPF, DKIM y DMARC a los dominios que envían más de 5000 mensajes al día. Un `550 5.7.515` siempre te toca arreglarlo a ti.
- Registra ya tus IP de envío en SNDS y JMRP. El acceso a SNDS caduca a los 10 meses salvo que renueves la acreditación.
- No reintentes con más insistencia, no cambies a IP nuevas y no suprimas los contactos con envíos aplazados.

## Primero, averigua con qué Microsoft estás hablando

Microsoft tiene dos sistemas de recepción.

**Outlook.com** es el correo personal: `outlook.com`, `hotmail.com`, `live.com` y `msn.com`, con hosts MX como `hotmail-com.olc.protection.outlook.com`. Tiene el [sitio Postmaster de Outlook.com](https://substrate.office.com/ip-domain-management-snds/Postmaster/Troubleshooting), SNDS para la reputación y su propio formulario de soporte para remitentes.

**Microsoft 365** (Exchange Online) aloja buzones de empresa. El correo para `acme.com` va a `acme-com.mail.protection.outlook.com`. Los errores están documentados en [Microsoft Learn](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online), los bloqueos se gestionan a través de `sender.office.com` y son los administradores del destinatario quienes deciden cómo te trata su tenant.

El nombre de dominio no te dirá con cuál de los dos te estás encontrando. La respuesta, sí. En esta línea de registro [publicada en mailop](https://www.mail-archive.com/mailop@mailop.org/msg27209.html) el 4 de septiembre, el host de `relay=` es un tenant de 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))
```

## Descifra la respuesta

Lee el código básico (`451`), el código ampliado (`4.7.500`) y el subcódigo entre paréntesis, como `(S77714)`. Microsoft no publica los subcódigos S, pero que muchos remitentes informen del mismo a la vez ya es una señal.

| Respuesta | Dónde | Qué dice la documentación de Microsoft | Primer paso |
|---|---|---|---|
| `451 4.7.500 Server busy. Please try again later from [IP]. (S77714)` | Microsoft 365 | Learn incluye 4.7.500-699 como “Access denied, please try again later”: actividad sospechosa, envío restringido temporalmente. | Deja que la cola reintente. Comprueba primero a qué afecta. |
| `451 4.7.500-699 (ASxxx)` | Microsoft 365 | Limitación por IP cuando la IP que se conecta “cambió sus patrones de envío anteriores al enviar un volumen mucho mayor”. | Aumenta el volumen más despacio. Se resuelve “a lo largo de unos días”. |
| `451 4.7.650 ... temporarily rate limited due to IP reputation (S775)` | Outlook.com | No figura en la tabla publicada por Microsoft. | Reduce el volumen y la concurrencia, y después revisa SNDS. |
| `451 4.7.652 ... exceeded the maximum number of connections (S3115)` | Outlook.com | No figura en la tabla. El texto indica la causa. | Abre menos conexiones. |
| `421 RP-001`, `RP-002`, `RP-003` | Outlook.com | Límites superados de velocidad, de velocidad por conexión y de conexiones, “relacionados con la reputación de la IP o del dominio”. | Limita el ritmo y después revisa SNDS. |
| `550 5.7.515 Access denied, sending domain [domain] does not meet the required authentication level.` | Outlook.com | El dominio envía más de 5000 al día y no cumple el requisito de SPF, DKIM y DMARC. | Corrige la autenticación y la alineación. |
| `550 5.7.1 ... part of their network is on our block list (S3150)` | Outlook.com | Bloqueo de tu IP o de tu rango. | Deja de enviar desde esa IP y abre un ticket. |
| `550 SC-001`, `SC-004`, `OU-002` y similares | Outlook.com | Rechazos por política relacionados con el contenido, la reputación o las quejas. SC-004 remite a JMRP. | Encuentra la causa antes de reanudar los envíos. |
| `550 5.7.606-649 Access denied, banned sending IP [IP]` | Microsoft 365 | La IP está en la lista de remitentes bloqueados. | Solicita que la retiren en `sender.office.com`. |
| `550 5.7.511 Access denied, banned sender` | Microsoft 365 | Requiere una investigación manual. | Reenvía el informe de no entrega (NDR) a `delist@microsoft.com`. |

Fuentes: la [referencia de NDR de Exchange Online](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online) de Microsoft, su [artículo sobre 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 tabla de códigos del sitio Postmaster y el [artículo sobre 550 5.7.515](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com); Al Iverson sobre [S775](https://www.spamresource.com/2026/02/microsoft-rate-limiting-issues.html) y [S3115](https://www.spamresource.com/2025/07/microsoft-says-too-many-connections.html); Twilio SendGrid sobre los [bloqueos S3140/S3150](https://support.sendgrid.com/hc/en-us/articles/38465017420955-Troubleshooting-Microsoft-Delivery-Issues-With-Error-550-5-7-1-S3140-S3150-Blocks).

### El 4 o el 5 ya te dice qué hacer

Las [Sender Best Common Practices de M3AAWG](https://www.m3aawg.org/sites/default/files/document/M3AAWG_Senders_BCP_Ver3-2015-02.pdf) dicen que, tras un fallo temporal, “el remitente debería cerrar la conexión y abrir una nueva más tarde”, y que los remitentes nunca deben tratar un fallo temporal como permanente. Las [políticas para remitentes](https://substrate.office.com/ip-domain-management-snds/Postmaster/Policies) de Microsoft, sobre los 5xx: “el remitente no debe intentar retransmitir ese mensaje a ese destinatario”.

Un 451 no es un rebote. Si tu plataforma o algún script lo trata como tal, corrige eso primero.

## Incidencia de Microsoft o problema de tu reputación

La documentación de Microsoft sobre 4.7.500 apunta a tus propios envíos. Normalmente acierta, pero no siempre.

### Cómo fue el 4 de septiembre de 2026

Qboxmail [contó en mailop](https://www.mail-archive.com/mailop@mailop.org/msg27208.html) que el problema “empezó a las 9:47 (CEST) en todas nuestras IP a la vez”, con los subcódigos S77714, S77717 y S77719. La [página de estado](https://poppulo1.statuspage.io/incidents/w0671ycn23fw) de Poppulo citaba el identificador de incidencia de Microsoft, EX1467029, a partir de las 11:19 (BST).

Según el [análisis que publicó emailexpert el 10 de septiembre](https://emailexpert.com/microsofts-ten-days-three-exchange-online-incidents-three-causes/), un operador culpó a unos cortes de fibra hasta que One.com, Qboxmail, Mailjet y Poppulo informaron de los mismos códigos en todas sus IP de envío y en todas las regiones. Microsoft lo atribuyó a un modelo antispam y, después, a una regla de limitación que seguía activándose durante la recuperación. emailexpert no encontró ningún informe público posterior a la incidencia. Un fallo de autenticación distinto, MO1465074, duró unas 67 horas, del 31 de agosto al 3 de septiembre. Nuestro [informe de septiembre](/es/blog/state-of-email-september-2026) cubre esos diez días.

### Cinco comprobaciones antes de actuar

1. **A qué te afecta.** Los problemas de la plataforma afectan a todas las IP, dominios y tipos de envío en cuestión de minutos. Los problemas de reputación suelen empezar en uno solo.
2. **Otros proveedores.** Si Gmail, Yahoo y Apple aceptan tu correo con normalidad y otros remitentes informan del mismo código de Microsoft, lo más probable es que la causa esté en Microsoft.
3. **Tus últimas 72 horas.** Un pico de volumen, una IP nueva, una lista importada, un cambio de DNS o un envío de reactivación hay que corregirlos en cualquier caso.
4. **Pregunta por ahí.** Revisa el archivo de mailop y las páginas de estado. Un administrador de Microsoft 365 puede abrir **Estado > Estado del servicio** (**Health > Service health** en inglés), cuyo [historial de problemas](https://learn.microsoft.com/en-us/microsoft-365/enterprise/view-service-health) cubre las incidencias de los últimos 7 o 30 días publicadas en tu tenant. Ahí es donde Poppulo encontró EX1467029.
5. **SNDS.** Un estado verde y sin bloqueos mientras se acumulan los aplazamientos indica que el problema no está en ti.

| Señal | Apunta a Microsoft | Apunta a ti |
|---|---|---|
| Momento | Todas las IP empiezan en el mismo minuto | Una IP o un dominio, o un aumento gradual |
| Otros proveedores | Funcionan con normalidad | También empeoran, o suben las quejas |
| Otros remitentes | El mismo código en mailop y en las páginas de estado | Nadie más habla de ello |
| Tus cambios recientes | Ninguno | Un salto de volumen, una IP nueva, una lista nueva |
| SNDS | Verde, sin bloqueos | Amarillo o rojo, quejas, “Blocked” |
| Código | 4.7.500 con un subcódigo del que informan otros | RP-00x, 4.7.650, 5.7.515, S3150 |

![Diagrama de decisión para las respuestas de Microsoft: los códigos 5xx llevan a corregir la autenticación, al portal de exclusión de lista o a un ticket de soporte; los códigos 4xx llevan a comprobar si hay una incidencia y, después, a esperar a que pase o a limitar el ritmo y revisar SNDS.](/images/blog/microsoft-451-4-7-500-deferrals-playbook-flowchart.png)

*Qué hacer con cada respuesta de Microsoft, según su documentación y los informes sobre la incidencia de septiembre de 2026.*

## SNDS y JMRP: configúralos antes de necesitarlos

[Smart Network Data Services](https://substrate.office.com/ip-domain-management-snds/snds) (SNDS) es el portal gratuito de Microsoft que muestra la reputación de cada IP en Outlook.com. Las [preguntas frecuentes de SNDS](https://substrate.office.com/ip-domain-management-snds/SNDS/FAQ) enumeran lo que muestra cada IP autorizada:

- **Resultado del filtrado.** Verde es menos del 10 % de mensajes considerados spam; amarillo, entre el 10 % y el 90 %, y rojo, más del 90 %.
- **Tasa de quejas**: quejas entre destinatarios. Más del 30 % de las IP se mantienen por debajo del 0,3 %, “un buen listón al que aspirar”.
- **Comandos RCPT frente a destinatarios de los mensajes.** Una gran diferencia indica listas desactualizadas.
- **Estado de la IP**: Blocked, Bot o Junked.

Puede que los datos “no estén disponibles para las IP que enviaron menos de 100 mensajes ese día”. Para obtener acceso, solicita una IP, un rango o un ASN, y SNDS envía un enlace a las direcciones que encuentra mediante el DNS inverso (`postmaster@`, `abuse@`) o RDAP. No se aceptan solicitudes manuales.

SNDS se relanzó en junio de 2026. Al Iverson [señaló el 19 de junio](https://www.spamresource.com/2026/06/snds-and-jmrp-in-transition.html) que las rutas de retorno de JMRP ya no identifican de forma fiable la campaña y el destinatario, así que codifica esos datos en otra parte. Según la página de inicio de SNDS (actualizada el 22 de septiembre), el acceso caduca 10 meses después de la aprobación o de la migración, con tres recordatorios. Apúntalo en el calendario.

El [Junk Mail Reporting Program](https://substrate.office.com/ip-domain-management-snds/Postmaster/Services) (JMRP), en el que te inscribes desde SNDS, te devuelve cada mensaje que un usuario de Outlook.com marca como correo no deseado, a menudo “en tan solo 72 horas” desde la inscripción. Quita de todas tus listas a quienes se quejen e inscribe las IP nuevas a medida que las añadas. Con IP compartidas, que no puedes registrar, pregunta a tu proveedor qué vigila.

## Soporte para remitentes y retirada de listas de bloqueo

**Outlook.com.** El formulario de soporte de la [página de solución de problemas de Postmaster](https://substrate.office.com/ip-domain-management-snds/Postmaster/Troubleshooting) requiere una cuenta de Microsoft, solo cubre los cuatro dominios personales y “no garantiza” la entrega. Twilio SendGrid (consejo de un proveedor) recomienda incluir tu dominio, tus IP, una descripción del tipo de envío, el texto del rebote y capturas de SNDS; responder a la primera respuesta automática pidiendo que se escale el caso, y solicitar tu cuota de volumen y una revisión del Volume-Based Limit.

**Microsoft 365.** Para `5.7.606-649`, usa el [portal de exclusión de lista](https://learn.microsoft.com/en-us/defender-office-365/external-senders-use-the-delist-portal-to-unblock-yourself) en `sender.office.com`: una dirección y una IP por visita, con confirmación por email. La retirada “puede tardar hasta 24 horas o más”. Para `5.7.511`, envía el NDR por email a `delist@microsoft.com` y cuenta con una respuesta en un plazo de 48 horas.

Una limitación ASxxx no se puede retirar con una solicitud. Si la empresa destinataria filtra el correo entrante a través de un tercero antes de Microsoft 365, el artículo de Learn dice que un conector configurado por su administrador elimina la limitación. Si no, desaparece a medida que acumulas historial.

## Reintenta, limita el ritmo y aumenta el volumen poco a poco

**Reintenta según un calendario.** El [RFC 5321, sección 4.5.4.1](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.5.4.1), dice que “el intervalo entre reintentos DEBERÍA (SHOULD) ser de al menos 30 minutos” y que el plazo para desistir “por lo general tiene que ser de al menos 4 o 5 días”, con dos intentos en la primera hora y, después, uno cada dos o tres horas. No lo acortes por un envío urgente.

**Limita el ritmo por destino.** M3AAWG dice que los receptores esperan un ajuste “como un proceso global para todos los emails que les envía la misma dirección IP”. Cuando Microsoft aplaza tus envíos, ralentiza todo lo que va a esa familia de MX (Outlook.com o Microsoft 365).

**Vigila las conexiones.** La política de Outlook.com dice que los remitentes “no deben abrir más de 500 conexiones simultáneas” sin un acuerdo previo. Es un techo, y un `4.7.652 (S3115)` significa que has superado el tuyo.

**Aumenta poco a poco el volumen en IP y dominios nuevos.** Microsoft dice que una IP nueva “puede esperar estar a pleno rendimiento en un par de semanas o antes”, según el volumen, la exactitud de la lista y las quejas. Las IP nuevas que cubre un registro SPF existente heredan parte de la reputación del dominio. Empieza por los contactos que han interactuado hace poco.

## Qué no hacer

- **Reintentar con más insistencia.** Vaciar la cola cada pocos minutos acumula conexiones en una IP que Microsoft quiere frenar, y acabarás recibiendo un 4.7.652.
- **Cambiar de IP para esquivarlo.** Las IP nuevas no tienen reputación y es más probable que den problemas, y repartir el correo entre IP nuevas es justo lo que hacen los spammers que usan la técnica snowshoe.
- **Reintentar un 5xx.** Microsoft lo prohíbe y, tras “varias respuestas de no entrega”, debes dejar de enviar a ese destinatario.
- **Suprimir los contactos con envíos aplazados.** La dirección sigue siendo válida.
- **Reenviar a los destinatarios aplazados.** Sus mensajes siguen en la cola. Enviarías duplicados.
- **Tocar el DNS en pleno pánico.** Cambiar SPF o DKIM a mitad de una incidencia añade un segundo problema, salvo que hayas recibido un `5.7.515`.

Para la alineación DMARC y el paso de `p=none` a una política aplicada, consulta nuestra [guía de entregabilidad](/es/blog/email-deliverability). Para que los restablecimientos de contraseña y los recibos sigan llegando, nuestra [guía de emails transaccionales](/es/blog/transactional-emails) explica cómo enviarlos desde su propio dominio.

## Cómo se ve en Brew

Brew gestiona la infraestructura de envío y reintenta los fallos temporales, así que nunca tienes que ajustar colas ni límites de conexiones. Esto es lo que ves:

- **Eventos Retrasado.** Un aplazamiento registra un evento Retrasado (`delivery_delayed`), y el destinatario pasa de aceptado a retrasado y, después, a entregado o rebotado. En **Eventos**, busca “retrasado” y escribe `@hotmail.com` o `@outlook.com` para limitarte a Outlook.com (los filtros de dominio se combinan con un O lógico; los destinatarios de Microsoft 365 usan sus propios dominios). El evento indica que el mensaje está a la espera, no por qué.
- **Detalles del rebote.** La sección Metadatos de un evento Rebotado contiene el tipo de rebote y el mensaje del proveedor.
- **Recuentos por la API.** El [resumen de analíticas](https://docs.brew.new/api-reference/public-v1/analytics/brand-overview-totals-rates-timeseries) devuelve `deliveryDelayed` y `pending` junto a los entregados y los rebotados. `get_email_analytics` hace lo mismo por MCP.
- **Una supresión que respeta los 4xx.** Los rebotes duros y las quejas suprimen el contacto de inmediato. Los rebotes blandos solo lo suprimen después de tres en 30 días.
- **Aumento progresivo.** El [Envío gradual](https://docs.brew.new/create-emails/send-options#gradual-send) divide un envío grande en lotes por porcentaje, cada hora o cada día, que puedes pausar si Outlook.com empieza a aplazar tus envíos.
- **Salud del dominio.** La tarjeta Entregabilidad de cada dominio da una puntuación de 0 a 100 que tiene en cuenta la llegada a la bandeja de entrada, la reputación, la autenticación, el contenido y la configuración de envío; también está disponible con la herramienta MCP `get_domain_health`. Una prueba de bandeja de entrada (10 créditos) llega a buzones semilla de Gmail, Outlook, Yahoo, Apple y otros proveedores.

Brew todavía no ofrece webhooks de entrega ni datos de SNDS o JMRP (los recuentos por proveedor se obtienen de la API de eventos con `groupBy=recipientDomain`), así que usa los portales de Microsoft para la reputación. Ante una posible incidencia de Microsoft, nosotros dejaríamos el envío tal cual y veríamos cómo los eventos Retrasado pasan a Entregado.

## Preguntas frecuentes

### ¿Qué significa 451 4.7.500 Server busy en Outlook o Microsoft 365?

Es un rechazo temporal de Microsoft 365 (Exchange Online), que figura como “Access denied, please try again later” tras una actividad sospechosa. Normalmente se debe a que ha cambiado tu patrón de envío, pero el 4 de septiembre de 2026 fue una incidencia de Microsoft (EX1467029). Deja que tu servidor reintente y comprueba si otros remitentes también lo ven.

### ¿Cuánto tiempo seguirá Microsoft aplazando mis emails?

Microsoft dice que la limitación basada en patrones se resuelve “a lo largo de unos días” a medida que acumulas historial, y que la retirada de la lista puede tardar hasta 24 horas o más. Sigue reintentando durante al menos 4 o 5 días, como recomienda el RFC 5321, y la mayor parte del correo aplazado acabará entregándose.

### ¿Qué es 550 5.7.515 y cómo lo soluciono?

Outlook.com rechaza el correo de los dominios que envían más de 5000 mensajes al día y no cumplen sus normas de autenticación, que aplica desde el 5 de mayo de 2025. SPF y DKIM deben superarse, el dominio debe publicar DMARC (`p=none` es suficiente) y SPF o DKIM deben estar alineados con el dominio del From.

### ¿Debo conseguir una dirección IP nueva si Microsoft bloquea la mía?

No. Microsoft dice que las IP nuevas no tienen reputación y es más probable que den problemas. Corrige la causa, solicita que te retiren de la lista y vuelve a aumentar el volumen poco a poco con la IP que tienes.

### ¿Los aplazamientos de Microsoft cuentan como rebotes?

No. M3AAWG dice que los remitentes no deben tratar un 4xx como permanente. Solo se convierte en rebote si se agotan los reintentos o si el servidor devuelve un 5xx. En Brew, un aplazamiento aparece como un evento Retrasado, y los contactos solo se suprimen tras varios rebotes blandos.