¿Qué es DKIM?
DKIM (DomainKeys Identified Mail) es un protocolo de autenticación de correo electrónico que usa criptografía de clave pública para verificar que un mensaje fue enviado por un servidor autorizado y que el contenido del mensaje no fue alterado en tránsito. El servidor emisor firma los mensajes salientes con una clave privada, y el servidor receptor verifica la firma usando una clave pública publicada en el DNS del emisor. A diferencia de SPF, que solo verifica la dirección IP del servidor emisor, DKIM verifica la integridad del mensaje y sobrevive al reenvío de correo. DKIM se define en el RFC 6376.
Esta guía forma parte de nuestra guía completa de DKIM. Relacionado: el registro DKIM y cómo funcionan las firmas DKIM.
DKIM - DomainKeys Identified Mail - es el segundo pilar de la autenticación de correo moderna. Mientras que SPF verifica que un mensaje fue enviado desde un servidor autorizado, DKIM va más allá: firma criptográficamente el propio mensaje, demostrando que el contenido no ha sido manipulado y que el dominio emisor declarado realmente autorizó el mensaje.
El RFC 6376 define DKIM como un método para asociar un nombre de dominio con un mensaje de correo, permitiendo así que una persona, un rol o una organización reclame cierta responsabilidad sobre el mensaje. La firma sobrevive al reenvío de correo, lo cual es una ventaja crítica frente a SPF.
Entender DKIM es esencial para cualquiera que gestione infraestructura de correo, porque la alineación DKIM es una de las dos vías para pasar la autenticación DMARC, y para el correo reenviado, a menudo es la única vía.
Cómo funciona DKIM: la visión general
DKIM opera sobre un principio criptográfico sencillo: el servidor emisor firma el mensaje con una clave privada, y el servidor receptor verifica la firma con una clave pública publicada en el DNS.
El proceso de firma (saliente)
- El servidor de correo emisor genera un hash de determinadas cabeceras del correo y del cuerpo del mensaje
- El servidor cifra este hash usando la clave privada DKIM del dominio
- El servidor añade una cabecera
DKIM-Signatureal mensaje que contiene el hash cifrado, el nombre del selector, el dominio firmante y metadatos sobre qué cabeceras se firmaron - El mensaje se transmite al servidor receptor
El proceso de verificación (entrante)
- El servidor receptor extrae la cabecera
DKIM-Signaturedel mensaje - Lee los valores
d=(dominio) ys=(selector) de la firma - Realiza una búsqueda DNS de
<selector>._domainkey.<domain>para recuperar la clave pública - Usa la clave pública para descifrar la firma y recuperar el hash original
- Calcula de forma independiente el hash de las mismas cabeceras y del cuerpo usando el algoritmo especificado
- Si los dos hashes coinciden, la firma es válida - el mensaje es auténtico y no está modificado
Para un recorrido técnico detallado de este proceso, consulta Cómo funciona DKIM: una guía completa de autenticación de correo.
Para los detalles a nivel de RFC del algoritmo de verificación, consulta Dentro del RFC 6376: cómo funciona realmente la verificación DKIM.
La cabecera DKIM-Signature
Una cabecera de firma DKIM tiene este aspecto:
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
c=relaxed/relaxed; q=dns/txt; t=1618884473;
h=from:to:subject:date:message-id;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk...
| Etiqueta | Significado |
|---|---|
v=1 | Versión de DKIM (siempre 1) |
a=rsa-sha256 | Algoritmo de firma |
d=example.com | Dominio firmante (usado para la alineación DMARC) |
s=selector1 | Selector - identifica qué clave pública usar |
c=relaxed/relaxed | Método de canonicalización para cabecera/cuerpo |
q=dns/txt | Método de consulta para la clave pública |
t=1618884473 | Marca de tiempo de la firma |
h=from:to:subject:... | Lista de cabeceras incluidas en la firma |
bh=... | Hash del cuerpo |
b=... | La firma en sí |
Claves DKIM: pública y privada
DKIM usa criptografía asimétrica. El propietario del dominio genera un par de claves:
- Clave privada - Almacenada de forma segura en el servidor de correo emisor. Nunca se comparte ni se publica. Se usa para firmar los mensajes salientes.
- Clave pública - Publicada en el DNS como un registro TXT en
<selector>._domainkey.<domain>. La usan los servidores receptores para verificar las firmas.
Formato del registro DNS
Un registro DNS de DKIM tiene este aspecto:
selector1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4..."
| Etiqueta | Significado |
|---|---|
v=DKIM1 | Versión |
k=rsa | Tipo de clave (RSA es el estándar; Ed25519 está emergiendo) |
p=... | La clave pública, codificada en base64 |
Puedes consultar la clave pública DKIM de cualquier dominio usando la herramienta de consulta DKIM.
Tamaños de clave
- RSA de 1024 bits - El tamaño de clave mínimo recomendado. Todavía muy usado, pero considerado débil según los estándares modernos.
- RSA de 2048 bits - El estándar recomendado actual. Ofrece seguridad sólida, pero produce registros DNS más largos que pueden requerir dividir el registro TXT.
- Ed25519 - Un algoritmo más nuevo y eficiente que produce firmas y claves más cortas. Soportado por un número creciente de servidores de correo, pero aún no universal.
Guía detallada: Comprender los algoritmos criptográficos de DKIM: RS256 vs RS512 y tendencias emergentes
Selectores: gestionar varias claves
Los selectores DKIM permiten a un dominio publicar varias claves DKIM simultáneamente. Cada clave se identifica con una cadena de selector, y la etiqueta s= en la cabecera DKIM-Signature indica al receptor qué selector (y por tanto qué clave pública) usar para la verificación.
Los selectores cumplen varios propósitos:
- Varios servicios de envío - Tu servidor de correo principal y cada servicio de terceros (SendGrid, Mailchimp, etc.) pueden tener cada uno su propio par de claves DKIM con un selector único
- Rotación de claves - Al rotar las claves, puedes publicar la nueva clave bajo un nuevo selector mientras el selector antiguo permanece activo durante el periodo de transición
- Separación por departamentos - Distintos equipos o divisiones pueden usar distintos selectores con fines de seguimiento y gestión
Las convenciones comunes de nomenclatura de selectores incluyen s1, s2, google, sendgrid, k1, o nombres basados en fechas como 202604.
Canonicalización: gestionar las modificaciones del mensaje
Los mensajes de correo se modifican con frecuencia en tránsito - se añaden o eliminan espacios en blanco, se reescriben cabeceras y los saltos de línea pueden cambiar. La canonicalización define cómo los procesos de firma y verificación normalizan el mensaje antes de calcular el hash, de modo que las modificaciones menores no rompan la firma.
Hay dos modos de canonicalización, aplicados de forma independiente a las cabeceras y al cuerpo:
- simple - Casi ninguna tolerancia a modificaciones. Las cabeceras deben coincidir exactamente (excepto por los espacios en blanco finales). El cuerpo se normaliza solo por las líneas vacías finales. Úsalo cuando controles toda la ruta de entrega y ningún intermediario vaya a modificar el mensaje.
- relaxed - Más tolerante. Los nombres de las cabeceras se pasan a minúsculas, el espacio en blanco se normaliza y los espacios múltiples se colapsan en uno. En el cuerpo, se elimina el espacio en blanco final de cada línea. Úsalo para la mayoría de los despliegues del mundo real.
La configuración c=relaxed/relaxed (relaxed tanto para cabeceras como para cuerpo) es la más común y recomendada.
Alineación DKIM
La alineación DKIM es un concepto de DMARC que determina si el dominio de la firma DKIM (valor d=) coincide con el dominio de la cabecera From visible. Esto es crítico porque DMARC exige que al menos uno de SPF o DKIM sea a la vez válido y alineado.
Alineación relajada (relaxed)
Los dominios organizativos deben coincidir, pero se permiten los subdominios. Por ejemplo:
- From:
user@example.comcond=mail.example.com- Pasa la alineación relajada (mismo dominio organizativo) - From:
user@example.comcond=example.com- Pasa la alineación relajada
Alineación estricta (strict)
Los dominios deben coincidir exactamente:
- From:
user@example.comcond=example.com- Pasa la alineación estricta - From:
user@example.comcond=mail.example.com- Falla la alineación estricta
Guía detallada: Dominar la alineación DKIM: claves, firmas y por qué los correos fallan la verificación
Rotación de claves DKIM
Las claves privadas DKIM deben rotarse periódicamente para limitar el daño si una clave se ve comprometida. El proceso de rotación implica:
- Generar un nuevo par de claves con un nuevo selector
- Publicar la nueva clave pública en el DNS
- Configurar el servidor emisor para firmar con la nueva clave privada
- Esperar a la propagación del DNS y verificar las firmas con la nueva clave
- Eliminar la clave pública antigua del DNS tras un periodo de transición
¿Con qué frecuencia deberías rotar? No hay un estándar universal, pero las recomendaciones comunes van de cada 6 meses a anualmente. Los entornos de alta seguridad pueden rotar con más frecuencia.
Guía detallada: ¿Cuándo deberías rotar tus claves DKIM?
Por qué falla DKIM
La verificación DKIM puede fallar por varias razones:
Modificación del mensaje en tránsito
Si cualquier cabecera firmada o el cuerpo del mensaje se modifica tras la firma, el hash no coincidirá y la verificación fallará. Los culpables comunes incluyen:
- Listas de correo que añaden pies de página o modifican la línea del asunto
- Puertas de enlace de correo que reescriben cabeceras para cumplimiento o análisis de seguridad
- Servicios de reenvío que alteran las cabeceras del mensaje
Problemas de DNS
- El registro de la clave pública DKIM no existe o es inalcanzable
- El selector de la firma no coincide con ninguna clave publicada
- Retrasos de propagación del DNS tras una rotación de claves
Errores de configuración
- La clave privada no coincide con la clave pública publicada
- El algoritmo de firma especificado en la firma no coincide con el tipo de clave
- Las cabeceras listadas en la etiqueta
h=no se incluyeron en el cálculo real de la firma
Guías detalladas:
- ¿Por qué falla DKIM? ¿Qué puedes hacer al respecto?
- Error de firma DKIM inválida: así puedes solucionarlo
- Cómo evitar los errores comunes de SPF y DKIM en 2026
DKIM vs SPF: complementarios, no competidores
DKIM y SPF cumplen propósitos distintos y tienen fortalezas distintas:
| Característica | SPF | DKIM |
|---|---|---|
| Qué verifica | Dirección IP del servidor emisor | Integridad y origen del mensaje |
| Cómo funciona | Búsqueda DNS de IPs autorizadas | Verificación de firma criptográfica |
| Sobrevive al reenvío | No - el reenvío cambia la IP emisora | Sí - la firma viaja con el mensaje |
| Protege la integridad del contenido | No | Sí - detecta manipulaciones |
| Tipo de registro DNS | TXT en el dominio | TXT en selector._domainkey.domain |
| Base de alineación DMARC | Dominio del Return-Path | Dominio d= de la firma |
Como SPF se rompe durante el reenvío de correo (la IP del servidor reenviador no está en el registro SPF del dominio original), DKIM es a menudo el único método de autenticación que pasa para los mensajes reenviados. Esto hace que la alineación DKIM sea esencial para los dominios que usan listas de correo, reglas de reenvío o cualquier infraestructura de relé.
Guías detalladas:
- En qué se diferencia SPF de DKIM y DMARC
- ¿Están alineados tus identificadores de SPF y DKIM?
- Cómo combinar las pruebas de SPF, DKIM y DMARC para la seguridad
DKIM para correo reenviado y retransmitido
Una de las ventajas prácticas más importantes de DKIM sobre SPF es su comportamiento durante el reenvío de correo. Cuando un mensaje se reenvía a través de un servidor intermediario (una lista de correo, una regla de reenvío automático o un servicio de relé), SPF se rompe porque la dirección IP del servidor reenviador no está listada en el registro SPF del dominio original. DKIM, por el contrario, sobrevive al reenvío siempre que el contenido del mensaje no se modifique. Si eres nuevo en la configuración de esto, las preguntas frecuentes de AutoSPF responden a las dudas de configuración más comunes.
Por eso DKIM es crítico para el cumplimiento de DMARC en entornos con:
- Listas de correo - Organizaciones que participan en listas de correo del sector o grupos de distribución internos
- Reenvío de correo - Usuarios que reenvían correo de un proveedor a otro (p. ej., reenviar una dirección universitaria a Gmail)
- Alojamiento compartido - Entornos donde el correo pasa por servidores de relé compartidos
- Puertas de enlace de correo - Dispositivos de seguridad que retransmiten correo sin modificar el contenido
Sin embargo, DKIM se romperá si el intermediario modifica las partes firmadas del mensaje. Las modificaciones comunes que rompen DKIM incluyen añadir pies de página, reescribir la línea del asunto o eliminar adjuntos. El software de listas de correo como Mailman y LISTSERV a menudo añade cabeceras y pies de página de lista, lo que puede romper las firmas DKIM basadas en el cuerpo.
La solución es configurar DKIM con canonicalización c=relaxed/relaxed (que tolera cambios menores de espacio en blanco) y asegurarse de que cualquier software de listas de correo que operes esté configurado para preservar las firmas DKIM siempre que sea posible.
Patrones comunes de configuración de DKIM
Distintas configuraciones de infraestructura de correo requieren distintos enfoques de configuración de DKIM:
Un único proveedor
Si todo tu correo pasa por un único proveedor (p. ej., Google Workspace), ese proveedor gestiona la firma DKIM automáticamente. Solo necesitas publicar en tu DNS la clave pública que te proporcionan.
Varios proveedores con selectores separados
Cuando varios servicios envían correo en tu nombre, cada servicio recibe su propio par de claves DKIM con un selector único. Por ejemplo:
google._domainkey.example.com- La clave DKIM de Google Workspaces1._domainkey.example.com- La clave DKIM de SendGridk1._domainkey.example.com- La clave DKIM de Mailchimp
Cada servicio firma los mensajes con su propia clave privada, y los receptores buscan la clave pública correcta según el selector de la cabecera DKIM-Signature.
Firma en las instalaciones (on-premises)
Las organizaciones que operan sus propios servidores de correo (Exchange, Postfix, Exim) necesitan generar sus propios pares de claves, instalar la clave privada en el servidor de correo y publicar la clave pública en el DNS. Puedes crear un par de claves con nuestro generador DKIM gratuito. Esto te da control total sobre el proceso de firma, pero requiere que gestiones la generación, la rotación y el almacenamiento de las claves.
DKIM y TLS: distintas capas de seguridad
DKIM y TLS (Transport Layer Security) contribuyen ambos a la seguridad del correo, pero operan en distintas capas:
- TLS cifra la conexión entre servidores de correo durante la transmisión, evitando la interceptación en tránsito. No verifica la identidad del remitente ni protege contra la suplantación.
- DKIM verifica la identidad del remitente y la integridad del mensaje, pero no cifra el contenido del mensaje.
Ambos son necesarios para una seguridad de correo integral.
Guía detallada: TLS y DKIM: por qué necesitas ambos para una seguridad de correo sólida
Configurar DKIM para tu plataforma
La configuración de DKIM varía según la plataforma de correo. El proceso general es:
- Generar un par de claves DKIM (tu plataforma de correo suele hacerlo)
- Publicar la clave pública como un registro DNS TXT en la ubicación correcta del selector
- Activar la firma DKIM en la plataforma de envío
- Verificar la configuración con una consulta DKIM
Para instrucciones específicas por plataforma, consulta estas guías:
- Guía definitiva de configuración de SPF y DKIM en Microsoft 365
- Autenticación DKIM: una guía completa para una entregabilidad de correo segura
- Configurar SPF y DKIM para Salesforce
- Dominar SPF y DKIM para SendGrid
- Guía completa para configurar SPF y DKIM en Mailgun
- Cómo AutoSPF habilita SPF y DKIM en cPanel
DKIM en la pila de autenticación
DKIM es uno de los tres protocolos que trabajan juntos para autenticar el correo:
- SPF - Verifica que el servidor emisor está autorizado
- DKIM - Verifica la integridad del mensaje y proporciona una firma a nivel de dominio (esta guía)
- DMARC - Vincula SPF y DKIM con requisitos de alineación, define la política de cumplimiento y habilita la generación de informes
DMARC exige que al menos uno de SPF o DKIM pase y esté alineado con el dominio de la cabecera From. En la práctica, configurar tanto SPF como DKIM maximiza tus posibilidades de pasar DMARC, porque si un método falla (p. ej., SPF falla debido al reenvío), el otro aún puede proporcionar un resultado válido y alineado.
Guías detalladas:
- Cómo SPF, DKIM y DMARC trabajan juntos durante los fallos de autenticación
- Protocolos de autenticación de correo: SPF, DKIM y DMARC explicados
- Cómo probar la compatibilidad del aplanamiento SPF con DMARC y DKIM
Herramientas de diagnóstico
- Herramienta de consulta DKIM - Consulta y valida claves públicas DKIM de cualquier dominio y selector
- Verificador de autenticación de dominio - Comprueba SPF, DKIM y DMARC en una sola búsqueda
- Verificador SPF - Valida tu registro SPF junto con DKIM
- Verificador DMARC - Verifica tu política DMARC y la configuración de alineación
Próximos pasos
- Verifica tu configuración DKIM actual - Usa la herramienta de consulta DKIM para comprobar si tu dominio tiene claves DKIM válidas publicadas
- Comprueba la alineación - Asegúrate de que el dominio
d=de tus firmas DKIM coincide con el dominio de tu cabecera From - Revisa la fortaleza de la clave - Confirma que estás usando claves RSA de al menos 2048 bits
- Planifica la rotación de claves - Establece un calendario de rotación y documenta el proceso
- Despliega DMARC - Si aún no lo has hecho, configura DMARC para exigir la alineación de SPF y DKIM y recibir informes agregados
- Supervisa con informes DMARC - Usa los informes agregados DMARC para identificar fallos de DKIM en todos los servidores receptores