Cómo generar una clave DKIM (y publicar la correcta)

El CNAME antes que el TXT, cuando sea posible

Muchos proveedores ofrecen publicar un CNAME que apunta a un registro que ellos mantienen, en lugar de un TXT con la clave fija. El CNAME es prioritario: permite al proveedor rotar la clave sin retocar el DNS cada vez. Se publica una vez, y la rotación de claves se vuelve transparente. El TXT en bruto sigue siendo válido, pero obliga a intervenir en cada renovación.

Generar una clave a mano (caso avanzado)

Quien opera su propia infraestructura de envío (un servidor Postfix, por ejemplo) genera el par por sí mismo. Conceptualmente, se crea una clave RSA, se extrae la parte pública y se construye el registro DNS. El registro publicado se parece a:

selector._domainkey.ejemplo.es.  IN TXT
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQ... (clave pública)"

El p= contiene la clave pública codificada. La clave privada correspondiente, por su parte, permanece en el servidor, leída por la herramienta de firma. Dos reglas de oro en este caso: proteger la clave privada como un secreto crítico, y elegir un tamaño adecuado (ver más abajo).

Qué tamaño de clave elegir

La pregunta vuelve siempre: ¿1024 o 2048 bits? La respuesta corta: 2048 bits es el estándar recomendado hoy, más robusto. El 1024 sigue aceptándose pero está envejeciendo. Hay, no obstante, un matiz técnico (la longitud del registro DNS) que merece una guía dedicada — 1024 o 2048 bits lo desarrolla. Partiendo de cero, la elección es 2048.

La trampa que lo anula todo: la alineación

Aquí está el error más costoso. Se puede generar y publicar una clave DKIM perfectamente válida, ver cómo la firma «pasa», y sin embargo no aportar nada a DMARC. ¿Por qué? Porque DMARC exige que el dominio firmante (d= en la firma) se alinee con el del From:. La firma DKIM por defecto de muchas plataformas usa su dominio (d=plataforma.es), no el del remitente. Resultado: la firma es válida, pero para el dominio equivocado.

La solución es configurar una firma con la marca propia: la mayoría de los proveedores ofrecen una opción de «dominio de firma personalizado» o «DKIM autenticado», que hace firmar con d=ejemplo.es. Es precisamente lo que hace útil una clave DKIM para DMARC. El mecanismo completo está en cómo funcionan juntos los tres protocolos.

Verificar que la clave funciona

Una vez publicada la clave y activada la firma, hay tres cosas que controlar:

1. La clave pública está ahí, completa y en el selector correcto (dig TXT selector._domainkey.ejemplo.es).
2. La firma pasa sobre un mensaje real — ver cómo verificar una firma de correo.
3. Se alinea con el From:, visible en los informes agregados.

Todo esto se confirma de una vez con nuestro analizador DMARC gratuito, que verifica la presencia, la validez y la alineación de las claves.

Activar DKIM en las plataformas más habituales

El procedimiento exacto depende de la plataforma, pero el esquema es el mismo en todas partes: activar DKIM en la consola, recuperar el registro, publicarlo, esperar, firmar. Algunas referencias concretas:

• Microsoft 365. En el portal de seguridad, bajo la autenticación del correo, se activa DKIM para el dominio. Microsoft proporciona dos CNAME (selector1 y selector2) a publicar; ambos sirven para permitir la rotación alternada de las claves. Una vez publicados y propagados, se activa la firma.
• Google Workspace. En la consola de administración, bajo la autenticación del correo, se genera una clave (2048 bits) para el dominio. Google da un TXT a publicar en el selector google. Tras la propagación, se inicia la autenticación.
• Enrutadores y SaaS (Brevo, SendGrid, Mailchimp…). Casi todos ofrecen un dominio de firma personalizado mediante uno o varios CNAME. También es ahí donde se activa la alineación (d=ejemplo.es) — el paso que hace la firma útil para DMARC.

En todos los casos, la regla es la misma: copiar el valor íntegramente, esperar la propagación antes de activar la firma, y verificar después que el d= es de verdad el del dominio y no el del proveedor.

Los errores de generación más frecuentes

Tres fallos vuelven una y otra vez. Primero, activar la firma antes de la propagación DNS: las primeras firmas apuntan a una clave aún no visible y fallan — hay que esperar a que dig muestre la clave antes de firmar. Segundo, truncar la clave al copiar y pegar, sobre todo en 2048 bits, donde es larga: un solo carácter que falte rompe toda la verificación. Por último, olvidar la alineación: se activa DKIM, la firma pasa, pero con el d= del proveedor — la protección parece completa cuando DMARC no se apoya en nada. Verificar sistemáticamente estos tres puntos tras cada activación ahorra la abrumadora mayoría de los fallos de arranque de DKIM.

Preguntas frecuentes

¿Debo generar la clave yo mismo? Rara vez. En un envío a través de una plataforma (Microsoft, Google, un SaaS), ella genera el par y guarda la clave privada. La generación manual solo concierne a quien opera su propia infraestructura de firma.

¿Adónde va la clave privada? Permanece en el entorno que firma (la plataforma o el servidor propio). Nunca se publica en DNS y no debe abandonar jamás ese entorno. El DNS solo contiene la clave pública.

¿Se puede reutilizar la misma clave para varios dominios? A evitar. Cada dominio debería tener su propia clave (y su propio selector), para aislar los riesgos y simplificar la rotación.

¿Cuánto tiempo antes de que funcione? El tiempo de la propagación DNS (de unos minutos a unas horas). La firma no se activa en el lado de la plataforma hasta que la clave pública sea visible, o las primeras firmas fallarán.

¿1024 o 2048 bits? 2048 para un nuevo despliegue. El 1024 todavía funciona pero es menos robusto; a reemplazar en la próxima rotación.

DKIM y entregabilidad: por qué importa de verdad

Más allá de la seguridad, DKIM tiene un efecto concreto en la entregabilidad del correo. Los grandes proveedores de correo (Gmail, Outlook, Yahoo) integran la presencia y la alineación de DKIM en sus puntuaciones de reputación: un dominio que firma correctamente desde hace tiempo, con una clave alineada, construye un historial de confianza que los filtros antispam tienen en cuenta. A la inversa, un dominio sin DKIM (o con una firma no alineada) se trata con más desconfianza, sobre todo si su reputación es todavía joven. DKIM no impide el spam — un spammer puede perfectamente firmar sus mensajes — pero le dice al receptor «este mensaje viene realmente de quien dice venir», lo que es una señal de legitimidad importante. Combinado con SPF y DMARC, constituye el trío de base que todo remitente serio debe tener implantado antes de buscar optimizar cualquier otra cosa. Bien configurado una vez, DKIM trabaja de forma invisible, acumulando reputación con cada correo legítimo enviado.

Thomas genera el registro correcto

Entre el tamaño de clave, el CNAME frente al TXT y sobre todo la alineación, una clave DKIM mal puesta pasa desapercibida hasta el día en que DMARC falla. Thomas, el CISO virtual, indica para cada plataforma el registro exacto a publicar, verifica que la firma se alinea con el dominio, y guía hasta un DKIM que cuenta de verdad para DMARC.

Análisis de dominio gratuito o crear una cuenta para un DKIM correcto a la primera.