El DKIM (DomainKeys Identified Mail) es una firma digital que el dominio remitente añade a cada correo. Permite que el servidor receptor compruebe que el mensaje procede de ese dominio y que nadie lo ha modificado por el camino, lo que limita la suplantación de identidad (spoofing) y influye en la deliverability. El IETF lo estandarizó en 2007 (RFC 4871) y lo revisó en 2011 (RFC 6376).
¿Qué comprueba exactamente un servidor cuando escribe dkim=pass en la cabecera de un mensaje? Comprueba que una firma adjuntada por el dominio remitente coincide con una clave pública publicada en el DNS de ese dominio, y que el cuerpo no ha cambiado durante el tránsito. Nada más. Un panel de emailing que muestra «DKIM OK» no dice nada, por tanto, de la lista a la que se envía ni de la reputación de la IP.
Desde el 1 de febrero de 2024, Google exige autenticación SPF, DKIM y DMARC a los remitentes que envían más de 5.000 mensajes diarios a Gmail. Esta guía lee una firma campo por campo, muestra el registro que hay que publicar y detalla después la prueba y las causas de fallo.
La cabecera DKIM-Signature, campo por campo
Abre el original de un correo recibido: la cabecera se parece a esto (valores de ejemplo, firma abreviada).
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ejemplo.es; s=s1; t=1760000000; h=from:to:subject:date:message-id; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=Zm9ybWF0IGQnaWxsdXN0cmF0aW9u...
Cada etiqueta responde a una definición de la RFC 6376, publicada por el IETF en septiembre de 2011.
| Etiqueta | Valor de ejemplo | Función |
|---|---|---|
| v | 1 | Versión de la especificación DKIM |
| a | rsa-sha256 | Algoritmo de firma: RSA y huella SHA-256 |
| c | relaxed/relaxed | Canonización de las cabeceras y del cuerpo (tolerancia a espacios y saltos de línea) |
| d | ejemplo.es | Dominio firmante, que se compara con el dominio del From para el alineamiento DMARC |
| s | s1 | Selector, que indica qué clave hay que recuperar en el DNS |
| t | 1760000000 | Marca de tiempo Unix de la firma (9 de octubre de 2025 a las 08:53 UTC) |
| h | from:to:subject:date:message-id | Lista de las cabeceras cubiertas por la firma |
| bh | 47DEQpj8… | Huella (hash) del cuerpo del mensaje |
| b | Zm9ybWF0… | Firma, calculada sobre las cabeceras listadas en h |
Dos etiquetas se confunden con frecuencia. bh contiene la huella del cuerpo y b la firma en sí, calculada sobre las cabeceras de h y sobre la propia cabecera DKIM-Signature (con b vacía). Una huella SHA-256 ocupa 32 bytes, es decir, 44 caracteres en base64 dentro de bh. Si se modifica un solo byte del cuerpo, se rompe bh; si se modifica una cabecera firmada, se rompe b. El algoritmo rsa-sha1 está proscrito desde la RFC 8301 (enero de 2018): una firma moderna muestra rsa-sha256. La etiqueta opcional l, que limita lo firmado a un número de bytes del cuerpo, deja la puerta abierta a que se añada contenido después de la parte cubierta; la RFC 6376 describe su mal uso en la sección 8.2.
De la firma a la verificación: quién hace qué
La expresión habitual («cifrar el hash con la clave privada») confunde los papeles. En la práctica, la secuencia tiene cuatro tiempos.
- El servidor de envío (MTA) canoniza el cuerpo, calcula su huella SHA-256 y la coloca en bh.
- Calcula la huella de las cabeceras listadas en h, más la de la propia cabecera DKIM-Signature, y firma el resultado con su clave privada. Esa firma pasa a ser b. La clave privada nunca sale del servidor de envío.
- El servidor receptor lee d y s, consulta el DNS en s._domainkey.d y recupera la clave pública. El remitente ya no interviene en este punto.
- El receptor recalcula la huella del cuerpo y la compara con bh, y después verifica b con la clave pública. Si ambas comprobaciones coinciden, el resultado es dkim=pass.
Selector y registro TXT: dónde se publica la clave
El selector, valor de la etiqueta s, construye el nombre DNS que consultará el receptor: s._domainkey.d. Con s=s1 y d=ejemplo.es, la consulta apunta a s1._domainkey.ejemplo.es, donde se espera un registro TXT.
s1._domainkey.ejemplo.es. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
La etiqueta v indica la versión, k el tipo de clave y p la clave pública en base64. Una p vacía señala una clave revocada. El inicio del valor delata el tamaño: MIIBIjANBgkq… corresponde a una clave RSA de 2048 bits y MIGfMA0GCSqG… a una de 1024 bits.
La RFC 8301 obliga a los firmantes a usar claves RSA de al menos 1024 bits y recomienda 2048. Una clave de 1024 bits ocupa unos 216 caracteres. Una de 2048 bits ocupa 392 caracteres en base64: supera los 255 caracteres de una cadena DNS, así que el registro debe dividirse en varias cadenas entre comillas, algo que algunas interfaces DNS hacen solas y otras no. Cada herramienta de envío (Google Workspace, un CRM, un ESP) recibe su propio selector bajo el mismo dominio, y por eso una zona suele contener varios.
Una última trampa: según la interfaz, el campo «nombre de host» espera s1._domainkey solo o el nombre completo. Si escribes el nombre completo donde el dominio se añade automáticamente, resulta s1._domainkey.ejemplo.es.ejemplo.es, que el receptor no encuentra. Este registro vive en la misma zona que el resto de registros DNS del remitente (SPF, MX, DMARC): una sola interfaz que modificar y un solo propietario de la zona que localizar.
Configurar DKIM en Google Workspace, Microsoft 365 o un ESP
En Google Workspace, el camino pasa por la consola de administración: Aplicaciones > Google Workspace > Gmail > Autenticar el correo electrónico. El botón «Generar nuevo registro» crea el par de claves; se copia el valor TXT en la zona DNS y luego se inicia la autenticación. Tras activar Gmail, la clave solo aparece en la consola pasadas entre 24 y 72 horas, según la documentación de ayuda de Google Workspace.
Microsoft 365 (Office 365 en la documentación antigua) funciona de otra manera. El portal Microsoft Defender (security.microsoft.com), en el apartado «Email authentication settings», ofrece dos selectores llamados selector1 y selector2, que se publican como CNAME hacia registros alojados por Microsoft, siguiendo el modelo selector1-ejemplo-es._domainkey.inquilino.onmicrosoft.com. Solo uno de los dos firma a la vez y el otro espera a la próxima rotación, de modo que el cambio se hace sin cortes.
Con un ESP, la plataforma proporciona los registros TXT o CNAME que hay que copiar. Mientras la zona DNS no los contenga, el ESP firma con su propio dominio: la prueba muestra dkim=pass, pero el dominio d no coincide con el From, así que la firma no cuenta para DMARC. Ocurre lo mismo con una pasarela de salida que añade un pie de página: el cuerpo cambia después de la firma, un caso que la documentación de Google Workspace señala de forma expresa.
Probar DKIM: leer Authentication-Results
Envía un mensaje de prueba a un buzón de Gmail, abre el menú de tres puntos del mensaje y elige Mostrar original. Gmail muestra allí «DKIM: PASS» con el dominio y detalla el veredicto en la cabecera Authentication-Results.
Authentication-Results: mx.google.com; dkim=pass header.i=@ejemplo.es header.s=s1 header.b=Zm9ybWF0; spf=pass smtp.mailfrom=ejemplo.es; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ejemplo.es
En la línea dkim, header.s indica el selector usado, header.i la identidad firmante y header.b los primeros caracteres de la firma. Este formato es el de la RFC 8601. Los veredictos posibles son pass, fail (firma inválida), none (sin firma), neutral, temperror y permerror (error DNS pasajero o definitivo).
Para aislar un problema de DNS antes de enviar nada, el comando dig +short TXT s1._domainkey.ejemplo.es devuelve el valor publicado; una herramienta de prueba DKIM en línea (dkim lookup, dkim checker) hace la misma consulta con el valor de s de la cabecera.
Por qué falla una firma DKIM
Un dkim=fail casi siempre se debe a uno de estos casos.
- El cuerpo ha cambiado después de la firma, por ejemplo por un pie de página que añade un relé. bh deja de coincidir.
- No se encuentra el selector: errata o nombre de host duplicado con el dominio.
- La clave pública está truncada: TXT de 2048 bits sin dividir.
- El proveedor ha regenerado la clave privada sin que se actualizara el DNS.
- El mensaje pasa por una lista de distribución o un reenvío que reescribe el asunto o añade un pie de página: la firma original ya no cubre el contenido recibido.
- La firma es válida, pero el dominio d es distinto del dominio del From: DMARC la rechaza por falta de alineamiento.
Alineamiento DMARC y requisitos de Gmail y Yahoo
Yahoo aplica sus requisitos desde febrero de 2024: su Sender Hub pide que el dominio del From esté alineado con el dominio SPF o con el dominio DKIM (buenas prácticas de Yahoo). En modo relaxed, el valor por defecto, un d=news.ejemplo.es se alinea con un From en ejemplo.es; el modo estricto (adkim=s) exige la identidad exacta, según la RFC 7489 de 2015. Un mensaje enviado por un ESP con d=mailer.esp-ejemplo.com y un From en @ejemplo.es falla, por tanto, el alineamiento DKIM; si el Return-Path también pertenece al ESP, falla igualmente el SPF. Con una política DMARC en p=reject, se rechaza todo mensaje cuyo SPF y DKIM no estén alineados.
Los umbrales cambian según el volumen. Para cualquier remitente hacia Gmail, Google pide SPF o DKIM desde el 1 de febrero de 2024; por encima de 5.000 mensajes diarios, se exigen ambos. Google pide además un DMARC publicado (basta p=none), registros DNS directo e inverso válidos y una conexión TLS; el formato de los mensajes sigue la RFC 5322. En cuanto a reputación, la página fija como objetivo una tasa de spam inferior al 0,10 % en Postmaster Tools y prohíbe llegar al 0,30 %. Yahoo reclama SPF y DKIM a la vez, un DMARC al menos en p=none y el mismo tope del 0,3 %. El SPF por sí solo ya no basta para un volumen alto.
Rotación de claves
Sustituir una clave sin cortes requiere dos selectores, por ejemplo s1 y después s2. Se publica la nueva clave bajo s2 mientras s1 sigue firmando, se pasa la firma a s2 y se deja s1 en el DNS el tiempo necesario para que se verifiquen los mensajes que siguen en cola. Si se elimina demasiado pronto, aparecen dkim=fail en envíos legítimos que se atribuyen por error a una caída del DNS.
Lo que el DKIM no comprueba
Un spammer puede firmar sus envíos con su propio dominio y obtener dkim=pass: la firma prueba el origen del mensaje, pero no juzga ni el contenido ni la calidad de la lista. Un dominio perfectamente firmado que escribe a direcciones muertas acumula hard bounces, y su reputación de remitente se resiente igualmente.
Antes de la próxima campaña, pasa una muestra de la lista por una verificación de direcciones: el resultado indica cuántas direcciones inválidas contiene la base antes de que lleguen a Postmaster Tools.
