Descifra los códigos 451 4.7.500, 4.7.650, RP-001 y 550 5.7.515 de Microsoft, distingue una incidencia de Outlook de un problema de reputación y evita errores.
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.
*.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.550 5.7.515 siempre te toca arreglarlo a ti.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, 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, 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 el 4 de septiembre, el host de relay= es un tenant de Microsoft 365:
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))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 de Microsoft, su artículo sobre ASxxx, la tabla de códigos del sitio Postmaster y el artículo sobre 550 5.7.515; Al Iverson sobre S775 y S3115; Twilio SendGrid sobre los bloqueos S3140/S3150.
Las Sender Best Common Practices de M3AAWG 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 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.
La documentación de Microsoft sobre 4.7.500 apunta a tus propios envíos. Normalmente acierta, pero no siempre.
Qboxmail contó en mailop 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 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, 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 cubre esos diez días.
| 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 |
Qué hacer con cada respuesta de Microsoft, según su documentación y los informes sobre la incidencia de septiembre de 2026.
Smart Network Data Services (SNDS) es el portal gratuito de Microsoft que muestra la reputación de cada IP en Outlook.com. Las preguntas frecuentes de SNDS enumeran lo que muestra cada IP autorizada:
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 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 (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.
Outlook.com. El formulario de soporte de la página de solución de problemas de Postmaster 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 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 según un calendario. El RFC 5321, sección 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.
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. Para que los restablecimientos de contraseña y los recibos sigan llegando, nuestra guía de emails transaccionales explica cómo enviarlos desde su propio dominio.
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:
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é.deliveryDelayed y pending junto a los entregados y los rebotados. get_email_analytics hace lo mismo por 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.
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.
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.
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.
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.
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.
