Skip to main content
New SPF lookups must resolve in milliseconds — why a DMARC tool's add-on isn't enough Learn Why → →

¿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)

  1. El servidor de correo emisor genera un hash de determinadas cabeceras del correo y del cuerpo del mensaje
  2. El servidor cifra este hash usando la clave privada DKIM del dominio
  3. El servidor añade una cabecera DKIM-Signature al mensaje que contiene el hash cifrado, el nombre del selector, el dominio firmante y metadatos sobre qué cabeceras se firmaron
  4. El mensaje se transmite al servidor receptor

El proceso de verificación (entrante)

  1. El servidor receptor extrae la cabecera DKIM-Signature del mensaje
  2. Lee los valores d= (dominio) y s= (selector) de la firma
  3. Realiza una búsqueda DNS de <selector>._domainkey.<domain> para recuperar la clave pública
  4. Usa la clave pública para descifrar la firma y recuperar el hash original
  5. Calcula de forma independiente el hash de las mismas cabeceras y del cuerpo usando el algoritmo especificado
  6. 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...
EtiquetaSignificado
v=1Versión de DKIM (siempre 1)
a=rsa-sha256Algoritmo de firma
d=example.comDominio firmante (usado para la alineación DMARC)
s=selector1Selector - identifica qué clave pública usar
c=relaxed/relaxedMétodo de canonicalización para cabecera/cuerpo
q=dns/txtMétodo de consulta para la clave pública
t=1618884473Marca 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..."
EtiquetaSignificado
v=DKIM1Versión
k=rsaTipo 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.com con d=mail.example.com - Pasa la alineación relajada (mismo dominio organizativo)
  • From: user@example.com con d=example.com - Pasa la alineación relajada

Alineación estricta (strict)

Los dominios deben coincidir exactamente:

  • From: user@example.com con d=example.com - Pasa la alineación estricta
  • From: user@example.com con d=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:

  1. Generar un nuevo par de claves con un nuevo selector
  2. Publicar la nueva clave pública en el DNS
  3. Configurar el servidor emisor para firmar con la nueva clave privada
  4. Esperar a la propagación del DNS y verificar las firmas con la nueva clave
  5. 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:

DKIM vs SPF: complementarios, no competidores

DKIM y SPF cumplen propósitos distintos y tienen fortalezas distintas:

CaracterísticaSPFDKIM
Qué verificaDirección IP del servidor emisorIntegridad y origen del mensaje
Cómo funcionaBúsqueda DNS de IPs autorizadasVerificación de firma criptográfica
Sobrevive al reenvíoNo - el reenvío cambia la IP emisoraSí - la firma viaja con el mensaje
Protege la integridad del contenidoNoSí - detecta manipulaciones
Tipo de registro DNSTXT en el dominioTXT en selector._domainkey.domain
Base de alineación DMARCDominio del Return-PathDominio 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:

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 Workspace
  • s1._domainkey.example.com - La clave DKIM de SendGrid
  • k1._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:

  1. Generar un par de claves DKIM (tu plataforma de correo suele hacerlo)
  2. Publicar la clave pública como un registro DNS TXT en la ubicación correcta del selector
  3. Activar la firma DKIM en la plataforma de envío
  4. Verificar la configuración con una consulta DKIM

Para instrucciones específicas por plataforma, consulta estas guías:

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:

Herramientas de diagnóstico

Próximos pasos

  1. Verifica tu configuración DKIM actual - Usa la herramienta de consulta DKIM para comprobar si tu dominio tiene claves DKIM válidas publicadas
  2. Comprueba la alineación - Asegúrate de que el dominio d= de tus firmas DKIM coincide con el dominio de tu cabecera From
  3. Revisa la fortaleza de la clave - Confirma que estás usando claves RSA de al menos 2048 bits
  4. Planifica la rotación de claves - Establece un calendario de rotación y documenta el proceso
  5. Despliega DMARC - Si aún no lo has hecho, configura DMARC para exigir la alineación de SPF y DKIM y recibir informes agregados
  6. Supervisa con informes DMARC - Usa los informes agregados DMARC para identificar fallos de DKIM en todos los servidores receptores
Rated 5/5 on G2 · Trusted since 2018

Trusted by 50,000+ domains

"AutoSPF Flattens SPF Records Seamlessly & Keeps Changes Logged - I am quite pleased with the product"

It does what it promises to do, and does it very well. I appreciate that it keeps a log of changes made, which prevents many mistakes. A client's SPF record would have way too many lookups, but AutoSPF makes that problem go away. The length of the SPF record is typically not the issue; it's the amount of lookups in the record that are. AutoSPF "flattens" the record, automatically expanding the defined lookups to IP addresses or ranges. And it auto-updates the record when the un-flattened lookups change.
PJ

Peter J.

President · Small-Business (50 or fewer emp.)

"Helped us go beyond capacity"

AutoSPF did exactly as described, it helped us get past our 10 lookup limit. Afterwards, we hit another limit regarding overall capacity and when contacted, they quickly provided us with a new solution to eliminate capacity issues entirely going forward, so now we can add as many SPF records as needed. They also provided us with a personalized support video explaining their new method in its entirety using our instance as the example.
VU

Verified User

Financial Services · Mid-Market (51-1000 emp.)

"Great service and great support"

AutoSPF was easy to initially set up on our own and a great cost effective entry into spf flattening. Needed our first support assistance today and got great response including a video demonstrating the issue I was trying to solve, a quick fix, and more detailed followup.
GF

Greg F.

Mid-Market (51-1000 emp.)