Migración de DKIM 1024 a 2048 bits: pasos, validación y errores típicos
Cómo migrar tu firma DKIM de claves RSA 1024 a 2048 bits: TXT particionado, selector de transición, validación dig y errores DNS comunes.
Las claves DKIM de 1024 bits se consideraron suficientes durante años, pero hoy son el mínimo absoluto que algunos receptores aceptan y otros ya empiezan a degradar. Migrar a 2048 bits es una tarea sencilla en teoría y delicada en la práctica, sobre todo porque un TXT de 2048 bits supera el límite de 255 caracteres por cadena de DNS y los paneles no siempre lo gestionan bien. Esta guía explica cuándo conviene migrar, cómo hacerlo sin parar envíos, y qué validar después.
Por qué seguir usando 1024 bits es un riesgo
RSA 1024 bits está computacionalmente al borde de lo razonable. Aunque todavía no es trivial romperlo, los grandes proveedores ya lo marcan como “weak” en señales internas. Resultados habituales de mantener 1024:
- Algunos receptores aplican
dkim=passcon anotación de clave débil; la firma valida pero no aporta el peso reputacional que aportaría 2048. - En auditorías de autenticación, 1024 aparece como hallazgo a corregir.
- Si combinas 1024 con DMARC laxo, las señales que sumas son menores que las que un atacante podría replicar.
Migrar a 2048 elimina ese ruido y te alinea con la recomendación de RFC 8301, que pide al menos 2048 bits.
El obstáculo real: el TXT troceado
Un registro TXT en DNS está limitado a 255 caracteres por cadena. Una clave RSA 1024 cabe en una cadena. Una clave RSA 2048 no: ronda los 380-400 caracteres una vez codificada en Base64 dentro del valor del TXT.
DNS resuelve esto permitiendo varias cadenas en un mismo registro, concatenadas por el resolver:
selector._domainkey IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
"...primeraParteSeguida..."
"...resto..." )Pero los paneles de DNS varían enormemente:
- Algunos aceptan que pegues el valor completo y lo trocean automáticamente.
- Otros requieren que tú metas las cadenas con comillas separadas.
- Otros tienen un campo de texto único que admite el valor sin trocear y lo gestionan ellos.
Si lo metes mal, el resolver leerá un TXT cortado y la firma fallará silenciosamente.
Plan de migración
1. Genera la clave 2048 bits
En proveedores SaaS (Workspace, SES, Postmark, Brevo) basta con regenerar DKIM y elegir 2048. Si ya está en 2048 por defecto, te dan el TXT y listo.
En MTA propio (OpenDKIM):
openssl genrsa -out /etc/opendkim/keys/tudominio.com/s2026.private 2048
openssl rsa -in /etc/opendkim/keys/tudominio.com/s2026.private -pubout -outform PEM -out s2026.publicConvertir la pública en formato TXT (sin cabecera/pie y todo en una línea):
grep -v -e "BEGIN" -e "END" s2026.public | tr -d '\n'Ese es el valor que va detrás de p=.
2. Usa un selector nuevo, no el mismo
Aprovecha la migración para introducir un selector con marca temporal (s2026a, mai2026, k2). Eso te permite tener 1024 y 2048 conviviendo sin tocar el TXT antiguo:
s1._domainkey (1024 bits, antiguo, sigue activo)
s2026a._domainkey (2048 bits, nuevo)La rotación entre ellos sigue las reglas habituales que cubrimos en la guía de rotación de claves DKIM.
3. Publica el TXT troceado correctamente
Dependiendo del panel, hay tres patrones:
Panel que admite valor único largo (Cloudflare, Route 53, la mayoría modernos): pega el valor completo “v=DKIM1; k=rsa; p=AQUI_LA_CLAVE_LARGA” sin más. Internamente lo guardan partido en cadenas de hasta 255.
Panel que pide cadenas separadas con comillas: introdúcelas así literalmente:
"v=DKIM1; k=rsa; p=MIIBIjANBgkq...primera_parte"
"resto_de_la_clave..."Sin espacios entre comillas y la siguiente cadena, salvo el necesario.
Panel limitado (algunos paneles antiguos): si tu panel cuenta caracteres y rechaza valores >255, hay que cambiar de panel o partir a mano usando la sintaxis BIND. Algunos proveedores te permiten editar la zona en formato BIND directamente.
4. Verifica con dig que el TXT se lee como una sola entidad
Comprueba primero la zona desde varios resolvers:
dig +short TXT s2026a._domainkey.tudominio.com
dig @1.1.1.1 +short TXT s2026a._domainkey.tudominio.com
dig @8.8.8.8 +short TXT s2026a._domainkey.tudominio.comdig +short te devuelve las cadenas con comillas separadas; eso es normal y correcto. Lo importante es que al concatenarlas obtengas un valor completo que empieza por v=DKIM1; k=rsa; p= y termina sin truncarse.
Para validar la clave en sí, puedes ver el largo aproximado:
dig +short TXT s2026a._domainkey.tudominio.com | tr -d '"' | tr -d ' 'Si esperabas 2048 bits y la cadena es muy corta, algo se truncó.
5. Activa la firma con el nuevo selector
En el sistema de envío:
- En MTA propio, modifica
KeyTableySigningTablede OpenDKIM para apuntar al nuevo selector y recarga. - En SaaS, marca el nuevo DKIM como activo o “primary”.
Envía un email de prueba a una cuenta tuya. En “Mostrar original” busca:
DKIM-Signature: v=1; a=rsa-sha256; d=tudominio.com; s=s2026a; ...
Authentication-Results: ...; dkim=pass header.d=tudominio.com header.s=s2026aSi dkim=pass con el nuevo selector, la migración técnica está hecha.
6. Mantén el viejo en convivencia y luego retíralo
Como en cualquier rotación, deja el TXT de 1024 bits publicado mientras pueda haber mensajes firmados con él en cola o en relays. Pasados 7-30 días según volumen, retíralo.
Validación adicional
Email a tu propia cuenta y “Mostrar original”
Es la prueba definitiva. Si Gmail dice dkim=pass y la cabecera muestra el nuevo selector, la firma 2048 funciona.
Reportes DMARC RUA
Tras unos días, los reportes mostrarán pasadas DKIM contra el nuevo selector. Si ves fallos donde antes había éxitos, reabre el caso: probablemente el TXT está truncado en algún resolver.
Tester específico de DKIM
Hay herramientas externas que te muestran la clave pública decodificada y su tamaño. Útiles para confirmar que el TXT se reconstruye correctamente sin tener que firmar y validar tú mismo.
Errores frecuentes
TXT troceado mal con espacios o saltos de línea
Si entre las dos cadenas hay un espacio o el panel guarda mal las comillas, la concatenación produce basura. La firma falla intermitentemente porque algunos resolvers son más laxos que otros.
Cambiar la clave manteniendo el mismo selector
Si reutilizas default._domainkey y reemplazas el TXT viejo por uno nuevo, durante la propagación habrá receptores que aún tengan en caché el TXT viejo. Cualquier mensaje firmado en ese intervalo con la nueva privada fallará en esos receptores. La solución correcta es selector nuevo siempre, no reutilización.
Esperar 1024 sea aceptado como antes
Aunque hoy mayoritariamente lo es, algunos receptores empezarán a tratarlo como señal débil y a degradar la confianza. Si tu volumen es relevante, no te quedes ahí.
Olvidar que algunos proveedores firman con su propio selector
Si usas Mailchimp, Brevo o similar, el selector es del proveedor (k1._domainkey.tudominio.com apuntando a sus servidores). El tamaño de clave depende de ellos. Asegúrate de que su DKIM también es 2048 si quieres una pila homogénea.
TTL alto durante la migración
Como en toda rotación, baja TTL del TXT a 300-600 mientras dura la operación. Te ahorra horas si tienes que rectificar.
Casos particulares
Microsoft 365 / Exchange Online
Microsoft 365 todavía configura por defecto claves más cortas en algunos tenants. Comprueba en el centro de seguridad si los selectores que tienes activos están a 2048 y, si no, regenera.
Google Workspace
Workspace permite generar claves DKIM de 1024 o 2048 desde el panel. Selecciona 2048 y publica el TXT que te da. Más detalles en la guía de Google Workspace.
MTA propio en producción intensa
Si tu MTA firma cientos de miles de mensajes/día, el coste de CPU adicional al firmar 2048 vs 1024 es mínimo en máquinas modernas. No es excusa para no migrar.
Mantenimiento posterior
Una vez en 2048, anota la fecha y planifica la próxima rotación dentro de 12-24 meses según tu política. Aprovecha para revisar la pila completa: SPF, DKIM, DMARC alineado, reputación limpia, y, si aplica, BIMI con su VMC.
Recursos relacionados
Si quieres profundizar, prueba estas herramientas gratuitas: Domain Health, mail tester, validador SPF y validador DMARC.
¿Necesitas que alguien lleve tu canal de email entero? Abalola Mail es la agencia de email marketing especializada en ecommerce de Abalola para ecommerce: estrategia, producción y operación del stack sobre Klaviyo, Mailchimp o Brevo.