Rotación de claves DKIM: cómo cambiar selectores sin romper cold email

DKIM agrega al mensaje una firma creada con una clave privada. El receptor toma de la firma el dominio d= y el selector s=, consulta la clave pública correspondiente en DNS y comprueba que el contenido firmado no cambió de una forma incompatible. Rotar significa introducir un par nuevo y dejar de usar el anterior sin crear una ventana en la que los mensajes ya no puedan validarse.

El selector es la pieza que permite esa transición. RFC 6376 divide el espacio de claves por selector para que un dominio pueda publicar varias claves simultáneamente. El estándar describe el patrón: anunciar la clave nueva junto con la anterior, empezar a firmar con el selector nuevo y retirar la clave vieja después del periodo en que mensajes anteriores todavía puedan estar en tránsito o pendientes de verificación.

No reemplaces el valor del selector existente con otra clave. El RFC advierte que reutilizar un selector vuelve imposible distinguir entre una firma antigua que ya no valida y un mensaje falsificado. La estrategia más clara es asignar una clave nueva a un selector nuevo y conservar evidencia de cuándo cambió el firmante.

Una clave DKIM puede quedar años detrás de un proveedor, una agencia o una cuenta administradora que ya cambió de dueño. El riesgo no aparece únicamente cuando alguien anuncia una filtración. También existe cuando nadie sabe quién generó la clave, qué servicio conserva la privada o qué dominios continúan firmando con ella.

La rotación reduce la vida útil de una credencial y prueba que el equipo puede cambiarla sin detener correo. También permite migrar longitud o proveedor y retirar accesos antiguos. No mejora por sí sola el copy, la reputación ni la llegada a la bandeja principal. Un resultado dkim=pass confirma que una firma validó para su dominio; no certifica que la lista sea correcta o que el mensaje merezca respuesta.

Para cold email, el impacto operativo es concreto. Si un selector desaparece antes de la transición, DMARC puede perder una de sus rutas de alineación. Si una plataforma firma con un dominio ajeno, DKIM puede pasar sin alinear con el From visible. Por eso la rotación debe comprobar mensajes reales de cada combinación de dominio, buzón y plataforma de envío, no solamente un TXT verde.

RFC 6376 explica que las claves pueden reemplazarse de forma regular y que su vida puede ser relativamente corta, pero no impone un calendario único de 30, 90 o 365 días. Google y Microsoft tampoco publican en las guías consultadas un mismo intervalo obligatorio para cualquier dominio. Copiar una frecuencia sin conocer quién administra la privada produce cumplimiento de calendario, no necesariamente control.

La recomendación de picos.Ai es definir una frecuencia basada en capacidad y riesgo, y añadir disparadores inmediatos: sospecha de exposición, salida de un proveedor, cambio de control administrativo, migración de plataforma, clave sin responsable, selector compartido fuera de política o algoritmo y longitud que ya no cumplen el estándar interno. Esta es una regla operativa propuesta, no un mandato atribuido a Google o al IETF.

El calendario solo sirve si cada rotación deja evidencia: dominio, selector anterior y nuevo, proveedor, tamaño de clave, responsable, fecha de publicación, inicio de firma, resultado de pruebas, periodo de convivencia y retiro. Si la tarea termina en “se cambió DNS”, el siguiente equipo volverá a empezar desde la incertidumbre.

Lista cada dominio y subdominio usado en From, cada proveedor que envía, el d= y s= observados en DKIM-Signature, el MAIL FROM, la alineación DMARC, el responsable y la última prueba. Separa correo corporativo, transaccional, marketing, soporte y outbound. Un dominio puede recibir firmas de Workspace, Microsoft 365 y una plataforma externa en mensajes distintos.

Obtén un mensaje original de cada flujo representativo. Guarda headers y resultado Authentication-Results. La firma visible muestra qué selector se usa hoy; DNS por sí solo puede contener claves antiguas que ya no participan. También registra si el proveedor administra la clave privada, si permite una clave propia o si expone CNAME hacia su infraestructura.

Confirma capacidad de reversión y TTL antes del cambio. Asigna una ventana con responsable de DNS, administrador de correo y operador de campaña. Pausa lanzamientos que puedan confundir la medición. Rotar durante una migración de plataforma de envío, un cambio de From y un aumento de volumen es una manera eficiente de perder causalidad.

En un sistema administrado por el propio equipo, genera el nuevo par de claves en un entorno controlado y asigna un selector nunca reutilizado. Publica la clave pública bajo selector-nuevo._domainkey.dominio y conserva el registro anterior. La clave privada no debe aparecer en tickets, prompts, repositorios ni capturas; solo el servicio firmante necesita acceso.

Espera a que el registro nuevo responda desde resolvers relevantes y valida tipo, nombre y valor. Después configura el firmante para usar la clave nueva. Envía pruebas autorizadas a cuentas controladas y confirma que DKIM-Signature contiene el nuevo s=, el d= esperado y un resultado dkim=pass. Comprueba también que DMARC pasa por una identidad alineada.

Mantén publicada la clave anterior durante la ventana de transición definida para mensajes en cola o aún no verificados. Cuando exista evidencia suficiente de que el selector nuevo firma los flujos previstos y el anterior dejó de aparecer en tráfico actual, retira o revoca el viejo según la arquitectura. El RFC no fija una espera universal: documenta la elección y no conviertas una estimación en estándar inexistente.

La guía de Google Workspace permite generar un registro nuevo desde Admin console → Gmail → Authenticate email. Google recomienda seleccionar una clave de 2048 bits cuando el proveedor DNS la soporta y permite elegir un prefijo de selector distinto si el nombre predeterminado ya está en uso. Cada dominio necesita su propia clave.

Google indica publicar primero el TXT y no pulsar Start authentication todavía. Tras guardar DNS, la autenticación puede tardar hasta 48 horas en empezar a funcionar. Después se activa desde la consola y se verifica con un mensaje enviado fuera de la organización, revisando el original. Esa espera documentada pertenece a Workspace; no debe copiarse como TTL universal para cualquier proveedor.

La consola de Google no presenta el mismo modelo operativo de dos CNAME alternos que Microsoft 365. Por eso sigue su flujo actual y prueba el selector que realmente aparece en los headers. Si una plataforma externa también firma, rota esa clave bajo el procedimiento del proveedor correspondiente; cambiar Workspace no renueva automáticamente todas las firmas del stack.

Microsoft 365 genera dos pares para DKIM de un dominio personalizado y publica sus claves mediante dos CNAME. Un selector está activo y el otro queda inactivo hasta una rotación. Microsoft advierte que los valores exactos deben obtenerse del portal de Defender o Exchange Online PowerShell; los ejemplos de documentación no deben copiarse como si fueran universales.

La rotación puede ejecutarse con Rotate-DkimSigningConfig. Microsoft documenta campos para inspeccionar KeyCreationTime, RotateOnDate y los selectores anterior y posterior. También indica que el cambio tarda cuatro días —96 horas— y que no puede iniciarse otra rotación mientras esa operación sigue en curso.

Si el cambio incluye pasar de 1024 a 2048 bits, Microsoft señala una particularidad: el nuevo tamaño aplica al siguiente selector activo en la primera rotación y al otro selector cuando vuelva a rotarse. Verifica ambos valores y no declares completada la migración de tamaño después de observar solo un mensaje firmado con una de las dos claves.

RFC 6376 exige al menos 1024 bits para claves RSA de larga duración y explica el tradeoff entre seguridad, costo y restricciones DNS. Google recomienda 2048 bits cuando el host de dominio los soporta. Eso justifica preferir 2048 en nuevas configuraciones compatibles; no justifica afirmar que cualquier mensaje con 1024 será rechazado automáticamente por todos los receptores.

El tamaño tampoco compensa custodia deficiente. Una clave de 2048 bits copiada en un repositorio público está peor controlada que una clave gestionada por un servicio con acceso restringido y rotación verificable. Registra quién controla la privada, cómo se autoriza al firmante y qué evento obliga a reemplazarla.

Evita generar claves en páginas aleatorias. Para Workspace y Microsoft 365 usa las funciones del proveedor. Para infraestructura propia, usa herramientas criptográficas aprobadas y almacenamiento de secretos adecuado. El público necesita la clave de DNS; nadie necesita que la privada viaje por Slack para “agilizar” el cambio.

Envía desde cada flujo a Gmail, Microsoft y otra cuenta controlada si forma parte de tu matriz habitual. Descarga el original. En DKIM-Signature registra d=, s=, algoritmo y canonicalización; en Authentication-Results registra dkim, header.d y header.s cuando estén disponibles. Confirma que el selector nuevo resuelve públicamente y que el cuerpo no fue modificado por una etapa posterior.

Revisa DMARC por separado. Un dkim=pass solo contribuye a DMARC si el dominio firmante se alinea con el From bajo la política correspondiente. SPF alineado puede mantener un DMARC pass durante una falla DKIM, pero no debe ocultar que la rotación salió mal. El objetivo es restaurar las dos capas previstas, no celebrar que una ruta alternativa evitó el síntoma.

Prueba respuestas y procesamiento normal. Una modificación del gateway, firma legal o plataforma después de DKIM puede romper el hash del cuerpo o encabezados firmados. Compara con una referencia anterior y cambia una variable a la vez. Si el selector nuevo falla, revierte el firmante al anterior mientras su clave pública todavía existe y corrige antes de reintentar.

Retira el selector viejo solo después de confirmar cuatro cosas: el nuevo aparece en todos los flujos previstos; valida en receptores de prueba; DMARC conserva alineación; y no quedan sistemas autorizados firmando con el anterior. Consulta logs, headers recientes y reportes DMARC, entendiendo que estos últimos son agregados y pueden llegar con retraso.

Define una ventana suficiente para el correo en tránsito y las colas de tu entorno. Si existe un incidente de compromiso, el balance cambia: puede ser necesario revocar antes y aceptar fallas sobre mensajes antiguos para detener abuso. Documenta la decisión, comunica el impacto y conserva el material necesario para investigar sin mantener una credencial expuesta.

Después del retiro, consulta DNS desde fuera, envía nuevas pruebas y actualiza el inventario. Elimina accesos del proveedor saliente y cierra el cambio con marca de tiempo y responsable. Un selector retirado que todavía aparece en mensajes actuales no es una curiosidad; es evidencia de un firmante que el inventario no cubrió.

Durante la ventana posterior, observa dkim=fail, dkim=temperror, DMARC fail, cambios por dominio receptor, rebotes y códigos de rechazo. Segmenta por dominio, selector, plataforma de envío y tipo de flujo. Un promedio global puede esconder que Workspace funciona mientras una plataforma transaccional continúa firmando con la clave retirada.

No atribuyas cualquier caída de respuestas a DKIM. Si autenticación y entrega permanecen estables, vuelve a lista, señal, oferta, copy y momento de envío. Si aparecen fallas de firma, resuelve primero identidad y ruta. Separar capas evita que el equipo reescriba asuntos para corregir un selector inexistente.

Programa una revisión del inventario y una prueba de recuperación, no solo la próxima fecha de rotación. La capacidad importante es cambiar la clave con evidencia y reversión. Un calendario perfecto con procedimientos no ensayados sigue siendo una alarma que nadie quiere escuchar.

Configurar DKIM una vez demuestra que el equipo pudo publicar una clave. Rotarlo demuestra que conoce dominios, firmantes, selectores, DNS, alineación y responsables. En un stack con Google Workspace, Microsoft 365, Clay, Instantly, Smartlead, CRM y proveedores transaccionales, esa segunda capacidad es la que evita depender de una persona o agencia que ya no está.

picos.Ai construye el plan operativo desde mensajes reales: inventario, d= y s= observados, nueva clave, propagación, transición, validación, monitoreo y retiro. No promete que rotar DKIM lleve el correo a la bandeja principal; sí evita que una credencial olvidada o un cambio improvisado rompa una condición básica de autenticación.

Si no sabes qué selector firma cada dominio o quién conserva sus claves, usa el enlace Hablemos al final de esta página. Podemos mapear una muestra, separar Workspace de plataformas externas y preparar una rotación con reversión. La meta no es cambiar DNS rápido. Es poder explicar cada firma antes, durante y después del cambio.