Desde la noche del viernes 6 de noviembre de 2026, hora de Estados Unidos, administradores de correo en la lista de correo Mailop empezaron a reportar un patrón inusual: los mensajes enviados a los buzones de consumo de Microsoft eran rechazados en firme cuando el dominio de envío no publicaba un registro DMARC. El especialista en entregabilidad Al Iverson reprodujo el comportamiento en sus propias pruebas y lo documentó en Spam Resource, y los informes fueron confirmados de forma independiente por dmarcian, EasyDMARC y el proveedor francés de correo transaccional Sweego, que observó los rechazos en su propio tráfico transaccional.
Cómo eran los rebotes
Los remitentes recibían un aviso de fallo permanente que decía:
550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)
Varios detalles diferenciaban este comportamiento de las reglas de Microsoft para remitentes masivos:
- El rechazo afectaba al correo enviado a direcciones de outlook.com, hotmail.com, live.com y msn.com, pero no a los buzones empresariales de Microsoft 365, que aceptaron los mismos mensajes en las pruebas de Iverson.
- También se rechazaban dominios con SPF y DKIM válidos y en regla. Solo importaba la ausencia de registro DMARC.
- Se veían afectados remitentes pequeños. El requisito publicado por Microsoft cubre a quienes envían 5.000 o más mensajes al día y genera un rebote distinto, el 550 5.7.515, que detalla los resultados individuales de SPF, DKIM y DMARC. El nuevo rebote 5.7.1 solo indica que faltan registros de autenticación.
- Los rechazos eran intermitentes. Algunos mensajes pasaban y otros remitentes veían aceptado su correo al reintentarlo, lo que hacía el problema fácil de pasar por alto o de diagnosticar mal.
Microsoft no ha anunciado nada
Al 9 de noviembre de 2026, Microsoft no había publicado ningún aviso de postmaster, ninguna entrada de blog ni ninguna nota de estado del servicio que describiera el comportamiento. Un moderador en un hilo del foro de soporte de Microsoft escribió el 7 de noviembre que los contribuyentes del foro no podían confirmar si los informes se habían escalado al equipo de protección de correo de Outlook.com, y sugirió que los rechazos intermitentes entre remitentes de distintos proveedores apuntaban a algo más amplio que un único dominio mal configurado. Microsoft ha reconocido un problema en curso como degradación del servicio bajo investigación, y The Register recoge la discusión del foro al sugerir que el comportamiento podría no haber sido intencionado.
Hacia el mediodía del lunes 9 de noviembre, hora de Estados Unidos, Iverson informó de que sus mensajes de prueba volvían a entregarse y de que otros remitentes veían lo mismo, por lo que la interrupción inmediata parece haber terminado. Si fue un endurecimiento deliberado que se revirtió o un error de filtrado, Microsoft no lo ha dicho.
Por qué los remitentes deberían tomarlo como una advertencia
El episodio importa menos por lo que Microsoft pretendía que por lo que demostró. Durante aproximadamente tres días, uno de los mayores proveedores de buzones del mundo rechazó correo de dominios sin autenticar a cualquier volumen, sin una sola palabra oficial de advertencia. Los dominios que habían confiado en “somos demasiado pequeños para las reglas de remitentes masivos” o en “con SPF y DKIM basta” descubrieron que ambas suposiciones pueden fallar de la noche a la mañana.
La solución reportada por remitentes en el hilo de preguntas y respuestas de Microsoft es la misma que la industria recomienda desde hace años: publicar un registro DMARC. Varios comentaristas confirmaron que añadir un registro, incluso con política p=none, detuvo los rebotes. Un registro p=none no cuesta nada, satisface la comprobación y le entrega informes agregados que muestran quién envía correo como su dominio, la base para avanzar hacia la aplicación estricta más adelante.
Qué hacer ahora
Revise todos los dominios desde los que envía correo, incluidos los dominios aparcados y las herramientas internas que envían notificaciones, y asegúrese de que cada uno publica un registro DMARC. Confirme que SPF y DKIM están publicados y alineados con el dominio visible del campo From, porque DMARC solo pasa si al menos uno de los dos está alineado. Después, supervise sus informes agregados antes de endurecer la política. Si prefiere que la autenticación, la higiene del DNS y la entregabilidad las lleve una plataforma que mantiene DMARC desde el primer día, regístrese gratis en Excello Mail.