un río abajo DMARC El pase no establece que la persona que inició un mensaje estaba autorizada a utilizar su remitente visible. La investigación LaunDroMARC de diciembre de 2025 de Engage Security describe una ruta indirecta en la que el envío de correos electrónicos cambia la identidad evaluada por SPF. Comprenda los saltos individuales antes de describir el hallazgo como una derivación DMARC universal o asumir que todos los inquilinos de Microsoft se comportan de la misma manera en la actualidad.
Separar las dos fuentes de evidencia.
El investigador original describe un mensaje entrante que pasó SPF para su propio dominio de sobre pero no pasó DMARC contra el dominio visible imitado De. En el caso informado, una ruta de reenvío Microsoft 365 reescribió el sobre en el dominio de reenvío, que también coincidía con el dominio De visible. Luego, el receptor final observó SPF alineado. Los investigadores informan sobre un trato diferente entre el original y las copias enviadas. Estos son hallazgos atribuidos a su investigación, no observaciones realizadas para esta revisión. Participar en la investigación de seguridad.
La documentación de Microsoft explica que SRS cambios CORREO DE, no el campo De visible, y proporciona patrones de reescritura para rutas de reenvío aplicables. También advierte que SRS normalmente no resuelve DMARC alineación para correo reenviado. Esas declaraciones son compatibles con la coincidencia de identidad especial de la investigación: normalmente el dominio De original difiere del dominio del reenviador; el caso denunciado involucra deliberadamente el mismo dominio. Documentación de Microsoft SRS.
Comprenda el veredicto posterior
Referencias: RFC 9989 §4.4, RFC 8601 §5.
SPF pregunta si el host que se conecta está autorizado para la identidad del sobre en ese salto. DMARC compara un dominio autenticado con el dominio De visible. Ninguno de los resultados, por sí solos, reconstruye cómo el actor original obtuvo acceso a un flujo de trabajo de reenvío. Por lo tanto, un resultado alineado en sentido descendente puede ser correcto para las identidades evaluadas y, al mismo tiempo, seguir siendo una prueba inadecuada de la autorización comercial.
No interpretes un SRS que parezca Return-Path como prueba de que Microsoft lo produjo. Conserve los resultados confiables del receptor final, la información de pares y el seguimiento de mensajes, y compare la evidencia de los límites de recepción y reenvío. incrustado arbitrariamente Authentication-Results El texto no es un veredicto confiable. RFC 8601 explica el requisito del límite de confianza; RFC 9989 proporciona el contexto de alineación del dominio.
Reproducir sólo la comparación de identidad.
El modelo de no entrega del paquete de revisión privada contiene dos casos ficticios. En el caso normal, el dominio visible originalauthor.test difiere del sobre reescrito forwarder.test, por lo que se supone que el paso SPF descendente permanece sin alinear. En el segundo caso, el dominio visible es forwarder.test; el mismo sobre reescrito ahora se alinea. Ambos comienzan con un dominio de envolvente original diferente y sin alineación. DKIM.
Las entradas de los dispositivos retenidos se volvieron a calcular fuera de línea el 8 de noviembre de 2026 utilizando esta comparación de dominio exacto. No envía correo falsificado, no crea reglas de reenvío, no utiliza Exchange Online , no implementa hashes SRS ni demuestra que un inquilino actual acepta la ruta. Su objetivo es explicar por qué los dos veredictos difieren sin reproducir un ataque contra un servicio real. El comportamiento histórico de los proveedores, el comportamiento actual de los inquilinos y la comparación abstracta permanecen etiquetados por separado.
Investigar a la defensiva
Inventario autorizado para reenvío externo y sus dueños de negocios. Para un incidente sospechoso, conserve el original y las copias reenviadas, las marcas de tiempo, el método de enrutamiento, la autenticación previa al reenvío y los resultados finales. Revise la documentación actual del proveedor y el seguimiento de mensajes antes de cambiar una regla. La fuente de Microsoft distingue el reenvío aplicable de los casos de grupo de retransmisión y locales, por lo que una única afirmación de configuración no es suficiente para cubrir todas las rutas.
Aplique cambios a través del proceso de seguridad de correo aprobado por la organización y luego pruebe flujos de trabajo legítimos. Evite reglas de autorización amplias basadas únicamente en la infraestructura del proveedor o en los resultados de pases posteriores. Este artículo establece el mecanismo y las preguntas de investigación. No afirma una fecha de corrección no verificada, exposición universal, explotación exitosa o un defecto actual del servicio de Microsoft.