Desde el 5 de noviembre, Outlook y Hotmail rechazan mensajes legítimos de forma inconsistente, sin aviso previo ni documentación oficial del cambio de política.
Microsoft comenzó a rechazar correos electrónicos dirigidos a direcciones de consumidor —Outlook, Hotmail, Live y MSN— si el dominio remitente no publica un registro DMARC, a partir del 5 de noviembre de 2025. El bloqueo afecta a remitentes pequeños que hasta ahora quedaban fuera de la política de mayo de 2025, que solo exigía DMARC a dominios que envían más de 5.000 mensajes diarios a buzones de consumidor. La empresa no emitió aviso previo, no publicó entrada en el portal de salud del servicio ni comunicado en su blog de postmaster. Los usuarios reciben códigos de error 550 5.7.1 o 550 5.7.23 en reportes de no entrega (NDR), pero el rechazo es intermitente: algunos mensajes pasan mientras otros rebotan desde el mismo dominio.
Cómo un cambio no documentado genera fallas silenciosas en transacciones críticas
La inconsistencia del bloqueo convierte el problema en una falla silenciosa. El remitente ve un rebote lleno de siglas técnicas, asume un error temporal y sigue adelante. El destinatario nunca sabe que se envió un mensaje. Facturas, confirmaciones de cita médica, restablecimientos de contraseña y cartas de oferta laboral desaparecen sin rastro visible para el cliente, que interpreta el silencio como negligencia del proveedor, no como un problema de entrega de correo.
Frank Dickson, de Dickson Research, señaló que exigir DMARC a todos los dominios remitentes hace el correo más seguro, pero implementarlo sin aviso y con mensajes de error que apuntan al problema equivocado genera caos operativo. Un moderador externo de Microsoft clasificó el problema como degradación del servicio bajo investigación activa en el foro comunitario de la empresa, pero no hay cronograma de resolución ni explicación oficial del alcance del cambio.
Por qué miles de dominios legítimos quedaron sin protección DMARC
DMARC (autenticación, reporte y conformidad de mensajes basada en dominio) verifica que el remitente sea quien dice ser, apoyándose en dos mecanismos previos: SPF (que valida la dirección IP del servidor remitente) y DKIM (que agrega una firma criptográfica al mensaje). Sin DMARC, suplantar un dominio es trivial, y ahí comienza buena parte del phishing y el compromiso de correo empresarial. Pero como Microsoft solo exigía DMARC a remitentes masivos, muchos emisores pequeños —pymes, organizaciones sin fines de lucro, escuelas, estudios jurídicos, consultorios médicos— concluyeron razonablemente que la política no les aplicaba.
Organizaciones más grandes también fallan en dominios secundarios, regionales o subdominios usados por plataformas de marketing y facturación, configurados años atrás y nunca revisados. Nadie es dueño del sistema de nombres de dominio (DNS), y el temor a romper correo legítimo enviado por terceros frena la adopción de controles más estrictos. Algunos dominios reportados como bloqueados tenían SPF, DKIM y DMARC funcionando, lo que sugiere que el problema no es solo ausencia de registros sino también un error en la lógica de validación de Microsoft.
Impacto en América Latina: dependencia de Outlook en sectores sin recursos técnicos propios
En Argentina, México y Colombia, Outlook y Hotmail concentran una porción significativa de cuentas de correo de consumidor, especialmente en sectores con infraestructura técnica limitada: consultorios médicos, estudios contables, pequeños comercios electrónicos y organizaciones educativas que operan con dominios configurados por terceros hace años. La falla silenciosa golpea con más fuerza en contextos donde no hay equipo de TI interno que monitoree logs de rebote ni interprete códigos de error SMTP. Un consultorio en Buenos Aires que envía confirmaciones de turno desde un dominio sin DMARC no sabrá que sus pacientes nunca recibieron el mensaje hasta que empiecen a faltar a las citas. Una tienda en línea en Ciudad de México que usa un proveedor de correo transaccional sin DMARC configurado perderá ventas sin entender por qué los clientes no completan el pago.
La región depende estructuralmente de servicios de correo gratuitos de Microsoft para comunicación con clientes, y la ausencia de aviso previo impide que estos emisores pequeños reaccionen antes de que el daño operativo sea visible. A diferencia de grandes remitentes que monitorean tasas de entrega en tiempo real, las pymes latinoamericanas descubren el problema cuando un cliente reclama por un servicio que nunca recibió confirmación.
Cómo verificar si un dominio está afectado y qué hacer para recuperar la entrega
MailRoute, empresa de seguridad de correo, publicó un comando de diagnóstico que cualquier organización puede ejecutar en una terminal para verificar si su dominio tiene DMARC: dig +short TXT _dmarc.example.com (reemplazando example.com por el dominio propio). Si la respuesta comienza con v=DMARC1, hay un registro DMARC activo. Si no hay respuesta, el dominio está expuesto al bloqueo.
La solución inmediata es agregar un registro TXT en la zona DNS del dominio: v=DMARC1 ; p=none. Esta configuración declara que el dominio usa DMARC y solicita reportes de validación, pero instruye a los receptores a no tomar acción sobre fallas (política p=none). Esto detiene los rebotes sin cambiar cómo otros proveedores tratan el correo, siempre que SPF o DKIM estén alineados con el dominio del campo From. Organizaciones con Microsoft 365 que nunca activaron DKIM para sus propios dominios deben hacerlo ahora.
Dickson advierte que p=none es solo el primer paso, no la meta final. El objetivo es llegar a p=reject, que instruye a los receptores a rechazar cualquier intento de suplantación del dominio. Para eso, las organizaciones necesitan inventariar cada servicio que envía correo en su nombre —CRM, sistema de facturación, plataforma de recursos humanos, herramientas de marketing— y validar que todos estén correctamente autenticados. Dickson señala que la mayoría de las organizaciones no puede producir esa lista completa, y sin ella es imposible implementar una política de rechazo sin romper flujos de correo legítimos.
Nuestro análisis
Este caso revela un patrón recurrente en cambios de política de seguridad de correo por parte de grandes proveedores: la intención es correcta —DMARC reduce drásticamente la superficie de ataque para phishing y suplantación—, pero la ejecución sin aviso previo, documentación clara ni período de transición convierte una mejora de seguridad en un riesgo operativo. La inconsistencia del bloqueo sugiere que Microsoft está probando o ajustando la implementación en producción, lo que explica por qué algunos mensajes pasan y otros rebotan desde el mismo dominio. La ausencia de comunicación oficial —ni entrada en el portal de salud del servicio, ni postmaster notice, ni blog post— deja a los administradores de correo sin contexto para diagnosticar el problema, y los códigos de error 550 5.7.1 y 550 5.7.23 no apuntan claramente a DMARC como causa raíz.
Lo que todavía no se sabe es si Microsoft planea mantener este requisito de forma permanente para todos los remitentes, independientemente del volumen, o si el bloqueo actual es un error de configuración que se corregirá. Tampoco está claro cuántos dominios están afectados ni cuánto correo transaccional crítico se está perdiendo sin que los remitentes lo sepan. La falla silenciosa es especialmente peligrosa en sectores regulados —salud, finanzas, educación— donde la pérdida de un mensaje puede tener consecuencias legales o de cumplimiento. ¿Cuántas organizaciones pequeñas en América Latina están perdiendo clientes en este momento sin saber que el problema no es su servicio, sino un cambio no documentado en la infraestructura de correo de Microsoft?