Defaults.Exposed › Soluciones › Guides

'DKIM signature not valid': las causas, en el orden en que hay que comprobarlas (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. Consulte cómo calificamos.

“DKIM signature not valid” tiene cinco causas habituales, que conviene comprobar en orden: contenido modificado en tránsito, un registro de clave truncado, una clave publicada que no coincide con el firmante, el selector equivocado y una canonicalización frágil. Solo 10.092.481 de 261.086.232 dominios calificados (3,87%) reúnen la tríada completa de SPF + DKIM + DMARC con aplicación, según el censo de Defaults.Exposed (2026-06-29).

El orden de la corrección importa porque la causa más común no está en absoluto en su DNS. Compruebe primero qué modificó el mensaje en tránsito y luego avance hacia dentro: la integridad del registro de clave, si coincide con lo que su servidor de correo firma realmente, el selector y, por último, los ajustes de firma. La mayoría de las firmas inválidas se resuelven en el paso uno o dos.

¿Qué significa realmente “DKIM signature not valid”?

Todo mensaje firmado con DKIM lleva una cabecera DKIM-Signature que indica un dominio (d=), un selector (s=), un hash del cuerpo del mensaje (bh=) y una firma criptográfica sobre el hash del cuerpo más determinadas cabeceras (b=). El receptor obtiene su clave pública del DNS en <selector>._domainkey.<domain>, recalcula ambos hashes y comprueba la firma (RFC 6376). “Signature not valid” es la jerga de verificadores y cabeceras para decir: esa verificación se ejecutó y falló — la clave se encontró, pero las cuentas no salieron.

Esa última frase es oro para el diagnóstico. Un verificador que no puede encontrar su clave dice algo distinto — típicamente una cabecera como dkim=fail (no key for signature) — y eso es un problema de selector, tratado en DKIM “no key for signature” — correcciones de selector y rotación. Y un verificador que recalcula un hash de cuerpo distinto suele decirlo de forma explícita: body hash did not verify — Microsoft lo reporta como dkim=fail (body hash did not verify), mientras que Gmail a menudo presenta el mismo diagnóstico como dkim=neutral (body hash did not verify). En cualquier caso apunta a una modificación del contenido, tratada en “body hash did not verify” — qué cambió su mensaje. Lea la redacción exacta en la cabecera Authentication-Results antes de tocar nada: le dice cuál de las cinco causas tiene entre manos.

Hacer esto bien es raro: 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 el 3,87% de 261 millones de dominios calificados combina SPF, DKIM y una política DMARC con aplicación — la configuración que las reglas para remitentes masivos ahora dan por supuesta. El panorama etapa por etapa está en el modelo de madurez de adopción de SPF.

¿Cuáles son las cinco causas, en orden?

La causa 1 va en negrita porque rompe firmas de mensajes que se firmaron perfectamente. Una pasarela de seguridad añade un aviso legal, un pie de página de cumplimiento se estampa después de la firma, una lista de correo añade [listname] al asunto — el cuerpo o las cabeceras firmadas cambian, los hashes ya no coinciden y la firma es inválida sin que su DNS tenga culpa alguna. Si los fallos se correlacionan con correo que pasó por una pasarela, una lista o un salto de archivado, empiece por ahí.

¿Cómo arreglo “DKIM signature not valid”?

1. Ejecute el análisis gratuito en defaults.exposed antes de tocar el DNS. Le muestra si su registro de clave publicado está presente, bien formado y completo — separando “su DNS está roto” (causas 2–4) de “su DNS está bien, el mensaje está siendo modificado” (causa 1) en un solo paso.
2. Lea la cabecera Authentication-Results de un mensaje que falle. body hash did not verify → causa 1, vaya a la guía del body hash — los sospechosos habituales son los pies de página de pasarelas y los avisos legales, y la corrección es firmar después de la modificación. no key for signature → causa 4, vaya a la guía del selector. Un fallo de firma sin más → continúe.
3. Compruebe si la clave publicada está truncada. Consulte <selector>._domainkey.<yourdomain> como TXT (dig TXT selector._domainkey.example.com). Una clave pública RSA de 2048 bits es más larga que el límite de 255 caracteres de una sola cadena TXT, por lo que debe publicarse como varias cadenas entrecomilladas que los receptores concatenan — y las interfaces web de los proveedores de DNS son tristemente célebres por truncar el pegado en silencio, estropear la división o inyectar espacios y comillas en el valor p=. Compare carácter por carácter con la clave que generó su firmante; nuestras guías de configuración de DKIM cubren las peculiaridades de cada proveedor.
4. Confirme que la clave publicada coincide con el firmante. Tras una rotación de claves, una migración de proveedor o una reconexión del ESP, es común que el firmante tenga una clave privada nueva mientras el DNS sigue sirviendo la clave pública antigua — todas las firmas se verifican contra la clave equivocada y fallan. Vuelva a copiar el registro actual desde la consola de administración de su proveedor. Mejor aún: donde el proveedor ofrezca delegación por CNAME, úsela — el proveedor rota las claves de su lado y toda esta clase de fallos desaparece. Y nunca borre un selector antiguo hasta que se haya drenado el tráfico firmado con él.
5. Corrija los ajustes de firma, no solo el registro. Establezca la canonicalización en c=relaxed/relaxed, que tolera el reajuste de espacios y el replegado de cabeceras que los servidores intermedios hacen de forma legítima; la canonicalización simple falla ante cambios que un humano ni siquiera puede ver. Y no use la etiqueta l= de longitud de cuerpo: se pensó para dejar pasar los pies de página, pero permite que cualquiera añada contenido a su mensaje firmado sin romper la firma — un vector de ataque real — y aun así no sobrevive a la mayoría de las modificaciones de las pasarelas. Sin l= es a la vez la opción más segura y la más fiable.
6. Vuelva a analizar y luego compruebe la alineación. Una firma válida solo ayuda a DMARC si el dominio d= se alinea con su dominio From — una firma que se valida como d=yourcompany.gappssmtp.com pasa DKIM y aun así falla DMARC. Si ese es su caso, consulte la trampa de la firma predeterminada y luego resuelva todo lo demás que el análisis señale en la página de arreglar DKIM.

Preguntas frecuentes

¿“DKIM signature not valid” es lo mismo que “body hash did not verify”? El mensaje del body hash es un subcaso concreto: el cuerpo cambió después de la firma (pies de página, avisos legales, reescrituras de listas). “Signature not valid” es el veredicto genérico para cualquier verificación fallida, incluidas las claves incorrectas y los cambios de cabeceras — por eso el paso 2 de arriba es leer la cabecera, y por eso el caso del body hash tiene su propia guía.

¿Una firma DKIM inválida significa que mi correo está siendo rechazado? No por sí sola — los receptores tratan una firma rota como una ausente. El daño llega vía DMARC: si SPF tampoco pasa con alineación, el mensaje falla DMARC y se aplica su política publicada. Según el censo de 2026-06-29, solo el 3,87% de 261.086.232 dominios calificados reúne SPF, DKIM y una política DMARC con aplicación a la vez — pero Gmail y Microsoft ahora esperan exactamente eso de los remitentes, así que una pata DKIM rota cuesta entregabilidad incluso antes del rechazo.

¿Debería usar una clave DKIM de 1024 o de 2048 bits? De 2048 bits — las claves de 1024 bits están por debajo de las recomendaciones criptográficas actuales y algunos receptores las puntúan a la baja. La pega es puramente operativa: una clave de 2048 bits no cabe en una sola cadena TXT de 255 caracteres, así que debe dividirse correctamente (causa 2 de arriba). La delegación por CNAME a su proveedor esquiva por completo el problema de la división.

Mi DKIM pasa en un verificador pero DMARC sigue fallando — ¿cómo? Casi con seguridad es alineación: la firma se valida, pero su dominio d= (por ejemplo, yourcompany.gappssmtp.com o yourtenant.onmicrosoft.com) no coincide con su dominio From, así que DMARC no puede usarla. Active la firma con dominio personalizado de su proveedor — la guía completa está en la guía de la trampa de la firma predeterminada.

¿Puedo simplemente desactivar DKIM si sigue fallando? No — desde los mandatos para remitentes masivos de 2024, Gmail y Yahoo exigen DKIM a los remitentes de volumen, y una política DMARC con aplicación necesita DKIM en la práctica porque SPF por sí solo se rompe con el reenvío. Arregle la firma; las causas de arriba se pueden resolver todas en una tarde.

Envíe el informe al propietario

Si está arreglando esto para un cliente o para su empresa, cierre el círculo con pruebas. Vuelva a ejecutar el análisis gratuito tras sus cambios y reenvíe el informe calificado al propietario del negocio: fechado, en lenguaje claro, con DKIM en verde. Es el documento que necesitarán para la renovación del ciberseguro y el próximo cuestionario de seguridad de proveedores — la diferencia entre “arreglé una cosa del DNS” y un antes-y-después documentado que dice que el dominio autentica su correo.

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