La rotación de claves DKIM consiste en reemplazar el par de claves que firma su correo, según un calendario o tras una preocupación de seguridad, sin romper la autenticación. Parece arriesgado porque un paso en falso hace que el correo legítimo falle, pero el diseño de DKIM lo vuelve sencillo: los selectores le permiten publicar una clave nueva junto a la antigua, cambiar la firma y retirar la antigua más tarde. Esta guía explica cómo funciona y ofrece un plan paso a paso.
Cómo funcionan la firma DKIM y los selectores
Cuando su plataforma envía un mensaje, crea una firma con una clave privada y la añade a los encabezados. La firma nombra el dominio firmante, escrito d=, y un selector, escrito s=. Un receptor construye un nombre DNS a partir de ellos, selector._domainkey.dominio, obtiene la clave pública publicada allí y comprueba la firma. Si la clave coincide y las partes firmadas del mensaje no han cambiado, DKIM pasa.
DKIM-Signature: v=1; a=rsa-sha256; d=mail.example.com; s=2026a;
h=from:to:subject:date:message-id; bh=...; b=...En este ejemplo el selector es 2026a, así que el receptor consulta 2026a._domainkey.mail.example.com. Como el selector es solo una etiqueta que usted elige, puede publicar varios a la vez. Ese es todo el truco de la rotación: el selector antiguo sigue verificando el correo antiguo mientras el selector nuevo firma el correo nuevo.
Por qué rotar
- Limitar la exposición. Una clave privada que existe desde hace años ha sido vista por más sistemas y personas. La rotación limita el valor de cualquier filtración pasada.
- Responder a cambios de personal. Si un administrador que tenía acceso a la clave se va, reemplazarla elimina un riesgo latente.
- Pasar a claves más fuertes. Muchos dominios antiguos aún publican claves de 1024 bits. La rotación es el momento natural para mejorar.
- Cumplir la política. Las revisiones de seguridad y algunos cuestionarios de clientes preguntan con qué frecuencia cambian las claves.
- Mantener el proceso practicado. Un equipo que rota dos veces al año gestiona con calma una rotación de emergencia.
La rotación no es una herramienta de entregabilidad. Cambiar las claves no mejora por sí solo la ubicación en la bandeja de entrada. Su finalidad es la seguridad y la higiene. Hágalo con cuidado para no perjudicar la entrega, y no espere un aumento de reputación.
Elegir la longitud de clave
El estándar DKIM fija 1024 bits como mínimo para los firmantes y recomienda 2048 bits. Los verificadores no están obligados a aceptar nada por debajo de 1024 bits. Para la mayoría de los remitentes, la opción sensata hoy es RSA de 2048 bits, que da un margen cómodo sin un gran costo de rendimiento.
| Longitud de clave | Situación | Nota práctica |
|---|---|---|
| 512 bits | No aceptable | Se considera rota y los receptores modernos la rechazan |
| 1024 bits | Mínimo permitido, aún común | Funciona, pero actualice en la próxima rotación |
| 2048 bits | Recomendada | Requiere un valor TXT dividido en varias cadenas o un CNAME |
| 4096 bits | Permitida por el estándar | Rara vez necesaria, y el registro puede superar los límites prácticos de tamaño del DNS |
El límite de 255 caracteres
Una sola cadena de un registro TXT puede contener como máximo 255 caracteres, y una clave pública de 2048 bits es más larga. Por eso el registro contiene varias cadenas entre comillas, que el receptor une. La mayoría de los proveedores de DNS lo gestionan cuando pega un valor largo. Si el suyo no lo hace, divídalo manualmente o pida a su plataforma de envío una opción de CNAME.
2026a._domainkey.mail.example.com. TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."
"...rest of the public key..." )Antes de empezar: dos modelos de gestión de claves
| Modelo | Cómo funciona | Qué hace usted para rotar |
|---|---|---|
| Gestionado por la plataforma (CNAME) | Usted publica un CNAME de su selector a un nombre que controla la plataforma, y esta cambia la clave detrás | Poco o nada; confirme el calendario y que el CNAME se mantiene |
| Gestionado por el cliente (TXT) | Usted publica la clave pública, y la plataforma firma con la clave privada que usted proporcionó o que ella generó | Siga el plan completo que se describe a continuación |
| Firma autoalojada | Su propio servidor de correo firma, y usted conserva la clave privada | Genere las claves, actualice la configuración del servidor y el DNS |
Un plan de rotación seguro
- Inventaríe los selectores. Liste todos los selectores publicados bajo _domainkey para el dominio e identifique qué sistema usa cada uno. Los selectores desconocidos son un hallazgo en sí mismos; no los elimine hasta saber qué firma con ellos.
- Elija un esquema de nombres. Use selectores que incluyan una fecha o una secuencia, como 2026a y 2027a, para distinguir las claves de un vistazo.
- Genere la nueva clave. Cree un par de claves de 2048 bits, o pida a su plataforma que emita uno. Guarde la clave privada solo donde la necesite el sistema de firma.
- Publique la nueva clave pública. Añada el registro del nuevo selector. No toque el antiguo. Confirme que resuelve desde fuera de su red.
- Pruebe antes de cambiar. Firme un mensaje de prueba con el nuevo selector y confirme que DKIM pasa en los encabezados recibidos.
- Cambie la firma. Modifique la configuración de firma para usar el nuevo selector en todos los mensajes nuevos. A partir de este momento la clave antigua no firma nada nuevo.
- Monitoree. Vigile los informes agregados de DMARC y los datos de rebotes en busca de un aumento de fallos DKIM durante los días siguientes.
- Espere a los rezagados. Mantenga publicado el registro antiguo durante al menos varios días. Los mensajes en cola, reintentados o reenviados se verifican cuando se procesan, no cuando se envían.
- Retire la clave antigua. Elimine el registro del selector antiguo y borre la clave privada antigua de todos los sistemas que la tuvieran.
- Registre la rotación. Anote en su manual operativo la fecha, el nuevo selector y la fecha de la próxima rotación.
Cuánto tiempo conservar la clave antigua
La clave pública antigua debe permanecer en el DNS hasta que ningún correo firmado con ella pueda seguir en tránsito o esperando verificación. Para el correo transaccional y de marketing habitual, bastan unos pocos días. Si envía a través de listas de correo o servicios de reenvío que retienen mensajes, o si su calendario de reintentos es largo, espere más. Mantener publicada una clave antigua un poco de más no cuesta nada. Eliminarla demasiado pronto causa fallos difíciles de diagnosticar.
Qué puede salir mal y cómo detectarlo
| Problema | Señal | Solución |
|---|---|---|
| Selector que no coincide | DKIM falla con clave no encontrada | Compare el valor s= de la firma con el nombre DNS |
| Clave pública truncada | DKIM falla con clave incorrecta o firma que no coincide | Vuelva a pegar la clave y compruebe que están todas las partes de la cadena |
| Clave antigua eliminada demasiado pronto | Fallos solo en el correo retrasado | Restaure el registro antiguo y espere más la próxima vez |
| Firma no cambiada | El nuevo selector nunca aparece en los encabezados | Revise la configuración de firma y cualquier ajuste en caché |
| Dos sistemas comparten un selector | Fallos intermitentes después de que un sistema rota | Dé a cada sistema su propio selector |
| CNAME eliminado durante la limpieza | DKIM falla de repente en todas partes con una clave gestionada por la plataforma | Restaure el CNAME exactamente como se le proporcionó |
Use los informes para confirmar el éxito
Los informes agregados de DMARC muestran, por cada fuente de envío, cuántos mensajes pasaron o fallaron DKIM y SPF. Revíselos en los días posteriores a la rotación. Una rotación limpia muestra que aparece el nuevo selector y que el número de fallos se mantiene estable. Si los fallos aumentan en una fuente, probablemente sigue firmando con una clave que ya no está publicada. Nuestra guía sobre los informes agregados de DMARC explica cómo leerlos.
Rotación de emergencia
Si sospecha que una clave privada ha quedado expuesta, rote de inmediato y acorte el solapamiento. Publique y cambie a una clave nueva tan rápido como pueda hacerlo con seguridad, y luego elimine la clave comprometida aunque algún correo retrasado pueda fallar. Un atacante con la clave privada antigua podría firmar correo falsificado que pase DKIM para su dominio mientras la clave pública siga publicada, así que la ventana de exposición importa más que la pérdida de unos pocos mensajes retrasados. Un DMARC aplicado y una política de rechazo limitan lo que pueden hacer esas falsificaciones, pero la clave debe retirarse igualmente pronto.
Haga que la rotación sea rutina
- Ponga la fecha de rotación en un calendario compartido, con un responsable designado.
- Mantenga una tabla de selectores, los sistemas que los usan y sus fechas de creación.
- Use un selector exclusivo para cada sistema de envío.
- Configure alertas sobre las tasas de fallo de DKIM, para detectar una mala rotación en cuestión de horas.
- Practique primero en un subdominio de bajo riesgo si el proceso es nuevo para su equipo.
¿Necesita ayuda para planificar una rotación? Díganos qué dominios y sistemas de envío utiliza y le sugeriremos un orden seguro.
Lecturas adicionales y fuentes
Preguntas frecuentes
¿Qué es un selector DKIM?
Un selector es una etiqueta que indica a los receptores qué clave pública deben obtener. La firma nombra un selector y un dominio, y el receptor consulta un registro DNS en selector._domainkey.dominio. Como el selector forma parte del nombre, un mismo dominio puede publicar muchas claves a la vez, y eso es lo que hace segura la rotación.
¿Con qué frecuencia debo rotar las claves DKIM?
No hay un intervalo único obligatorio. Muchas organizaciones rotan una o dos veces al año, o cuando se va alguien con acceso a la clave privada o se sospecha un compromiso. Elija un calendario que realmente vaya a cumplir, y rote antes si alguna vez sospecha que una clave ha quedado expuesta.
¿Qué longitud de clave DKIM debo usar?
Use RSA de 2048 bits siempre que su proveedor de DNS y su sistema de envío lo admitan. El estándar DKIM exige a los firmantes usar al menos 1024 bits y recomienda 2048, y los verificadores no deben aceptar claves de menos de 1024 bits. Las claves más largas dan más margen a medida que crece la potencia de cálculo.
¿Por qué mi proveedor de DNS rechaza mi clave de 2048 bits?
Una clave pública de 2048 bits supera los 255 caracteres, que es el límite de una sola cadena en un registro TXT. Debe dividirse en varias cadenas entre comillas que el receptor une. Muchos proveedores la dividen automáticamente; si el suyo no lo hace, divídala a mano o use un CNAME hacia el registro alojado en la plataforma.
¿Puedo borrar la clave antigua justo después de cambiar?
No de forma segura. Los mensajes pueden retrasarse en las colas o reintentarse durante días, y los receptores verifican la firma cuando procesan el mensaje. Mantenga publicado el registro antiguo durante al menos varios días, y más tiempo si envía a través de rutas de reenvío lentas.
¿Qué ocurre si elimino una clave que sigue en uso?
Los mensajes firmados con ese selector fallan la verificación DKIM. Si el SPF está alineado, DMARC aún puede pasar, pero si el SPF no está alineado, el mensaje puede ponerse en cuarentena o rechazarse con una política DMARC aplicada. Por eso primero se cambia la firma y la clave antigua se elimina después.
¿Mi plataforma de envío rota las claves por mí?
Algunas plataformas gestionan las claves DKIM y las publican mediante un CNAME que usted apunta una sola vez, de modo que la rotación ocurre de su lado. Otras le dan un registro estático que usted debe reemplazar. Compruebe qué modelo usa su plataforma antes de planificar una rotación.
¿Deben los distintos flujos de correo usar selectores diferentes?
Sí, es una buena práctica. Tener selectores separados para el correo transaccional, el de marketing y los sistemas internos facilita rotar o revocar uno sin afectar a los demás, y hace más clara la revisión de los encabezados.
¿Puedo probar una clave antes de cambiar a ella?
Sí. Publique primero el registro nuevo, confirme que resuelve, y luego envíe mensajes de prueba firmados con el selector nuevo a un buzón que controle y compruebe en los encabezados que DKIM pasa antes de cambiar todo el tráfico.