What Is DKIM (DomainKeys Identified Mail)? How It Secures Your Email

Cuando llega un correo electrónico a su bandeja de entrada afirmando ser de su banco, su proveedor de software o su director general, ¿cómo sabe el servidor receptor que es genuino? SPF comprueba si la IP remitente está autorizada por el propietario del dominio. Sin embargo, SPF falla cuando el correo se reenvía y solo cubre el sobre, no el mensaje en sí. DomainKeys Identified Mail, conocido como DKIM, adopta un enfoque diferente y más robusto: utiliza firmas criptográficas para demostrar que partes específicas de un correo —las cabeceras y el cuerpo— fueron autorizadas por el propietario de un dominio determinado y no han sido modificadas durante el tránsito.

DKIM es uno de los tres pilares de la autenticación moderna del correo electrónico, junto con SPF y DMARC. Comprender cómo funciona, qué significan sus modos de fallo y cómo interactúa con DMARC es esencial para cualquier organización que desee proteger su dominio frente a la suplantación y el phishing.

¿Qué es DKIM?

DomainKeys Identified Mail es un estándar de autenticación de correo electrónico definido en RFC 6376. Permite al servidor de correo remitente adjuntar una firma criptográfica a un correo electrónico. La firma se calcula sobre determinadas cabeceras y el cuerpo del mensaje utilizando una clave privada en poder del remitente. La clave pública correspondiente se publica en DNS bajo un subdominio especial. Cuando un servidor receptor recibe el correo, recupera la clave pública y la utiliza para verificar la firma.

Si la firma es válida, el servidor receptor sabe dos cosas:

1. El correo fue firmado por alguien que controla la clave privada del dominio firmante.
2. Las partes firmadas del correo —cabeceras y cuerpo— no han sido alteradas desde la firma.

Crucialmente, DKIM opera a nivel de mensaje, no de sobre como SPF. Esto significa que sobrevive al reenvío de correo: cuando un reenviador pasa el mensaje, la firma DKIM permanece en las cabeceras y el servidor de correo del destinatario final aún puede verificarla. Esto hace de DKIM el más resistente del par SPF/DKIM en los flujos de correo indirecto.

Cómo funciona DKIM — firma y verificación

El proceso DKIM tiene dos vertientes: la firma en el servidor remitente y la verificación en el servidor receptor.

Firma (saliente):

1. El servidor remitente selecciona qué cabeceras incluir en la firma —típicamente From, Subject, Date, To y otras— y las canonicaliza según un algoritmo definido (simple o relaxed).
2. El servidor calcula un hash del cuerpo del mensaje y lo incluye en la firma.
3. Firma los datos combinados utilizando la clave privada asociada a un selector con nombre para el dominio.
4. La firma resultante se añade al correo como una cabecera DKIM-Signature.

Verificación (entrante):

1. El servidor receptor lee la cabecera DKIM-Signature y extrae el dominio firmante (d=) y el selector (s=).
2. Realiza una consulta DNS TXT en <selector>._domainkey.<domain> para recuperar la clave pública.
3. Recalcula el hash de las cabeceras y el cuerpo como se describe en la firma y verifica la firma con la clave pública.
4. Si la firma coincide y el hash del cuerpo es correcto, el resultado es pass. Cualquier discrepancia —cabeceras modificadas, cuerpo modificado, clave incorrecta— produce fail u otro resultado distinto de pass.

Anatomía de una cabecera DKIM-Signature

Una cabecera DKIM-Signature tiene el siguiente aspecto:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=mail2024;
  h=from:to:subject:date:message-id; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=abc123...base64encodedSignature...==

Las etiquetas clave son:

El registro DNS de la clave pública se publica en <selector>._domainkey.<domain> como un registro TXT, por ejemplo:

mail2024._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

Tipos de resultado DKIM: pass, fail, permerror, temperror y más

El proceso de verificación DKIM puede producir seis resultados distintos. Comprender cada uno es importante porque tienen implicaciones diferentes para DMARC:

Solo pass puede satisfacer DMARC DKIM — y únicamente si el dominio firmante también está alineado con la dirección Header-From.

DKIM y DMARC — por qué la alineación es la clave

Que una firma DKIM se verifique con éxito es necesario pero no suficiente para DMARC. DMARC añade un requisito más: la alineación. El dominio firmante en la etiqueta d= del DKIM-Signature debe estar alineado con el dominio de la dirección Header-From visible: la que sus destinatarios ven en su cliente de correo.

Hay dos modos de alineación, configurados a través de la etiqueta adkim en su registro DMARC:

• Alineación flexible (adkim=r, por defecto): los dominios organizacionales deben coincidir. Una firma de mail.example.com está alineada con example.com en la dirección From.
• Alineación estricta (adkim=s): los dominios deben ser idénticos. mail.example.com no está alineado con example.com.

Esta distinción importa en la práctica. Muchos proveedores de servicios de correo firman los mensajes salientes con su propio dominio en la etiqueta d= en lugar del suyo. La firma DKIM se verifica —el mensaje no ha sido manipulado—, pero el dominio firmante es mailchimp.com o sendgrid.net, no yourdomain.com. Esto significa que DMARC DKIM falla a pesar de una firma criptográficamente válida.

La solución es configurar la firma DKIM con su propio dominio en cada ESP. Esto generalmente implica generar un par de claves, publicar la clave pública en su DNS y autorizar al ESP a usar la clave privada correspondiente al firmar mensajes en su nombre.

Cómo DMARCFlow explica la alineación DKIM en los informes DMARC

Los informes agregados DMARC incluyen resultados de autenticación DKIM brutos —dominio, selector y resultado— para cada lote de mensajes de cada fuente de envío. DMARCFlow analiza estos datos registro por registro y asigna cada resultado a uno de cuatro escenarios de información DKIM claramente definidos:

Para cada registro, DMARCFlow también muestra los resultados DKIM brutos individuales —el dominio firmante, el selector y el resultado bruto (pass / fail / permerror / temperror / neutral / none)— junto con una explicación en lenguaje sencillo de lo que significa cada resultado y si puede contribuir a DMARC. Esto convierte los datos XML opacos en inteligencia procesable.

DKIM frente a SPF — complementarios, no competidores

SPF y DKIM resuelven problemas relacionados pero diferentes, y sus debilidades se complementan mutuamente:

DMARC solo requiere que uno de los dos —SPF o DKIM— pase y esté alineado. En la práctica, configurar ambos proporciona redundancia: si SPF falla en un reenviador, DKIM aún puede satisfacer DMARC. Si DKIM no está configurado en un ESP, la alineación SPF puede salvar la situación. La configuración más resistente tiene ambos correctamente alineados.

Problemas DKIM comunes y cómo resolverlos

• Sin firma DKIM en absoluto. Muchas organizaciones añaden SPF pero nunca configuran la firma DKIM, quedando totalmente dependientes de SPF para DMARC. Cualquier ESP que no admita DKIM —o donde DKIM no haya sido habilitado— producirá mensajes sin resultado DKIM. Solución: habilite la firma DKIM en cada plataforma de envío y publique la clave pública correspondiente en DNS.
• Firma con el dominio del ESP, no con el suyo. La causa más común de "pass pero no alineado": su ESP firma con su propio dominio por defecto. Solución: configure una identidad DKIM personalizada en el ESP. Esto generalmente implica generar un par de claves en el panel de control del ESP, añadir un registro DNS TXT para el selector proporcionado y activar la firma alineada al dominio.
• Modificación del cuerpo que rompe la firma. Las listas de correo, los servicios de reenvío o las puertas de enlace de seguridad que añaden pies de página, modifican las líneas de asunto o alteran las cabeceras pueden invalidar las firmas DKIM. Usar la canonicalización relaxed (c=relaxed/relaxed) tolera cambios menores de espacio en blanco, pero no puede sobrevivir a modificaciones estructurales. Considere usar DKIM con solo las cabeceras más estables en h=, o coordine con los administradores de listas para usar ARC (Authenticated Received Chain).
• Claves expiradas o revocadas. Si una clave privada se ve comprometida o revoca el registro de clave pública DNS antes de que expire el TTL, los mensajes en tránsito pueden fallar DKIM. Planifique la rotación de claves con cuidado (véase más adelante) y mantenga los registros de claves antiguas activos durante el tiempo que puedan estar en tránsito mensajes firmados con ellas.
• permerror en todos los mensajes. Un error permanente generalmente significa que la cabecera DKIM-Signature está malformada, faltan etiquetas requeridas o el registro de clave pública DNS no es válido o está ausente. Verifique el registro en <selector>._domainkey.<domain> con una herramienta de consulta DNS y compárelo con lo que publicó su ESP.
• temperror de forma intermitente. Los fallos DNS transitorios durante la recuperación de la clave causan temperror. No son fallos criptográficos y deberían resolverse en el próximo intento. Si son persistentes, investigue la salud DNS en su registrador o considere un proveedor DNS secundario.
• Selector incorrecto en DNS. Si el selector en la cabecera DKIM-Signature no coincide con ningún registro DNS publicado, la verificación fallará. Asegúrese de que el nombre del selector configurado en su plataforma de firma coincida exactamente con el subdominio bajo el que publicó la clave.

Rotación de claves DKIM — por qué y cómo

Las claves privadas DKIM son secretos de larga duración. A diferencia de los registros SPF, que son públicos, la clave privada debe mantenerse confidencial. Si alguna vez se filtra o ve comprometida, un atacante puede firmar mensajes con la identidad de su dominio. La rotación de claves —sustituir periódicamente los pares de claves antiguos por nuevos— limita la ventana de daño de una clave comprometida.

La rotación según las mejores prácticas es la siguiente:

1. Genere un nuevo par de claves para un nuevo selector (p. ej., mail2026).
2. Publique la nueva clave pública en DNS en el subdominio del nuevo selector.
3. Espere a la propagación de DNS, que suele tardar unos minutos o una hora según el TTL.
4. Cambie su plataforma de firma para usar la nueva clave privada y el nuevo selector.
5. Mantenga el registro DNS antiguo activo durante al menos 48–72 horas (o más si los mensajes pueden estar retrasados) para permitir que los mensajes en tránsito firmados con la clave antigua aún puedan verificarse correctamente.
6. Elimine el registro DNS antiguo tras el período de gracia.

Muchas organizaciones rotan anualmente. Las organizaciones con mayor conciencia de seguridad rotan cada 3–6 meses. Si sospecha que una clave está comprometida, rote inmediatamente siguiendo los pasos anteriores pero comprimiendo el calendario.

Cómo DMARCFlow convierte la complejidad DKIM en claridad

Gestionar DKIM a través de múltiples ESP, dominios y selectores —mientras se monitoriza en busca de fallos, se rastrea la alineación y se sabe cuándo rotar claves— supone una carga operativa considerable. DMARCFlow está diseñado para absorber esa complejidad y ofrecerle una visión clara y procesable de su postura DKIM.

Esto es lo que DMARCFlow aporta específicamente a DKIM:

• Análisis de información DKIM por registro. Cada registro de cada informe agregado DMARC se analiza individualmente. Para cada registro, DMARCFlow identifica todos los resultados DKIM brutos (dominio, selector, resultado), determina cuál de los cuatro escenarios DMARC DKIM se aplica y explica el resultado en lenguaje sencillo. Puede ver exactamente qué dominio firmante y selector satisficieron DMARC DKIM —o exactamente por qué falló.
• Conciencia del modo de alineación. DMARCFlow lee la etiqueta adkim de su política DMARC real y evalúa cada resultado DKIM frente al modo de alineación correcto —flexible o estricto—. El análisis siempre refleja su configuración real, no una suposición genérica.
• Soporte para múltiples firmas. Un correo puede llevar más de una firma DKIM —por ejemplo, una de su dominio y otra del ESP—. DMARCFlow evalúa todas ellas y determina correctamente si al menos una proporciona un pass alineado, que es lo que DMARC requiere.
• Análisis de fallos de autenticación. Cuando los fallos DKIM aparecen en muchos registros, DMARCFlow los agrupa, calcula las tasas de fallo por fuente de envío y muestra las principales direcciones IP fallidas, para que sepa dónde investigar primero.
• Puntuación de seguridad con componente DKIM. DMARCFlow calcula una puntuación de seguridad sobre 100 para su dominio. El desglose muestra exactamente cómo su postura DKIM contribuye a la puntuación global junto con SPF, la aplicación de política, la cobertura y los informes. Un dominio sin alineación DKIM no alcanzará una puntuación alta, y el desglose le indica por qué.
• Seguimiento del nivel de madurez. Los dominios sin ninguna alineación DKIM están limitados a niveles de madurez inferiores. El modelo de madurez de DMARCFlow le muestra exactamente qué está bloqueando la progresión y qué desbloquearía la configuración de la alineación DKIM.
• Motor de recomendaciones. Si DKIM está fallando debido a un dominio firmante no alineado en un ESP específico, DMARCFlow le indica qué corregir y cómo, incluida la orientación sobre cómo publicar un selector personalizado para esa plataforma.
• Cumplimiento RGPD, alojado en la UE. Todos los datos de informes se procesan y almacenan exclusivamente en la Unión Europea. No se retienen datos personales. Imprescindible para organizaciones reguladas por el RGPD.

Conclusión

DKIM es un mecanismo de autenticación del correo electrónico potente y resistente. Al adjuntar una firma criptográfica a sus mensajes salientes, demuestra que partes específicas del correo fueron autorizadas por el titular de la clave privada de su dominio y no han sido alteradas durante el tránsito. A diferencia de SPF, DKIM sobrevive al reenvío de correo, lo que lo hace indispensable para organizaciones que dependen de listas de correo, reenviadores o rutas de envío indirecto.

Pero un pass DKIM por sí solo no es suficiente para DMARC. El dominio firmante debe estar alineado con la dirección Header-From según su modo de alineación configurado. Los cuatro escenarios de información DKIM —desde un pass de firma alineada hasta ningún resultado DKIM en absoluto— representan el espectro completo de lo que encontrará en los informes DMARC. Saber qué escenario se aplica a cada una de sus fuentes de envío es lo que le permite tomar la acción correctiva adecuada.

DMARCFlow hace ese diagnóstico rápido y preciso. Analiza cada resultado DKIM en cada informe DMARC, lo asigna a un escenario claro y le proporciona las recomendaciones necesarias para actuar —ya sea publicar un selector personalizado en un ESP, rotar una clave o investigar un permerror persistente—. Combine eso con la puntuación de seguridad, el seguimiento de madurez y el manejo de datos conforme a la UE, y tendrá una plataforma diseñada para llevarle de "DKIM existe en algún lugar" a "DKIM está completamente alineado y protegiendo activamente mi dominio".