← RFC Reference

DKIM — DomainKeys Correo Identificado

Por qué existe este RFC

SPF verifica que un mensaje proviene de una dirección IP autorizada, pero no dice nada sobre el contenido del mensaje. Un mensaje podría pasar SPF y luego ser modificado por un relé comprometido. SPF también se rompe cuando el correo se reenvía, porque la IP de envío cambia.

DKIM resuelve ambos problemas. Al adjuntar una firma criptográfica al mensaje mismo, proporciona una aserción de identidad a nivel de dominio que sobrevive al reenvío (la firma viaja con el mensaje) y garantiza la integridad del contenido (cualquier modificación invalida la firma).

RFC 6376, publicado en 2011, es la especificación DKIM actual. Obsoletó RFC 4871 e introdujo mejoras en canonicalización, gestión de claves y semántica de firmas. Sigue siendo el fundamento de la autenticación de correo moderno junto con SPF y DMARC.

Cómo funciona

Firma (lado del remitente)

1. El servidor de correo de envío (o un agente de firma en la parte anterior) selecciona qué encabezados y cuerpo se firmarán.
2. Canonicaliza el contenido seleccionado usando algoritmos simple o relaxed para normalizar espacios en blanco y mayúsculas.
3. Calcula un hash del cuerpo canonicalizado, luego un hash de los encabezados seleccionados más el hash del cuerpo.
4. Firma el hash del encabezado usando la clave privada del dominio (RSA o Ed25519).
5. Añade un encabezado DKIM-Signature al mensaje que contiene la firma, el dominio de firma (d=), el selector (s=) y metadatos sobre qué se firmó.

Verificación (lado del receptor)

1. El receptor extrae los valores d= (dominio) y s= (selector) del encabezado DKIM-Signature.
2. Consulta DNS por la clave pública en <selector>._domainkey.<domain>.
3. Re-canonicaliza los encabezados y cuerpo firmados usando el mismo algoritmo especificado en la firma.
4. Verifica la firma contra la clave pública. Si es válida, el resultado es pass.

Ejemplo de encabezado DKIM-Signature

Registro de clave pública DNS

Detalles técnicos clave

Canonicalización

El correo puede ser modificado sutilmente en tránsito (espacios en blanco finales eliminados, encabezados re-plegados). La canonicalización normaliza el contenido antes del hash para que los cambios benignos no rompan la firma. Hay dos algoritmos disponibles, especificados por separado para encabezados y cuerpo:

La configuración más común es c=relaxed/relaxed, que tolera las modificaciones más comunes en tránsito.

Tipos de clave

RFC 6376 definió firmas RSA. RFC 8463 añadió posteriormente soporte para Ed25519. Las claves RSA deben tener al menos 2048 bits; las claves de 1024 bits se consideran débiles y algunos receptores las rechazan. Las claves Ed25519 son mucho más pequeñas (44 caracteres en DNS) y más rápidas de verificar.

Selectores

El selector (s= tag) permite a un dominio publicar múltiples claves DKIM simultáneamente. Esto es esencial para la rotación de claves: publica una clave nueva bajo un selector nuevo, comienza a firmar con ella, luego elimina el registro DNS del selector anterior después de un período de transición.

La etiqueta l= (límite de longitud del cuerpo)

La etiqueta opcional l= limita cuántos bytes del cuerpo se firman. Fue concebida para permitir que las listas de correo añadan pies de página sin romper firmas. En la práctica, crea una vulnerabilidad de seguridad: un atacante puede añadir contenido malicioso después de la porción firmada. La mayoría de implementaciones conscientes de seguridad evitan usar l=.

Firma de encabezados

La etiqueta h= lista qué encabezados se incluyen en la firma. La mejor práctica es firmar al menos: From, To, Subject, Date, Message-ID, MIME-Version y Content-Type. El encabezado From es requerido por especificación. Firmar un encabezado que no existe previene que sea añadido después de la firma (una medida anti-replay importante).

Errores comunes

• Usar claves RSA de 1024 bits: Estas son criptográficamente débiles por estándares modernos. Gmail y otros receptores principales pueden reducir la confianza. Siempre usa RSA de 2048 bits o Ed25519.
• No rotar claves: Las claves privadas DKIM deben rotarse periódicamente (cada 6-12 meses). Los selectores hacen esto transparente — publica la clave nueva, cambia la firma, retira la clave antigua.
• Firmar con un dominio desalineado: Para que DMARC pase mediante DKIM, el dominio d= en la firma debe alinearse con el dominio del encabezado From: (coincidencia exacta o subdominio, dependiendo de la política DMARC). Si tu ESP firma como d=esp.com, la alineación DMARC falla a menos que configures firma DKIM personalizada.
• Sobre-firmar versus bajo-firmar encabezados: No firmar encabezados importantes (como Subject) permite a los atacantes modificarlos. Sobre-firmar encabezados que intermediarios legítimamente añaden puede causar falsos fallos.
• Retraso en propagación de registros DNS: Después de publicar una clave DKIM nueva, espera a la propagación de DNS antes de firmar con el selector nuevo. Una firma que referencia una clave pública inexistente fallará la verificación.
• Usar la etiqueta l= de longitud del cuerpo: Esto permite que contenido sin firmar sea añadido al mensaje. Evítalo.

Impacto en la entregabilidad

• Fundamento para DMARC: La alineación DKIM es uno de los dos caminos hacia DMARC pass (el otro siendo alineación SPF). Ya que DKIM sobrevive al reenvío mientras SPF no, DKIM es a menudo el camino de autenticación más confiable.
• Vinculación de reputación: DKIM vincula mensajes al dominio de firma (mediante la etiqueta d=). Los proveedores de buzón utilizan esto para construir reputación de dominio. La firma consistente de DKIM construye reputación positiva con el tiempo.
• Requerido por proveedores principales: Gmail y Yahoo requieren que SPF o DKIM pasen para todos los remitentes. Remitentes masivos (5,000+ mensajes/día a Gmail) deben tener tanto SPF como DKIM pasando, más una política DMARC.
• Sobrevive al reenvío: A diferencia de SPF, una firma DKIM viaja con el mensaje. Cuando el correo se reenvía a través de listas de correo, reglas .forward o expansiones de alias, DKIM aún puede validar (siempre que el sistema de reenvío no modifique contenido firmado). Esto hace DKIM esencial para compatibilidad con listas de correo.
• Integridad del contenido: Más allá de la autenticación, DKIM prueba que el mensaje no fue alterado en tránsito. Esto protege contra modificaciones de hombre en el medio e incrementa la confianza del receptor.

Related RFCs