Cómo funciona la firma DKIM
DKIM (DomainKeys Identified Mail) permite a un receptor verificar que un mensaje lo envió alguien que tiene la clave privada de tu dominio y que nadie lo alteró por el camino. El servidor emisor calcula el hash del cuerpo, el hash de un conjunto concreto de cabeceras, firma el resultado con la clave privada y añade una cabecera DKIM-Signature que incluye el dominio firmante (d=), el selector (s=), la lista de cabeceras firmadas (h=), el hash del cuerpo (bh=) y la propia firma (b=). El receptor recoge la clave pública en selector._domainkey.dominio como registro TXT, recalcula los hashes y comprueba la firma.
Como la firma viaja con el mensaje, DKIM sobrevive a los reenvíos, a las listas de correo que no reescriben el cuerpo y a cualquier salto que SPF no llega a ver. Eso lo convierte en el más robusto de los dos métodos de autenticación y en el que con más probabilidad sostiene la alineación de DMARC en cold email. El dominio d= tiene que estar alineado con el dominio de la cabecera From para que DMARC pase por DKIM, así que firma con el dominio desde el que envían tus buzones de verdad, no con un dominio compartido del proveedor.
El registro de DNS en sí es pequeño: v=DKIM1 para la versión, k=rsa para el tipo de clave y p= seguido de la clave pública codificada en base64. Entre las etiquetas opcionales están t=y para el modo de pruebas, que le dice al receptor que ignore los fallos y que conviene quitar en cuanto esté verificado, y h= para restringir los algoritmos de hash. Una etiqueta p= vacía significa que la clave ha sido revocada.
Longitud de la clave, selectores y rotación
El RFC 8301 obliga a los verificadores a admitir claves de hasta 2048 bits y a los firmantes a usar al menos 1024. En la práctica, hoy el estándar es 2048 bits y varios receptores puntúan las claves de 1024 bits como débiles. La única razón para elegir 1024 es un proveedor de DNS que no admite un valor TXT de más de 255 caracteres, y ni siquiera entonces: la solución correcta es partir el valor en varias cadenas, que es justo lo que da el generador, en lugar de debilitar la clave. Una clave pública de 2048 bits ocupa unos 392 caracteres en base64; una de 1024 bits, unos 216.
Un selector no es más que una etiqueta que permite a un dominio publicar varias claves a la vez. Los proveedores usan selectores fijos: google en Google Workspace, selector1 y selector2 en Microsoft 365, k1 en Mailchimp, s1 y s2 en SendGrid, zoho o zmail en Zoho. Para tus propias claves, los selectores con fecha, del estilo de s202609, hacen que la rotación se documente sola.
- Rota las claves cada 6 a 12 meses, o de inmediato si sospechas que una clave privada se ha filtrado.
- Publica primero el selector nuevo, cambia la firma a ese selector y deja el registro antiguo en DNS al menos una semana, para que el correo en tránsito siga verificándose.
- Revoca un selector retirado publicando un p= vacío en lugar de borrar el registro, así los receptores obtienen una respuesta explícita.
- Usa un selector distinto por cada sistema de envío, para poder revocar uno sin tocar los demás.
Dónde va la clave privada y dónde no debe ir nunca
Si tus buzones están alojados en Google Workspace o en Microsoft 365, no necesitas generar ninguna clave. Esos proveedores crean y custodian ellos mismos la clave privada; tú solo copias en DNS el registro público que te dan. Lo mismo vale para la mayoría de servicios de relay SMTP. Este generador es para los casos en que la firma la controlas tú: un servidor Postfix o Exim con OpenDKIM, Amazon SES con clave propia, un Mailgun o servicio similar que acepte una clave personalizada, o un equipo que firma el correo saliente.
La clave privada que ves aquí la produce la API WebCrypto de tu navegador y se exporta en formato PEM PKCS#8, que es lo que esperan OpenDKIM, SES y la mayoría del software SMTP. Nunca se transmite, y al recargar la página se destruye. Guárdala con el mismo cuidado que una contraseña: en el servidor que firma con permisos de archivo restrictivos, en un gestor de secretos o en un gestor de contraseñas. No debe pegarse nunca en DNS, ni subirse a un repositorio, ni enviarse por chat. Si una clave queda expuesta, genera un par nuevo con un selector nuevo, cambia la firma y revoca el selector antiguo.
DKIM para dominios secundarios de cold email
Gmail y Yahoo exigen que todo remitente pase SPF o DKIM, y que los remitentes masivos pasen ambos más la alineación de DMARC. Como la mayor parte del volumen de cold email corre sobre buzones de Google Workspace o Microsoft 365 repartidos entre dominios secundarios, el paso práctico en cada dominio es activar DKIM en la consola del proveedor, publicar el registro que te da y verificarlo con el comprobador de arriba. Un dominio que envía sin DKIM tiene muchas más papeletas de caer en spam desde el primer día, y un dominio cuyo registro DKIM está mal escrito, un espacio de más o una comilla que falta en el valor p= es el caso clásico, está sin firmar a efectos prácticos.
Verifica después de cada cambio de DNS y después de cualquier migración de proveedor. El comprobador analiza el registro publicado, estima el tamaño de la clave a partir de la longitud en base64 y señala el modo de pruebas, las claves revocadas y los valores corruptos. El escaneo de selectores prueba los diez selectores de proveedor más comunes, para que encuentres el registro sin saber el selector de antemano. Si no coincide ninguno, abre un mensaje que te hayas enviado a ti mismo, mira las cabeceras y lee la etiqueta s= de la línea DKIM-Signature. ColdBox ejecuta esta comprobación en cada buzón conectado y te avisa si un registro desaparece o deja de verificar, para que una clave rota no te cueste una campaña en silencio.