Digamos que una distribuidora de 12 personas nos llama porque sus facturas están cayendo en spam con dos de sus clientes más grandes. Todo lo demás llega bien. Usan Google Workspace, el SPF está publicado y la consola de administración muestra DKIM autenticando. Pedimos un mensaje con las cabeceras completas. La línea Authentication-Results dice dkim=pass, y enseguida nombra un dominio firmante que pertenece a su plataforma de facturación, no a ellos. DMARC falla igual. Eso la consola nunca se los iba a mostrar.
DKIM en un dominio de Workspace falla de pocas maneras, y no son intercambiables. Una llave que se generó pero nunca se publicó. Una llave publicada bajo un nombre de host que el editor de DNS reescribió por su cuenta. Un gateway que edita los mensajes después de que Google los firma. O el correo que más importa saliendo por un tercero que Google ni toca. Este es el orden en que lo revisamos en un dominio de cliente, y qué significa cada síntoma.
Dónde se activa DKIM, y el paso que todos se saltan
En la consola de administración, DKIM vive en Menú, luego Apps, Google Workspace, Gmail, y ahí Autenticar correo. Eliges el dominio, el largo de la llave y un prefijo de selector, y das clic en Generar nuevo registro. La documentación de Google es clara en que esto tiene dos partes: primero agregas la llave en tu proveedor de dominio, después regresas a la consola, activas la firma DKIM y das clic en Iniciar autenticación.
El paso que se salta es el último. El registro TXT está publicado, los verificadores públicos lo muestran, todos asumen que el trabajo terminó, y Google sigue sin firmar con esa llave porque nunca se inició la autenticación del dominio. Confirma que el dominio aparezca autenticando antes de ir a buscar algo más interesante.
Hay dos tiempos de espera que conviene conocer antes de declarar algo roto. En una organización recién creada, Google documenta que hay que esperar de 24 a 72 horas después de activar Gmail para poder generar la llave DKIM, y que pedirla antes puede devolver un error diciendo que el registro no se creó. Ya publicada la llave, Google indica que la autenticación DKIM puede tardar hasta 48 horas en empezar a funcionar, y que durante esa ventana la página de Autenticar correo puede seguir mostrando el aviso de que debes actualizar los registros DNS del dominio. Si el registro está bien, ese aviso no es una falla. Es un reloj.
El nombre google._domainkey, y las dos formas en que se rompe
El prefijo de selector por defecto es google, que deja la llave pública en google._domainkey.tudominio.com. Google recomienda usar otro prefijo si el dominio ya tiene una llave con ese selector, algo más común de lo que parece en dominios que pasaron por un proveedor de correo anterior.
Tipo: TXT
Host: google._domainkey
Valor: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
(el resto de la llave tal cual la entrega la consola)Dos errores explican casi todos los registros que terminamos reparando. El primero es escribir el nombre completo en el campo de host. La mayoría de editores de DNS te agregan el dominio, así que google._domainkey.tudominio.com termina como google._domainkey.tudominio.com.tudominio.com, y el nombre que consulta el verificador no tiene nada. El segundo es una llave que perdió caracteres en el camino, casi siempre pegada en un campo que la cortó o con un espacio que se coló en algún extremo.
Revisa el registro publicado desde fuera del panel, porque el panel te muestra lo que escribiste y no lo que responde el internet:
dig +short TXT google._domainkey.tudominio.comSi no devuelve nada, el registro no está donde el verificador va a buscarlo, sin importar lo que muestre la interfaz de DNS. Si el dominio se movió hace poco, corre la misma consulta contra tus propios nameservers, porque una zona vieja en el hosting anterior puede seguir respondiendo.
Lee la cabecera antes de cambiar nada
Adivinar aquí sale caro. Cada cambio te compra otra espera de propagación, y para la tercera edición ya nadie recuerda cuál era el estado original. Gmail te da la respuesta directo: abre el mensaje, da clic en Más junto a Responder y elige Mostrar original. La página de ayuda de Google apunta a la misma línea que nosotros, Authentication-Results, y a si trae dkim=pass.
Lee dos cosas en esa cabecera, no una. Si DKIM verificó, y qué dominio firmó. Una firma puede verificar perfecto y aun así reprobar DMARC, porque el dominio dentro de la firma no es el dominio que tus destinatarios ven en el De. Las guías para remitentes de Google lo plantean sin rodeos: el dominio organizacional de la cabecera De tiene que alinear con el dominio organizacional de SPF o con el de DKIM, y basta con que alinee uno de los dos.
En términos de la firma, según el RFC 6376, la etiqueta d= es el dominio firmante, s= es el selector que ubica la llave pública en DNS y bh= es el hash del cuerpo del mensaje. Esas tres etiquetas responden casi todas las preguntas que vas a tener.
Qué significa cada falla
Ninguna firma con tu dominio
Correo que sale de Gmail sin firma DKIM con tu dominio apunta a la consola, no al DNS. O nunca se inició la autenticación, o se trata de un dominio secundario o un alias de dominio que se configuró aparte y nunca recibió su propia llave. Cada dominio que firmes necesita su llave y su registro.
La llave está publicada pero el verificador no puede usarla
Este es el nombre de host mal armado o la llave truncada de la sección anterior, y la salida de dig lo resuelve en segundos. Si la consulta devuelve un valor que parece completo, compáralo carácter por carácter contra la consola y no a ojo en los extremos. Una llave falla igual de completo por un carácter faltante que por cincuenta.
body hash did not verify
Esta vale la pena memorizarla. Google documenta que significa que el mensaje fue modificado en tránsito, y nombra la causa habitual: un gateway de salida que cambia los mensajes antes de enviarlos, por ejemplo agregando un pie de página al final de cada correo saliente. La firma se calculó sobre un cuerpo y se verificó contra otro.
En dominios de clientes esto casi siempre es un equipo o un servicio en la ruta de salida: una herramienta de avisos legales, un gateway de seguridad, un relay de archivado. Las listas de correo y las reglas de reenvío rompen el hash del cuerpo de la misma forma más adelante, y por eso un mensaje que falla al llegar a un destinatario pasa sin problema en todos los demás. La solución es detener la modificación, o firmar después de ella y no antes.
La firma verifica pero nada alinea
Esta es la historia del inicio. El correo sí está firmado, por el proveedor que lo envía, y DMARC falla igual porque el dominio de ese proveedor no es el tuyo. No es un problema de Workspace y ninguna cantidad de trabajo en la consola lo va a mover.
Los remitentes que Google nunca firma
Google firma el correo que sale de Google. Plataformas de facturación, CRMs, herramientas de marketing, mesas de ayuda, checkouts de e-commerce y sistemas contables envían desde su propia infraestructura, y si no publicas los registros DKIM que cada uno te entrega, firman con su dominio o no firman por ti.
El inventario toma una tarde y te ahorra semanas. Enumera cada sistema que manda correo mostrando tu dominio en el De, entra a la página de autenticación de cada proveedor, publica lo que pide y verifica dentro de su consola. Escribimos el detalle por proveedor para los tres grandes en por qué Mailchimp, HubSpot y Klaviyo fallan la alineación DMARC, y el patrón se repite casi en todos: uno o dos CNAME, un dominio de envío dedicado y un botón de verificación que nadie presionó.
El volumen no es la salida que muchos esperan. Las guías para remitentes de Google exigen SPF y DKIM, más DMARC en el dominio de envío, para quienes mandan más de 5,000 mensajes al día a Gmail desde el 1 de febrero de 2024. Una distribuidora de 12 personas ni se acerca a esa cifra. Tampoco está exenta del filtrado, y un dominio de bajo volumen tiene menos historial de reputación en el cual apoyarse, no más.
1024 o 2048, y el registro que no cabe
Google ofrece los dos largos al generar, y recomienda 2048 bits cuando tu proveedor de dominio lo soporta. El detalle aparece en la propia página de solución de problemas de Google: una llave de 2048 bits no se puede ingresar como una sola cadena de texto en un registro DNS con el límite de 255 caracteres. Google da dos salidas. Generar una llave de 1024 bits, o preguntarle a tu proveedor si admite registros TXT de más de 255 caracteres y usar 2048 si es así.
En la práctica, la mayoría de proveedores actuales parten el valor largo en cadenas entrecomilladas por ti, que es la misma solución aplicada de forma automática. Si el tuyo lo trunca en silencio, vas a ver un registro que se ve correcto y que no verifica en ningún lado, así que confirma con dig antes de culpar a otra cosa.
La rotación es justamente para lo que existen los selectores. El RFC 6376 ubica la llave pública por dominio firmante más selector, así que un dominio puede tener más de una llave válida al mismo tiempo. Eso te da una secuencia limpia: genera la llave de reemplazo con un prefijo nuevo, publícala, inicia la autenticación para que la firma pase al selector nuevo, y deja el registro TXT anterior en su lugar hasta que ya no haya mensajes firmados con la llave vieja en tránsito o guardados en algún archivo que alguien vaya a verificar. Ahí sí, elimínalo. Borrar el registro viejo la misma hora en que rotas es como una rotación se convierte en una caída.
Qué vigilamos después del arreglo
Una fila en verde en la consola prueba que Google está firmando. No dice nada de los demás sistemas que envían por ti. Los reportes agregados de DMARC sí, y son la única vista que cubre todas las fuentes a la vez, con un resultado DKIM y un dominio firmante por cada una. Leemos varias semanas de ellos antes de tocar una política DMARC, que es el tema de cómo leer un reporte DMARC agregado. Ya que estás en la zona, vale confirmar que el lado de SPF tampoco se haya pasado de su presupuesto de consultas, algo que cubrimos en SPF y el límite de consultas DNS.
Cómo ayuda Guanacos Tech
Hacemos esto de punta a punta para empresas pequeñas y medianas en Norteamérica y Latinoamérica: leer las cabeceras, reparar el registro, encontrar a los remitentes que nadie recordaba, resolver el gateway que reescribe los cuerpos, y luego vigilar los reportes DMARC hasta que el panorama esté limpio. Si el correo de tu dominio en Workspace está fallando DKIM y prefieres no gastar una semana en esperas de propagación, pega un mensaje en el analizador de arriba, o agenda una llamada y lo vemos contigo. Más sobre el trabajo completo en entregabilidad de correo.