Un mensaje reenviado puede ser legítimo y aun así fallar DMARC. El último servidor receptor evalúa la conexión y el mensaje que realmente recibe, no la intención del remitente o el resultado de una entrega anterior. La pregunta útil es qué identidad autenticada todavía se alinea con el dominio De visible después del salto de reenvío. Preservar esa distinción antes de considerar una excepción de política.
Reconstruir la ruta
Referencias: RFC 8601 §1.2, RFC 8601 §5.
Recopile el mensaje sin formato original, el mensaje sin formato reenviado, las marcas de tiempo, la configuración de reenvío y los resultados de autenticación generados por el receptor. Mantenga el sobre SMTP separado de los encabezados visibles: un mensaje guardado no necesariamente conserva el sobre utilizado en cada salto. Obtenga evidencia de seguimiento de los sistemas responsables de esos saltos. No trate un mensaje insertado por el remitente Authentication-Results campo como un receptor de observación confiable. RFC 8601 explica ese límite.
Etiquete el remitente original, el intermediario y el destinatario final. Luego registre la IP de conexión, el dominio del sobre, el dominio visible De y cada DKIM dominio de firma en cada punto de evaluación aplicable. Un diagrama de ruta sólo es útil si refleja los traslados observados. Un salto desconocido permanece desconocido en lugar de que se le asigne un resultado de autenticación supuesto.
Identificar el camino de supervivencia
Referencias: RFC 7208 §2.3, RFC 9989 §4.4, RFC 9989 §5.3.5, RFC 6376 §3.4.
SPF evalúa el sistema de conexión frente a una identidad envolvente. En el receptor final, un servidor de reenvío puede estar fuera de la autorización del dominio del sobre original. un conservado firma DKIM aún puede proporcionar un pase alineado porque la verificación está vinculada al mensaje firmado y al dominio de firma. La reescritura de contenido puede eliminar ese camino restante. DMARC necesita un resultado autenticado alineado, no simplemente cualquier pase SPF o DKIM . RFC 9989, RFC 7208 y RFC 6376 defina estas comprobaciones separadas.
Un sobre reescrito con SRS puede pasar SPF para el dominio del reenviador sin alinearse con el dominio De del autor original. Una nueva firma de ese mismo transportista tiene la limitación análoga. Ninguna observación significa que el mensaje sea necesariamente malicioso y ninguna repara automáticamente la autenticación alineada del autor.
Ejecute el ejemplo acotado
Referencias: RFC 9989 §4.4, RFC 9989 §5.3.5.
El modelo de alineación estricta retenido se puede inspeccionar por separado de la captura SMTP . El estuche directo proporciona pases SPF y DKIM alineados. El caso de reenvío preservado proporciona una falla SPF y un éxito DKIM alineado, por lo que el modelo de alineación estricta aún se cumple. El caso de pie de página proporciona errores tanto para las rutas como para los errores. El SRS Los casos aíslan cómo una identidad SPF exitosa pero no alineada no cambia nada de ese razonamiento.
Esos valores booleanos son entradas deliberadas, no resultados de consultas DNS en vivo o verificación de firmas criptográficas. Los mensajes sin procesar generados son sintéticos y nunca fueron recibidos. Ilustran un cambio de cuerpo controlado pero no satisfacen el requisito de mensajes originales reales y reenviados con resultados confiables. La sección del laboratorio SMTP retenida a continuación proporciona evidencia histórica recibida localmente; La evidencia de producción externa permanece abierta.
Reparar la causa estrecha
Referencias: RFC 9989 §7.4.
Solicite al intermediario que conserve el contenido firmado siempre que sea posible y verifique la ubicación de la firma en el servicio de origen. Pruebe una ruta autorizada representativa antes de cambiar la política de dominio amplia. Si un receptor aplica una excepción local, conserve su alcance, propietario, vencimiento y requisitos de filtrado independiente. La entrega bajo una excepción no es un pase DMARC .
Cierre la investigación sólo cuando el camino perdido, el cambio realizado y la decisión del receptor observada estén documentados por separado. Vuelva a probar los flujos de trabajo periódicos y de bajo volumen, así como la ruta diaria obvia. Una medida en toda la organización hacia el monitoreo simplemente para ocultar un defecto de reenvío puede reducir la protección del correo no relacionado sin reparar al intermediario.
Evidencia de laboratorio SMTP retenida
Referencias: RFC 7208 §4, RFC 6376 §6.
La captura retenida del 7 de noviembre de 2026 a las 21:29:16 UTC registra que el receptor de bucle invertido capturó mensajes directos, de reenvío conservado y modificados en el pie de página a través de SMTP real. Observó el par 127.0.0.2 para la conexión de origen y 127.0.0.3 para la conexión de reenvío. pyspf evaluó esas IP contra DNS de dispositivos aislados; dkimpy verificó firmas RSA reales. El caso directo pasó ambas comprobaciones, la copia reenviada conservada no superó SPF pero pasó DKIM alineado y la copia del pie de página falló ambas. Authentication-Results generados por el receptor y los mensajes sin procesar completos se conservan junto con los sobres y los valores SHA-256.
Para esta revisión se inspeccionaron el corredor histórico y los mensajes retenidos; el experimento de red no se volvió a ejecutar. Su ejecución original utilizó únicamente loopback y no envió correo de Internet. Su receptor crea Authentication-Results a partir de sus propias comprobaciones, dando a esos campos una procedencia de laboratorio conocida. El resultado y la disposición de la autenticación permanecen separados: las seis muestras SMTP reciben 250 bajo una política de captura explícita, incluidas las muestras fallidas. El límite de confianza es este laboratorio controlado, no un proveedor de buzones de producción. El adaptador DNS proporciona respuestas fijas retenidas en lugar de consultar DNS público, y el evaluador DMARC utiliza únicamente igualdad estricta de dominio. El descubrimiento completo del dominio organizacional, el análisis de políticas de producción y los resultados de la implementación en vivo aún no se han probado.