Fallo DMARC: diagnóstico de SPF, DKIM y alineación

Un fallo DMARC significa que el mensaje no obtuvo un resultado de autenticación válido y alineado con el dominio de From. Con p=reject se solicita el rechazo; con p=quarantine se solicita un tratamiento restrictivo. El receptor puede aplicar excepciones locales y no se garantiza una carpeta de spam concreta. Conviene investigar la configuración, aunque también pueden coexistir problemas de reputación. Para el contexto general, consulta correo empresarial para pequeñas empresas.

Muchos casos se relacionan con la alineación, el reenvío que hace fallar SPF, un flujo sin DKIM o un SPF que supera su límite de evaluación DNS. Lee las cabeceras, compara los dominios e identifica qué mecanismo no aportó un resultado válido y alineado.

Esta guía ofrece una tabla de diagnóstico, un proceso de investigación y ejemplos DNS que debes adaptar y verificar, sin prometer una solución definitiva para todos los casos.

Qué significa realmente un fallo DMARC

DMARC falla cuando ningún mecanismo proporciona un resultado de autenticación válido y alineado. SPF o DKIM puede pasar para un dominio distinto; si ninguno pasa alineado con From, DMARC falla.

La especificación exige que SPF o DKIM pase y que el dominio autenticado esté alineado con el dominio RFC5322 de From. Consulta RFC 7489.

Situación	SPF	DKIM	DMARC	Interpretación	Qué revisar
Ambos mecanismos fallan	Fail	Fail	Fail	Posible error de configuración, reenvío o remitente no autorizado; no prueba abuso	Contrasta remitente, IP, DNS y firma con el inventario y los registros
Autenticación sin alineación	Pass, sin alineación	Pass, sin alineación	Fail	La autenticación pasa, pero no está alineada con From	Configura y verifica Return-Path propio y DKIM alineado
Correo reenviado	Fail	Pass, alineado	Pass	Posible comportamiento esperado del reenvío	Verifica firma válida y alineada y conservación de los datos firmados tras la canonicalización
Reenvío con modificación	Fail	Fail	Fail	Una lista o intermediario puede haber cambiado datos firmados; investiga la causa	Evalúa el flujo y las excepciones locales; ARC puede informar al receptor, no convertir el fallo en autenticación válida
SPF PermError	PermError	Fail o ausente	Fail	Posible exceso del límite de evaluación SPF o sintaxis incorrecta	Audita SPF; separar proveedores requiere usar realmente los nuevos dominios del sobre

Paso 1: comprobar primero la alineación

Muchos fallos en correo legítimo son de alineación: el proveedor autentica su dominio, no el tuyo. Importa qué dominio pasa, no solo que una verificación pase.

Ejemplo:

From de cabecera: support@yourdomain.com
Return-Path: bounces.vendor.net
DKIM: d=vendor.net

El mensaje puede mostrar spf=pass y dkim=pass y fallar DMARC porque vendor.net no está alineado con yourdomain.com.

Es habitual en marketing, CRM, soporte y SMTP alternativos. Comprueba si el proveedor permite autenticar el dominio, personalizar Return-Path y el dominio de rebotes o firmar DKIM con tu dominio. Un dominio de seguimiento o de enlaces personalizados no sustituye el Return-Path propio.

Estos cambios DNS son ilustrativos; utiliza los valores del proveedor real y activa y prueba sus funciones:

Type: CNAME
Host: bounces
Value: yourvendor.example.net

Type: CNAME
Host: k1._domainkey
Value: dkim1.yourvendor.example.net

Type: CNAME
Host: k2._domainkey
Value: dkim2.yourvendor.example.net

TrekMail ofrece un proceso de configuración DNS según el servicio elegido. Consulta cómo añadir un dominio y los registros DNS necesarios. Si ya existe SPF, consolida las autorizaciones válidas en un único registro por dominio real del sobre, no añadas un segundo SPF. El panel no demuestra la autenticación de todos los flujos.

Paso 2: revisar las cabeceras originales

Abre el código fuente del mensaje e identifica Authentication-Results, Return-Path y los dominios DKIM d=. Confía solo en los resultados generados por el receptor que evalúa el mensaje; un remitente puede añadir cabeceras falsas.

Utiliza esta lista:

Identifica el dominio visible de From.
Comprueba si SPF pasó.
Comprueba para qué dominio pasó SPF.
Comprueba si DKIM pasó.
Identifica el dominio firmante real de DKIM.
Compara ambos con From.

Un ejemplo de cabecera con fallo DMARC:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@sendgrid.net header.s=s1;
  spf=pass smtp.mailfrom=bounces.sendgrid.net;
  dmarc=fail (p=reject) header.from=yourdomain.com

Interprétala con atención:

SPF pasó para bounces.sendgrid.net, que comparte el dominio organizativo sendgrid.net. La identidad DKIM indicada pertenece a sendgrid.net, pero header.i no sustituye el dominio d= de la firma: debes comprobarlo. From usa yourdomain.com. El resultado del receptor muestra que ningún mecanismo aportó autenticación alineada.

Repite la comprobación para cada flujo. El correo transaccional puede estar corregido mientras marketing, soporte o los alias reenviados siguen fallando. Consulta también cómo configurar correo en tu dominio.

Paso 3: investigar el reenvío por separado

El reenvío puede hacer fallar SPF: el intermediario envía desde otra IP que puede no estar autorizada por el dominio real de MAIL FROM. DMARC todavía pasa si DKIM sigue válido y alineado y se conservan los datos firmados tras la canonicalización.

Un SPF fallido en Google Groups, Outlook, servicios de antiguos alumnos o universidades no cuenta toda la historia. Si DKIM pasa alineado, DMARC pasa. Eso no garantiza que el contenido sea seguro ni que se entregue en la bandeja de entrada.

RFC 7960 explica que conservar el remitente del sobre original puede provocar fallos SPF; reescribirlo, por ejemplo mediante SRS, no restablece la alineación con el From original. DKIM puede aportar el resultado alineado, pero no sobrevive a todas las rutas. Consulta RFC 7960.

No añadas autorizaciones SPF indiscriminadamente para intentar reparar todos los reenvíos. Revisa lo siguiente:

Firma con DKIM los flujos de salida compatibles y verifica su alineación.
Evalúa el modo relajado, que compara el dominio organizativo; el estricto necesita una razón concreta y pruebas.
Investiga las listas que modifican datos firmados y pueden hacer fallar DKIM y, si no queda otro resultado alineado, DMARC.

Si dependes del reenvío, consulta la configuración del reenvío de correo y cómo reenviar correo del dominio a Gmail. TrekMail ofrece reenvío y opciones SMTP según el plan; eso no garantiza la conservación de DKIM ni la entrega a través de cualquier intermediario.

Paso 4: auditar SPF y los errores permanentes

SPF PermError puede aparecer al superar el límite de diez mecanismos o modificadores que requieren consultas DNS, incluidas evaluaciones anidadas, o por sintaxis e inclusiones inválidas. No es un límite de paquetes DNS totales. Un resultado permanente inutilizable no aporta un SPF válido y alineado para DMARC.

Un SPF con muchas inclusiones puede tener este aspecto:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:mail.zendesk.com include:sendgrid.net include:servers.mcsv.net ~all

Su apariencia no determina si es válido. Evalúa las inclusiones anidadas y redirecciones conforme a las reglas SPF; contar únicamente las consultas visibles no basta.

Consulta los registros con estas herramientas:

dig +short txt yourdomain.com
nslookup -type=txt yourdomain.com

Estas consultas no demuestran por sí solas un PermError. Audita los servicios activos. Si dejaste de usar una plataforma hace seis meses, elimina su autorización solo tras confirmar que ya no se necesita. Puedes evaluar separar proveedores por subdominios:

marketing.yourdomain.com
support.yourdomain.com
billing.yourdomain.com

Cada dominio puede tener su propia evaluación SPF si el proveedor lo utiliza realmente en MAIL FROM. Crear el subdominio no cambia el envío: activa la configuración y prueba SPF, DKIM y la alineación con From antes de migrar el flujo.

La documentación de TrekMail explica cómo evitar SPF duplicados y consolidar autorizaciones en un TXT válido. Consulta la comprobación del estado DNS.

Paso 5: distinguir errores de posibles suplantaciones

No todos los fallos DMARC requieren autorizar otra fuente. Algunos corresponden a intentos de suplantación; otros, a remitentes legítimos mal configurados o reenvíos. El resultado de autenticación no basta para decidirlo.

Si SPF y DKIM fallan desde una IP desconocida, no la permitas ni la bloquees automáticamente. Contrasta inventario, registros y rutas de reenvío. Las políticas p=quarantine y p=reject solicitan restricciones, pero su aplicación depende del receptor y de posibles excepciones locales.

Utiliza este proceso:

Investiga la IP o el proveedor desconocido antes de clasificarlo como abuso.
Si el remitente está autorizado, identifica la plataforma y comprueba su autenticación de dominio.
Si falta DKIM en una plataforma compatible, configúralo y verifica la firma y la alineación.
Si ningún mecanismo puede pasar alineado, evalúa cambiar de proveedor o separar el flujo con configuración activa y pruebas, no solo nuevos DNS.

Las directrices de Google citadas explican la aplicación de políticas DMARC cuando fallan la autenticación o la alineación, según el caso y las reglas locales. Consulta los requisitos y su ámbito actual en la guía de autenticación de remitentes de Google.

Patrones de fallo según el tipo de remitente

El tipo de sistema puede orientar la investigación, pero no demuestra automáticamente la causa. Verifica el flujo y los resultados reales.

Tipo de remitente	Causa posible	Comprobación o corrección
Marketing	DKIM o dominio de rebotes sin alineación	Configurar DKIM propio y Return-Path personalizado y probarlos
Soporte o CRM	Dominios de autenticación del proveedor no alineados con From	Completar y verificar la autenticación de dominio
Reenvío de buzón	SPF falla tras el salto	Verificar DKIM válido y alineado y la conservación de datos firmados
Lista de correo	Reenvío con cambios de cuerpo o cabeceras firmadas	Investigar los fallos; ARC puede orientar excepciones locales, no garantizar DMARC válido
Pequeña empresa con varios servicios	Evaluación SPF excesiva o DNS incompleto	Consolidar autorizaciones y evaluar dominios del sobre separados y realmente usados
Agencia con muchos dominios	Configuraciones DNS inconsistentes	Estandarizar el proceso con valores adaptados y pruebas por cliente

Resolver fallos DMARC en varios dominios

Un cliente usa Google Workspace, otro cPanel, otro SendGrid y otro reenvía a Gmail. Si nadie documenta los DNS vigentes, los fallos pueden convertirse en incidencias recurrentes.

Un proceso común puede ayudar: inventario, lista DNS y plan de migración para revisar dominios, reenvíos, SMTP y autenticación. La centralización no sustituye las pruebas por flujo.

La oferta descrita de TrekMail presenta planes de pago desde $3.50 al mes, prueba gratuita de 14 días sujeta a condiciones y un plan sin coste con SMTP propio según la oferta vigente. Dominios personalizados, buzones IMAP, catch-all, reenvío, copia IMAP, API y herramientas DNS dependen del plan y sus límites. La copia de mensajes no sustituye el cambio de MX ni migra todas las aplicaciones; estas funciones tampoco garantizan ahorro ni menos incidencias.

Para muchos dominios de clientes, consulta alojamiento de correo multidominio y compara el proceso con la gestión manual en cada registrador.

Lista breve para investigar un fallo DMARC

Empieza por un mensaje fallido, identifica los dominios autenticados, compáralos con From y prueba la corrección correspondiente. Repite la revisión para los demás flujos, incluidos los críticos poco frecuentes.

Abre el mensaje y revisa Authentication-Results del receptor fiable.
Comprueba si SPF pasó y para qué dominio real del sobre.
Comprueba si DKIM pasó y para qué dominio d=.
Compara ambos dominios con From visible.
Si ninguno pasa alineado, corrige la autenticación y la alineación necesarias.
Si hay reenvío, verifica que DKIM siga válido y alineado y conserve los datos firmados.
Si SPF excede su límite, elimina autorizaciones no usadas o configura dominios del sobre separados con pruebas.
Si ambos mecanismos fallan desde una fuente desconocida, investígala antes de clasificarla o cambiar su tratamiento.

Ese es el proceso: decisiones basadas en resultados fiables, inventario y pruebas, no en suposiciones.

Conclusión: identificar el mecanismo que causa el fallo

Un fallo DMARC puede aparecer durante la entrega por desalineación, reenvío con DKIM inválido, SPF PermError o una fuente no autorizada. La investigación debe distinguirlos sin asumir que todos los fallos son abuso ni que un resultado válido garantiza seguridad.

Corrige la configuración identificada y verifica mensajes reales, en vez de añadir DNS al azar. TrekMail ofrece almacenamiento compartido, gestión multidominio, SMTP propio en Nano, SMTP gestionado en planes compatibles y copia IMAP según la oferta actual. No sustituye la validación ni garantiza la migración completa. Consulta TrekMail o compara condiciones en https://trekmail.net/pricing.