Activar DKIM en Google Workspace: la guía paso a paso

La longitud de clave: 2048 bits, salvo que la zona lo impida

La opción preseleccionada es 2048 bits, y es la correcta. Una clave RSA de 1024 bits se considera demasiado corta desde hace años en los referenciales criptográficos; los grandes proveedores todavía aceptan firmas de 1024, pero nada justifica crear una clave débil en 2026. El propio Google propone 2048 por defecto.

La única razón real para bajar es mecánica: la clave pública de 2048 bits produce un valor de unos 400 caracteres, por encima del límite de 255 caracteres por cadena de un registro TXT. El estándar DNS resuelve el problema —un TXT admite varias cadenas concatenadas— y la mayoría de las interfaces modernas parten el valor automáticamente. Algunos paneles antiguos, sin embargo, rechazan la entrada larga. En ese caso hay dos salidas: partir el valor a mano en dos cadenas entrecomilladas o, como último recurso, regenerar una clave de 1024. El arbitraje completo —solidez, compatibilidad, rotación— está desplegado en la comparativa de claves de 1024 y 2048 bits. El reflejo sano: intentar primero 2048 y bajar solo tras un rechazo comprobado de la zona.

Publicar el TXT google._domainkey y arrancar la autenticación

El diálogo de generación muestra dos valores que trasladar a la zona DNS: el nombre de host, google._domainkey, y el valor TXT, que empieza por v=DKIM1; k=rsa; p=. Publicado, el registro tiene este aspecto:

google._domainkey.ejemplo.es.  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…" )

Dos precauciones al introducirlo. Primero, el nombre de host: según la interfaz DNS, el campo espera solo google._domainkey (la interfaz añade el dominio) o el nombre completo google._domainkey.ejemplo.es; el error clásico produce google._domainkey.ejemplo.es.ejemplo.es, que ningún verificador consultará jamás. Después, el valor: la clave debe copiarse entera, sin espacios parásitos ni truncamientos; una clave amputada en un solo carácter produce firmas inverificables, peor que ninguna firma. Un rápido dig TXT google._domainkey.ejemplo.es confirma lo que el mundo ve realmente.

Con el registro publicado, de vuelta a la consola: el botón «Iniciar autenticación» pide a Google verificar la presencia de la clave y conmuta la firma de los mensajes salientes a d=ejemplo.es con el selector google. Si la verificación falla, la culpa es casi siempre de la propagación: según los TTL y los resolutores, la clave tarda de unos minutos a 48 horas en ser visible en todas partes. El error no es definitivo: el botón admite un nuevo intento más tarde. Una vez arrancada la autenticación, los mensajes siguientes se firman de inmediato; los ya enviados conservan, claro está, la firma antigua.

La verificación: DKIM-Signature y s=google

La prueba está en las cabeceras. El test más simple: enviar un mensaje desde el dominio a un buzón externo —vale cualquier dirección Gmail personal— y abrir después «Mostrar original» en Gmail. La página resume los tres veredictos (SPF, DKIM, DMARC) y muestra la cabecera completa.

Dos líneas importan. La primera, DKIM-Signature, debe llevar el par correcto dominio-selector:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=ejemplo.es; s=google; h=from:to:subject:date; …

d=ejemplo.es y s=google: la firma compromete ya al propio dominio. La segunda, Authentication-Results, debe mostrar dkim=pass header.i=@ejemplo.es. Si el d= sigue mencionando gappssmtp.com, la autenticación no ha arrancado realmente, o el mensaje salió antes del cambio.

A escala, la confirmación llega con los informes agregados DMARC: en pocos días, el volumen emitido por las IP de Google debe aparecer alineado por DKIM. Un matiz importante: dkim=pass por sí solo no dice nada de la alineación; una firma gappssmtp.com intacta también muestra pass. La diferencia la marca la correspondencia entre el d= y el From, y es justo lo que miden los informes.

Lo que la activación cambia para la alineación DMARC

DMARC valida un mensaje cuando al menos uno de sus dos mecanismos pasa y se alinea: SPF contra el dominio del Return-Path, DKIM contra el dominio del d=. En un dominio de Google Workspace, SPF suele estar ya en marcha y alineado para los envíos directos. La activación de DKIM no es, por tanto, redundante: añade la pierna que sobrevive donde SPF se cae.

El caso decisivo es el reenvío. Un mensaje reenviado automáticamente —un buzón de reenvío, la dirección de un antiguo empleado, una lista interna— llega al destinatario final desde la IP del servidor que reenvía, no desde Google: SPF falla. La firma DKIM, en cambio, viaja dentro del mensaje y sigue siendo verificable mientras el contenido firmado no se altere. Con DKIM alineado, esos flujos reenviados siguen pasando DMARC; sin él, se convierten en falsos positivos en cuanto la política se endurece.

Por eso la activación de DKIM es, de hecho, un prerrequisito del paso a p=quarantine y luego a p=reject: convierte unos informes llenos de fallos ambiguos en una base sana donde los únicos fallos restantes son los sospechosos. Los escalones de política y su sintaxis exacta —p=, rua=, alineación estricta o relajada mediante adkim=— se recorren en los ejemplos comentados de registros DMARC, la parada natural una vez que la firma está en marcha.

Las trampas: dominio reciente, alias y multidominio

El dominio añadido recientemente. En un dominio recién conectado a Google Workspace, la generación de la clave puede permanecer indisponible varias horas, y el arranque de la autenticación puede fallar aunque el TXT esté correctamente publicado. La propia documentación de Google menciona un plazo de hasta 72 horas tras la activación de Gmail en el dominio. El síntoma —un botón inoperante, un error persistente— se cura con paciencia, no regenerando claves frenéticamente.

Los alias de dominio. Cada alias envía correo bajo su propio nombre, y la alineación DKIM se juzga alias por alias. La clave del dominio principal no cubre un alias: hay que seleccionarlo en el desplegable, generar su propia clave, publicarla en su zona DNS y arrancar su autenticación. Un alias olvidado sigue firmando como gappssmtp.com, y sus mensajes fallarán la alineación el día del endurecimiento.

El multidominio. La misma lógica: el procedimiento se repite dominio a dominio. El selector google puede reutilizarse en cada zona sin conflicto —un selector es local a su zona—. Los informes agregados siguen siendo el mejor detector de un dominio olvidado.

Los remitentes terceros. La clave generada en la consola solo firma lo que sale de Gmail. Una plataforma de emailing —Mailchimp, Brevo, SendGrid— firma con sus propias claves, configuradas en su lado. Y en el lado Microsoft la mecánica difiere sensiblemente (dos registros CNAME, selectores selector1/selector2): la guía equivalente para Microsoft 365 recorre ese terreno.

La rotación de claves. Una rotación posterior sigue la misma secuencia —generar, publicar, rearrancar—, dejando la clave pública antigua publicada unos días para que los mensajes aún en tránsito sigan verificándose.

En resumen

Por defecto, Google Workspace firma DKIM con un dominio técnico gappssmtp.com que no sirve de nada para DMARC. La activación sobre el dominio propio sigue un camino corto: consola de administración (Aplicaciones → Google Workspace → Gmail → Autenticar correo electrónico), generación de una clave de 2048 bits, publicación del TXT google._domainkey, arranque de la autenticación y verificación en las cabeceras (d= del dominio, s=google). La operación se repite para cada dominio y cada alias, y solo cubre el tráfico de Gmail: las plataformas terceras firman por separado. La ganancia es tangible: una pierna de autenticación que sobrevive a los reenvíos y hace realista el paso a p=reject.

Queda medir el estado real: un análisis DMARC gratuito del dominio muestra en segundos si los envíos de Google Workspace salen alineados, y qué falta todavía. Para seguir la progresión en los informes y endurecer la política al ritmo adecuado, la apertura de una cuenta lleva unos minutos; la firma, por su parte, ya está en su sitio.