¿Qué es DKIM y cómo funciona una firma DKIM?

DKIM es el método de autenticación del correo que sobrevive al trayecto. Mientras SPF comprueba el servidor del que procede un mensaje, DKIM firma el propio mensaje, de modo que la prueba viaja con él a través de relays y de la mayoría de los reenvíos. Esta guía explica qué contiene una firma, cómo la verifican los receptores, cómo funcionan las claves y los selectores, y qué la rompe. También es el punto de partida de nuestras guías sobre DKIM.

¿Qué es DKIM?

DKIM son las siglas de DomainKeys Identified Mail. Está definido en el RFC 6376, un documento de la categoría Standards Track de septiembre de 2011. El RFC dice que DKIM "permite a una persona, función u organización asumir cierta responsabilidad sobre un mensaje asociando un nombre de dominio al mensaje".

Funciona con un par de claves:

• Tu plataforma de correo guarda una clave privada y la usa para firmar cada mensaje saliente.
• La clave pública correspondiente se publica en el DNS bajo tu dominio.
• El receptor lee la firma, obtiene la clave pública y comprueba que ambas coinciden.

Tres cosas que DKIM no es:

• No es cifrado. El mensaje sigue siendo legible. DKIM solo demuestra el origen y la integridad.
• No comprueba el From. El dominio firmante puede ser cualquier dominio. Vincularlo a la dirección From visible es tarea de DMARC.
• No es motivo de rechazo por sí solo. La sección 6.3 del RFC 6376 dice que los receptores "NO DEBERÍAN" decidir si aceptan un mensaje basándose solo en que falte una firma o no se pueda verificar, porque "ese rechazo causaría graves problemas de interoperabilidad".

¿Cómo funciona la firma DKIM?

Cuando tu servidor envía un mensaje:

1. Elige los encabezados que firmará y los enumera en h=. El encabezado From: "DEBE firmarse" (sección 5.4 del RFC 6376).
2. Canonicaliza los encabezados y el cuerpo: los normaliza según las reglas elegidas para que pequeños cambios inofensivos en tránsito no rompan la firma.
3. Calcula el hash del cuerpo y pone el resultado en bh=.
4. Calcula el hash de los encabezados firmados, incluido el propio encabezado DKIM-Signature nuevo con un b= vacío, y firma ese hash con la clave privada.
5. Escribe la firma en b= y añade el encabezado DKIM-Signature al principio del mensaje.

Una firma tiene este aspecto (abreviada):

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s202610;
  h=from:to:subject:date:message-id; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB...

¿Cómo verifica un receptor una firma DKIM?

1. Lee el encabezado DKIM-Signature y comprueba las etiquetas obligatorias.
2. Obtiene la clave pública con una consulta DNS TXT a <s>._domainkey.<d>, por ejemplo s202610._domainkey.example.com.
3. Vuelve a calcular el hash del cuerpo con la misma canonicalización y lo compara con bh=. Si no coinciden, aparece el conocido error "body hash did not verify".
4. Verifica b= con los encabezados firmados usando la clave pública.
5. Registra el resultado, por ejemplo dkim=pass header.d=example.com en Authentication-Results.

Un mensaje puede llevar varias firmas: del remitente, de un servicio de correo y de una lista de correo. Una firma rota no hace que un mensaje sea peor que uno sin firmar: el RFC 6376 dice que un verificador "NO DEBERÍA tratar un mensaje que tiene una o más firmas incorrectas y ninguna correcta de forma distinta a un mensaje sin ninguna firma".

¿Qué es la canonicalización DKIM?

El correo se reescribe ligeramente en tránsito: se reajustan las líneas de los encabezados, se eliminan espacios finales. La canonicalización decide cuánto de eso tolera una firma. La sección 3.4 del RFC 6376 define dos algoritmos para los encabezados y dos para el cuerpo, que se escriben como c=header/body.

El RFC dice que relaxed "tolera modificaciones habituales como la sustitución de espacios en blanco y el reajuste de líneas de los campos de encabezado". Si falta c=, se aplica simple/simple. Ningún modo sobrevive a cambios reales de contenido, como un pie añadido por una lista de correo o un aviso legal añadido por una pasarela.

¿Qué son los selectores DKIM y las claves en el DNS?

Un selector identifica una clave entre varias del mismo dominio. La sección 3.1 del RFC 6376 los introduce "para admitir varias claves públicas simultáneas por dominio firmante". Eso es lo que permite que cada servicio de envío tenga su propia clave y que puedas sustituir una clave sin interrupciones.

La clave está en <selector>._domainkey.<domain>:

s202610._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Cada proveedor publica las claves de forma distinta. Microsoft 365 usa dos registros CNAME, selector1 y selector2, que apuntan a claves que Microsoft aloja y rota. Google Workspace te pide publicar un registro TXT, por defecto en google._domainkey (Google). Nuestras páginas de registros DKIM por proveedor muestran los registros de servicios habituales, y cómo encontrar un selector DKIM explica cómo leerlo en un mensaje.

¿Qué longitud debe tener una clave DKIM?

El RFC 8301 actualizó en 2018 las reglas criptográficas de DKIM:

Usa RSA de 2048 bits. El inconveniente está en el DNS: una clave pública de 2048 bits es demasiado larga para una sola cadena TXT de 255 caracteres, así que se guarda como varias cadenas que los receptores vuelven a unir. La mayoría de los proveedores de DNS lo gestionan bien; si el tuyo trunca la clave, la firma falla.

¿Y Ed25519?

El RFC 8463 añade el algoritmo Ed25519-SHA256, que "tiene claves mucho más cortas que RSA para niveles de seguridad similares". Su registro de clave usa k=ed25519 y la clave pública en base64 tiene solo 44 caracteres, así que cabe en una sola cadena TXT. El RFC dice que los verificadores DEBEN implementarlo, pero los grandes proveedores de buzones no documentan si lo hacen, y Microsoft 365 solo documenta claves RSA (1024 o 2048 bits) para su firma DKIM. La sección 6 del RFC 8463 ofrece la vía segura: firmar con ambos algoritmos, cada uno con su propio selector.

¿Qué relación tiene DKIM con DMARC?

DMARC (RFC 9989) aprueba un mensaje cuando SPF o DKIM dan pass para un dominio alineado con el dominio From. En DKIM, el dominio que cuenta es d=. El RFC 9989 explica por qué hace falta la alineación: "un mensaje puede llevar una firma válida de cualquier dominio, incluso de uno usado por un actor malintencionado".

Así que no todo pass es útil. Si tu herramienta de boletines firma con d=vendor-mail.net, DKIM da pass, pero DMARC para example.com no gana nada con ello. Activa en cada servicio la firma con tu dominio personalizado para que d= sea tu dominio o un subdominio suyo.

DKIM importa más que SPF para DMARC, porque en general sobrevive al reenvío. La sección 7.4 del RFC 9989 dice que el correo reenviado "muy probablemente fallará las comprobaciones SPF" mientras que "las firmas DKIM normalmente seguirán siendo válidas", e indica que los dominios que publican p=reject "DEBEN aplicar firmas DKIM válidas a sus mensajes". Para tener la visión completa, consulta qué es DMARC y SPF, DKIM y DMARC: diferencias.

¿Qué rompe DKIM?

La primera fila es la más habitual. Nuestra guía sobre DKIM "body hash did not verify" trata cada fallo en detalle.

¿Cada cuánto hay que rotar las claves DKIM?

La guía de rotación de claves de M3AAWG dice que "las claves DKIM deberían rotarse al menos cada seis meses"; su revisión de abril de 2018 flexibilizó el ciclo trimestral anterior. Los selectores lo hacen sencillo, como describe la sección 3.1 del RFC 6376: publica la nueva clave con un selector nuevo, cambia la firma a ella y mantén publicada la clave pública antigua mientras pueda haber correo firmado con ella en tránsito. Después revoca la antigua.

Microsoft 365 alterna entre sus dos selectores cuando lo solicitas, y Microsoft Learn documenta los pasos. El procedimiento completo para otras plataformas está en Rotación de claves DKIM.

¿Cómo configuro DKIM?

1. Enumera todos los servicios que envían en nombre de tu dominio, igual que harías para SPF.
2. Activa en cada uno la firma con tu dominio personalizado. La mayoría de los servicios generan la clave y te muestran un registro TXT o CNAME para publicar. Nuestra guía de configuración de DKIM para Microsoft 365 y Google Workspace explica paso a paso las dos grandes plataformas.
3. ¿Tienes tu propio servidor de correo? Crea un par de claves de 2048 bits con el DKIM Key Generator (generador de claves DKIM), que genera la clave en tu navegador, y configura tu servidor para firmar con ella.
4. Publica el registro en tu proveedor de DNS y compruébalo con el DKIM Checker (verificador de DKIM).
5. Envía un mensaje de prueba a un buzón externo y confirma dkim=pass con tu dominio en header.d, usando el Email Header Analyzer (analizador de encabezados de correo).
6. Publica DMARC para que los receptores actúen según el resultado.

Nuestras guías sobre DKIM

Próximos pasos

1. Revisa tus selectores y la solidez de tus claves con el DKIM Checker.
2. Confirma que todos los servicios de envío firman con tu dominio en d=, no con el del proveedor.
3. Sustituye cualquier clave de 1024 bits por una de 2048 bits en la próxima rotación y pon la rotación en el calendario.
4. Cuando DKIM dé pass en todas partes, endurece tu política DMARC hacia quarantine o reject; compruébala con el DMARC Checker (verificador de DMARC).

DKIM protege tu dominio en los buzones de otras personas. Para el correo que llega al tuyo, un filtro del correo entrante como iBlockSpam comprueba la autenticación de cada remitente junto con las señales de spam y phishing; consulta cómo funciona.

Si hay aplicaciones o dispositivos que envían correo a través de iBlockSpam, su relay de salida (smart host) firma esos mensajes con DKIM, con 500 mensajes de relay de salida incluidos por dominio al mes.

Consulta nuestras otras guías sobre SPF, DKIM y DMARC.