Nadie lo anunció. Sin aviso del postmaster, sin entrada de salud del servicio, sin publicación en el blog de Microsoft. Desde el 5 de noviembre, sin embargo, los servidores de correo de consumo de Outlook están rechazando correos de dominios que no publican un registro DMARC en DNS — y lo inusual es que el impacto no se limita a los remitentes masivos. Un único mensaje de una pequeña oficina puede rebotar.
Así es lo que pasa: si tu dominio no tiene un registro DNS TXT con la política DMARC configurada, parte de tus correos enviados a outlook.com, hotmail.com, live.com y msn.com empieza a rebotar con el error:
550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS91519)
El código AS91519 cambia por mensaje — es un identificador interno del servidor Microsoft que procesó el rechazo — pero el mensaje de error en sí es consistente y directo. El primer día, algunos remitentes recibieron el mismo aviso sin el código entre paréntesis; la ausencia del identificador hacía el mensaje parecer aún más genérico y, de cierta forma, más alarmante, como si algo estuviera gravemente roto en vez de simplemente faltar una configuración.
El punto que más preocupa a los administradores de correo no es que el bloqueo exista, sino que es inconsistente. Outlook no rechaza todos los correos de un dominio sin DMARC — rechaza algunos. Un correo pasa, otro rebota, un reenvío puede funcionar. Para quien no monitorea logs de transporte, esto significa que clientes, proveedores o candidatos pueden estar intentando contactar y sin saber que el correo nunca llegó. La persona del otro lado nunca sabe que se envió un mensaje.
"Dominios con SPF, DMARC y DKIM válidos también están recibiendo rechazos. Solo pasa con un pequeño porcentaje de los correos (probablemente depende del servidor Microsoft al que tu mensaje es enrutado)", escribió un usuario en los foros de Microsoft, citado por Windows Latest. Otro reportó que la mitad de los clientes que lo contactaron desde el 5 de noviembre recibieron un mensaje de rechazo.
La situación es especialmente desconcertante porque muchos de estos dominios tienen SPF y DKIM configurados correctamente. Lo que falta, en la gran mayoría de los casos, es el registro DMARC que conecta estos dos mecanismos con la identidad del remitente. Sin él, incluso si el correo pasa la verificación de IP autorizada (SPF) y tiene una firma criptográfica válida (DKIM), Outlook ya no puede confirmar que el mensaje realmente pertenece al dominio declarado en el campo "De".
El registro que soluciona el problema es una sola línea en el DNS del dominio:
Name: _dmarc Value: v=DMARC1; p=none
La política p=none es el punto de partida seguro. Declara que el dominio usa DMARC y solicita a los receptores que envíen reportes, pero les dice que no tomen ninguna acción contra mensajes que fallen la verificación. Nada sobre cómo Gmail, Yahoo o cualquier otro proveedor trata tu correo cambia. El registro puede añadirse en minutos a través de la mayoría de los registradores.
¿Qué cambió realmente Microsoft?
La respuesta corta es: nadie lo sabe con certeza. Hasta el 6 de noviembre, no había ningún anuncio oficial. Lo que se sabe es que las reglas publicadas de Microsoft siempre requirieron SPF, DKIM y DMARC para remitentes que envían más de 5.000 mensajes por día a los servicios de consumo — la llamada regla de "bulk sender". Esa regla, actualizada en mayo de 2025, estaba claramente dirigida a departamentos de marketing y proveedores de correo masivo. La mayoría de las pequeñas empresas asumían, con razón, que no se aplicaba a ellas.
Lo que ha cambiado ahora es que el requisito parece haber caído sobre todos los remitentes, independientemente del volumen. Administradores en las listas Mailop, Fastmail y MailRoute reportaron rechazos para clientes con SPF y DKIM válidos y alineados al dominio "From" pero sin DMARC. Spam Resource probó el escenario el 7 de noviembre: correos a outlook.com fueron rechazados con el código 550 5.7.1, mientras que el mismo correo enviado a un dominio corporativo Microsoft 365 fue aceptado sin problema.
Esto confirma que el cambio no afecta al Microsoft 365 (el servicio empresarial), solo a los dominios de consumo — los que usuarios normales usan para correo personal. El filtro está corriendo en una capa diferente del sistema, lo que explica por qué dominios con configuración empresarial adecuada no sufren, pero un correo de un dominio pequeño a una cuenta individual Hotmail es bloqueado.
¿Por qué tantos dominios aún no tienen DMARC?
La respuesta es que DMARC siempre fue visto como algo para remitentes grandes. Si no envías 5.000 correos por día, no necesitabas preocuparte. El resultado es que cientos de miles de dominios — muchos de ellos pequeños negocios, sitios personales, ONGs y agencias públicas — nunca configuraron la política. Un levantamiento por DmarcDkim.com de 982 expositores en la feria it's.BB (alemana de TI) mostró que solo 364 dejan a los receptores rechazar suplantaciones de su dirección — esto significa que alrededor del 63% de los expositores no tenían protección DMARC, aun siendo empresas de tecnología.
La historia de la evolución del DMARC entre los principales proveedores muestra que el cambio de Microsoft no es aislado. En mayo de 2025, Outlook.com comenzó a requerir autenticación completa para remitentes de alto volumen. En noviembre de 2025, Gmail anunció que estaba "fortaleciendo la aplicación" con rechazos temporales y permanentes. Ahora, en noviembre de 2026, Outlook está extendiendo el requisito a todos los remitentes.
Cada proveedor sigue el mismo patrón: primero el filtro de spam, luego el requisito de alto volumen, luego el requisito universal. El DMARC con p=none, que hoy es el piso para recibir correo en Outlook, también es el primer paso hacia p=reject — que dice a los receptores que rechacen mensajes que suplanten el dominio. Cuando eso pase, la situación será aún más dramática, porque muchos dominios que hoy están en p=none no están preparados para p=reject.
Qué significa esto para la infraestructura de correo
El correo es el protocolo más antiguo de internet que aún funciona con la misma simplicidad de 1982. Pero esa simplicidad fue su ruina: sin autenticación nativa, el correo fue el primer servicio digital ampliamente explotado por estafadores, y DMARC fue la primera solución práctica al problema. Lo que Microsoft hizo hoy fue hacer la autenticación obligatoria en al menos uno de los mayores proveedores de correo del mundo — y, lo más importante, sin aviso previo.
La ausencia de anuncio puede parecer solo una falla de comunicación corporativa, pero el efecto práctico es una prueba en escala real: ¿cuántos dominios se rompen cuando DMARC se vuelve obligatorio, no recomendado? La respuesta le dirá al mundo si la infraestructura de correo global está lista para una era sin suplantación.
Los administradores que ya configuraron DMARC probablemente no sintieron nada más que alivio — el filtro ya estaba en su lugar. Para los demás, la curva de aprendizaje es corta: añadir un registro TXT, verificar que SPF y DKIM pasen para el dominio "From", y monitorear los reportes que empiezan a llegar. La diferencia es que esta vez, Microsoft no va a esperar.
La pregunta que queda es cuántos otros correos perdidos existen hoy en dominios que creían tener lo básico configurado — y cuántos más serán rechazados antes de que DMARC deje de ser el piso y se convierta en la pared.
Fuentes: MailRoute, Spam Resource, Windows Latest
✓ Fuentes independientes cruzadas y verificadas antes de la publicación
