DKIM fail: todas las causas y cómo corregirlas

⚡TL;DR

• Un resultado dkim=fail significa que la firma DKIM del email no pudo ser verificada por el servidor de recepción
• Las 3 causas más frecuentes: body hash alterado (contenido modificado), clave pública no encontrada en el DNS, firma expirada (plazo x= superado)
• El reenvío de email rompe casi siempre la firma DKIM, es un comportamiento esperado que solo ARC puede compensar
• Usa el comando dig TXT selector._domainkey.captaindns.com para verificar que tu clave pública está correctamente publicada
• Combina siempre DKIM con DMARC y SPF para una autenticación completa

Abres los encabezados de un email y te encuentras con dkim=fail. El mensaje se envió correctamente, tu configuración parecía correcta, pero la verificación DKIM falla. Este escenario es frecuente y las causas son múltiples.

Esta guía revisa cada causa de un fallo DKIM, explica cómo diagnosticarla y proporciona la solución precisa a aplicar. Ya sea que el problema venga del DNS, de la firma, del reenvío o de la alineación DMARC, sabrás exactamente qué corregir.

¿Cómo leer un resultado DKIM en los encabezados de email?

Cada email recibido contiene un encabezado Authentication-Results añadido por el servidor de recepción. Es ahí donde encuentras el veredicto DKIM.

Los veredictos posibles

Veredicto	Significado
dkim=pass	Firma verificada con éxito
dkim=fail	La firma existe pero la verificación falló
dkim=none	No se encontró ninguna firma DKIM en el mensaje
dkim=neutral	Firma presente pero el verificador no pudo concluir
dkim=temperror	Error temporal (timeout DNS, servidor no disponible)
dkim=permerror	Error permanente (sintaxis DNS inválida, clave malformada)

Ejemplo de encabezado con fallo

Authentication-Results: mx.google.com;
  dkim=fail (body hash did not verify) header.d=captaindns.com header.s=google header.b=abc12345;
  spf=pass smtp.mailfrom=captaindns.com;
  dmarc=fail

El texto entre paréntesis (body hash did not verify) indica la razón precisa del fallo. Es tu punto de partida para el diagnóstico.

Las 7 causas de un fallo DKIM

Causa 1: body hash no verificado

Mensaje: body hash did not verify

Es el error más común. El servidor de envío calcula un hash del contenido del email y lo incluye en la firma (etiqueta bh=). El servidor de recepción recalcula este hash. Si los dos no coinciden, es un fallo.

Causas frecuentes:

• Un relé intermedio modificó el contenido (añadido de footer, reescritura de URL, antivirus)
• El servidor de mailing añade un píxel de tracking después de la firma
• Un proxy de email o un DLP (Data Loss Prevention) altera el cuerpo del mensaje

Diagnóstico:

# Verificar que el registro DKIM está correctamente publicado
dig TXT google._domainkey.captaindns.com +short

Solución: identifica el servicio que modifica el contenido después de la firma. Configúralo para actuar antes de la firma DKIM, o excluye las modificaciones del cuerpo firmado.

Causa 2: clave pública no encontrada

Mensaje: key not found o no key for signature

El servidor de recepción no encuentra el registro DNS selector._domainkey.dominio. Sin clave pública, es imposible verificar la firma.

Causas frecuentes:

• El selector declarado en la firma (s=) no corresponde a ningún registro DNS
• El registro fue eliminado por error
• El CNAME hacia el proveedor (Google, Microsoft) no está configurado
• La propagación DNS no ha terminado

Diagnóstico:

# Reemplaza "selector" por el valor del campo s= de la firma
dig TXT selector._domainkey.captaindns.com +short

Si el comando no devuelve nada, el registro está ausente.

Solución: publica (o vuelve a publicar) el registro DNS TXT o CNAME correspondiente al selector. Espera la propagación DNS (hasta 48h según el TTL).

Causa 3: firma expirada

Mensaje: signature expired

La etiqueta x= de la firma DKIM establece una marca de tiempo de expiración. Si el servidor de recepción verifica la firma después de esa fecha, es un fallo.

Causas frecuentes:

• El email permaneció en cola de espera demasiado tiempo (greylisting, servidor de recepción lento)
• El valor x= es demasiado corto (ej: 1 hora en lugar de 7 días)
• Desfase de reloj entre los servidores

Solución: aumenta la duración de validez de la firma. La mayoría de los proveedores usan 7 días. Si controlas el servidor de envío, verifica que x= deje un plazo suficiente (mínimo 72 horas recomendado).

Causa 4: error de canonicalización

Mensaje: bad signature o signature verification failed

La canonicalización define cómo el servidor normaliza el mensaje antes de verificar la firma. Existen dos modos: simple y relaxed. Si el encabezado DKIM declara c=simple/simple pero un relé modifica espacios o las mayúsculas de los encabezados, la verificación falla.

Diagnóstico: en la firma DKIM, busca la etiqueta c=. Si vale simple/simple, probablemente sea la causa.

Solución: cambia a c=relaxed/relaxed. Este modo tolera las modificaciones menores (espacios, mayúsculas) que los relés de email realizan habitualmente.

Causa 5: clave demasiado corta

Mensaje: key too short o insecure key

Desde 2024, Google y Yahoo rechazan las claves RSA de 512 y 768 bits. El tamaño mínimo aceptado es 1024 bits, y se recomienda 2048 bits.

Diagnóstico:

# Recuperar la clave y verificar su tamaño
dig TXT google._domainkey.captaindns.com +short
# Copiar el valor p= y decodificar en Base64 para contar los bits

Solución: genera un nuevo par de claves RSA de 2048 bits (o Ed25519) y publica la nueva clave pública en el DNS. Actualiza la configuración de tu servidor de envío con la nueva clave privada.

Causa 6: reenvío de email (forwarding)

El reenvío de email es la causa más difícil de resolver. Cuando un servidor intermedio retransmite un mensaje, puede modificar el contenido (añadido de encabezados, reescritura de la dirección de retorno). La firma DKIM original queda entonces invalidada.

Casos típicos:

• Reenvío automático Gmail/Outlook hacia otro buzón
• Listas de difusión (mailing lists) que añaden un footer
• Alias de email que reenvían hacia otro dominio

Solución: no existe una solución universal. El protocolo ARC (Authenticated Received Chain, RFC 8617) fue diseñado para este caso: cada servidor intermedio añade su propia firma ARC, formando una cadena de confianza. Gmail y Microsoft soportan ARC. En cuanto al remitente, no puedes evitar la ruptura de la firma durante el reenvío.

Causa 7: falta de alineación DMARC

Mensaje: dmarc=fail (cuando dkim=pass)

Este caso es particular. La firma DKIM es técnicamente válida (dkim=pass), pero DMARC falla porque el dominio d= de la firma no corresponde al dominio del From:. Es un problema de alineación, no de firma.

Ejemplo:

• From: contact@captaindns.com
• Firma DKIM: d=sendgrid.net (el proveedor firma con su propio dominio)

DKIM pasa, pero la alineación falla porque sendgrid.net ≠ captaindns.com.

Solución: configura tu proveedor de envío para que firme con tu dominio (d=captaindns.com). En la mayoría de los proveedores (SendGrid, Mailchimp, Brevo), esto se hace creando un CNAME selector._domainkey.captaindns.com apuntando a su infraestructura.

Diagnóstico rápido: tabla resumen

Síntoma	Causa probable	Verificación	Solución
body hash did not verify	Contenido modificado después de la firma	Identificar el relé que modifica	Firmar después de las modificaciones
key not found	Registro DNS ausente	dig TXT s._domainkey.dominio	Publicar el registro
signature expired	Plazo x= superado	Comparar x= con la hora de verificación	Aumentar la duración
bad signature	Canonicalización demasiado estricta	Verificar c= en la firma	Cambiar a relaxed/relaxed
key too short	Clave RSA <1024 bits	Decodificar la clave pública	Regenerar en 2048 bits
dkim=pass + dmarc=fail	Alineación de dominio	Comparar d= y From:	Firmar con tu dominio

Diferencia entre dkim=fail, dkim=none y dkim=temperror

Estos tres veredictos señalan situaciones muy diferentes.

dkim=fail: existe una firma DKIM en el mensaje, pero su verificación falló. Es un problema activo que debes corregir.

dkim=none: no hay ninguna firma DKIM presente en el mensaje. El servidor de envío no firma los emails. Configura DKIM en tu servidor o en tu proveedor.

dkim=temperror: el servidor de recepción no pudo verificar la firma debido a un error temporal (timeout DNS, servidor sobrecargado). La verificación se reintentará. Si el problema persiste, verifica que tus servidores DNS respondan rápidamente (TTL bajo, sin SERVFAIL).

Plan de acción recomendado

1. Identifica el veredicto exacto: abre los encabezados del email y anota el texto entre paréntesis después de dkim=fail
2. Verifica tu registro DNS: ejecuta un análisis con el verificador DKIM para confirmar que la clave pública está correctamente publicada y es sintácticamente válida
3. Identifica tus selectores activos: usa el DKIM Selector Finder para escanear los selectores conocidos en tu dominio
4. Corrige la causa identificada: aplica la solución correspondiente a tu caso (consulta la tabla anterior)
5. Monitorea los resultados: después de la corrección, envía emails de prueba y verifica que dkim=pass aparezca en los encabezados

FAQ

¿Qué significa dkim=fail en los encabezados de email?

El veredicto dkim=fail indica que el mensaje contiene una firma DKIM, pero que el servidor de recepción no pudo verificarla. El texto entre paréntesis (ej: body hash did not verify) precisa la razón del fallo. Esto no significa necesariamente que el email sea fraudulento, una modificación legítima del contenido en tránsito también puede provocar este fallo.

¿Por qué mi DKIM falla si el registro DNS es correcto?

Si tu registro DNS es válido pero DKIM falla, el problema probablemente viene del contenido del mensaje. Un relé intermedio (antivirus, DLP, proxy) pudo modificar el cuerpo después de la firma. Verifica también que el selector en la firma (s=) corresponda al publicado en el DNS.

¿Cuál es la causa del mensaje 'body hash did not verify'?

Este mensaje significa que el hash del contenido calculado por el servidor de recepción no corresponde al hash declarado en la firma (etiqueta bh=). El cuerpo del mensaje fue modificado entre la firma y la verificación. Las causas más frecuentes son los relés que añaden un footer, los sistemas antivirus y las herramientas de reescritura de URL.

¿Se puede entregar un email a pesar de un fallo DKIM?

Sí. DKIM por sí solo no determina la entrega. Es la política DMARC del dominio la que decide: con p=none, el email se entrega incluso si DKIM falla. Con p=reject, el email se rechaza únicamente si SPF también falla (DMARC exige que uno de los dos pase). Muchos proveedores entregan el mensaje en la carpeta de spam en lugar de rechazarlo.

¿Cuál es la diferencia entre dkim=fail y dkim=none?

dkim=fail significa que existe una firma pero su verificación falló. dkim=none significa que no hay ninguna firma DKIM presente en el mensaje. El primero es un problema de configuración, el segundo indica que DKIM no está activado en absoluto en el servidor de envío.

¿El reenvío de email rompe siempre la firma DKIM?

En la mayoría de los casos, sí. El reenvío suele modificar el contenido (añadido de encabezados, reescritura de direcciones), lo que invalida la firma DKIM original. El protocolo ARC (RFC 8617) fue diseñado para resolver este problema creando una cadena de confianza entre los servidores intermedios. Gmail y Microsoft soportan ARC.

¿Cómo verificar que mi corrección DKIM funcionó?

Después de aplicar tu solución, envía un email de prueba a una dirección Gmail o Outlook. Abre los encabezados del mensaje recibido y busca Authentication-Results. Si ves dkim=pass, la corrección es efectiva. También puedes usar una herramienta de prueba en línea que muestre los resultados de autenticación detallados.

📖 Glosario

• DKIM (DomainKeys Identified Mail): protocolo de autenticación de email por firma criptográfica, que verifica la integridad de los mensajes salientes.
• Body hash: huella SHA-256 del cuerpo del email, incluida en la firma DKIM (etiqueta bh=).
• Selector: identificador de texto que forma la dirección DNS de la clave pública DKIM (selector._domainkey.dominio).
• Canonicalización: normalización del mensaje (espacios, mayúsculas) antes del cálculo de la firma. Modos: simple o relaxed.
• ARC (Authenticated Received Chain): protocolo RFC 8617 que preserva los resultados de autenticación durante el reenvío de emails.
• Alineación DKIM: verificación por DMARC de que el dominio d= de la firma corresponde al dominio del From:.

---

Genera tus claves DKIM en segundos: usa el generador DKIM para crear un par de claves RSA 2048 o Ed25519 con el registro DNS listo para publicar.

---

📚 Guías DKIM relacionadas

• Cómo encontrar tu selector DKIM: 4 métodos: encabezados de email, DNS, consola de administración y escaneo automático.
• ¿Qué es un registro DKIM? La guía completa: funcionamiento, etiquetas DNS, RSA vs Ed25519 y rotación de claves.

Fuentes

• RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures
• RFC 8617 - The Authenticated Received Chain (ARC) Protocol
• Google Workspace - Resolver problemas DKIM