Cómo solucionar los errores «La firma DKIM no es válida» y «El hash del cuerpo no se ha verificado»

Si has recibido el error «La firma DKIM no es válida», significa que hay un problema con tu configuración de DKIM que debes solucionar. Estos errores suelen deberse a una entrada incorrecta en el registro DNS de DKIM, a retrasos en la propagación del DNS, a errores durante la evaluación de la firma DKIM o a modificaciones realizadas en el mensaje después de su firma. 

Esta guía repasa cada causa y su solución, con una sección dedicada al error «No se ha verificado el hash del cuerpo de la firma DKIM», que está estrechamente relacionado y que apunta a un problema concreto y muy fácil de solucionar.

Acerca de las firmas DKIM

DKIM añade una firma criptográfica a los encabezados de tus correos electrónicos, y el servidor receptor comprueba esa firma con una clave pública publicada en tu DNS. Si ambas no coinciden, aparece el error «La firma DKIM no es válida». Para obtener una explicación detallada de cómo funciona el protocolo, consulta nuestra guía sobre qué es DKIM.

Dado que la mayoría de las personas que se encuentran con este error ya tienen DKIM configurado y solo necesitan solucionar el problema que se ha producido, el resto de esta página se centra en el diagnóstico y las soluciones, más que en los conceptos básicos.

¿Cuándo puede fallar DKIM con el error «Tu firma DKIM no es válida»?

Aparecerá el mensaje «Tu firma DKIM no es válida» cuando falle la comprobación de autenticación DKIM. Estas son las causas más habituales:

• El dominio de la firma DKIM y el dominio del remitente no coinciden.
• El registro de la clave pública DKIM publicado en el DNS no es correcto.
• El registro de la clave pública DKIM no se publica en absoluto en el DNS.
• El servidor no consigue acceder a la zona DNS del dominio del remitente para realizar la consulta, una situación habitual cuando se recurre a proveedores de alojamiento poco fiables.
• La longitud de la clave DKIM es insuficiente. Los proveedores actuales esperan claves de 2048 bits, y las claves más antiguas de 1024 bits suscitan cada vez más desconfianza, mientras que las claves muy cortas se rechazan directamente.
• El mensaje se modificó durante el reenvío automático.

Todos estos, excepto el último, son problemas técnicos que puedes resolver directamente. El caso del reenvío es diferente, ya que no puedes controlar si el servidor del destinatario añade un pie de página de cumplimiento o reescribe el mensaje de alguna otra forma. Entonces, ¿qué ocurre cuando esos mensajes reenviados automáticamente no superan ni SPF como DKIM, y tu política DMARC está configurada para rechazar?

Esto solía ser un verdadero problema para los servidores receptores que intentaban gestionar correo reenviado legítimo pero no autenticado. La solución provisional actual es la protocolo Authenticated Received Chain (ARC), que permite a cada servidor de correo de la cadena registrar los resultados de autenticación que ha detectado, de modo que el destinatario final pueda seguir reconociendo que el mensaje fue autenticado antes de que el reenviador lo modificara. Sin embargo, ARC siempre fue una solución experimental, y el sector está dejando atrás esta tecnología. En otro borrador de la IETF de abril de 2026 se ha propuesto reclasificar ARC como estándar histórico, ya que sus enseñanzas se están incorporando a DKIM2, una nueva versión de DKIM que se está desarrollando en la IETF (draft-ietf-dkim-dkim2-spec) y que resuelve el reenvío dentro del protocolo central, en lugar de añadir un segundo mecanismo por encima. En lugar de pedir a los destinatarios que confíen en el relato de un intermediario sobre lo que ha visto, DKIM2 hace que cada eslabón de la cadena registre exactamente lo que ha modificado como una «receta» reversible, de modo que el verificador pueda deshacer esos cambios y volver a comprobar la firma del remitente original. Esto aún se está estandarizando, por lo que ARC sigue siendo la solución práctica hoy en día, pero conviene saber que el problema del reenvío tiene una solución real en camino.

Cómo solucionar el error «La firma DKIM no es válida»

Aunque tengas configurados los registros DKIM, es posible que sigas viendo un error de firma no válida. A continuación te indicamos las soluciones, correspondientes a cada una de las causas mencionadas anteriormente.

Solución 1: Solucionar el problema de las entradas DNS de DKIM incorrectas

Una vez que hayas creado el registro TXT de DKIM y lo hayas añadido a tu configuración de DNS, un error de firma no válida suele deberse a un error en ese registro. Para localizarlo:

• Utiliza la función de búsqueda DKIM de PowerDMARC para comprobar tu registro.

• Introduce tu nombre de dominio y el selector, o deja el selector en blanco para que la plataforma lo detecte automáticamente; a continuación, haz clic en «Comprobar».

• La herramienta analiza tu entrada DNS de DKIM y señala cualquier error en la sintaxis de tu registro.

Para corregir el registro, inicia sesión en cPanel o en la consola de gestión de DNS que utilices, abre el «Editor avanzado de zonas DNS» en la sección «Dominios», selecciona tu dominio, ve a «Editar registros DNS», corrige el valor del registro DKIM y guarda los cambios.

Solución 2: Esperar a que se superen los retrasos en la propagación del DNS

También es posible que aparezcan errores justo después de cambiar la configuración del DNS. Esto es normal: la propagación del DNS tarda entre 24 y 48 horas, y el tiempo exacto depende del valor de TTL establecido en el registro. Espera unos días a que se propague por completo y, mientras tanto, comprueba el estado con nuestro comprobador de propagación de DNS.

Solución 3: Vuelve a hacer coincidir el dominio de la firma DKIM con tu dominio de envío

Abre el encabezado «DKIM-Signature» de un mensaje con error y comprueba el valor de valor «d=» con tu dirección «De» visible. Si no coinciden, tu servicio de envío está firmando con su propio dominio en lugar del tuyo, lo que rompe la alineación y hace que falle la comprobación. La solución es configurar ese servicio para que firme con tu dominio. La mayoría de las plataformas de correo electrónico cuentan con una opción de «DKIM personalizado» o «autenticar tu dominio» precisamente para esto, y nuestra guía sobre cómo configurar DKIM explica el proceso.

Solución 4: Regenerar una clave que es demasiado corta

Si tu proveedor sigue firmando con una clave de 1024 bits (o menos), vuelve a generarla con 2048 bits, que es el estándar actual que exigen Google y otros proveedores importantes. Puedes generar un nuevo par de claves en la consola de administración de tu ESP o con nuestro generador DKIM, publicar la nueva clave pública en tu DNS y confirmar que se resuelve correctamente mediante nuestra herramienta de búsqueda de registros DKIM.

Solución 5: Resolver el problema de un servidor DNS al que no se puede acceder

Si el servidor receptor no puede acceder a tu DNS para buscar la clave pública, DKIM fallará independientemente de lo bien que esté configurado el resto. Comprueba si se puede acceder a tu registro mediante una herramienta de comprobación de propagación de DNS. Si el DNS de tu proveedor de alojamiento es lento o poco fiable, plantéate trasladar el alojamiento de tu DNS a un proveedor especializado, como Cloudflare o Amazon Route 53.

Solución 6: Gestionar los mensajes modificados durante el reenvío automático

Las modificaciones en el reenvío hacen que DKIM deje de funcionar, y no siempre existe una solución por parte del remitente. Si controlas el servidor de reenvío, activa la firma ARC (y, en Microsoft 365, añade los servidores de reenvío de confianza a tu lista de «Sealers ARC de confianza» en Defender) para que el correo reenviado legítimo no se descarte. Si no lo controlas, se trata de un comportamiento esperado, no de una configuración incorrecta: tus informes agregados de DMARC mostrarán estos fallos, y lo más acertado es tenerlos en cuenta en tu política y seguir supervisando la situación, en lugar de perseguir a todo el mundo.

Note: ARC is a temporary fix and not a permanent solution. DKIM2 is being designed to fix forwarding at the protocol level, so this whole category of failure should shrink as it rolls out. Keep any existing ARC setup running to support legacy gateways in the meantime, but there's little reason to invest heavily in new ARC engineering now.

¿Por qué aparece el mensaje "DKIM-Signature Body Hash Not Verified"?

El error «DKIM-signature body hash not verified» significa que el hash del cuerpo del mensaje que calcula el servidor receptor no coincide con el valor almacenado en la etiqueta «bh=» del encabezado «DKIM-Signature». En pocas palabras, el cuerpo del correo electrónico que ha comprobado el destinatario no es idéntico al cuerpo que firmó tu servidor. Algo ha alterado el mensaje en el trayecto.

Vale la pena entender esto con precisión, porque es algo frustrantemente habitual y suele significar que, por lo demás, tu configuración de DKIM es correcta. La comprobación del hash del cuerpo del mensaje se realiza antes de la comprobación completa de la firma, por lo que, cuando el hash del cuerpo falla, falla toda la evaluación de DKIM y el destinatario ni siquiera pasa a verificar la propia firma criptográfica.

Causas habituales de los fallos del «body hash»

• Una pasarela de correo electrónico o un filtro que añada contenido tras la firma DKIM: Los avisos legales, los pies de página legales, los píxeles de seguimiento, los bloques para darse de baja, los banners de antivirus y los pies de página de marketing insertados por una pasarela de salida una vez que el mensaje ya ha sido firmado modificarán el cuerpo del mensaje y romperán el hash. Esta es la causa más frecuente.
• Una lista de correo o un servidor de reenvío ha modificado el cuerpo del mensaje: El software de las listas de correo suele añadir pies de página para darse de baja o reescribir el asunto, y los servidores de reenvío pueden eliminar o añadir encabezados. Ambos alteran el contenido firmado.
• Una discrepancia en la codificación de caracteres o en el formato de fin de línea: Si el mensaje se firma utilizando una codificación (por ejemplo, UTF-8 con una marca de orden de bytes) y el servidor receptor lo interpreta de forma diferente, o si los finales de línea cambian de CRLF a LF en algún punto del tránsito, el contenido a nivel de bytes ya no coincide y el hash falla.
• La firma DKIM se realiza demasiado pronto en el flujo de correo saliente: Esta es la causa principal de la mayoría de los problemas mencionados anteriormente. Si tu sistema firma el mensaje antes de que un componente posterior lo modifique, el hash del cuerpo fallará siempre.
• Una clave privada incorrecta o girada: Si la clave de firma ya no coincide con la clave pública publicada en el DNS, la verificación falla.

Cómo diagnosticar un fallo del sistema de hash del cuerpo

Sigue estos pasos para localizar dónde se está produciendo la modificación:

1. Envía el mismo mensaje de prueba a Gmail, Outlook o Hotmail, y a un buzón interno. Asegúrate de que el contenido, los enlaces y la ruta sean idénticos en los tres.
2. Comprueba el encabezado «Authentication-Results» en cada receptor. Si el hash del cuerpo falla en los tres, el problema está en tu lado de envío. Si solo falla en uno (Outlook suele ser el culpable), es más probable que el problema esté en la estructura MIME o en la codificación de caracteres que en tu configuración de firma.
3. Revisa el orden del flujo de correo y comprueba si la firma DKIM se realiza antes o después de cualquier modificación del contenido saliente.
4. Comprueba el registro DNS de DKIM y verifica que el selector y la clave pública coincidan con los datos de la firma que ha dado error, utilizando nuestra herramienta de búsqueda de registros DKIM.
5. Envía un mensaje de prueba en texto sin formato, sin seguimiento, sin pie de página ni archivos adjuntos. Si ese mensaje llega a su destino mientras que tu correo habitual no lo hace, habrás identificado la modificación por proceso de eliminación.

Cómo solucionar los errores de «Body Hash»

• Firma el mensaje al final, después de cada modificación del contenido: Esta es la solución más habitual y eficaz. Cambia el orden de «redactar, firmar con DKIM, añadir el aviso legal, enviar» por «redactar, añadir el aviso legal, firmar con DKIM, enviar», de modo que firmes exactamente el mensaje que recibirá el destinatario.
• Configura las pasarelas de salida para que no modifiquen el cuerpo del mensaje: O bien, configúralas para que vuelvan a firmar con DKIM una vez que hayan terminado de realizar los cambios.
• Estandariza tu codificación a UTF-8 sin marca de orden de bytes y mantén los finales de línea CRLF constantes a lo largo de toda la ruta de envío. Esto es especialmente importante en entornos de Exchange y Microsoft 365.
• Utiliza la canonicización flexible (c=relaxed/relaxed): Esto tolera pequeñas diferencias de espacios en blanco y de formato que, de otro modo, invalidarían una firma bajo una canonización «simple» estricta. No salvará una firma cuando se añada un aviso legal o un pie de página completo, pero elimina los errores causados por cambios de formato insignificantes.

Errores de hash en el cuerpo del mensaje específicos de Outlook y Microsoft 365

Un problema recurrente, que inunda los propios foros de soporte de Microsoft, es que un mensaje supera la verificación DKIM en Gmail y Yahoo, pero falla en Outlook o Hotmail. Esto suele ocurrir con mensajes que contienen archivos adjuntos o imágenes incrustadas, y se debe a la forma en que el sistema de Microsoft gestiona la estructura MIME y la codificación de caracteres, más que a un problema con la configuración de la firma.

La forma más clara de confirmarlo es comparar el encabezado «Authentication-Results» del mismo mensaje en ambos receptores. Los casos de éxito y de fallo tienen este aspecto:

Ninguno

# En Gmail (se admite)

Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=selector1;
spf=pass; dmarc=pass

# En Outlook (da error con el mismo mensaje)

Authentication-Results: protection.outlook.com;
dkim=fail (body hash did not verify)
header.d=yourdomain.com header.s=selector1;
spf=pass; dmarc=fail (p=none)

Cuando detectes un error de DKIM, la forma más rápida de entenderlo es leer los propios encabezados de autenticación del mensaje, en lugar de intentar adivinar la causa.

Cómo interpretar el encabezado «Authentication-Results»

En Gmail, abre el mensaje, haz clic en el menú de los tres puntos y selecciona «Mostrar original». Busca el encabezado «Authentication-Results» y localiza el resultado «dkim=». Aparecerá «pass», «fail» o «neutral», y suele ir seguido de una cadena explicativa como «el hash del cuerpo no se ha verificado», «la firma no se ha verificado» o «la clave es demasiado corta». Esa cadena explicativa te indica a qué tipo de problema te enfrentas y, por lo tanto, cuál de las soluciones anteriores debes aplicar.

Mientras lees el encabezado, las etiquetas «DKIM-Signature» te servirán de referencia:

v= Versión de DKIM (p. ej., v=1)

aa) algoritmo de firma (p. ej., a=rsa-sha256)

d= dominio de firma (comprueba que coincida con tu dirección de remitente)

s= selector, utilizado para localizar la clave pública en el DNS

h= los encabezados incluidos en la firma

bh= el hash del cuerpo (el valor que da error en un mensaje de «hash del cuerpo no verificado»)

b= la propia firma criptográfica

Si comparas el valor «d=» con el dominio «From» visible, se confirma que coinciden; el selector «s=» te indica qué registro DNS debes comprobar, y una discrepancia en «bh=» confirma que el cuerpo del mensaje se modificó tras la firma.

Si resulta que la fuente es una que no reconoces, comprueba si pertenece a tu lista de remitentes autorizados y compárala con tus informes de fallos de DMARC para ver qué tipo de correo envía y comprueba si la IP aparece en alguna lista negra. 

Si se trata de un remitente legítimo, configura DMARC correctamente para autorizarlo. Si no lo es, se trata de una señal de suplantación de identidad que justifica tomar medidas.

He solucionado el error «La firma DKIM no es válida». ¿Y ahora qué?

Para reforzar tu configuración de DKIM a partir de aquí:

1. Regístrate con nuestro servicio de DKIM alojado para supervisar los resultados de tu autenticación DKIM a lo largo del tiempo.
2. Activa SPF y DMARC para disfrutar de mayor seguridad y una autenticación más precisa.
3. Renueva tus claves DKIM periódicamente para disfrutar de una mayor protección.

Sigo sin poder solucionar el error

Si el error «Firma DKIM no válida» persiste, ponte en contacto con tu proveedor de servicios de correo electrónico para que te orienten, o ponte en contacto con nosotros para recibir asesoramiento especializado sobre todo lo relacionado con la autenticación del correo electrónico.

Preguntas frecuentes

¿Qué significa «No se ha verificado el hash del cuerpo de la firma DKIM»? 

Significa que el hash del cuerpo del mensaje calculado por el servidor receptor no coincide con el valor «bh=» que tu servidor registró al firmar el mensaje. En la práctica, el cuerpo del correo electrónico se modificó tras la firma, normalmente mediante la incorporación de un aviso legal, un pie de página, un píxel de seguimiento o una modificación de la pasarela añadida posteriormente en la ruta de envío.

¿Por qué el hash del cuerpo del mensaje DKIM falla solo en Outlook, pero pasa la comprobación en Gmail? 

Cuando un mensaje se envía correctamente en Gmail pero falla en Outlook o Hotmail, la causa suele estar en la forma en que el sistema de Microsoft gestiona la estructura MIME y la codificación de caracteres, más que en tu configuración de firma. Esto ocurre con mayor frecuencia en mensajes con archivos adjuntos o imágenes incrustadas. Compara el código fuente sin procesar en ambos receptores, estandariza tu codificación de transferencia y utiliza una canonicización flexible.

¿Cómo puedo activar la firma DKIM una vez añadidos los avisos legales? 

Reorganiza el flujo de correo saliente de modo que la firma sea el último paso en el que se modifique el contenido. En lugar de firmar y luego añadir un aviso legal, añade primero el aviso legal y firma después. Para ello, ejecuta tu firmador DKIM después de los filtros de contenido y de los servicios de aviso legal o de firma, de modo que firme el mensaje final que el destinatario recibe realmente.

¿Cuál es la diferencia entre «no se ha podido verificar el cuerpo del mensaje» y «no se ha podido verificar la firma»? 

«El cuerpo del mensaje no se ha verificado» significa que el cuerpo del mensaje ha cambiado tras la firma, por lo que la solución pasa por corregir el cuerpo o el flujo del correo. «La firma no se ha verificado» es un mensaje más amplio y suele indicar un cambio en la cabecera firmada, una discrepancia en la clave o un problema relacionado con el DNS o la clave. La cadena de motivo que aparece en la cabecera «Authentication-Results» te indica de cuál de estos casos se trata.

¿Filtra DKIM los correos electrónicos? 

DKIM no filtra el correo electrónico directamente. Proporciona una señal de «aprobado» o «rechazado» que los servidores receptores tienen en cuenta a la hora de determinar la puntuación de spam. Los mensajes procedentes de un dominio de confianza que superen la verificación DKIM pueden obtener una puntuación de spam más baja, mientras que un fallo en DKIM puede contribuir a que un mensaje sea marcado como spam o puesto en cuarentena.

¿Puedo ignorar los errores de DKIM si DMARC está configurado con p=none? 

Con p=none, el correo con errores sigue entregándose, por lo que un error de DKIM no bloqueará nada de forma inmediata. Sin embargo, ignorarlo va en contra del objetivo de avanzar hacia la aplicación de las normas y te impide confiar en tus propios datos de autenticación. Es mejor resolver los errores mientras se está en p=none, para poder pasar con seguridad a p=quarantine y p=reject más adelante.

¿Con qué frecuencia debo rotar las claves DKIM? 

Una práctica habitual consiste en rotar las claves cada seis meses o un año. La rotación periódica limita los daños en caso de que una clave privada quede expuesta. Lo importante es actualizar la clave pública publicada en el DNS como parte de la rotación, ya que una clave rotada que no se refleje en el DNS provocará por sí misma errores de firma.

• Acerca de
• Últimas publicaciones

Yunes Tarada

Experto en seguridad de dominios y correo electrónico en PowerDMARC

Yunes es jefe de equipo de operaciones en PowerDMARC con conocimientos especializados en autenticación y seguridad del correo electrónico. Yunes es Administrador Asociado de Azure certificado por Microsoft y cuenta con certificaciones de CompTIA A+ y muchas más.

Últimos mensajes de Yunes Tarada (ver todos)

• Cómo solucionar los errores «La firma DKIM no es válida» y «El hash del cuerpo no se ha verificado» - 16 de julio de 2026
• Guía de configuración de DKIM, DMARC y SPF de Kit - 6 de julio de 2026
• NIST SP 800-81r3: Directrices de seguridad del DNS para el correo electrónico - 25 de junio de 2526