DKIM 1024 o 2048 bits: qué tamaño de clave elegir
Por Thomas · CISO virtual · 2026-07-12
A la hora de generar una clave DKIM, una pregunta vuelve siempre: ¿1024 o 2048 bits? La respuesta de fondo es simple —2048 es la elección correcta hoy— pero viene acompañada de una trampa técnica que muchos descubren en el peor momento: una clave de 2048 bits es más larga, y su publicación en DNS puede tropezar con un límite poco conocido. Esta guía explica por qué apuntar a 2048, cómo evitar la trampa de los 255 caracteres, y cómo migrar una vieja clave de 1024 sin romper nada.
La respuesta corta: 2048 bits
Para un nuevo despliegue, 2048 bits es la opción correcta. Es el estándar recomendado hoy: una clave de 2048 es netamente más resistente a la fuerza bruta que una de 1024, considerada demasiado débil para los usos modernos. Los grandes proveedores de correo y las buenas prácticas de seguridad convergen en 2048 como base. Partiendo de cero, la cuestión está zanjada: 2048.
Por qué el 1024 tiene los días contados
El de 1024 bits no está «roto» en el sentido de que cualquiera pudiera forjar una firma mañana por la mañana. Pero su margen de seguridad se ha erosionado con la potencia de cálculo disponible, hasta el punto de que hoy se considera insuficiente para un secreto destinado a durar. Conservarlo es aceptar una clave cuya robustez no hace más que decrecer. Muchos dominios siguen funcionando en 1024 por herencia —una clave puesta hace años y nunca renovada. Es precisamente el tipo de deuda que una rotación de claves bien llevada viene a saldar.
La trampa del 2048: el límite DNS de los 255 caracteres
Esto es lo que sorprende al pasar a 2048. Una clave pública de 2048 bits, codificada, es larga —a menudo más de 255 caracteres. Ahora bien, un registro TXT DNS se compone de cadenas de las cuales cada una está limitada a 255 caracteres. Una clave de 2048 no cabe, por tanto, en una sola cadena: hay que partirla en varias cadenas dentro del mismo registro TXT.
En concreto, en lugar de un único valor largo, el registro se parece a:
selector._domainkey.ejemplo.es. IN TXT
( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
"...el resto de la clave en una segunda cadena entre comillas..." )
Las dos cadenas entre comillas son concatenadas por el resolver para reconstituir la clave. Es una particularidad de la sintaxis DNS, no una opción: pegar una clave de 2048 de un bloque en una interfaz que solo acepta una cadena produce o bien un error, o bien una clave truncada —y la firma falla. La mayoría de los alojadores DNS gestionan este particionado automáticamente, pero algunas interfaces exigen hacerlo a mano.
¿Y el 4096 bits?
Si 2048 está bien, ¿por qué no 4096 para estar «aún más seguro»? En la práctica, el 4096 rara vez se recomienda para DKIM: la clave se vuelve muy larga (varias cadenas, registros DNS voluminosos), algunas implementaciones la gestionan mal, y la ganancia real de seguridad frente a 2048 no lo justifica para la firma de correos. El consenso sigue siendo 2048 bits: el mejor compromiso entre robustez y compatibilidad. El 4096 queda reservado a casos muy particulares, con conocimiento de causa.
Cómo conocer el tamaño de la clave actual
Antes de migrar, conviene saber de dónde se parte. La clave pública se recupera en DNS (dig TXT selector._domainkey.ejemplo.es) y de ahí se deduce el tamaño; más simple aún, un paso por nuestro analizador gratuito lee la clave DKIM actual e indica si está en 1024 o 2048. Una vieja clave de 1024 que aparezca así no es una urgencia ardiente, pero sí un buen candidato para la próxima rotación.
Migrar del 1024 al 2048 sin romper nada
Pasar de 1024 a 2048 no es una operación aparte: es una rotación de clave normal, con un nuevo tamaño. La secuencia es la del doble selector:
- Generar una nueva clave de 2048 bajo un nuevo selector y publicar su clave pública (gestionando el particionado en cadenas si es necesario).
- Verificar que la nueva clave pública está completa y visible en DNS.
- Cambiar la firma del lado de la plataforma al nuevo selector.
- Vigilar los informes agregados: las nuevas firmas de 2048 deben pasar y alinearse.
- Retirar el antiguo selector de 1024 al cabo de unos días.
Todo se detalla en la rotación de claves. El único punto de atención específico del 2048 es la publicación DNS correcta de la clave más larga.
Cuando varias plataformas firman para un mismo dominio —el correo corporativo, una herramienta de marketing, un relé transaccional— cada una tiene su propio selector y su propia clave: la migración se lleva, por tanto, plataforma por plataforma, no de un bloque. Y en la práctica es una buena noticia: se moderniza una fuente cada vez, empezando por la que envía mayor volumen, y cada cambio sigue siendo reversible independientemente de los demás. No hay un día D en el que todo debe cambiar a la vez; una clave de 1024 que subsiste en una fuente menor no fragiliza en nada las claves de 2048 ya desplegadas en otros sitios —simplemente se queda en la lista de cosas por tratar en la próxima rotación.
Publicar una clave de 2048, paso a paso
La dificultad del 2048 no es criptográfica, es puramente práctica: la clave es demasiado larga para una sola cadena TXT. El procedimiento varía según el alojador DNS. Cuando la interfaz acepta un valor largo y gestiona sola el particionado (caso de la mayoría de los alojadores modernos), basta con pegar la clave tal cual: la interfaz inserta las comillas de separación en su lugar. Cuando exige cadenas de 255 caracteres máximo, hay que partir la clave en segmentos y rodear cada uno de comillas, que el resolver los recompondrá. En caso de duda, se publica y se verifica de inmediato con dig TXT selector._domainkey.ejemplo.es: la clave debe volver entera, reconstituida, sin corte ni carácter parásito. La vista previa de la interfaz no es fiable; lo que cuenta es lo que el DNS devuelve realmente. Una prueba de firma sobre un mensaje real confirma después que la clave publicada corresponde bien a la clave privada que firma.
Un poco de contexto: por qué el tamaño importa
El tamaño de una clave RSA mide, simplificando, la dificultad de «romperla» por cálculo. Una clave de 1024 bits ofrecía un margen cómodo hace quince años; la potencia de cálculo ha progresado tanto desde entonces que ese margen se ha reducido, y los organismos de estandarización han subido el listón a 2048 para los secretos destinados a durar. DKIM no escapa a esta lógica: una firma se supone que prueba el origen de un mensaje de forma fiable, lo que presupone una clave que un atacante no pueda reproducir. Conservar el 1024 por inercia es dejar que esa garantía se erosione sin darse cuenta. A la inversa, sobredimensionar en 4096 no aporta una garantía proporcional para el correo y complica la publicación —de ahí el consenso en 2048, el punto de equilibrio entre robustez real y compatibilidad universal. La regla práctica se resume así: 2048 por defecto, 1024 a reemplazar, 4096 solo si una exigencia precisa lo justifica.
Preguntas frecuentes
¿Es peligroso usar el 1024 hoy? No inmediatamente peligroso, pero debilitado y desaconsejado a largo plazo. Es una deuda a saldar en la próxima rotación, no una urgencia que tratar esta noche.
¿Por qué mi clave de 2048 no "cabe" en mi DNS? Porque supera los 255 caracteres y debe partirse en varias cadenas dentro del mismo registro TXT. Muchas interfaces lo hacen solas; algunas exigen insertar a mano las comillas de separación.
¿Hay que apuntar a 4096 para más seguridad? No, en general. 2048 es el estándar; 4096 recarga el registro y plantea problemas de compatibilidad sin un beneficio a la altura para DKIM.
¿Mi plataforma elige el tamaño por mí? A menudo, sí. Microsoft 365, Google Workspace y la mayoría de los SaaS generan claves de 2048 por defecto. La verificación sigue mereciendo la pena, sobre todo en cuentas antiguas configuradas hace tiempo.
¿Una clave más grande ralentiza el envío? El impacto sobre la firma y la verificación es insignificante. El único tema real del 2048 es la publicación DNS, no el rendimiento.
¿Cómo saber si mi clave está en 1024 o 2048 bits? Se recupera con dig TXT selector._domainkey.ejemplo.es y se mira el valor p=: una clave de 1024 bits se codifica en unos 216 caracteres en base64; una clave de 2048 bits en unos 392 caracteres. Nuestro analizador lo indica directamente.
Lo que el tamaño de clave no resuelve
Pasar de 1024 a 2048 es una buena decisión, pero el tamaño de clave no compensa un problema de alineación. Una clave de 2048 perfectamente publicada, con d= apuntando al dominio del proveedor en vez del dominio emisor, sigue sin contribuir a DMARC. Del mismo modo, una rotación cuidada no sirve de nada si la clave nunca se verifica tras la publicación —un carácter truncado y la firma falla en silencio hasta que un informe lo revela. El tamaño de clave es, por tanto, uno de los eslabones que cuidar, no el único —y desde luego no aquel por el que empezar. El buen orden: 1) asegurarse de que la clave está publicada y completa; 2) verificar que la firma se alinea con el dominio; 3) apuntar a 2048 bits (o migrar a ellos en la próxima rotación); 4) rotar con regularidad. Cada etapa se construye sobre la anterior; el tamaño es la tercera, no la primera.
Thomas verifica las claves
Conocer el tamaño de cada clave DKIM, detectar una vieja 1024 olvidada, publicar una 2048 sin truncarla: otros tantos detalles fáciles de fallar. Thomas, el CISO virtual, lee el tamaño de las claves actuales, señala las que hay que modernizar, y guía la publicación de una clave de 2048 correcta, particionado DNS incluido.
Analizar un dominio gratis o crear una cuenta para tener claves DKIM del tamaño adecuado.
Aplicar DMARC, en la práctica
Thomas, el CISO virtual de DMARC.com, identifica cada fuente de envío legítima, escribe los registros DNS exactos y lleva un dominio de p=none a p=reject — sin romper su correo.
Alcanzar p=reject — gratisGuías relacionadas
- Cómo verificar la firma DKIM de un email
Verificar una firma DKIM consiste en leer la cabecera DKIM-Signature y el resultado Authentication-Results, y después confirmar la alineación. Los métodos, las etiquetas clave y por qué una firma falla.
- Rotación de claves DKIM: por qué, cuándo y cómo (sin romper nada)
Rotar regularmente las claves DKIM limita el impacto de una fuga. El método correcto (doble selector), la frecuencia, la trampa de la retirada prematura, y dónde almacenar las claves privadas.
- Cómo generar una clave DKIM (y publicar la correcta)
Generar una clave DKIM es crear un par clave privada / clave pública, mantener una en secreto y publicar la otra en DNS. Los pasos, la elección del tamaño y la trampa de la alineación.
Sobre el autor
Thomas — Thomas es el CISO virtual de DMARC.com: un copiloto especializado en la autenticación de correo que acompaña a las organizaciones de p=none hasta p=reject, sin romper su correo. Sus guías se basan en los datos reales del Observatorio DMARC y de los informes RUA analizados por la plataforma.
