Microsoft rechaza correos sin registros DMARC sin aviso previo

El viernes por la mañana, 7 de noviembre de 2026, los administradores notaron un pico repentino en el rechazo de emails enviados a dominios gestionados por Microsoft como hotmail.com y outlook.com. El mensaje de rechazo citaba la falta de registros de autenticación, señalando específicamente la ausencia de políticas DMARC a pesar de contar con configuraciones válidas de SPF y DKIM. Este cambio no anunciado ha interrumpido las comunicaciones para numerosos servidores de correo autoalojados y pequeñas empresas que dependen de configuraciones DNS estándar.

Qué ocurrió

El problema fue identificado inicialmente por Mythic Beasts, un proveedor de hosting, después de que sus logs mostraran más de 500 rechazos el jueves que no habían ocurrido previamente. El código de error devuelto por los servidores de Microsoft era 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records. Crucialmente, los mensajes rechazados poseían registros completamente válidos de Sender Policy Framework (SPF) y DomainKeys Identified Mail (DKIM). El único componente faltante era un registro de Domain-based Message Authentication, Reporting, and Conformance (DMARC) en la zona DNS del dominio.

Para probar una solución, el equipo añadió un registro DMARC con la política establecida en "none" para varios dominios afectados. Esta política indica a los servidores receptores que el propietario del dominio no tiene instrucciones específicas para manejar correo no autenticado, actuando efectivamente como si no existiera ninguna política. Una vez publicado este registro, los servidores de Microsoft volvieron a aceptar los emails. Un estudio más amplio a través del Fediverse confirmó que otros operadores independientes estaban experimentando fallos idénticos, lo que indicaba un cambio generalizado en la lógica de filtrado de correo entrante de Microsoft, en lugar de un error de configuración aislado.

Inicialmente, la falta de anuncio llevó a especular que podría tratarse de un endurecimiento deliberado de los estándares de seguridad. El año pasado, Microsoft había introducido un requisito para que los dominios que envían más de 5.000 mensajes al día publicaran un registro DMARC, pero ese cambio se comunicó con mucha antelación. Este reciente cambio parecía aplicarse a todos los remitentes independientemente del volumen y sin advertencia previa. Una actualización del informe original aclaró posteriormente que el cambio probablemente fue involuntario, aunque Microsoft aún no había determinado cómo revertir el error de configuración.

Detalles clave

• Mensaje de error: Los emails rechazados devuelven 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records.
• Servicios afectados: La entrega de correo a hotmail.com y outlook.com está impactada.
• Causa raíz: Ausencia de un registro DNS DMARC, incluso cuando SPF y DKIM están correctamente configurados.
• Solución temporal: Publicar un registro DMARC con una política p=none restaura la entregabilidad.
• Alcance: El cambio parece afectar a todos los remitentes, no solo a aquellos de alto volumen que superan los 5.000 mensajes diarios.
• Estado: Microsoft no ha emitido un comunicado oficial ni un cronograma de reversión, aunque fuentes internas sugieren que el cambio fue accidental.

Contexto

La autenticación de correo electrónico depende de tres protocolos principales para prevenir el spoofing y el phishing. SPF lista las direcciones IP autorizadas para enviar email desde un dominio. DKIM añade una firma digital a cada mensaje, permitiendo al receptor verificar que no ha sido alterado durante el tránsito. DMARC se basa en estos dos especificando qué debe hacer el servidor receptor si un mensaje falla las comprobaciones de SPF o DKIM. Las políticas pueden establecerse en "none" (solo monitoreo), "quarantine" (enviar a spam) o "reject" (bloquear por completo).

Aunque DMARC es una buena práctica de seguridad, muchas configuraciones pequeñas autoalojadas lo omiten porque requiere un monitoreo cuidadoso para asegurar que el correo legítimo no sea bloqueado accidentalmente. Históricamente, los grandes proveedores han implementado gradualmente los requisitos de DMARC, comenzando a menudo con los remitentes de alto volumen. La aplicación repentina de la presencia de DMARC, incluso con una política pasiva "none", representa un cambio significativo en cómo los filtros de entrada validan la identidad del remitente. Esto convierte a DMARC de una mejora de seguridad recomendada a un requisito estructural obligatorio para la entrega básica.

Por qué importa

Para equipos que ejecutan su propio software o gestionan correo autoalojado, este incidente destaca la fragilidad de depender de plataformas externas con cambios operativos opacos. Sin aviso previo, comunicaciones comerciales críticas pueden desaparecer en agujeros negros, sin una forma inmediata de diagnosticar el problema a menos que se monitoreen de cerca los logs de rebotes. El hecho de que SPF y DKIM válidos fueran insuficientes subraya que los requisitos de cumplimiento evolucionan más rápido de lo que muchos pequeños operadores pueden rastrear.

Además, la incapacidad de contactar con Microsoft para obtener soporte agrava el problema. Los líderes de TI y desarrolladores pequeños deben confiar en foros comunitarios y depuración por ensayo y error para resolver problemas de entrega. Esto aumenta la carga operativa para equipos pequeños que pueden no tener expertos dedicados en entregabilidad de email. También sirve como recordatorio de que las configuraciones DNS de "configurar y olvidar" son riesgosas cuando los grandes destinatarios cambian su lógica de validación inesperadamente.

Qué puedes hacer

• Revisa tu DNS: Verifica si tu dominio tiene un registro DMARC utilizando herramientas de consulta en línea o utilidades de línea de comandos como dig.
• Añade un registro temporal: Si falta, añade un registro TXT para _dmarc.yourdomain.com con el valor v=DMARC1; p=none; para restaurar la entregabilidad inmediata.
• Monitorea los logs de rebote: Revisa los logs de tu servidor de correo para errores 550 5.7.1 e identificar cualquier mensaje perdido de los últimos días.
• Valida registros existentes: Asegúrate de que tus registros SPF y DKIM sigan siendo válidos y alineados con tu infraestructura de correo actual.
• Comunícate con los usuarios: Si conoces clientes que usan emails de Microsoft, infórmales sobre posibles retrasos y pídeles que revisen sus carpetas de spam.
• Planifica políticas más estrictas: Una vez restaurada la entregabilidad, considera pasar de p=none a p=quarantine o p=reject después de verificar que todas las fuentes legítimas pasan la autenticación.