El reenvío de correo electrónico es una de las actividades legítimas más comunes que causan fallas en la autenticación DMARC. Cuando un buzón reenvía automáticamente un mensaje entrante a otro destino—como una dirección personal de Gmail que reenvía a una cuenta de trabajo, o un administrador de oficina que reenvía mensajes a miembros del departamento—el mensaje reenviado puede fallar las verificaciones DMARC incluso cuando el remitente original configuró todo correctamente.

Esta ruptura de autenticación ocurre porque DMARC espera que la infraestructura de envío, los encabezados de mensajes y la alineación del dominio permanezcan sin cambios durante la entrega. El reenvío rompe esa suposición. El resultado: mensajes legítimos de dominios autenticados pueden ser rechazados, puestos en cuarentena o marcados cuando un servidor de reenvío los transmite al destinatario final.

Comprender por qué el reenvío rompe DMARC, qué falla durante el proceso de reenvío y cómo implementar políticas seguras para el reenvío ayuda a las organizaciones a aplicar protecciones anti-suplantación sin bloquear comunicaciones comerciales legítimas.

I. Por Qué el Reenvío de Correo Causa Fallas DMARC

La alineación DMARC requiere que SPF o DKIM pasen la autenticación y se alineen con el dominio en el encabezado From:. Cuando ocurre el reenvío, ambos mecanismos de alineación pueden fallar.

SPF Falla Durante el Reenvío

SPF autentica el servidor de envío contra el dominio listado en la dirección del sobre MAIL FROM. Cuando un mensaje se reenvía, el servidor de reenvío se convierte en el nuevo servidor de envío. El registro SPF original no autoriza la dirección IP del servidor de reenvío, por lo que la autenticación SPF falla en el destino final.

Ejemplo de flujo:

1. [email protected] envía correo a [email protected]
2. [email protected] reenvía el mensaje a [email protected]
3. El servidor de reenvío (oficina.net) entrega el mensaje a personal.com
4. personal.com verifica SPF para empresa.com contra la IP del servidor de reenvío
5. El servidor de reenvío no está en el registro SPF de empresa.com
6. SPF falla

El sobre MAIL FROM todavía hace referencia a empresa.com, pero la IP de envío ahora pertenece a oficina.net. La consulta SPF devuelve fail o softfail.

DKIM Puede Fallar Cuando el Contenido Cambia

DKIM firma los encabezados y el cuerpo del mensaje usando una firma criptográfica. Si el servidor de reenvío modifica el mensaje—como agregar un pie de página, cambiar la línea de asunto o alterar la estructura MIME—la verificación de firma DKIM falla.

Modificaciones comunes de reenvío que rompen DKIM:

• Agregar un aviso de reenvío o descargo de responsabilidad al cuerpo del mensaje
• Añadir [Fwd:] o [Externo] a la línea de asunto
• Convertir HTML a texto plano o alterar límites MIME
• Eliminar archivos adjuntos o cambiar la codificación

Incluso pequeños cambios invalidan la firma. Cuando DKIM falla, el mensaje reenviado pierde su prueba de autenticación.

La Alineación DMARC Falla Incluso Cuando DKIM Pasa

Incluso cuando el servidor de reenvío no modifica el mensaje y la verificación DKIM tiene éxito, DMARC aún puede fallar debido a los requisitos de alineación.

DMARC requiere que el dominio en el encabezado From: coincida con el dominio en el remitente del sobre SPF (alineación relajada o estricta) o el dominio en la firma DKIM (alineación relajada o estricta). Si SPF falla y DKIM pasa pero usa un dominio diferente (como el servidor de reenvío firmando con su propio dominio), la alineación DMARC falla.

Esto comúnmente ocurre cuando:

• La firma DKIM original permanece válida pero el dominio From: difiere del dominio de firma DKIM
• El servidor de reenvío agrega su propia firma DKIM, que no se alinea con el dominio From: original
• SPF falla y no existe firma DKIM alineada

II. Qué Falla, Cuándo y Qué Tan Visible Es

Las fallas de reenvío son a menudo silenciosas para el remitente original y el usuario que reenvía. El mensaje puede ser rechazado o puesto en cuarentena sin retroalimentación clara.

Condiciones de Falla

Cuando la Falla es Silenciosa

• El usuario que reenvía no recibe un rebote o notificación de falla
• El remitente original no ve falla de entrega porque el mensaje llegó exitosamente al buzón de reenvío
• El destino final rechaza el mensaje sin notificar al usuario que reenvía
• Los informes agregados DMARC muestran falla de autenticación, pero el remitente original puede no correlacionar la falla con el reenvío

Cuando la Falla es Visible

• El usuario que reenvía nota que los mensajes de ciertos remitentes dejan de llegar al destino final
• El proveedor del buzón final envía un aviso de rechazo al buzón de reenvío
• El remitente original recibe un rebote si el destino final genera una notificación de falla (raro)

III. Cómo Descubren las Organizaciones que el Reenvío Rompe DMARC

La mayoría de las organizaciones descubren problemas de reenvío después de pasar de p=none a p=quarantine o p=reject. Los mensajes que anteriormente se entregaban sin problemas repentinamente dejan de llegar a destinos reenviados.

Rutas comunes de descubrimiento:

• Los empleados reportan que los mensajes reenviados de clientes, proveedores o socios ya no llegan
• Los equipos de ventas notan que los reenvíos automáticos a sistemas CRM fallan
• Los reenvíos de mesa de ayuda desde sistemas de tickets a correo personal dejan de funcionar
• Los ejecutivos que usan reenvío de correo de cuentas corporativas a dispositivos personales pierden mensajes

Los informes agregados DMARC muestran fallas de autenticación desde direcciones IP del servidor de reenvío, pero los informes no identifican explícitamente el reenvío como la causa. Analizar los informes requiere correlacionar fuentes de falla con configuraciones de reenvío conocidas.

IV. Cómo Implementar Políticas DMARC Seguras para el Reenvío

Las organizaciones no pueden controlar cómo los servidores de reenvío de terceros manejan los mensajes. Sin embargo, pueden ajustar las políticas DMARC, monitorear patrones de falla y educar a los usuarios sobre alternativas de reenvío.

Escalonar la Aplicación por Flujo de Correo, No por Porcentaje

En lugar de usar pct= para aplicar gradualmente DMARC, escalone la aplicación por dominio, subdominio, grupo de remitentes y madurez del flujo de correo. Aplique p=reject a dominios de alto valor usados para transacciones financieras, notificaciones de cuenta y comunicaciones ejecutivas. Aplique p=quarantine o p=none a dominios con patrones de reenvío conocidos hasta que se implementen soluciones alternativas.

Evite confiar en el despliegue basado en porcentaje como estrategia principal. Los programas actuales conscientes de DMARC deberían escalonar la aplicación por dominio, subdominio, grupo de remitentes y función empresarial.

Usar Subdominios para Flujos de Correo con Mucho Reenvío

Si un flujo de correo específico se reenvía con frecuencia—como boletines, informes automatizados o notificaciones internas—envíe desde un subdominio con una política DMARC menos restrictiva. Esto aísla las fallas de reenvío del correo transaccional de alto valor.

Ejemplo:

• empresa.com → p=reject (transaccional, seguridad de cuenta)
• informes.empresa.com → p=none (informes automatizados, boletines)

Este enfoque preserva la protección anti-suplantación en el dominio principal mientras permite que los flujos de correo reenviados pasen.

Educar a los Usuarios sobre Alternativas de Reenvío

El reenvío se usa a menudo por conveniencia, pero las alternativas reducen las fallas de alineación DMARC:

• Use acceso nativo IMAP o POP en lugar de reenvío. La mayoría de los clientes de correo admiten gestión de múltiples cuentas.
• Use delegación de correo (como «Conceder acceso a tu cuenta» de Gmail o «Enviar en nombre de» de Microsoft 365) para gestionar múltiples buzones sin reenvío.
• Use alias de correo dentro del mismo dominio en lugar de reenviar a direcciones externas.
• Use listas de distribución o buzones compartidos para enrutamiento de correo basado en equipo en lugar de reglas de reenvío individuales.

Monitorear Informes Agregados para Patrones de Reenvío

Los informes agregados DMARC incluyen la dirección IP de origen, resultados de autenticación y recuento de mensajes. Las fallas de reenvío típicamente muestran:

• Falla SPF desde direcciones IP que pertenecen a proveedores de reenvío conocidos (Google Workspace, Microsoft 365, proveedores de alojamiento de correo)
• Pasa o falla DKIM dependiendo de si el mensaje fue modificado
• Falla de alineación si DKIM pasa pero no se alinea

Revisar estos patrones ayuda a identificar qué destinos de reenvío causan fallas y si el volumen justifica ajustes de política.

En una implementación gestionada de Skysnag, use el destino de informes generado por Skysnag. Lo siguiente es solo un ejemplo manual:

v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100; fo=1

Un registro estático tradicional puede funcionar, pero solo si los informes se reciben activamente, analizan y se actúa sobre ellos. Skysnag Protect agrega y analiza automáticamente informes DMARC para revelar patrones de reenvío e identificar remitentes afectados.

Considerar el Soporte ARC (Cadena de Recepción Autenticada)

ARC es un protocolo diseñado para preservar resultados de autenticación a través de servidores intermediarios, incluidos sistemas de reenvío. Cuando un mensaje pasa por un servidor de reenvío que admite ARC, el servidor agrega un conjunto de encabezados ARC que registra los resultados de autenticación originales. El destino final puede evaluar la cadena ARC para determinar si el mensaje fue autenticado antes del reenvío.

ARC no resuelve las fallas de reenvío por sí solo. El servidor receptor final debe honrar los encabezados ARC, y el servidor de reenvío debe implementar ARC correctamente. A partir de 2026, el soporte ARC está creciendo entre los principales proveedores de buzones, pero no está implementado universalmente.

Las organizaciones no pueden controlar si los servidores de reenvío o destinos finales admiten ARC. Sin embargo, monitorear encabezados relacionados con ARC en informes forenses DMARC puede ayudar a identificar si los sistemas de reenvío están intentando preservar la autenticación.

V. Qué Puede Salir Mal Después del Ajuste de Política

Ajustar las políticas DMARC para acomodar el reenvío introduce nuevos riesgos.

Debilitar la Política en el Dominio Principal

Reducir la aplicación DMARC en el dominio principal para prevenir fallas de reenvío reduce la protección anti-suplantación. Los atacantes pueden explotar la política debilitada para enviar correo no autenticado desde el dominio.

Ejemplo de falla:

• empresa.com cambia de p=reject a p=quarantine para permitir mensajes reenviados
• Un atacante suplanta [email protected] para enviar correo de phishing
• El mensaje suplantado falla DMARC pero se pone en cuarentena en lugar de rechazarse
• Algunos destinatarios recuperan el mensaje de cuarentena y caen víctimas del ataque de phishing

Desalineación de Política de Subdominio

Usar subdominios para flujos de correo con mucho reenvío funciona solo si la política DMARC del subdominio se establece explícitamente. Si el subdominio hereda la política p=reject del dominio padre a través de la etiqueta sp=, las fallas de reenvío persisten.

Ejemplo de falla:

• empresa.com → p=reject; sp=reject
• informes.empresa.com se crea para correo reenviado
• informes.empresa.com hereda p=reject del dominio padre
• Los mensajes reenviados aún fallan DMARC y son rechazados

Siempre publique un registro DMARC separado para subdominios con diferentes necesidades de aplicación.

Brechas de Educación del Usuario

Recomendar alternativas de reenvío no garantiza la adopción del usuario. Los empleados pueden continuar usando reglas de reenvío si las alternativas no están claramente comunicadas, documentadas o respaldadas por TI.

Ejemplo de falla:

• TI anuncia que el reenvío de correo causa fallas DMARC y recomienda acceso IMAP
• Los empleados no entienden cómo configurar IMAP o carecen de políticas de gestión de dispositivos móviles
• Los empleados continúan reenviando correo y reportan que faltan mensajes de proveedores y clientes
• TI soluciona manualmente casos individuales sin abordar el comportamiento raíz

Las alternativas de reenvío requieren capacitación del usuario, documentación clara y soporte de TI para tener éxito.

VI. Cómo Skysnag Protect Ayuda a Identificar y Abordar Fallas de Reenvío

Skysnag Protect agrega informes DMARC, identifica fallas de autenticación relacionadas con el reenvío y revela patrones que indican que flujos de correo legítimos están afectados por el reenvío.

Skysnag Protect:

• Identifica direcciones IP de origen que pertenecen a servicios de reenvío conocidos y resalta fallas DMARC originadas desde esas direcciones
• Muestra si SPF, DKIM, o ambos fallaron durante el reenvío
• Rastrea el volumen de mensajes de fuentes de reenvío para ayudar a priorizar ajustes de política
• Proporciona visibilidad sobre qué remitentes y flujos de correo están más afectados por el reenvío
• Genera informes que ayudan a los equipos de TI a educar a los usuarios sobre alternativas de reenvío y monitorear la adopción

Use Skysnag Protect para identificar remitentes legítimos, detectar fuentes no autorizadas y avanzar hacia la aplicación sin bloquear mensajes reenviados críticos para el negocio. Comience el monitoreo DMARC en.

VII. Conclusiones Clave

• El reenvío de correo rompe DMARC porque SPF falla cuando el servidor de reenvío no está autorizado por el registro SPF del remitente original.
• DKIM puede fallar si el servidor de reenvío modifica el cuerpo del mensaje, la línea de asunto o la estructura MIME.
• Incluso cuando DKIM pasa, la alineación DMARC puede fallar si el dominio From: no coincide con el dominio de firma SPF o DKIM.
• Las fallas de reenvío son a menudo silenciosas para el remitente original y el usuario que reenvía. El destino final rechaza o pone en cuarentena el mensaje sin retroalimentación clara.
• Las organizaciones deben escalonar la aplicación DMARC por dominio y flujo de correo, no por porcentaje. Use subdominios para flujos de correo con mucho reenvío.
• Eduque a los usuarios sobre alternativas de reenvío: acceso IMAP, delegación de correo, alias y buzones compartidos.
• Monitoree informes agregados DMARC para identificar patrones de reenvío y cuantificar el impacto.
• Skysnag Protect revela fallas relacionadas con el reenvío, rastrea flujos de correo afectados y ayuda a priorizar ajustes de política sin debilitar la protección anti-suplantación.