Clave DKIM: longitud recomendada, publicación y rotación

Tu clave DKIM es una pieza de autenticación publicada en el DNS cuyo estado puede influir en la entrega. Si es débil, está mal formada o queda obsoleta, los receptores pueden dejar de validar las firmas. Esto importa especialmente por los requisitos de autenticación de Gmail introducidos en febrero de 2024 y el refuerzo de su aplicación anunciado desde noviembre de 2025; consulta las condiciones vigentes. Si todavía estás revisando el DNS básico, empieza por correo empresarial y vuelve después.

La respuesta breve: usa una clave DKIM RSA de 2048 bits cuando se admita. Publícala correctamente en el DNS, lo que suele requerir dividir el TXT en varias cadenas entre comillas. Rótala de forma programada con selectores. En una rotación ordinaria, conserva el selector anterior unos días después del cambio para los mensajes en tránsito. Es un procedimiento prudente, no una garantía de entrega.

Si configuras un dominio nuevo, consulta también crear correo con tu dominio y los registros DNS necesarios de TrekMail para preparar DKIM, SPF y DMARC conjuntamente.

¿Qué es una clave DKIM?

En este contexto, es la parte pública de la configuración de firma DKIM. El servidor firma el correo saliente con la clave privada y el receptor obtiene la clave pública del DNS para verificar los datos firmados y la responsabilidad del dominio firmante. No acredita por sí sola la identidad personal ni la fiabilidad del From visible.

DKIM significa DomainKeys Identified Mail. La clave privada permanece en el sistema de envío y la pública se publica bajo un selector, normalmente con un nombre como s1._domainkey.example.com.

Al recibir un mensaje, el servidor examina la firma DKIM de las cabeceras, busca la clave pública en el DNS y la valida. Si pasa, obtiene dos señales:

• El cuerpo y las cabeceras firmadas conservan su integridad según las reglas de canonicalización de la firma.
• La firma se generó con acceso a la clave privada correspondiente a ese dominio y selector.

Esto no garantiza la llegada a la bandeja de entrada. Aporta una señal criptográfica verificable que los filtros pueden tener en cuenta.

¿Qué longitud de clave DKIM conviene usar?

Usa una clave RSA de 2048 bits como opción recomendada para DKIM en 2025 y 2026. El mínimo del estándar todavía permite RSA de 1024 bits, pero la recomendación práctica es 2048 bits: ofrece mayor resistencia con menos dificultades de tamaño DNS y compatibilidad que pueden presentar las claves de 4096 bits.

El RFC 8301 establece que los firmantes deben usar claves RSA de al menos 1024 bits y deberían utilizar al menos 2048 bits. Ese «deberían» expresa una recomendación técnica importante.

Si heredas una infraestructura antigua, no des por correcta la clave DKIM. Muchos paneles y sistemas generaban por defecto claves de 1024 bits. Aunque se usaran antes, conviene revisar y actualizar esa elección.

La documentación de Google muestra la importancia operativa. Gmail exige DKIM para remitentes masivos y su FAQ explica posibles límites de envío cuando falla la autenticación. Consulta las preguntas frecuentes sobre las directrices de Google para remitentes.

Por qué una clave DKIM de 2048 bits puede fallar en el DNS

Una clave DKIM de 2048 bits puede dar problemas porque cada cadena TXT DNS tiene un máximo de 255 octetos por fragmento entre comillas. La clave pública completa supera ese tamaño. Si el panel espera un único valor largo, puede rechazarlo, truncarlo o guardarlo incorrectamente.

Esto suele confundir: el problema no está necesariamente en la criptografía, sino en la interfaz DNS.

El valor público de p= para una clave RSA DKIM de 2048 bits puede requerir varias cadenas entre comillas dentro de un único registro TXT. El verificador DKIM o la aplicación que consume el registro concatena esas cadenas; no hay que confiar en que el resolutor DNS lo haga automáticamente. Si el valor almacenado es incorrecto, la validación puede fallar.

Fallos habituales:

• El panel recorta el registro a 255 caracteres de un byte.
• Añade espacios o saltos de línea dentro de la clave.
• Publicas varios TXT separados en vez de un TXT con varias cadenas entre comillas.
• Eliminas parte del prefijo v=DKIM1; k=rsa; p= al intentar acortarlo.

El resultado no es una clave más débil, sino una clave que puede no verificarse.

Cómo publicar correctamente una clave DKIM de 2048 bits

Publica un único TXT por selector y divide el valor largo solo en cadenas dentro de ese registro. El verificador receptor las concatena. Mantén la sintaxis correcta y comprueba después la respuesta DNS exacta desde la línea de comandos.

Sintaxis de archivo de zona:

s1._domainkey.example.com. IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."
  "...rest_of_the_public_key_here...QAB"
)

Muchas interfaces web requieren ese mismo registro en una línea:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..." "...rest_of_the_public_key_here...QAB"

Compruébalo desde fuera. No te fíes solo de la vista previa.

dig txt s1._domainkey.example.com +short

Busca una respuesta TXT completa. Dos cadenas entre comillas son normales si pertenecen al mismo registro. Fragmentos ausentes, escapes extraños o un resultado parcial requieren investigar tanto el registro publicado como la herramienta de consulta.

Con TrekMail, consulta SMTP gestionado de TrekMail y el asistente DNS. Según el plan vigente, puedes usar SMTP gestionado y obtener en el panel el valor del registro DKIM del dominio. La oferta descrita presenta Starter por $3.50 al mes y una prueba gratuita de 14 días con tarjeta para planes de pago. Nano se presenta como gratuito y usa SMTP externo; sus claves y selectores deben proceder del proveedor firmante. Comprueba las condiciones actuales.

Ejemplo conceptual: generas una clave DKIM de 2048 bits, la pegas en un registrador que trunca los TXT largos sin avisar y el correo sigue saliendo del servidor. El problema puede no verse hasta que Gmail detecta mensajes sin autenticación válida. Por eso conviene comprobar el DNS externamente.

Cómo rotar una clave DKIM reduciendo el riesgo de interrupciones

En una rotación ordinaria, añade un selector nuevo, publica su clave, cambia la firma y conserva temporalmente el anterior. Evita sobrescribir la clave activa. Los selectores distintos reducen los fallos de mensajes retrasados o reintentados. Si hay una posible filtración, la revocación inmediata puede tener prioridad sobre el periodo de transición.

Procedimiento prudente para una rotación programada:

1. Genera un par DKIM nuevo de 2048 bits.
2. Asígnale un selector nuevo, como s2.
3. Publica s2._domainkey.example.com en el DNS.
4. Cambia la configuración de firma a s2.
5. Conserva s1 publicado durante varios días, según tus colas y políticas.
6. Retira s1 cuando los mensajes firmados con él ya no estén en tránsito.

Un ejemplo de margen son 7 días. Puede cubrir retrasos, reintentos y cachés habituales, pero no es un plazo universal: ajústalo al entorno y al motivo de la rotación.

No sustituyas la clave bajo el mismo selector salvo que controles todos los casos de firma y tránsito o el proveedor lo requiera. La mayoría de los equipos no controla todos esos extremos. Usa los selectores para separar las claves.

Con varios sistemas de envío, documenta qué selector corresponde a cada uno. Es importante al investigar errores de un CRM, una plataforma de soporte, una aplicación y un proveedor de buzones que comparten dominio.

¿Cuándo rotar una clave DKIM?

Rótala según una política fija y también tras una exposición de la clave privada, un cambio de proveedor o una migración de envío. Una cadencia semestral puede servir como punto de partida para algunos equipos. Los entornos de mayor riesgo pueden necesitar otra frecuencia; una política previsible suele ser preferible a cambios improvisados.

Regla operativa: si la clave privada pudo filtrarse, sustitúyela y evalúa revocarla de inmediato. Si no hay incidencias, aplica igualmente la política de rotación.

Motivos para adelantarla:

• Cambiaste el proveedor de correo saliente.
• Retiraste a un proveedor que tenía acceso a la firma.
• Exportaste claves mediante un proceso inseguro.
• Encontraste una cuenta administrativa compartida antigua cuyo uso nadie puede explicar.

Motivos que no justifican aplazarla:

• «Lo haremos cuando tengamos tiempo».
• «La clave todavía pasa, así que está bien».
• «No recordamos dónde está la clave privada».

Con muchos dominios de clientes, esto se convierte en gestión operativa, no solo criptografía. Ahí cobra importancia el alojamiento de correo multidominio. Un dominio puede manejarse manualmente; cincuenta requieren un proceso.

¿Conviene usar Ed25519 para DKIM?

Ed25519 ofrece claves DKIM mucho más cortas y reduce las dificultades de longitud de TXT asociadas a RSA-2048. La contrapartida es la compatibilidad. El RFC 8463 lo normalizó para DKIM, pero RSA-2048 suele ser la opción más conservadora cuando buscas interoperabilidad amplia.

La ventaja operativa principal es el tamaño. La clave pública Ed25519 es pequeña frente a una RSA, por lo que publicarla suele ser más sencillo.

La desventaja es la variación del soporte. Algunos receptores y herramientas lo admiten bien; otros pueden no hacerlo. RSA-2048 también requiere comprobar compatibilidad, aunque es ampliamente utilizado. Si tu plataforma permite firma doble y conoces la ruta, puede tener sentido probar Ed25519 junto con RSA.

Para la mayoría de los operadores:

• Usa RSA-2048 como opción predeterminada.
• Considera Ed25519 si conoces la compatibilidad de los receptores y puedes probarla.
• No cambies a Ed25519 exclusivo solo porque el registro DNS sea más corto.

Enfoque anterior y nuevo: gestionar DKIM a escala

El enfoque anterior consiste en editar TXT manualmente, pegar claves grandes en distintos paneles y esperar que nadie olvide la rotación. El nuevo utiliza una gestión de DNS y firma repetible y, cuando corresponde, delegada: el ciclo de vida de las claves forma parte del proceso de correo.

Enfoque anterior:

• Cada dominio tiene una interfaz DNS diferente.
• La rotación depende de un recordatorio que puede ignorarse.
• Un error en un registrador puede afectar al correo de un cliente sin detectarse hasta que surgen problemas de entrega.

Enfoque nuevo:

• Un procedimiento común para muchos dominios.
• Firma gestionada con una configuración coherente.
• Menos trabajo repetitivo al diagnosticar TXT largos y cambios de autenticación.

TrekMail puede encajar en este modelo de alojamiento multidominio con tarifa fija en lugar de cargos por usuario. La oferta descrita incluye almacenamiento compartido, buzones IMAP, migración IMAP integrada, catch-all, reenvío, BYO SMTP en Nano y SMTP gestionado en planes de pago; comprueba las funciones actuales. Si gestionas reenvíos, revisa también la autenticación en esas rutas: reenviar correo de dominio a Gmail explica un caso relacionado.

Para equipos y agencias, la ventaja potencial no es un DNS «mágico», sino reducir errores repetitivos mediante un proceso centralizado. La oferta descrita de Starter parte de $3.50/mes; consulta los precios vigentes.

Conclusión sobre la clave DKIM

Como regla general, elige RSA-2048, publícala correctamente, verifica con consultas reales y rótala con selectores según una política. Si todavía usas 1024 bits, planifica la actualización cuando sea compatible. Si el panel daña los TXT largos, corrige el formato o utiliza un sistema que los gestione adecuadamente.

No consideres DKIM de forma aislada. Una clave verificable resulta más útil cuando SPF, DMARC y la infraestructura de envío también están bien configurados y alineados. Consulta los registros DNS necesarios de TrekMail y crear correo con tu dominio para revisar el conjunto.