Un correo enviado a una cuenta de Outlook.com puede rebotar aunque el dominio remitente tenga SPF y DKIM configurados. Desde el 5 de noviembre, administradores y proveedores de correo reportan rechazos en Outlook.com, Hotmail, Live y MSN cuando falta un registro DMARC, incluso en envíos de bajo volumen. El error que aparece es 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records, a veces seguido de AS9031519.
Los reportes describen un comportamiento irregular: algunos mensajes de un mismo dominio llegan y otros son rechazados; en ocasiones, el reenvío funciona. MailRoute y Teneo dicen haber observado el patrón en sus propios sistemas. Microsoft, en cambio, no ha publicado un aviso que confirme una nueva exigencia general ni ha explicado el identificador AS9031519. Esa falta de confirmación importa: también hay usuarios que dicen recibir el rechazo pese a tener los tres mecanismos configurados.
Un rechazo que no afecta a todos los mensajes
MailRoute sitúa sus primeros rebotes el 5 de noviembre en sus registros de correo saliente. Según la empresa, ese mismo día empezaron a aparecer informes públicos de otros administradores. Teneo describe rechazos desde esa fecha y documenta uno recibido el sábado 7 de noviembre a las 18:00 UTC, al enviar un mensaje a una dirección de outlook.be.
En el caso de Teneo, el mensaje tenía una firma DKIM del dominio remitente y el servidor de envío estaba autorizado por SPF; ambas comprobaciones pasaron. Lo que faltaba era el registro DMARC en _dmarc. Dos segundos después, otro mensaje del mismo dominio recibió la misma respuesta desde otro servidor de Outlook, según la empresa.
El error también apareció en consultas de usuarios publicadas en Microsoft Q&A. Un cliente dijo que alrededor del 50 % de sus clientes que le habían escrito desde el día anterior recibían el rebote. Otro explicó que varios clientes habituales ya no podían enviarle mensajes, aunque otros remitentes sí llegaban a su bandeja. Esa diferencia encaja con el carácter parcial que describen MailRoute y Teneo, pero no permite concluir que todos los casos tengan la misma causa.
Windows Latest informó de que pudo reproducir el problema el 8 de noviembre y recogió quejas de usuarios de Outlook.com y Hotmail. Un remitente contó que un mensaje enviado desde Zoho a una cuenta de Outlook.com fue rechazado a las 15:50 y llegó al repetir el envío a las 16:09; el mensaje entregado indicaba que SPF y DKIM habían pasado. El resultado del segundo intento no revela por sí solo qué ocurrió con el primero.
“Domains with valid SPF, DMARC and DKIM are being rejected. It only happens for a small percentage of the emails (probably depends on which Microsoft server your message gets routed to),”
— one user wrote
La frase procede de un comentario citado por Windows Latest en un foro de Microsoft. La publicación también recogió el caso de una persona que dijo que aproximadamente la mitad de los clientes que le habían escrito desde el 5 de noviembre recibieron un rechazo. En otro caso descrito en Microsoft Q&A, un usuario afirmó que sus mensajes a Gmail y a otra cuenta de Exchange sí se aceptaban, mientras que Outlook.com rechazaba el envío.
El código nuevo no es el error de alto volumen
Microsoft sí documenta una política de autenticación para remitentes de gran volumen, pero su página de soporte se refiere al código 550 5.7.515, no al 550 5.7.1 con AS9031519. La regla oficial alcanza a dominios que envían 5.000 mensajes o más a servicios de correo de consumo de Microsoft y usan el mismo dominio en la dirección From. Para ellos, Microsoft exige que SPF y DKIM pasen, que exista DMARC y que al menos SPF o DKIM estén alineados con el dominio From.
La página de soporte de Microsoft explica que DMARC puede pasar mediante SPF, DKIM o ambos, siempre que al menos uno se alinee con el dominio visible del remitente. También recomienda revisar la ruta de retorno, la firma DKIM y los ajustes de servicios externos que envían correo en nombre del dominio. Si una plataforma de facturación, un sistema de correo o un relay usa una firma o un dominio que no se alinea, que SPF o DKIM indiquen “pass” no basta necesariamente para que pase DMARC.
MailRoute y Teneo sostienen que los nuevos rechazos van más allá de esa regla: afectarían a dominios de cualquier volumen cuando no publican DMARC. Teneo distingue ambos errores por el código y el texto devuelto, y afirma que sus pruebas con el rechazo reciente no afectaron a buzones empresariales de Microsoft 365. Sus observaciones se refieren a los casos que han visto; Microsoft no ha confirmado que haya desplegado un requisito universal.
La diferencia también aparece en las respuestas de Microsoft Q&A. Una asesora independiente señaló que los requisitos para remitentes de gran volumen empezaron el año anterior y que el umbral de volumen era relevante. Otros participantes contaron que dominios muy por debajo de 5.000 mensajes diarios habían dejado de entregar correo. Las respuestas del foro no son un anuncio de Microsoft ni resuelven si el nuevo código corresponde a un cambio deliberado, a un despliegue parcial o a un fallo.
La solución que algunos remitentes ya probaron
En varios casos, añadir un registro TXT DMARC con el valor v=DMARC1; p=none permitió volver a entregar mensajes. Frank Lawler, en Microsoft Q&A, dijo que su correo desde Microsoft 365 a Hotmail rebotaba pese a que SPF y DKIM estaban bien. Tras comprobar que el dominio no tenía DMARC en el DNS público, publicó el registro y comunicó que Hotmail aceptó un nuevo envío. David R. describió una prueba similar: sus cabeceras indicaban que las comprobaciones pasaban, pero el registro público faltaba; después de añadirlo, el mensaje de prueba llegó a la misma cuenta Live.
Un usuario citado por Windows Latest también dijo que encontró ausente la entrada DMARC de su organización, la configuró con p=none y obtuvo resultados satisfactorios en sus pruebas posteriores. Son experiencias concretas, no una garantía para todos los rebotes: la propia Microsoft Q&A advierte que la ausencia de DMARC no demuestra por sí sola la causa en cada caso, y Windows Latest recogió quejas de remitentes que aseguraban tener registros válidos.
La política p=none declara el uso de DMARC, pero solicita a los receptores que no tomen medidas contra mensajes que no superen la validación. MailRoute y Teneo la presentan como el punto de partida que está resolviendo los casos observados. Añadir ese registro tampoco corrige una desalineación: si ni SPF ni DKIM pasan para el dominio que aparece en From, DMARC no se valida solo por haber publicado la entrada.
Para comprobar si existe el registro, MailRoute propone consultar el TXT de _dmarc del dominio. Desde una terminal, su ejemplo es dig +short TXT _dmarc.example.com, sustituyendo example.com por el dominio remitente. La empresa indica que una respuesta que empieza por v=DMARC1 confirma que hay un registro; la ausencia de resultados significa que no se encontró uno en esa consulta. Usuarios de Microsoft Q&A también recomendaron revisar el dominio público del remitente con MXToolbox.
El registro se publica en el proveedor de DNS del dominio, no en la configuración de la bandeja personal que recibe el correo. Un participante de Microsoft Q&A explicó que Microsoft 365 no crea automáticamente un registro DMARC para cada dominio. En ese mismo intercambio, un usuario encontró además registros DMARC duplicados y un error de sintaxis en SPF en otro dominio; por eso conviene revisar cada dominio de envío y no asumir que una única cuenta o servicio cubre todos los casos.
Qué pueden hacer remitentes y destinatarios
Si un mensaje rebota, los remitentes pueden conservar el informe completo de no entrega y comprobar SPF, DKIM, DMARC y la alineación con el dominio From. Microsoft recomienda usar las cabeceras del mensaje para revisar los resultados de autenticación y verificar también los servicios de terceros. Teneo aconseja buscar en los registros el texto del rechazo y el identificador AS9031519; si el problema continúa después de publicar DMARC, recomienda guardar la respuesta completa, incluido el nombre del servidor y la marca temporal.
El destinatario de Outlook.com no puede reparar los registros DNS del dominio que envía. En una respuesta de Microsoft Q&A, un usuario que preguntó si podía cambiar algo en su cuenta para recibir esos correos recibió la indicación de que el rechazo se produce antes de que el mensaje llegue al buzón. La sugerencia fue pedir al remitente o a su equipo de TI que revise DMARC; cambiar reglas de bandeja o la lista de remitentes seguros no corrige la configuración del dominio que origina el mensaje.
Si el remitente confirma que SPF, DKIM y DMARC pasan y están alineados, Microsoft Q&A plantea escalar el caso con el informe completo de no entrega y los datos del mensaje. Windows Latest también recomienda compartir el rebote con el proveedor de correo o con soporte de Microsoft. Reenviar el mensaje puede funcionar en algunos casos, pero no identifica la causa ni asegura que el siguiente intento llegue.
La cuestión que sigue abierta es si Microsoft está aplicando deliberadamente una comprobación de DMARC a remitentes de cualquier tamaño o si parte de los rechazos corresponde a un problema de servicio. MailRoute afirma que, a 6 de noviembre, no había encontrado un aviso de postmaster, una publicación en el blog ni una entrada de estado sobre el cambio. Teneo tampoco encontró, al 8 de noviembre, una declaración de Microsoft sobre AS9031519. Mientras no haya una explicación oficial, los reportes disponibles siguen mostrando dos situaciones: dominios sin DMARC que recuperaron la entrega tras publicarlo y remitentes que dicen recibir el mismo error pese a tener la autenticación configurada.
Fuentes: MailRoute, Microsoft Q&A, Microsoft Q&A, Microsoft Support, Windows Latest, Teneo SMTP Relay
