Las incidencias de fallo de DMARC suelen aparecer cuando parece que lo difícil ya está resuelto. SPF y DKIM están publicados. La política DMARC ya usa p=quarantine o p=reject. Entonces se reenvía un mensaje legítimo y no llega al destino esperado. Puede no ser suplantación ni spam: quizá recorrió una ruta que la configuración no soportaba correctamente.
Ese es uno de los problemas del fallo de DMARC durante el reenvío. El mensaje puede ser legítimo, pero el salto intermedio cambia el contexto de entrega y el receptor puede dejar de considerarlo fiable. Si solo compruebas que SPF y DKIM existen, parece aleatorio. Revisar la ruta, las firmas y la alineación permite identificar causas concretas y decidir qué corregir.
Si necesitas primero la configuración general, empieza por correo empresarial. Si ya utilizas reenvíos, consulta también reenvío de correo.
Qué significa realmente un fallo de DMARC
Un fallo de DMARC significa que el mensaje no obtuvo SPF aprobado y alineado ni una firma DKIM válida y alineada con el dominio del From visible. La autenticación por sí sola no basta. DMARC comprueba la relación entre el dominio autenticado y el que ve el destinatario, según el modo de alineación configurado.
DMARC se apoya en SPF y DKIM. El principio básico descrito en la especificación histórica RFC 7489 establece que basta con una de estas condiciones:
- SPF pasa y su dominio se alinea con el dominio del From de la cabecera.
- Una firma DKIM pasa y su dominio se alinea con el dominio del From de la cabecera.
Parece sencillo. En la práctica, las investigaciones de fallos de DMARC se complican al confundir tres conceptos:
- Autenticación: ¿SPF o DKIM pasó la comprobación?
- Alineación: ¿el dominio aprobado se alinea con el dominio del From de la cabecera?
- Conservación durante el reenvío: ¿los cambios del salto invalidaron la firma?
SPF puede pasar y aun así producirse un fallo de DMARC. DKIM también puede pasar y producirse un fallo de DMARC. Si ninguna identidad aprobada se alinea con el dominio requerido, DMARC falla.
Por qué el reenvío puede provocar fallos de DMARC
El reenvío puede causar un fallo de DMARC porque cambia la ruta y, a veces, el contenido. SPF depende de la conexión; DKIM, de la integridad de los datos firmados. El reenvío puede afectar a una comprobación y ciertas modificaciones o configuraciones pueden afectar a ambas.
Esta es una ruta habitual:
- Un remitente envía desde
sender.com. - Un buzón o una pasarela intermedia recibe el mensaje.
- Ese sistema lo reenvía automáticamente a Gmail, Outlook u otro destino.
El receptor final ya no ve la dirección IP original como cliente SMTP. Ve la dirección IP del servicio de reenvío.
Ese cambio puede explicar el inicio de un fallo de DMARC.
SPF suele verse afectado primero
SPF, definido en RFC 7208, comprueba si la dirección IP de conexión está autorizada para enviar por el dominio del remitente del sobre.
Tras el reenvío, la conexión procede del intermediario, no del remitente original. Si conserva el remitente del sobre y su IP no está autorizada, SPF falla. SRS puede cambiar ese remitente para permitir una comprobación SPF del dominio del intermediario, pero eso no garantiza alineación DMARC con el From original.
Ruta original:
sender.comenvía desde la IP A, autorizada por SPF. SPF pasa.
Ruta reenviada: el intermediario envía desde la IP B. El receptor compruebasender.comfrente a la IP B, no autorizada en este ejemplo. SPF falla.
Este fallo de SPF no garantiza un fallo de DMARC. Si sobrevive una firma DKIM válida y alineada, DMARC puede seguir pasando. Por eso conviene probar DKIM en las rutas indirectas reales.
DKIM puede conservar la autenticación del mensaje
DKIM, definido en RFC 6376, firma cabeceras seleccionadas y el cuerpo. La validez no depende de la dirección IP del intermediario. Por eso puede proporcionar una vía de aprobación DMARC cuando SPF deja de servir.
Para que DKIM ayude, deben cumplirse ambas condiciones:
- La firma sigue siendo válida después del reenvío.
- El dominio
d=se alinea con el dominio del From visible.
Si alguna falla y no hay SPF aprobado y alineado, puede producirse otro fallo de DMARC.
Algunos intermediarios modifican partes del mensaje de formas que pueden invalidar la firma:
- Añadir
[EXTERNAL]al asunto - Incorporar avisos o pies legales
- Reescribir delimitadores MIME
- Cambiar el ajuste de líneas o los espacios
La canonicalización relajada tolera ciertos cambios de formato, no todos. El resultado depende de los datos firmados y de la modificación. Un fallo de DMARC en correo reenviado no demuestra por sí solo suplantación: también puede indicar un problema de implementación.
La falta de alineación también provoca fallos sin reenvío
Un fallo de DMARC no requiere reenvío. Puede ocurrir si un servicio SaaS autentica con su propio dominio y ninguna identidad aprobada se alinea con el tuyo. El mensaje puede ser legítimo y aun así fallar DMARC.
Es una configuración que merece revisar en cada servicio externo.
Ejemplo:
- From:
billing@yourcompany.com - Return-Path:
bounce.vendor-mail.com - DKIM:
d=vendor-mail.com
SPF puede aprobar una identidad de vendor-mail.com. DKIM puede pasar para vendor-mail.com. En este ejemplo, DMARC muestra un fallo de DMARC porque ninguna identidad autenticada se alinea con yourcompany.com.
Configura autenticación de dominio personalizada según las opciones del proveedor. Basta con una vía aprobada y alineada para DMARC; DKIM alineado resulta especialmente útil cuando hay reenvíos. Un dominio del proveedor no causa el fallo si otra vía sí cumple los requisitos.
Si estás reorganizando una configuración con muchos alias, consulta alias de dominio frente a buzón. Documentar qué ruta usa cada dirección ayuda a localizar los problemas de autenticación.
Cómo diagnosticar el fallo a partir de las cabeceras
Las cabeceras permiten investigar muchos casos de fallo de DMARC sin adivinar. Empieza por Authentication-Results añadido por un servidor receptor de confianza, no por cualquier cabecera copiada. Compara los resultados y los dominios de SPF, DKIM y From.
Pide al destinatario las cabeceras completas y busca un resultado como este:
Authentication-Results: mx.google.com;
spf=fail smtp.mailfrom=sender.com;
dkim=pass header.i=@sender.com header.s=mail;
dmarc=pass header.from=sender.comEs compatible con un reenvío que hizo fallar SPF mientras DKIM conservó la aprobación DMARC. Confirma la ruta en las cabeceras; ese resultado no prueba por sí solo la llegada a la bandeja de entrada.
Este resultado requiere investigar:
Authentication-Results: mx.google.com;
spf=fail smtp.mailfrom=sender.com;
dkim=fail header.i=@sender.com;
dmarc=fail header.from=sender.comPuede ser un fallo de DMARC relacionado con el reenvío: la conexión cambió y DKIM dejó de validar. Comprueba si el intermediario modificó el mensaje o si la firma ya era inválida antes del salto.
| Resultado de la cabecera | Qué puede indicar | Qué hacer |
|---|---|---|
spf=fail, dkim=pass, dmarc=pass | Resultado compatible con reenvío | Confirma la ruta y supervisa; no cambies la política solo por SPF. |
spf=fail, dkim=fail, dmarc=fail | Reenvío con modificaciones o DKIM inválido | Investiga firma, canonicalización y cambios del mensaje. |
dkim=pass con dominio d= no alineado | Posible desalineación de un proveedor o relé | Revisa todas las vías y configura DKIM personalizado si corresponde. |
spf=permerror | SPF inválido, duplicado o con exceso de consultas | Audita autorizaciones y consultas; considera subdominios. Aplanar exige mantener las IP actualizadas. |
arc=pass | Cadena ARC criptográficamente válida | Evalúa la confianza en los intermediarios; no prueba alineación ni aceptación. |
Cómo reducir los fallos en correo reenviado
No puedes impedir todos los reenvíos. Para reducir el fallo de DMARC en mensajes legítimos, diseña y prueba esas rutas: DKIM válido y alineado, SPF mantenido e intermediarios que conserven los datos firmados. Ninguna combinación garantiza el tratamiento final del receptor.
1. Incorpora DKIM a todas las rutas de envío
Para conservar una vía DMARC durante el reenvío, configura DKIM alineado en cada flujo legítimo: boletines, soporte, facturación y otros mensajes. Comprueba su validez después de los saltos relevantes.
La firma debe alinearse con el From visible. Si el mensaje procede de yourdomain.com, puede firmarse con yourdomain.com o un subdominio que cumpla el modo de alineación configurado. El modo estricto exige coincidencia exacta.
En TrekMail, empieza por los registros DNS necesarios. Un estado DNS amarillo o rojo merece revisión; uno correcto tampoco sustituye una prueba del reenvío.
2. Evalúa la canonicalización DKIM relajada
La canonicalización simple tolera menos cambios de formato. Ciertas modificaciones pueden invalidar DKIM y contribuir a un fallo de DMARC. La relajada admite determinados cambios de espacios y normalización de cabeceras previstos por la norma; no es lo mismo que la alineación DMARC relajada.
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail;
c=relaxed/relaxed; h=from:to:subject:date:message-id; ...No conserva necesariamente una firma cuando se añade un pie al cuerpo. Es una tolerancia de formato, no una autorización para modificar libremente el contenido.
3. Revisa las identidades usadas por los proveedores
Si el CRM, soporte o boletín firma con d=vendor.com, comprueba si esa identidad se alinea o si existe otra vía aprobada y alineada. Sin ninguna, puede aparecer un fallo de DMARC incluso sin reenvío. Configura DKIM y remitente del sobre personalizados según el servicio; para rutas reenviadas, verifica especialmente DKIM alineado.
4. Mantén SPF dentro de sus límites
SPF no falla solo por reenvío. RFC 7208 limita a 10 los términos que requieren consultas DNS durante la evaluación, incluidos los correspondientes términos anidados. Superar el límite, no simplemente alcanzarlo, puede producir permerror y dejar SPF sin una vía aprobada para DMARC.
dig +short TXT example.com
dig +short TXT _dmarc.example.comSi acumulaste Google, Microsoft, Mailgun, SendGrid, Zendesk y tres proveedores antiguos en SPF, revisa cuáles siguen enviando. Retira autorizaciones obsoletas tras verificarlo y usa subdominios cuando tenga sentido, sin eliminar remitentes legítimos a ciegas.
5. Comprende los límites de SRS y ARC
SRS reescribe el remitente del sobre y puede permitir SPF para el dominio del intermediario, pero normalmente no lo alinea con el From original. ARC conserva resultados anteriores y permite al receptor valorar una ruta indirecta según su confianza en los selladores. No convierte automáticamente un fallo DMARC en aprobación ni garantiza entrega; tampoco sustituye DKIM bien configurado.
Las recomendaciones de Google para correo reenviado contemplan un tratamiento distinto de la alineación DMARC y recomiendan cabeceras ARC en servicios de reenvío. Eso no modifica la regla de aprobación del protocolo. Para operaciones en 2025 y 2026, consulta siempre el alcance vigente del receptor.
Si administras muchos buzones reenviados, compara las capacidades actuales de la plataforma. TrekMail ofrece reenvío y orientación DNS según su configuración; consulta usar tu propio SMTP y prueba la alineación con el proveedor elegido.
Enfoque anterior y enfoque actual para varios dominios
Una forma de gestionar el fallo de DMARC era acumular herramientas hasta perder el inventario de firmas. Otra separa claramente alojamiento de buzones, envío y salud DNS para poder identificar y corregir fallos. La visibilidad depende de mantener esa documentación.
| Enfoque anterior | Enfoque actual |
|---|---|
| La facturación por usuario puede fomentar alias y reenvíos improvisados | El alojamiento multidominio con tarifa fija puede facilitar buzones reales según las condiciones |
| Un SPF enorme para todos los servicios añadidos | DNS mantenido, autorizaciones necesarias y subdominios donde proceda |
| El proveedor firma con su dominio sin revisar alineación | Cada remitente dispone de una vía autenticada y alineada |
| No hay visibilidad hasta que los usuarios avisan | Las comprobaciones DNS pueden revelar errores que investigar |
| Los buzones se trasladan mediante exportaciones y suposiciones | La migración IMAP integrada puede copiar datos de buzones; DNS y autenticación se revisan aparte |
Ese es el enfoque operativo de TrekMail según sus funciones actuales: alojar varios dominios, usar almacenamiento compartido y comparar condiciones sin cargos por usuario, con SMTP administrado o externo. Consulta alojamiento de correo multidominio y imapsync para la migración. IMAP no traslada DNS, reputación ni aplicaciones.
Qué hacer cuando recibes una incidencia de DMARC
Ante un fallo de DMARC, no cambies automáticamente de reject a none. Primero determina si hubo reenvío, DKIM inválido o falta de alineación. Si necesitas ajustar la política para proteger tráfico legítimo, hazlo con inventario, informes disponibles, pruebas y un plan de reversión.
- Obtén las cabeceras completas del destinatario y confirma qué servidor receptor de confianza añadió los resultados.
- Comprueba si SPF falló al conectar un intermediario conocido.
- Revisa si DKIM pasó o falló y qué dominio
d=firmó. - Comprueba la alineación del dominio de firma con el From visible.
- Busca
arc=passy evalúa la confianza en la cadena si hubo un intermediario. - Revisa SPF por exceso de consultas o autorizaciones obsoletas.
Si alojas correo en TrekMail, empieza por añadir un dominio para revisar registros y por no recibo correos si el mensaje no aparece y no hay un rechazo visible.
Conclusión: investiga el diseño antes de tratar el fallo como un misterio
Un fallo de DMARC recurrente no demuestra que la infraestructura sea irrecuperable. Puede señalar dependencia de SPF en rutas indirectas, DKIM no alineado o inválido, o modificaciones de intermediarios. Los informes agregados ayudan, pero son parciales y no prueban por sí solos la causa de cada mensaje.
La corrección empieza por lo básico: configurar identidades alineadas, probar DKIM después de cada ruta relevante y mantener SPF. Incluye los reenvíos y las listas de correo en las pruebas, en lugar de asumir que preservan el mensaje.
Si buscas este modelo operativo, compara las funciones y condiciones actuales de TrekMail: alojamiento multidominio con tarifa fija, almacenamiento compartido, migración IMAP de buzones, catch-all y opciones de envío sin cargos por usuario. La fuente sitúa los planes de pago desde $3.50 al mes con facturación anual y una prueba gratuita de 14 días; comprueba el requisito de tarjeta. Nano se ofrece gratis sin tarjeta. Consulta precios o TrekMail. Los precios y las condiciones pueden cambiar.
En resumen: si hay reenvíos en tu entorno, el fallo de DMARC es un caso que conviene probar expresamente. Resolver las causas identificadas puede mejorar la operación, pero pasar DMARC no garantiza llegada a la bandeja de entrada.
