Cómo rotar claves DKIM con selectores nuevos sin perder firma válida

Aprende a rotar tu clave DKIM con un nuevo selector sin interrumpir envíos: convivencia de claves, ventana de propagación y validación con dig.

Las claves DKIM no caducan formalmente, pero conviene rotarlas cada cierto tiempo. Una clave que lleva años en producción se vuelve más fácil de comprometer si se filtra desde un backup, un servidor legacy o un proveedor que se da de baja. La rotación es un mantenimiento que casi nadie hace y, cuando se hace mal, deja a un dominio sin firma válida durante días. Esta guía explica cómo rotar la firma DKIM en producción sin perder envíos, cómo gestionar selectores en paralelo y cómo verificar que el cambio funciona en cada etapa.

Por qué rotar la clave DKIM

La firma DKIM se basa en un par de claves asimétricas: la privada vive en el servidor que envía, la pública se publica en el DNS bajo un selector concreto. Una vez configurada, todo funciona; pero si esa clave se filtra (un volcado de configuración, un proveedor que no aplicó bien permisos, una clave subida a un repositorio público), un atacante podría firmar correo en nombre de tu dominio.

Razones reales para rotar:

• Has cambiado de proveedor de envío y la clave antigua sigue colgando del DNS.
• Sospechas o detectas exposición de la clave privada.
• Vienes de claves de 1024 bits y quieres pasar a 2048.
• Tienes una política interna de rotación periódica (cada 6, 12 o 24 meses).
• Has consolidado múltiples remitentes en una sola plataforma y quieres limpiar selectores antiguos.

Si tu dominio está en una política DMARC en quarantine o reject, una rotación mal hecha puede generar una caída brusca de entregabilidad. Por eso conviene operar siempre con dos selectores en paralelo durante la transición.

El concepto de selector y por qué facilita la rotación

DKIM usa el campo s= en la cabecera DKIM-Signature del email para indicar qué selector se ha usado para firmar. El receptor consulta <selector>._domainkey.tudominio.com y obtiene la clave pública que tiene que validar la firma.

Esto significa que en el mismo dominio puedes tener varias claves DKIM activas a la vez, cada una con su selector. Esa es la base de una rotación segura: añades el selector nuevo, sirves nuevos envíos firmando con él, dejas el antiguo en DNS hasta confirmar que ya no se firma nada con él, y solo entonces lo retiras.

Selectores típicos: mail, default, s1, selector1, google, mailo, k1. Cuando rotas, conviene usar nombres con fecha o iteración (s2026a, s2026b) para dejar trazabilidad. No es estándar pero ayuda en operación.

Plan de rotación en 5 pasos

1. Genera el nuevo par de claves

La generación se hace en tu proveedor (Workspace, SES, Postmark, Brevo, MTA propio, etc.). Pide:

• Algoritmo rsa-sha256.
• Tamaño 2048 bits (huye de 1024 si todavía lo tienes; abordamos esa migración en otra guía).
• Selector nuevo, distinto del actual.

Algunos proveedores generan la clave por ti y solo te dan el TXT a publicar; otros (servidores propios con OpenDKIM, etc.) requieren generar el par localmente:

openssl genrsa -out s2026a.private 2048
openssl rsa -in s2026a.private -pubout -out s2026a.public

La privada queda solo en el servidor. La pública se transforma en el TXT que publicas.

2. Publica el TXT del selector nuevo en DNS

El registro vive en <selector>._domainkey.tudominio.com:

s2026a._domainkey.tudominio.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Comprobaciones:

• Una sola entidad, sin saltos de línea raros.
• TTL bajo durante la fase de rotación (300-600 segundos), para poder revertir rápido si algo sale mal.
• El TXT no debe partirse incorrectamente. Algunos paneles dividen valores largos en varias cadenas; está bien siempre que respeten el formato "parte1" "parte2" que DNS concatena en cliente.

3. Verifica la propagación antes de tocar el envío

Con dig:

dig +short TXT s2026a._domainkey.tudominio.com

Debes ver el TXT publicado. Prueba desde varios resolvers (1.1.1.1, 8.8.8.8) para descartar cachés:

dig @1.1.1.1 +short TXT s2026a._domainkey.tudominio.com
dig @8.8.8.8 +short TXT s2026a._domainkey.tudominio.com

Solo cuando el TXT esté visible globalmente puedes pasar al siguiente paso.

4. Cambia el selector activo en el sistema de envío

Aquí es donde varía según proveedor:

• En MTA propio (Postfix con OpenDKIM, Exim con dkim_selector), modifica la configuración para que firme con s2026a y recarga el servicio.
• En proveedores SaaS, marca el selector nuevo como activo. Algunos te permiten “preferir” el nuevo manteniendo el antiguo como fallback durante una ventana.
• En entornos con múltiples flujos (transaccional + marketing), aplica el cambio en cada uno por separado y monitoriza independientemente.

Tras el cambio, 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; ...

Confirma dkim=pass en Authentication-Results.

5. Mantén el selector antiguo en DNS durante un periodo de gracia

Aunque ya estés firmando con el nuevo, no borres el TXT antiguo de inmediato. Mantenerlo:

• Permite que mensajes ya en cola (en relays, en colas locales, en sistemas de reintentos) se validen contra el viejo si todavía fueron firmados con él.
• Cubre relays terciarios que pueden retrasar la entrega.
• Da espacio si necesitas hacer rollback.

Ventana razonable: entre 7 y 30 días, según volumen. Pasada la ventana y confirmado que ningún mensaje se firma con el antiguo, retira el TXT del DNS.

Convivencia de varios selectores

Es perfectamente válido tener s2026a._domainkey y s1._domainkey activos a la vez. El receptor valida contra el selector que aparezca en la cabecera DKIM-Signature. Lo que no debes hacer es publicar el mismo selector con valores distintos: provoca fallos intermitentes según el resolver que cachee qué versión.

Si tienes flujos separados (Workspace para corporativo, SES para transaccional, Mailchimp para marketing), cada uno usará su propio selector. La rotación se hace flujo a flujo, no a la vez.

Cómo afecta DMARC durante la rotación

Mientras los dos selectores son válidos, los reportes RUA de DMARC mostrarán pasadas para ambos. Cuando empieces a firmar solo con el nuevo, el viejo dejará de aparecer en los reportes; eso es la señal definitiva de que ya nadie depende de él.

Si tu DMARC está en reject y por error empiezas a firmar con un selector cuya pública aún no se ha propagado, los mensajes serán rechazados. Por eso el orden importa: primero TXT del nuevo selector, propagación, luego cambio de firma. Nunca al revés.

Errores frecuentes

Borrar el TXT antiguo antes de tiempo

Es el error más común. Resultado: cualquier mensaje firmado con el viejo selector que se valide tarde (relay diferido, retry) falla. Si el dominio está en DMARC reject, esos mensajes se descartan.

Generar la clave en local y olvidarla en producción

Si generas la clave en tu portátil pero el servidor de envío sigue firmando con la anterior, el receptor verá una firma inválida (la pública nueva no coincide con la privada que firma). Verifica siempre con un email de prueba antes de retirar el viejo.

Selector con caracteres no válidos

Los selectores deben ser etiquetas DNS válidas. Letras, números, guiones; no acentos, no espacios, no símbolos. Si lo nombras selector_2026, algunos resolvers lo aceptan y otros no.

TXT excedido en longitud

Las claves de 2048 bits superan los 255 caracteres por cadena que admite un TXT. La solución es publicar el valor partido en varias cadenas concatenadas. La mayoría de paneles lo gestionan, pero conviene verificar con dig que el resultado se lee correctamente.

TTL alto durante la rotación

Si tienes el TXT con TTL 86400, una corrección tardará un día en propagarse. Bájalo a 300-600 mientras dura la operación; súbelo después.

No comprobar varios resolvers

Tu propio resolver puede tener cacheado el viejo TXT y darte falsos positivos. Consulta desde resolvers públicos (1.1.1.1, 8.8.8.8, 9.9.9.9) antes de cambiar el envío.

Cómo validar que la rotación ha terminado

Pasados los días de gracia, comprueba:

• Reportes DMARC RUA: ningún mensaje legítimo aparece firmado con el selector viejo.
• Inspección manual de cabeceras en envíos recientes: solo aparece s=<nuevo>.
• Logs del MTA o del proveedor: no firma con el viejo.

Cuando los tres confirman, retira el TXT antiguo del DNS y sube de nuevo el TTL.

Buenas prácticas operativas

• Documenta cada rotación (fecha, selector antiguo, selector nuevo, persona responsable).
• Pon una alerta de calendario para la próxima rotación según tu política.
• Mantén las claves privadas fuera del repositorio: en un secret manager, no en .env versionado.
• Si tu proveedor permite “DKIM auto-rotation”, evalúa los pros y contras: simplifica la operación pero te quita visibilidad de cuándo cambia.
• Combina rotación con auditoría de reputación de dominio: si vas a tocar firma, aprovecha para revisar el resto de la pila (SPF, DKIM, DMARC).

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 retención y email marketing de Abalola para ecommerce: estrategia, producción y operación del stack sobre Klaviyo, Mailchimp o Brevo.