DKIM 'Body Hash Did Not Verify' — qué modificó su mensaje y cómo arreglarlo (2026)

Publicado 2026-07-08

Cifras a fecha de 2026-06-29 · metodología v7. Datos agregados del censo sobre 261 millones de dominios calificados. Vea cómo calificamos.

“Body hash did not verify” significa que su firma DKIM era válida cuando el mensaje salió de sus sistemas — y algo reescribió el cuerpo del mensaje después. La firma no está rota; el mensaje fue modificado en tránsito. Solo el 3,87% de los dominios — 10.092.481 — completa la tríada SPF-DKIM-DMARC, según el censo de Defaults.Exposed de 261.086.232 dominios (2026-06-29).

La solución es una búsqueda y luego una decisión. Encuentre el salto que modifica su correo — una pasarela que añade un aviso legal, un dispositivo que reescribe enlaces, una lista de correo que agrega un pie. Después firme después de ese salto, detenga la modificación, o haga la firma tolerante a ella — en ese orden.

¿Qué significa realmente “body hash did not verify”?

Una firma DKIM (RFC 6376) lleva dos hashes: bh=, un hash del cuerpo del mensaje tal como se firmó, y b=, que firma las cabeceras más ese hash del cuerpo. El verificador recalcula el hash del cuerpo a partir del mensaje que recibió; si no coincide con bh=, la verificación se detiene con la cadena que todo el mundo pega en un buscador — una cabecera del receptor como:

Authentication-Results: …; dkim=fail (body hash did not verify)

Esa es la cadena de motivo documentada de Microsoft; Gmail suele presentar el mismo diagnóstico como dkim=neutral (body hash did not verify). En cualquier caso, el veredicto acota el problema enormemente. Su clave DNS, su selector y su configuración de firma están todos bien. La criptografía hizo su trabajo: el cuerpo cambió entre la firma y la verificación — una línea añadida, una URL reescrita, un carácter recodificado bastan. (Un mensaje distinto — signature did not verify, no key for signature — significa un fallo distinto; empiece por “DKIM signature not valid”.) Y es urgente porque una firma fallida no puede darle a DMARC un resultado alineado: a menos que SPF pase con alineación en el mismo mensaje, el correo falla DMARC directamente.

¿Qué modificó su mensaje? Los sospechosos habituales

Algo en la ruta de entrega editó el cuerpo después de que su firmante lo sellara. En la práctica es una de cuatro cosas:

Quién lo modificó	Qué cambia	Señal típica
Pasarela saliente / smart host (reglas de transporte de Exchange, Mimecast, Proofpoint, Barracuda…)	Añade el aviso legal, el pie de marketing o el banner “EXTERNAL:” después de que el servidor de correo ya firmó	Todos los mensajes de esa ruta fallan; los envíos directos que evitan la pasarela pasan
Dispositivo de seguridad / protección de enlaces	Reescribe URLs hacia redirecciones de escaneo, añade envoltorios de seguimiento	Solo fallan los mensajes que contienen enlaces
Lista de correo (Google Groups, Mailman…)	Añade una etiqueta al asunto y un pie de lista, a veces reformatea el cuerpo	Solo falla el correo enviado a través de la lista
Reenviador / relé que recodifica MIME	Transcodifica el juego de caracteres, reajusta las líneas — invisible para un humano, letal para un hash	Los fallos se concentran en un destinatario o dirección de reenvío

Compruebe primero la fila en negrita — el servidor de correo firma, el dispositivo de borde edita, y cada mensaje sale con una firma que fue cierta durante treinta milisegundos.

¿Cómo encuentro el salto que está modificando mi correo?

Diagnóstico diferencial — compare una ruta que funciona contra la ruta que falla:

Envíe un mensaje de prueba directo a un buzón que controle en un receptor importante (Gmail funciona bien), evitando todo lo posible su cadena de salida.
Envíe un segundo mensaje por la ruta que falla — a través de la pasarela, a través de la lista, al dominio del destinatario afectado.
Compare las líneas Authentication-Results en ambas cabeceras completas. Envío directo dkim=pass, ruta fallida dkim=fail (o dkim=neutral) con body hash did not verify: el modificador vive entre esas dos rutas.
Mire el cuerpo recibido: ¿un aviso legal, un banner o un pie que usted no escribió? ¿Enlaces reescritos hacia un dominio de escaneo? Ese es su salto, con nombre — y la cadena de Received: muestra qué relé aparece solo en la ruta que falla.

Sus informes agregados de DMARC cuentan la misma historia a escala: una fuente que reporta sistemáticamente DKIM fail con SPF pass suele ser modificación en tránsito en su propia ruta, no un atacante.

¿Cómo lo arreglo?

Ejecute el análisis gratuito en defaults.exposed antes de tocar nada. Confirma que sus claves DKIM publicadas y su política DMARC están en orden, de modo que depure el único problema real — la modificación — y no persiga fantasmas en el DNS. La página de arreglar DKIM cubre las comprobaciones del lado de los registros.
Firme después del salto que modifica. La solución arquitectónicamente correcta: traslade la firma DKIM al dispositivo más externo que toca el mensaje. Las organizaciones con Exchange más pasarela deberían firmar en la pasarela (Mimecast, Proofpoint y similares lo admiten) y desactivar la firma aguas arriba. Si Google Workspace o Microsoft 365 es su último salto, firme allí y no deje que nada edite el correo después — vea configurar DKIM en Google Workspace o Microsoft 365.
O detenga la modificación. Saque la edición de la ruta de transporte: el aviso legal en la firma del cliente de correo o en la plantilla en lugar de una regla de transporte; el banner “EXTERNAL:” limitado solo al correo entrante (etiquetar su propio correo saliente como externo es una mala configuración por partida doble); el correo saliente autenticado eximido de la reescritura de enlaces.
Use canonicalización relaxed/relaxed (c=relaxed/relaxed). La canonicalización de cuerpo simple falla con una sola línea reajustada; relaxed tolera cambios de espacios en blanco y de finales de línea. Sea honesto sobre el límite: relaxed perdona el formato, nunca el contenido — un pie añadido sigue fallando, como debe ser.
Vuelva a probar ambas rutas y luego re-analice. Ambas rutas deberían mostrar ahora dkim=pass con su dominio en d=, y el informe del análisis debería salir limpio.

¿Debo usar la etiqueta l= para que DKIM ignore el contenido añadido?

No — y desconfíe de cualquier guía que lo sugiera. La etiqueta l= calcula el hash solo de los primeros N bytes del cuerpo, de modo que un pie añadido ya no rompe la firma. “Funciona” dejando el final de su mensaje sin firmar: cualquiera que tenga un mensaje firmado legítimo puede añadirle contenido arbitrario y su firma válida sigue verificándose sobre el resultado. Eso es un agujero de suplantación disfrazado de solución — el abuso práctico está demostrado, y algunos receptores penalizan o ignoran l= exactamente por esta razón. Resuelva la modificación; no deje parte de su correo sin firmar.

¿Y las listas de correo — puedo arreglarlas?

En general, no — y saberlo le ahorra semanas. Una lista que añade una etiqueta al asunto o un pie rompe su hash del cuerpo por diseño, y usted no controla la lista. Dos cosas ayudan:

Este residuo es exactamente la razón por la que el despliegue de DMARC se hace por etapas. Pasar de p=none por p=quarantine con una rampa de pct=, mientras se leen los informes agregados, significa que los mensajes alterados por listas quedan en cuarentena en lugar de destruirse mientras usted evalúa el impacto — el tema de de p=none a p=reject sin perder correo legítimo.
ARC es el mecanismo del receptor, no el suyo. Authenticated Received Chain permite que la lista dé fe de cómo se veía la autenticación a la llegada y que el receptor decida si confiar en ella. No hay nada que usted, el remitente, tenga que configurar. Las listas bien gestionadas lo mitigan reescribiendo la cabecera From; las mal gestionadas simplemente rompen su correo.

El reenvío es el caso contiguo — rompe SPF de forma fiable pero DKIM solo a veces, y por eso un DKIM alineado es su pata a prueba de reenvío cuando el cuerpo sobrevive: vea el correo reenviado falla SPF — por qué no puede arreglarlo.

¿Por qué DKIM se rompe tan a menudo cuando tan pocos dominios tienen siquiera la pila completa?

Porque DKIM es el hijo mediano frágil de la tríada: SPF es un registro DNS estático, DMARC una declaración de política, pero DKIM tiene que sobrevivir al viaje. Solo el 51,84% de los dominios calificados publica siquiera una clave DKIM localizable en el DNS, según el censo de Defaults.Exposed, y solo 10.092.481 dominios — el 3,87% de 261.086.232 calificados — mantienen SPF, DKIM y una política DMARC de aplicación a la vez (el modelo de madurez de adopción de SPF desglosa la escalera). Acertar con este arreglo es la parte más difícil de unirse a ese 3,87%.

Preguntas frecuentes

¿“Body hash did not verify” es señal de que alguien está suplantando mi dominio? Normalmente no — un suplantador por lo general no puede producir su firma DKIM en absoluto, así que su correo no muestra firma o muestra no key. Un hash del cuerpo fallido significa que un mensaje genuinamente firmado por su infraestructura fue editado después. Revise su propia pasarela antes de suponer un atacante.

SPF pasa en estos mensajes — ¿estoy a salvo de todos modos? Por ahora, quizá: DMARC solo necesita un resultado alineado. Pero el aprobado de SPF se evapora en cuanto alguien reenvía el mensaje, y si no está alineado con su dominio de From nunca contó para DMARC de todas formas. Con solo el 3,87% de los dominios manteniendo la tríada completa (censo de 2026-06-29 sobre 261.086.232 dominios), “una pata cojeando” es el estado normal — y el que tiene arreglo.

¿Cambiar a canonicalización relaxed/relaxed arreglará mi problema del aviso legal? No. Relaxed tolera solo cambios de espacios en blanco y de ajuste de líneas. Un aviso legal añadido es un cambio de contenido, y el hash debe fallar con él — eso es DKIM funcionando correctamente. Mueva el punto de firma o mueva el aviso legal.

El fallo solo ocurre con el dominio de un cliente. ¿Por qué? Su lado casi con seguridad modifica el correo entrante — un dispositivo de seguridad que reescribe enlaces o estampa banners antes de que corra su verificador, o un reenvío interno que recodifica el cuerpo. Envíeles la sección de diagnóstico de esta página; el arreglo está en su pasarela, no en el DNS de usted.

Envíe el informe al propietario

Si está arreglando esto para un cliente o para su empresa, cierre el círculo con evidencia. Cuando el salto que modificaba esté corregido, vuelva a ejecutar el análisis gratuito y reenvíe el informe calificado al propietario del negocio: fechado, en lenguaje claro, con la situación de DKIM y DMARC en una sola página. Es el documento que necesitará para la renovación del ciberseguro y el próximo cuestionario de proveedores — la prueba de que el correo que sale de la empresa es ahora el correo que llega.

Compruebe su dominio → · Guía de “DKIM signature not valid” → · Arreglar DKIM → · Cómo calificamos → · Solo datos agregados. Datos almacenados y procesados en la UE.