29 Jul 20264 minutos de lectura
Waseem OsmanDMARC EnthusiastFirma DKIM: cómo funcionan la generación y el compromiso de claves a escala

Descripción general de la firma DKIM:
- Una firma DKIM es una firma criptográfica codificada en base64, generada con una clave privada
- La canonicalización DKIM controla cuánto reformateo del mensaje puede tolerar una firma
- Una clave comprometida permite a un atacante falsificar mensajes firmados hasta que se rote y revoque
Lo más probable es que su infraestructura de correo firme cada mensaje saliente con una clave privada que quizá no haya rotado en años. Si esa clave se compromete, cada correo que su organización envíe bajo ella queda vulnerable a la falsificación. Eso no es un riesgo teórico.
Este artículo no es una introducción a DKIM. Lo que sigue es un análisis técnico de la firma DKIM en sí: qué es, cómo se genera y verifica, y qué la rompe a escala empresarial.
La plataforma de gestión de DMARC de Sendmarc muestra los resultados de DKIM en cada fuente de envío, de modo que los fallos aparecen antes de bloquear mensajes o complicar una revisión de cumplimiento. Explore nuestra plataforma de gestión de DMARC para ver cómo se rastrea DKIM en su cartera de dominios.
Qué es realmente una firma DKIM
Una firma DKIM es una firma criptográfica, codificada en base64 en la etiqueta b=, generada con la clave privada del dominio de envío y un algoritmo de hash criptográfico aplicado al cuerpo del mensaje y a un conjunto especificado de encabezados.
La clave privada usada para generar una firma DKIM se almacena en el agente de transferencia de correo (MTA) de envío. Su clave pública correspondiente se publica en un registro DNS TXT. Cuando el MTA recibe un mensaje que requiere DKIM, canonicaliza los campos de encabezado y el cuerpo especificados, los hashea con criptografía asimétrica RSA o Ed25519 y firma ese hash con la clave privada.
El resultado se incrusta en el encabezado DKIM-Signature junto con metadatos que indican al servidor receptor exactamente cómo verificarlo:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=default.private; bh=fdkeB/A0FkbVP2k4J4pNPoe23AvqBm9+b0C3OY87Cw8=; h=Date:From:Message-Id:To:Subject; b=M6g0eHe3LNqURha9d73bFWlPfOERXsXxr YtN2qrSQ6/0WXtOxwkEjfoNTHPzoEOlD i6uLLwV+3/JTs7mFmrkvlA5ZR693sM5gkVgVJmuOsylXSwd3XNfEcGSqFRRIrLhHtbC mAXMNxJtih9OuVNi96TrFNyUJeHMRvvbo34BzqWY=
Cada etiqueta tiene peso operativo. v= es la versión. a= es el algoritmo de firma. c= es el algoritmo de canonicalización. d= es el dominio de firma. s= es el selector. h= enumera los encabezados firmados. bh= es el hash del cuerpo. b= es la firma propiamente dicha.
El servidor receptor obtiene la clave pública y la compara con la firma. Si coinciden, la firma DKIM es válida. Si no, el mensaje falla DKIM y, según su política DMARC, puede quedar en cuarentena o rechazarse.
Canonicalización DKIM: por qué los mensajes pueden fallar la verificación
La canonicalización DKIM es el paso que la mayoría de los equipos de correo empresariales subestiman. Antes del hash, el mensaje debe normalizarse. DKIM define dos algoritmos de canonicalización para encabezados y cuerpo: simple y relaxed.
La canonicalización simple es estricta. Conserva encabezados y cuerpo exactamente como estaban al firmar. Un solo salto de línea o espacio hará que el correo falle DKIM.
La canonicalización relaxed tolera cambios menores: plegado de encabezados o múltiples espacios. La mayoría de las infraestructuras de envío modernas usan relaxed/relaxed por esa razón.
La consecuencia operativa es importante. Si su plataforma de envío usa canonicalización simple/simple y el correo pasa por un relay que reescribe, la firma se romperá y el mensaje no llegará al destinatario.
Compromiso de clave: el riesgo de falsificación
Una clave privada DKIM solo es tan segura como la infraestructura que la aloja. Si una clave se compromete —por una brecha, un gestor de secretos mal configurado o un offboarding mal comunicado—, cada mensaje firmado con ella puede falsificarse.
Este es el escenario que la mayoría de la documentación de DKIM pasa por alto. Un atacante con una clave privada robada puede redactar y firmar un mensaje totalmente nuevo, y esa firma pasará la verificación mientras la clave pública correspondiente siga publicada y no revocada en el DNS.
La ventana de exposición es directamente proporcional a cuánto tiempo la clave ha estado en producción sin rotación. Una clave activa durante tres años en un dominio que envía cientos de miles de mensajes es un objetivo de mucho mayor valor que una rotada trimestralmente.
La rotación de claves cierra esa ventana. Una vez que publica una nueva clave y revoca la anterior eliminando su registro DNS TXT, cualquier firma generada con la clave antigua fallará la verificación.
Fallos de validación de firma: qué indica realmente el error
Los fallos de DKIM se agrupan en categorías distintas, y cada una apunta a una causa diferente.
- PermError: El servidor receptor no puede verificar la firma. Las causas habituales incluyen un registro inválido o una clave ausente. Suele indicar un problema de configuración.
- Temp Error: El servidor verificador no pudo completar la consulta DNS en el momento de la entrega. Suele ser transitorio. Estos fallos a menudo se resuelven solos, pero deben supervisarse por patrones.
fail: La firma no puede evaluarse. Es el resultado de un error de sintaxis o de una clave ausente.none: No hay firma DKIM presente. No es un fallo de validación; es una ausencia. DMARC igual lo trata como un fallo de DKIM.
Cómo ayuda Sendmarc
La capacidad de gestión de DMARC de Sendmarc muestra los resultados de validación DKIM en todas las fuentes de envío, identificando qué remitentes fallan y qué dominios no tienen cobertura DKIM. Eso elimina el trabajo manual que de otro modo cargarían solos los equipos de TI sobrecargados, y ayuda a detectar fuentes de envío comprometidas o vulneradas antes de que escalen.
Explore nuestra solución de gestión de DMARC para ver cómo se rastrean los resultados de DKIM en toda su cartera de dominios.



Leave a reply Cancelar respuesta
Your email address will not be published. Required fields are marked *