DKIM fail indica que el destinatario no pudo validar una firma DKIM. Es un problema que merece revisión, pero no constituye por sí solo un veredicto sobre la confianza del mensaje ni determina su llegada a la bandeja de entrada. Para coordinar SPF, DKIM, DMARC, rutas y buzones, empieza por nuestra guía de correo empresarial.
El mensaje parece normal al enviarlo, pero Gmail, Microsoft o Yahoo muestran dkim=fail. Esto puede influir en el filtrado o la aceptación, junto con otras señales. Para corregirlo, necesitas averiguar si el error está en DNS, el sistema emisor o un dispositivo que modifica el correo durante el tránsito.
Trata el fallo como un incidente de autenticación: lee el resultado, identifica la categoría, comprueba selector y clave y revisa qué sistemas intervinieron después de la firma. Corrige el punto concreto, sin cambiar registros a ciegas.
Qué significa realmente DKIM fail
Un resultado DKIM fallido indica que no se pudo validar la firma. El contenido modificado puede producir fail; una clave ausente o inválida puede producir permerror, y un problema temporal de consulta DNS, temperror. Distinguirlos importa tanto como comprobar si las claves pública y privada corresponden.
En RFC 6376 se definen el hash del cuerpo bh= y la firma b=. Si no se validan, la firma no pasa. No demuestra necesariamente suplantación: puede deberse a una firma aplicada demasiado pronto, una clave incorrecta o modificaciones posteriores.
Piensa en DKIM como un precinto: si no puede comprobarse, hace falta investigar el motivo. Un precinto inválido no demuestra por sí solo que todo el paquete sea malicioso.
Revisa primero Authentication-Results en el mensaje recibido. Puede orientar el diagnóstico. El ejemplo siguiente combina resultados ilustrativos incoherentes como caso normal: con SPF válido y alineado al mismo dominio From, DMARC normalmente debería pasar aunque DKIM falle.
Authentication-Results: mx.google.com;
dkim=fail (body hash did not verify) header.i=@example.com header.s=tm1;
spf=pass smtp.mailfrom=example.com;
dmarc=fail header.from=example.comAntes de modificar el emisor, puedes contrastar tus registros con los registros DNS necesarios de TrekMail.
Cuatro categorías habituales de fallos DKIM
El diagnóstico suele centrarse en el hash del cuerpo, el selector o la clave, el formato DNS y las modificaciones de reenvíos o relays. Clasificar primero el problema evita rotar claves cuando la causa real es otra.
| Resultado de autenticación | Posible significado | Primera revisión |
|---|---|---|
dkim=fail (body hash did not verify) | El cuerpo firmado no coincide tras la canonicalización | Relays salientes, avisos legales, enlaces y canonicalización |
dkim=fail (signature did not verify) | Claves distintas, cabeceras modificadas u otro error de firma | Selector, rotación reciente, emisor y cabeceras firmadas |
dkim=permerror (no key for signature) | No se obtuvo una clave pública utilizable | Nombre del selector, cachés DNS y formato del registro |
dkim=temperror | Error temporal de DNS o del resolver | DNS autoritativo, TTL y disponibilidad de servidores |
La tabla orienta la primera revisión; después debes confirmar la causa con datos del mensaje y del DNS.
Tipo de fallo 1: el hash del cuerpo no coincide
Este fallo significa que el hash del cuerpo recibido, tras aplicar la canonicalización de la firma, no coincide con el firmado. No se exige siempre igualdad byte a byte, y este resultado no demuestra que el registro DNS sea correcto.
Según RFC 6376, si el hash recalculado no coincide con bh=, la comprobación falla de forma permanente. Revisa cambios después de la firma, así como la configuración del firmante y la integridad de la muestra que estás analizando.
Causas frecuentes:
- Microsoft 365, Exchange o una pasarela añaden avisos legales después de firmar.
- Mimecast, Barracuda, Proofpoint u otros filtros reescriben enlaces.
- Un relay modifica espacios o finales de línea de forma que la canonicalización no tolera.
- Una aplicación firma antes de que una pasarela cambie límites MIME o añada avisos como
[External].
Comprueba c=. El modo c=simple/simple tolera menos cambios que el relajado. La canonicalización relajada del cuerpo descrita en RFC 6376 ignora espacios finales y agrupa espacios repetidos dentro de las líneas; puede tolerar ciertos cambios de formato, pero no arregla modificaciones sustanciales del contenido.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=tm1; h=from:to:subject:date:mime-version;
bh=...; b=...Una mejora de arquitectura consiste en firmar al final del recorrido que controlas, después de pies, reescrituras y reglas de cumplimiento. Eso reduce las modificaciones internas posteriores, pero no garantiza que intermediarios externos conserven lo firmado.
Si utilizas reenvíos, consulta configuración del reenvío de correo y reenviar correo de dominio a Gmail. Una ruta que funciona en una prueba puede comportarse de otra forma cuando aparecen intermediarios adicionales.
Tipo de fallo 2: selector o claves incorrectos
Puede que la firma indique un selector para el que no exista una clave utilizable o que la clave DNS no corresponda a la privada del emisor. Es una causa de configuración; otros fallos de verificación pueden deberse a cambios en las cabeceras firmadas.
Busca el dominio y el selector en la firma:
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k1; ...Consulta exactamente ese selector:
dig txt k1._domainkey.example.com +shortUna respuesta vacía puede deberse a un registro ausente, un nombre incorrecto, cachés o problemas de consulta. Revisa el estado DNS antes de concluir. Si obtienes una clave, compárala con la que espera el emisor actual. En migraciones o entornos mixtos, otro sistema puede seguir utilizando una privada anterior.
Esto ocurre con varios emisores para un dominio: mensajes de aplicaciones por SES, soporte por Microsoft 365 y campañas por otro ESP. Una rotación coordinada de forma incompleta puede causar fallos intermitentes.
Con envío gestionado de TrekMail, revisa Managed TrekMail SMTP y dónde se aplica la firma en la ruta disponible. Con Nano o un emisor externo, consulta SMTP propio (BYO): la firma debe configurarse en el servicio que envía realmente.
Tipo de fallo 3: claves largas publicadas incorrectamente
Una clave de 2048 bits puede quedar mal publicada si el panel trata incorrectamente el TXT. El resultado puede ser permerror, un error de formato o una clave incompleta en la respuesta.
RFC 8301 exige claves RSA de al menos 1024 bits y recomienda al menos 2048 bits. Es una recomendación criptográfica, no una garantía de compatibilidad con todos los paneles DNS.
Comprueba que las cadenas TXT formen un solo registro y que no se hayan truncado ni entrecomillado incorrectamente. El ejemplo siguiente ilustra la estructura; sus fragmentos no constituyen una clave utilizable.
; Good DKIM TXT record pattern
k1._domainkey.example.com IN TXT (
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE..."
"restOfThePublicKeyContinuesHere..."
)Consulta el DNS e inspecciona todas las cadenas, no solo el primer segmento:
dig txt k1._domainkey.example.com +shortRevisa especialmente este punto tras cambiar de proveedor DNS, trasladar zonas o copiar registros manualmente. Contrasta la respuesta completa con la clave esperada.
Tipo de fallo 4: reenvíos, relays y falta de alineación
Un intermediario puede invalidar DKIM si cambia datos firmados, mientras SPF puede fallar por la nueva ruta. DMARC fallará si no queda otra autenticación válida y alineada; la aceptación final también depende de la política del destinatario.
Imagina un mensaje de example.com enviado a una universidad que lo reenvía a Gmail. SPF puede fallar porque el reenviador no está autorizado por el dominio original. DKIM puede sobrevivir si conserva los datos firmados; un pie, enlace reescrito o cambio en un asunto firmado podría invalidarlo. DMARC no pasa si tampoco existe otro resultado alineado válido.
Para remitentes generales a cuentas personales de Gmail, Google exige SPF o DKIM; para remitentes masivos, ambos y DMARC, con la alineación aplicable. Los reenvíos y listas tienen particularidades, y ARC puede transmitir resultados anteriores. El destinatario decide si confía en ARC: no garantiza la aceptación ni corrige la firma original.
Si reenvías correo, considera SRS y una ruta que preserve los datos firmados. Según la configuración disponible, TrekMail puede utilizar SRS para que SPF valide el nuevo remitente de sobre. SRS no restablece la alineación con el From original ni sustituye DKIM.
Si empleas muchos alias, consulta reenvío de alias y correo con dominio propio. La ruta real de cada mensaje importa más que el número de alias configurados.
Dónde revisar cuando aparece DKIM fail
Sigue un procedimiento repetible: resultado de autenticación, consulta del selector, ruta de firma y alineación. Así puedes distinguir un fallo DNS de una modificación posterior sin cambiar la configuración equivocada.
- Abre el mensaje original y localiza
Authentication-Results. Anota el resultado DKIM exacto. - Busca
d=,s=yc=enDKIM-Signature. - Consulta el selector con
digy comprueba el nombreselector._domainkey.example.com. - Confirma qué plataforma firma realmente. Varios emisores pueden producir resultados intermitentes.
- Revisa si una pasarela, filtro o reenviador modifica el cuerpo o las cabeceras firmadas.
- Comprueba la alineación:
d=debe alinearse con el dominioFrom:visible para que DKIM contribuya a aprobar DMARC, según el modo relajado o estricto.
Otra precaución: pegar fragmentos en un comprobador externo puede provocar falsos errores del hash. Para investigar DKIM fail, utiliza el mensaje original completo o un archivo .eml exportado sin modificaciones.
Resolver DKIM fail con un flujo coordinado en TrekMail
Corregir DNS, relays y pies entre varios proveedores exige identificar quién firma y cuándo. Un flujo coordinado aplica la firma al final de la ruta controlada, verifica DNS y distingue el envío gestionado del SMTP propio.
| Problema habitual | Enfoque coordinado |
|---|---|
| Varios saltos internos modifican mensajes ya firmados | Firmar después de las modificaciones en la última pasarela controlada |
| Rotación manual en herramientas distintas | Comprobar la gestión de firma y claves del SMTP gestionado disponible |
| Cambios DNS con SPF duplicado o selectores incorrectos | Aplicar registros coherentes y verificar cada uno |
| Reenvíos sin considerar SRS o ARC | Preservar la autenticación cuando sea posible y evaluar los mecanismos aplicables |
TrekMail diferencia Nano con SMTP propio de los planes de pago con envío gestionado según sus condiciones. Como referencia, estos se anuncian desde $3.50 al mes. Si quieres que TrekMail gestione la firma de salida, confirma el plan y la ruta disponibles. Si firma tu configuración de SES, SendGrid o Mailgun, revisa DKIM en ese servicio. Los planes de pago pueden ofrecer una prueba de 14 días que requiere tarjeta. Consulta las condiciones vigentes en precios de TrekMail.
Con SMTP propio, el diagnóstico suele dirigirse al selector, las claves o las modificaciones de la ruta externa. Verifica los datos antes de atribuir el problema al buzón o a un proveedor concreto.
Lista final para un incidente DKIM fail
El diagnóstico resulta más útil si tratas DKIM fail como un error concreto de verificación, no como una explicación universal de la entregabilidad. Lee el resultado, consulta el selector y revisa la ruta antes de modificarla.
Antes de cambiar producción:
- Lee la cabecera completa, no solo el resumen de un rebote.
- Distingue hash del cuerpo, verificación de firma, permerror y temperror.
- Consulta el selector exacto en DNS.
- Comprueba que la clave esté completa y las cadenas formen el registro correcto.
- Firma al final del recorrido controlado si después se modifica el mensaje.
- Valora
c=relaxed/relaxedpara tolerar cambios de formato compatibles, no modificaciones sustanciales. - Comprueba la alineación DMARC entre
d=y el dominioFrom:visible.
Si persiste el fallo, investiga su causa en lugar de esperar sin datos. Corrige el punto de firma, el selector o el intermediario responsable y confirma la mejora con mensajes reales.
