Qué es DKIM: el estándar de autenticación de email explicado

DKIM (DomainKeys Identified Mail) es un protocolo criptográfico de autenticación de email. Qué es DKIM en términos prácticos: adjunta una firma RSA a cada mensaje saliente que envía tu servidor de correo. El MTA receptor recupera tu clave pública del DNS, verifica esa firma y reporta el resultado como dkim=pass o dkim=fail. Ese resultado alimenta el modelo de reputación de tu dominio y determina si se mantiene la alineación DMARC. Sin una firma válida, el MTA receptor no tiene confirmación criptográfica de que el mensaje provino de tu infraestructura.

DKIM es un protocolo de firma, no un filtro

El nombre invita a un error frecuente. DKIM no bloquea el email. No pone en cuarentena los mensajes ni aplica ninguna política por sí solo. Lo que hace es estampar cada mensaje saliente con una afirmación verificable: este mensaje fue firmado por el dominio en el campo d=, usando la clave privada correspondiente al selector s=.

El MTA receptor toma esa afirmación, construye una consulta DNS a <selector>._domainkey.<dominio>, recupera el registro TXT que contiene la clave pública y ejecuta la verificación criptográfica. Si la verificación pasa, el encabezado de resultados de autenticación muestra dkim=pass. Si falla, ves dkim=fail o dkim=temperror.

Ninguno de estos resultados causa un rechazo por sí solo. La señal alimenta el modelo de reputación del servidor receptor y, fundamentalmente, la evaluación DMARC. El trabajo de DKIM es producir un resultado verificable, no actuar sobre él.

Qué firma DKIM y qué cubre la firma

DKIM firma dos cosas: encabezados de mensaje seleccionados y el cuerpo del mensaje. El algoritmo de firma hashea ambos y almacena el resultado en el campo de encabezado DKIM-Signature.

La lista de encabezados está controlada por el tag h= en la firma. Una configuración de producción típica incluye from:subject:date:message-id:content-type. El encabezado from es el campo que importa para la alineación DMARC. El hash del cuerpo cubre el cuerpo completo del mensaje, canonicalizado mediante canonicalización simple o relaxed.

La canonicalización relaxed es la que usa la mayoría de las stacks de producción. Normaliza los espacios en blanco antes del hashing, lo que permite que la firma sobreviva a un reformateo menor por parte de los MTA de relay. La canonicalización simple es más estricta: un único cambio de espacio en blanco al final rompe la firma. Verás c=relaxed/relaxed en el encabezado DKIM-Signature de prácticamente cualquier ESP bien configurado.

Lo que DKIM no firma: el remitente del sobre SMTP, los encabezados de enrutamiento como Received, y cualquier encabezado fuera de la lista h=. Esto es intencional. Firmar el sobre rompería los escenarios de reenvío, que es donde proviene la ventaja de DKIM sobre SPF.

El selector: un handle de control de acceso que la mayoría de los equipos trata como una etiqueta

El selector es la parte de DKIM que la mayoría de los equipos subestima hasta que necesitan rotar claves bajo presión.

El campo s= en tu DKIM-Signature apunta a una clave pública específica en tu DNS. El formato de lookup es <selector>._domainkey.<tudominio.com>. Si tu selector es mail2026 y tu dominio es example.com, el resolver busca un registro TXT en mail2026._domainkey.example.com.

Un dominio puede tener múltiples selectores activos simultáneamente. Cada servicio de envío, cada ESP, cada MTA interno debería usar su propio selector. Esto te da tres capacidades operacionales concretas:

• Rotación de clave independiente por servicio sin tocar otros remitentes.

• Atribución trazable en los logs de autenticación: el selector te dice qué clave de firma se usó en cada mensaje.

• Offboarding limpio: elimina el registro DNS del selector y ese ESP ya no puede firmar como tu dominio independientemente de lo que haga en su extremo.

A l'usage, voilà ce qu'on observe dans les traces: los equipos que configuran un selector compartido en todos sus servicios de envío no pueden revocar el acceso a un remitente sin interrumpir todos los demás. El selector no es cosmético. Es un handle de control de acceso.

DKIM y alineación DMARC: cómo funciona realmente la capa de aplicación

Que DKIM pase es un requisito previo para un tipo específico de éxito DMARC denominado alineación DKIM.

DMARC requiere al menos una de dos condiciones de alineación: alineación SPF o alineación DKIM. La alineación DKIM significa que el dominio en el encabezado From: coincide con el valor d= en la firma DKIM, y la firma se verifica. Cuando ambas condiciones se cumplen, DMARC considera el mensaje autenticado.

Por eso DKIM es la señal de autenticación más duradera. La alineación SPF se rompe con el reenvío: cuando se reenvía un mensaje, el remitente del sobre SMTP cambia, y la evaluación SPF falla contra la nueva IP de envío. La alineación DKIM sobrevive al reenvío porque la firma y el encabezado From: viajan con el cuerpo del mensaje y no son reescritos por los MTA de relay, asumiendo que el cuerpo no se modifica en tránsito.

Para dominios con una política DMARC p=reject, un mensaje que falla tanto la alineación SPF como la DKIM es rechazado por el MTA receptor. Ese es el mecanismo que impide que los emails falsificados de tu dominio lleguen a las bandejas de entrada a escala. DKIM no es la última línea de defensa aquí. Pero es la línea que se mantiene cuando el reenvío está en el camino.

Desde 2024, Google, Yahoo y Microsoft exigen DKIM para remitentes masivos que envíen 5.000 o más mensajes por día a sus MX. Los mensajes de dominios no firmados se enrutan al spam o se rechazan por defecto.

Ce n'est pas une feature marketing. C'est une contrainte d'infrastructure.

Longitud de clave y rotación: decisiones prácticas para 2026

La mayoría de las implementaciones DKIM usan RSA-SHA256. La pregunta clave es la longitud de la clave.

Las claves RSA de 1024 bits todavía aparecen en configuraciones heredadas. El NIST deprecó RSA de 1024 bits para la mayoría de los casos de uso en 2015. Una clave de 2048 bits proporciona un margen significativamente mayor y está soportada por todos los principales MTA y proveedores de recepción. Si estás generando una nueva clave hoy, usa 2048 bits.

Algunos equipos han migrado su clave de firma activa a 2048 bits pero dejaron selectores antiguos de 1024 bits publicados en DNS porque nadie auditó el inventario. Trois signaux qui changent le comportement du moteur: si ves k=rsa con una clave de 1024 bits en un selector antiguo, ese selector es una vulnerabilidad incluso si tu infraestructura de firma actual ya ha avanzado. Un selector válido pero deprecado es explotable.

Calendario de rotación de claves: la mayoría de los equipos de infraestructura rotan anualmente, algunos trimestralmente para dominios de mayor sensibilidad. La secuencia importa:

1. Generar un nuevo par de claves.

2. Publicar la nueva clave pública bajo un nuevo nombre de selector en DNS.

3. Esperar la propagación TTL, típicamente 24 a 48 horas para registros con un TTL bajo.

4. Cambiar la clave de firma en la configuración de tu MTA al nuevo selector.

5. Verificar dkim=pass en mensajes salientes mediante una herramienta de prueba de email o inspeccionando los encabezados de resultados de autenticación en un mensaje de prueba.

6. Después de confirmar que la nueva clave está activa y firmando correctamente, eliminar el registro DNS antiguo.

La rotación no es disruptiva si sigues el orden: DNS primero, cambio de clave segundo, eliminación del registro antiguo al final. Invertir los pasos 4 y 6 provoca una ventana de dkim=fail.

Señales operacionales a monitorear después de configurar DKIM

DKIM no es una tarea de configuración única. Las siguientes señales indican que algo ha derivado o se ha roto.

dkim=temperror en encabezados recibidos. Los fallos temporales generalmente indican problemas de búsqueda DNS en el lado receptor, o un desfase TTL durante la rotación de claves. Si ves esto en mensajes salientes poco después de una rotación de clave, espera la propagación completa antes de concluir que la clave en sí está mal configurada.

dkim=fail en mensajes que enviaste. La modificación del cuerpo por un relay intermedio es la causa más común. Comprueba si hay un salto de reenvío, un procesador de listas de correo, o un relay que inyecta pie de página en la ruta de entrega. Si el fallo es constante en un único flujo, mapea la cadena de relay salto por salto.

Encabezado DKIM-Signature completamente ausente. El daemon de firma en tu MTA no está en ejecución, la ruta de la clave de firma es incorrecta, o el mapeo dominio-selector está mal configurado en la configuración de tu MTA. Esto es una interrupción completa de DKIM para los flujos de mensajes afectados.

Registro TXT del selector ausente del DNS. La zona DNS fue editada o migrada sin preservar el registro del selector DKIM. Verifica con dig TXT <selector>._domainkey.<dominio> desde un resolver externo.

En una configuración de envío multi-región, los resultados DKIM inconsistentes entre nodos son frecuentemente causados por nodos que usan diferentes configuraciones de selector. Confirma que la configuración de la clave de firma está sincronizada en todos los nodos de envío antes de implementar una rotación.

Lo que DKIM no protege

DKIM no es un filtro anti-spam. Un remitente puede registrar un nuevo dominio, configurar DKIM válido y enviar spam completamente autenticado. La firma se verifica correctamente. La autenticación confirma el origen, no la intención o la calidad del contenido.

DKIM tampoco aborda la suplantación de nombre de visualización, donde el encabezado From: muestra un nombre de confianza como "Equipo de Nómina" emparejado con un dominio controlado por un atacante. La verificación criptográfica opera sobre el dominio, no sobre la presentación visual en el MUA. La mayoría del phishing a nivel MUA depende del engaño por nombre de visualización en lugar de la suplantación del dominio exacto.

Lo que DKIM sí protege: la suplantación de dominio exacto, donde un atacante intenta enviar desde tu dominio sin poseer tu clave privada. Combinado con una política DMARC p=reject que aplica la alineación DKIM, esto evita que esa clase de mensaje falsificado llegue a las bandejas de entrada en los proveedores receptores que aplican DMARC.

En términos prácticos: DKIM solo no es suficiente. El modelo de protección requiere la aplicación de la política DMARC por parte del MTA receptor. DKIM es la capa de autenticación que hace significativo a DMARC. SPF es la otra capa de autenticación, y maneja la verificación del remitente del sobre. Los tres funcionan juntos. La ausencia de cualquiera de ellos deja una brecha en la cadena de aplicación.

Si ya has configurado DKIM y SPF pero aún no has publicado un registro DMARC, las firmas existen pero no hay ninguna política de aplicación activa. El modo de monitoreo (p=none con informes rua) es un primer paso razonable: obtienes informes agregados que muestran las tasas de éxito de autenticación en tu dominio de envío antes de comprometerte con p=quarantine o p=reject.