¿Google Workspace rota las claves DKIM por mí?

No. La consola de administración te da un botón para generar un registro nuevo y un control para activar la autenticación, así que la rotación es una decisión tuya y una secuencia que ejecutas tú. Lo que Google publica como requisito para el correo hacia cuentas personales de Gmail es una clave de 1024 bits o más, con 2048 recomendado, no un intervalo de rotación.

¿Cuánto tiempo debo dejar el registro DKIM anterior en el DNS?

El tiempo suficiente para que ningún mensaje firmado con la clave anterior siga esperando verificación. El RFC 6376 espera que las dos claves públicas estén publicadas durante la transición. En dominios de clientes dejamos dos semanas, contadas desde que la firma pasa al selector nuevo, y leemos un ciclo completo de reportes agregados de DMARC antes de borrar algo.

¿Rotar la clave rompe DMARC?

No si publicas el registro nuevo bajo un selector nuevo, esperas a que resuelva, verificas con un mensaje real que DKIM pasa con él y dejas el registro anterior en su lugar un par de semanas. La falla ocurre al borrar el registro viejo demasiado pronto, y pesa más en un dominio con p=reject.

Rotar la clave DKIM en Google Workspace: la secuencia segura

Imagina una empresa de logística de 30 personas que pasó a Google Workspace en 2019 y desde entonces firma todo su correo con la misma clave DKIM. Nadie recuerda haberla generado. El selector sigue siendo el que viene por defecto, la clave es de 1024 bits y funciona, que es justamente la razón por la que nadie la ha revisado. Hasta que una revisión de seguridad de un cliente pregunta cuándo se cambió por última vez la clave de firma, y la respuesta honesta es nunca.

Rotar esa clave toma unos diez minutos en la consola de administración y unas dos semanas en el DNS. La diferencia entre esos dos números es donde se pierde el correo. La falla típica se ve así: alguien genera un registro nuevo, lo publica, activa la autenticación y borra el registro TXT anterior esa misma tarde. Todo mensaje que ya estaba en una cola del receptor, esperando en un reenvío o guardado en un sistema que lo va a verificar después, ahora falla DKIM, porque la clave con la que se firmó ya no existe. En un dominio con p=reject, fallar DKIM sin nada más alineado significa correo rechazado. El procedimiento no es difícil, pero el orden importa. Todo lo que sigue sale de la documentación de Google y de los RFC de DKIM, revisados el 6 de octubre de 2026.

Por qué un dominio en Workspace rotaría la clave

En cuentas reales aparecen tres razones, y solo la primera es urgente.

La clave es de la época de los 1024 bits. El RFC 8301 dice que quien firma debe usar claves RSA de al menos 1024 bits y debería usar al menos 2048. Las guías para remitentes de Google indican que el correo hacia cuentas personales de Gmail necesita una clave de 1024 bits o más, y recomiendan 2048 cuando tu proveedor de dominio lo soporta. Una clave generada hace años en un panel de DNS que no aceptaba valores largos casi siempre es de 1024, y actualizarla es una rotación, se le llame así o no.

Nadie sabe de dónde salió la clave. Heredaste el dominio, o un proveedor de gateway generó una clave para él alguna vez, o hay dos registros bajo _domainkey y solo uno firma algo. Rotar hacia una clave que generaste tú, con un selector que elegiste tú, cambia una duda por un dato.

Alguien lo pidió. Los cuestionarios de seguridad y las políticas internas suelen pedir rotación periódica. El RFC 6376 creó los selectores para esto: un dominio que firma puede publicar más de una clave pública a la vez, así que las claves se pueden reemplazar de forma rutinaria sin dejar un hueco.

Un límite honesto. En Google Workspace la clave privada la genera y la guarda Google, y tú nunca la tocas, así que aquí la rotación es higiene y longitud de clave, no algo que harías como respuesta a una filtración. Si tienes una clave que generaste fuera de Google, en un gateway de correo o en un servidor, y crees que la mitad privada quedó expuesta, ese es otro trabajo y es más urgente. Ten en cuenta también que lo que Google publica como requisito es una longitud mínima de clave, no un intervalo de rotación. Nada se vence si dejas la clave quieta.

Qué revisamos antes de tocar el registro

Rotar es la parte fácil. Saber qué firma tu correo hoy es la parte que te salva. Cuatro revisiones, en este orden.

Cuál selector está activo y de qué largo es la clave. Lee la firma de un mensaje que el dominio haya enviado de verdad y luego consulta el registro al que apunta. La etiqueta s= de la cabecera DKIM-Signature es el selector, y el valor publicado es un registro TXT bajo ese selector:

dig +short TXT google._domainkey.example.com

Un valor p= corto es una clave de 1024 bits. Uno largo, normalmente publicado como varias cadenas entre comillas, es de 2048. La página de solución de problemas de Google explica el límite de 255 caracteres que vuelve incómodo el valor largo, y nuestra guía sobre fallas de DKIM en Google Workspace recorre el registro que no cabe y el selector que no está.

Si Google es el firmante que importa. Google firma el correo que sale de Google. Tu plataforma de facturación, tu CRM y tu tienda en línea firman con claves propias, y rotar la clave de Workspace no cambia nada para ellos. Si el problema que quieres resolver es un proveedor que falla DMARC, este no es el trabajo correcto.

Tu política DMARC. Con p=none, un error durante la rotación produce una línea fea en un reporte. Con p=reject, produce facturas rechazadas. El procedimiento es el mismo, pero la ventana de traslape deja de ser opcional.

Qué más maneja el correo en la salida. Un gateway de seguridad o un equipo intermedio delante de Gmail puede modificar el mensaje después de que Google lo firma, y eso rompe la firma sin importar cuál clave esté vigente. Rotar sobre una ruptura que ya existía hace que la ruptura parezca nueva.

La rotación, en el orden que mantiene el correo firmado

Genera el registro nuevo con un selector distinto. En la consola de administración, en la página de autenticación de correo, elige el dominio y genera un registro nuevo. La página de configuración de Google es explícita: si tu dominio ya usa una clave DKIM con el prefijo google, escribes un prefijo diferente en el formulario. Elige algo que vayas a reconocer después, como el año y el mes. Usa 2048 bits salvo que tu proveedor de DNS no pueda guardar el valor.
Publica el TXT nuevo y deja el anterior en paz. La clave nueva va bajo su propio nombre de host, así que los dos registros conviven sin estorbarse:
```
gt2610._domainkey.ejemplo.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."
google._domainkey.ejemplo.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."   (no lo toques)
```
Si tu proveedor rechaza el valor largo, divídelo en cadenas entre comillas, una tras otra en el mismo registro, que es lo que indica la página de solución de problemas de Google.
Espera antes de activar nada. Google documenta que después de agregar una clave DKIM puede tomar hasta 48 horas para que la autenticación DKIM empiece a funcionar, y que la página de autenticación de correo puede seguir pidiéndote actualizar los registros DNS hasta por 48 horas aunque el registro esté correcto. Si agregaste un nombre nuevo, una consulta fallida en los primeros minutos significa que una respuesta negativa sigue en caché en algún lado, no que te equivocaste.
Activa la autenticación. De vuelta en la página de autenticación de correo, activa la autenticación para que Google firme con el selector nuevo.
Compruébalo con un mensaje real. Manda uno a un buzón que controles, abre las cabeceras completas y revisa dos cosas: que la etiqueta s= nombre tu selector nuevo y que los resultados de autenticación muestren DKIM pasando con tu dominio. Que la consola confirme que el registro existe es una cosa. Una cabecera es la prueba de que el correo se está firmando con él.
No borres el registro anterior. Ni hoy, ni esta semana.

Cuánto tiempo dejar publicada la clave anterior

El RFC 6376 responde esto de frente: durante una transición, las dos claves públicas se publican a la vez, todo el tiempo que el correo firmado con la más antigua pueda seguir en tránsito antes de ser verificado. La pregunta es cuánto dura eso en la práctica, y dura más de lo que casi todos suponen.

Correo diferido. Un receptor que rechazó tu mensaje de forma temporal lo va a reintentar durante horas o días, y lo verifica cuando por fin lo acepta.
Reenvíos y listas. Un mensaje que pasa por una dirección de reenvío o por una lista se verifica otra vez en cada salto, a la hora en que ocurra ese salto.
Todo lo que verifica al abrir. Los archivos históricos, los sistemas de journaling y las herramientas de seguridad suelen revisar la firma cuando alguien abre o reporta un mensaje, lo que puede ser semanas después de la entrega.

Nuestra práctica en dominios de clientes son dos semanas, y el reloj arranca cuando la firma pasa al selector nuevo, no cuando se publica el registro. Antes de borrar, leemos un ciclo completo de reportes agregados de DMARC y queremos ver la nueva ruta de firma pasando en cada fuente que importa. Muchos emisores de reportes nombran el selector en el resultado de DKIM, lo que vuelve fácil seguir el cambio. Leer esos archivos es un trabajo en sí mismo, y está en cómo leer un reporte agregado de DMARC.

Dos reglas del RFC 6376 que vale la pena conservar. No reutilices un selector para una clave nueva: si sobrescribes el registro anterior con el valor nuevo, un mensaje que falla porque la clave ya no existe se vuelve indistinguible de una falsificación, y por eso las claves nuevas llevan selectores nuevos. Y cuando se cierra la ventana, borrar el registro es suficiente. El RFC señala que no hay diferencia semántica definida entre una clave revocada y una eliminada, así que no necesitas publicar primero una clave vacía.

Los remitentes que rotan sin ti y los que no lo harán nunca

Donde un proveedor te hizo publicar registros CNAME en lugar de TXT, el proveedor es dueño de la clave que está detrás y puede rotarla sin pedirte nada. Microsoft 365 es el ejemplo más claro del modelo: te hace publicar dos CNAME de selector, mantiene uno activo a la vez, usa el segundo para la siguiente rotación, y la documentación de Microsoft advierte que la rotación no es inmediata, con unos cuatro días antes de que la clave privada nueva empiece a firmar.

Donde un proveedor te dio un valor TXT para pegar, nada rota hasta que una persona lo haga, y esa persona normalmente no existe. Cuando inventariamos los remitentes de un dominio los listamos aparte, porque cada uno es una rotación manual en el calendario de otra gente y cada uno merece su propia semana. Un cambio de autenticación a la vez es más lento y es la razón por la que los rollbacks quedan pequeños.

Qué vigilamos después

Durante las dos semanas entre el cambio y el borrado queremos tres cosas ciertas: que la consola muestre la autenticación activa para el dominio, que un mensaje de prueba de cada ruta real de envío pase DKIM con el selector nuevo, y que los reportes agregados no muestren ninguna fuente dependiendo todavía de la clave anterior. Si un reporte muestra una fuente fallando después del cambio, el registro viejo sigue ahí, que es justamente para lo que se dejó.

Mantén el trabajo de política aparte. Si tu política DMARC va a subir, ese es su propio proyecto con su propio plan de retroceso, y está descrito en cómo pasar DMARC de p=none a p=reject. Rotar una clave en la misma semana que un cambio de política significa que, cuando algo se rompa, no vas a saber cuál de los dos cambios lo rompió.

Después anota el selector que elegiste y la fecha en que hiciste el cambio, en un lugar donde el próximo administrador vaya a buscar. La clave de seis años del primer párrafo existe porque nadie anotó nada, y esa es la parte de este trabajo que de verdad se repite.

Cómo ayuda Guanacos Tech

Hacemos rotaciones de clave como parte del trabajo de autenticación para empresas pequeñas y medianas en Norteamérica y Latinoamérica, en inglés y español, con nuestra consultoría de entregabilidad de correo. El valor casi nunca está en el registro nuevo. Está en el inventario de lo que firma tu correo, en la ventana de traslape sostenida el tiempo suficiente y en alguien leyendo los reportes mientras la clave anterior sigue viva. Con una llamada de 30 minutos nos alcanza para leer tu registro actual, tus reportes DMARC y un juego de cabeceras crudas, y decirte si vale la pena rotar ahora o si el problema real es otro.

Rotar la clave DKIM de Google Workspace sin perder un mensaje firmado