¿Qué es DKIM y cómo prueba que un email no ha sido falsificado?

Cómo es tu registro DKIM

La clave pública se publica en el DNS bajo un nombre muy preciso: <selector>._domainkey.ton-domaine.fr. Aquí tienes un ejemplo concreto de registro TXT:

s1._domainkey.ton-domaine.fr.  IN TXT
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Desmenucemos las etiquetas que cuentan:

• s= (el selector): no es una etiqueta dentro del registro, sino el prefijo del nombre DNS. El selector te permite publicar varias claves en paralelo: una por proveedor de envío, o una antigua y una nueva durante una rotación. Es el pivote de toda la gestión DKIM. Lo exploramos en detalle en el papel del selector DKIM.
• p= (la clave pública): la clave pública codificada en base64. Es el corazón del registro. Detalle crucial: suprimir p= o vaciar su valor revoca el selector, los destinatarios consideran entonces la clave como retirada. Es el mecanismo limpio para desactivar una clave comprometida.
• k= (el algoritmo): el algoritmo de clave, siendo rsa con mucho el más común. Algunas infraestructuras modernas aceptan también ed25519, más compacto, a menudo publicado como segundo selector junto al RSA.
• v=DKIM1: la versión, presente al principio de cada registro.

Un punto que engaña a los principiantes: la clave pública suele ser demasiado larga para caber en una única cadena DNS de 255 caracteres. Se corta entonces en varias cadenas entre comillas, que el resolvedor vuelve a unir. No es un error, es el funcionamiento normal.

Selectores y rotación: el verdadero saber hacer de DKIM

Es aquí donde DKIM pasa de «funciona» a «funciona limpiamente y de forma duradera». El selector es tu clave de bóveda para dos necesidades recurrentes.

Un selector distinto por fuente de envío. Si envías vía Google Workspace y vía una plataforma de marketing y vía tu propio servidor transaccional, dale a cada uno su propio selector con su propio par de claves. La ventaja es enorme: el día en que un proveedor se ve comprometido, o lo abandonas, revocas únicamente su selector (retirando su p=) sin tocar los demás. Tus otros flujos siguen firmando y pasando sin interrupción.

La rotación regular. Una clave DKIM no es eterna: cuanto más vive, más crece el riesgo de que se filtre. La buena práctica es rotarla periódicamente, y el selector hace la operación indolora:

1. Genera un nuevo par de claves y publica la nueva clave pública bajo un nuevo selector (p. ej. s2), dejando el antiguo (s1) en su sitio.
2. Cambia tu servidor de envío para que firme con la nueva clave (s2).
3. Espera a que todo el correo firmado con la clave antigua se haya entregado (unos días de margen).
4. Retira el antiguo selector (s1) del DNS.

Ninguna interrupción, ningún mensaje rechazado durante el cambio. Desarrollamos el procedimiento completo, con las trampas, en cómo rotar una clave DKIM sin romper tu entregabilidad. Y si partes de cero, nuestra guía generar un par de claves DKIM te da los comandos exactos.

Tamaño de clave: 1024 vs 2048 bits

La longitud de la clave RSA determina su resistencia. Dos tamaños circulan hoy:

• 1024 bits: históricamente el estándar por defecto, todavía aceptado por los destinatarios, pero ahora considerado débil. Una clave de 1024 bits sigue siendo rompible por un atacante motivado con recursos, y cada vez más proveedores la degradan.
• 2048 bits: la opción a privilegiar. Es el estándar recomendado hoy, y ofrece un margen de seguridad cómodo para los años venideros. La casi totalidad de los DNS y de las plataformas de envío lo soportan sin esfuerzo.

La única limitación histórica de los 2048 bits era la longitud del registro DNS (de ahí el corte en cadenas mencionado más arriba), pero eso ya no es un obstáculo real. Genera siempre 2048 bits para cualquier clave nueva. Si aún funcionas con 1024, aprovecha tu próxima rotación para subir a 2048: es exactamente el tipo de cambio que los selectores facilitan. Comparamos los dos en detalle en DKIM 1024 vs 2048 bits: cuál elegir.

Cuerpo firmado, cabeceras firmadas: lo que DKIM protege de verdad

Una sutileza útil: DKIM no firma todo el mensaje a ciegas. Firma el cuerpo y una lista elegida de cabeceras (declarada en la etiqueta h= de la firma). Las cabeceras no listadas pueden cambiar sin romper la firma, lo cual es deliberado, ya que ciertas cabeceras técnicas son legítimamente reescritas por los servidores intermediarios.

Esta distinción explica un fenómeno común: un email puede ser modificado en tránsito (una pasarela que añade un banner «externo», una lista de distribución que aplica un pie de página) y ver su firma DKIM romperse, porque el cuerpo firmado ya no es idéntico. No es forzosamente un ataque: a veces es un intermediario un poco demasiado celoso. Es precisamente para distinguir esos casos por lo que cruzamos DKIM con las demás señales. Si quieres inspeccionar una firma real, cómo verificar una firma DKIM te muestra cómo leer cada etiqueta a mano.

DKIM frente al reenvío: donde brilla

Aquí está la ventaja decisiva de DKIM sobre SPF. Cuando un email es reenviado (forwarding) —por ejemplo de una dirección .fr a un @gmail.com personal— la IP de envío cambia: es ahora el servidor que reenvía quien entrega el mensaje. Resultado: SPF se rompe, porque la IP del reenvío no está en tu registro SPF.

DKIM, en cambio, sobrevive mucho mejor al reenvío. La firma viaja con el mensaje; mientras el cuerpo y las cabeceras firmadas no se modifiquen, la firma sigue siendo válida incluso tras varios saltos. Por eso DKIM suele ser el único mecanismo que «aguanta» en el correo reenviado, y por eso es esencial desplegarlo correctamente. Un dominio que solo se apoya en SPF verá una parte de su correo legítimo fallar a la autenticación en cuanto pase por un reenvío.

Por qué DKIM no basta: hace falta DMARC por encima

Aquí está el punto que nunca hay que olvidar. DKIM prueba que un mensaje es íntegro y está firmado por un dominio. Pero no verifica que ese dominio corresponda al que el usuario ve en el campo From:. Un atacante puede perfectamente firmar su correo con DKIM para su propio dominio (malvado.com), pasar el control DKIM sin problema, y sin embargo mostrar tu dominio en el From:. DKIM, por sí solo, no ve la mentira.

El eslabón que falta se llama alineación, y es el papel de DMARC. DMARC exige que el dominio autenticado por DKIM (el d=) corresponda al dominio del From: visible. Es esa regla la que transforma DKIM de una simple prueba de integridad en una verdadera protección contra la suplantación de tu identidad. Sin DMARC, DKIM es una cerradura en una puerta que el atacante simplemente rodea pasando por la ventana de al lado.

Por eso DKIM, SPF y DMARC forman un todo. DKIM y SPF aportan las pruebas; DMARC las vincula a tu dominio visible y dice a los destinatarios qué hacer en caso de fallo. Para la visión de conjunto, empieza por qué es DMARC: es el estándar que por fin da sentido a tu firma DKIM.

Pasa a la acción

DKIM no es complicado, pero cada detalle cuenta: el buen selector, una clave de 2048 bits, una rotación limpia, y sobre todo DMARC por encima para vincularlo todo a tu dominio visible. Este es el orden de marcha que recomiendo:

• Genera una clave de 2048 bits y publícala bajo un selector claro (uno por fuente de envío).
• Verifica que cada una de tus plataformas de envío firma bien en DKIM: Google y Microsoft lo activan en unos clics, pero las herramientas de terceros lo olvidan a menudo.
• Planifica una rotación regular vía un segundo selector, sin cortar nunca el flujo.
• Corona el conjunto con DMARC para exigir la alineación y cerrar la puerta a la suplantación.

¿No te apetece adivinar en qué punto estás? Lanza una verificación gratuita e instantánea de tu configuración SPF, DKIM y DMARC con nuestro analizador DMARC gratuito: te muestra tus selectores detectados, el tamaño de tus claves y una nota clara. Después deja que Thomas, tu CISO virtual, te diga exactamente qué corregir y en qué orden.

Analiza tu dominio gratis → o crea una cuenta y deja que Thomas se ocupe del resto.