DKIM: la guía completa de la firma DKIM

La cabecera DKIM-Signature, descifrada

Toda la mecánica DKIM cabe en una cabecera añadida al mensaje. Aquí hay una, tal como se encuentra en el código fuente de un correo:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=ejemplo.es; s=s2026; t=1753344000;
  h=from:to:subject:date:mime-version;
  bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZYLQ=;
  b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR...

Las etiquetas (tags) que la componen están normalizadas. Las siete principales:

Etiqueta	Nombre	Función
v=	Versión	Siempre 1: la versión del estándar DKIM utilizada.
a=	Algoritmo	El algoritmo de firma y de hash, rsa-sha256 en la inmensa mayoría de los casos (ed25519-sha256 para las claves modernas).
d=	Dominio	El dominio firmante, el que reivindica el mensaje. Es el que DMARC comparará con el From: visible.
s=	Selector	El nombre de la clave utilizada, que indica al destinatario dónde buscar la clave pública en el DNS.
h=	Cabeceras firmadas	La lista de cabeceras cubiertas por la firma; toda cabecera ausente de esta lista puede cambiar sin romperla.
bh=	Hash del cuerpo	La huella del cuerpo del mensaje en el momento de la firma.
b=	Firma	La firma criptográfica en sí, codificada en base64.

Otras etiquetas aparecen según la configuración: c= (el modo de canonicalización mencionado antes), t= (marca de tiempo de la firma), x= (fecha de expiración más allá de la cual la firma ya no debe aceptarse), i= (identidad del agente firmante, a veces un subdominio o una dirección), o l= (longitud de cuerpo firmada — una opción arriesgada, porque autoriza añadir contenido después de la parte firmada, y que las buenas prácticas desaconsejan).

Dos etiquetas merecen atención especial. Primero d=: es la reivindicación de identidad de la firma, y el eje de todo el edificio DMARC. Después h=: la lista de cabeceras firmadas determina lo que la firma protege realmente. Firmar From es obligatorio; firmar también Subject, Date, To y Reply-To es muy recomendable, para que no puedan falsificarse a posteriori.

Los selectores: varias claves para un mismo dominio

Un dominio casi nunca tiene una sola clave DKIM. El correo profesional sale típicamente de varios sitios — la mensajería principal, una herramienta de marketing, un CRM, un servicio de facturación — y cada uno firma con su propio par de claves. El selector es el mecanismo que hace posible esta coexistencia: un nombre arbitrario, elegido por el firmante, que identifica cada clave publicada.

El descubrimiento de la clave pública sigue una convención fija. El destinatario lee s= y d= en la firma, y consulta el DNS en la dirección:

<selector>._domainkey.<dominio>

Para s=s2026 y d=ejemplo.es, la consulta TXT apunta por tanto a s2026._domainkey.ejemplo.es. Cada proveedor de envío usa sus convenciones de nombres: google para Google Workspace, selector1/selector2 para Microsoft 365, nombres propios de cada plataforma en los demás casos. De ahí un reflejo de auditoría útil: enumerar los selectores publicados bajo _domainkey revela la lista de servicios autorizados a firmar por el dominio — incluidos los que todos habían olvidado.

Esta arquitectura multiclave aporta dos beneficios operativos mayores. El aislamiento: si un proveedor se ve comprometido o se abandona, se revoca su selector sin tocar los demás flujos, que siguen firmando con normalidad. La flexibilidad: se puede introducir una clave nueva junto a la antigua, que es el fundamento de la rotación sin cortes descrita más abajo. El papel exacto del selector, sus convenciones y sus trampas se detallan en nuestra guía dedicada al selector.

Generar y publicar una clave DKIM

En la práctica, el par de claves nace de dos maneras. O bien la plataforma de envío lo genera por usted — es el caso de las suites ofimáticas y de la mayoría de las plataformas de emailing, que entregan directamente el registro DNS a publicar —, o bien lo genera usted mismo (servidor de correo autoalojado, exigencia de control de las claves), con una herramienta estándar como OpenSSL. Los comandos exactos, paso a paso, están en nuestra guía de generación paso a paso.

La clave pública se publica después en el DNS, y coexisten dos modelos:

El TXT directo. Usted crea el registro TXT bajo <selector>._domainkey.<dominio>, con la clave a la vista:

s2026._domainkey.ejemplo.es.  IN TXT
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Conserva el control completo de la clave — usted la rota, usted la revoca. Punto de vigilancia: una clave RSA de 2048 bits supera el límite de 255 caracteres por cadena DNS; el registro se divide entonces en varias cadenas entre comillas que los resolutores recomponen automáticamente. Esta división es normal, pero algunas interfaces DNS la gestionan mal.

El CNAME delegado. Usted publica un simple alias que apunta a un registro alojado en el proveedor de envío:

s1._domainkey.ejemplo.es.  IN CNAME  s1.domainkey.proveedor-envio.example.

El proveedor aloja la clave real y puede rotarla sin que usted toque su zona DNS. Es el modelo dominante entre las plataformas de emailing, y tiene un mérito operativo real: la rotación pasa a ser su problema, no el de usted. Su contrapartida es una delegación de confianza — el proveedor controla una identidad criptográfica de su dominio. En ambos modelos, la etiqueta t=y (modo de prueba) puede acompañar un despliegue inicial, y la revocación se efectúa vaciando el valor p= del registro.

La rotación de claves: una higiene, no un acontecimiento

Una clave DKIM no está llamada a ser eterna. Cuanto más tiempo vive una clave privada, más aumenta la probabilidad de que se filtre: una copia de seguridad extraviada, un servidor comprometido, un proveedor abandonado con la clave aún activa, una copia olvidada en un repositorio de código. Y una clave privada DKIM robada permite firmar mensajes perfectamente auténticos a ojos de los destinatarios — con la alineación DMARC de regalo. La rotación periódica acota ese riesgo en el tiempo: una clave robada ayer ya no vale nada después de la rotación.

Sobre la frecuencia, la referencia citada habitualmente por el sector (en particular las recomendaciones de M3AAWG) es una rotación al menos dos veces al año, es decir, cada seis meses aproximadamente. En la práctica: cada seis meses para los flujos sensibles, una vez al año como mínimo absoluto, e inmediatamente ante cualquier sospecha de compromiso o al separarse de un proveedor.

Lo notable es que la rotación puede ser totalmente transparente, gracias a los selectores. El procedimiento sin cortes cabe en cuatro pasos:

1. Generar un nuevo par de claves y publicar la nueva clave pública bajo un selector nuevo (por ejemplo s2027), sin tocar el antiguo.
2. Cambiar la firma en el lado del servidor de envío hacia la clave nueva.
3. Esperar unos días: el correo firmado con la clave antigua, todavía en tránsito o en cola, debe terminar de entregarse y verificarse.
4. Revocar el selector antiguo (vaciar su p=) y, después, suprimirlo.

En ningún momento circula un mensaje sin clave pública verificable: los dos selectores coexisten durante el cambio. El procedimiento detallado, con las trampas a evitar y el caso de las claves delegadas en CNAME, es objeto de nuestra guía de la rotación de claves. Un último recordatorio de la misma higiene: la clave privada es un secreto crítico, a almacenar como tal (cofre de secretos, acceso restringido), nunca en claro en un repositorio o en un ticket.

¿1024 o 2048 bits?: el tamaño de la clave

Para las claves RSA, dos tamaños se encuentran sobre el terreno. El de 1024 bits, durante mucho tiempo el valor por defecto, sigue siendo aceptado por los verificadores pero ya no ofrece un margen de seguridad serio: la RFC 8301 lo fijó como mínimo absoluto, y factorizar una clave de ese tamaño ya no está fuera del alcance de un adversario con muchos recursos. El de 2048 bits es el estándar actual: margen criptográfico holgado, soporte universal del lado destinatario, y su única restricción práctica — el registro DNS dividido en varias cadenas — es un asunto menor con cualquier proveedor DNS decente.

La regla es, pues, sencilla: toda clave nueva se genera en 2048 bits, y un dominio todavía equipado en 1024 aprovecha su próxima rotación para subir de nivel — exactamente el tipo de cambio que el mecanismo de los selectores vuelve indoloro. La historia, además, ya ha dictado sentencia: las claves cortas (512 y 768 bits) fueron factorizadas públicamente hace más de una década, y los grandes proveedores penalizan o ignoran las firmas producidas con claves débiles. El argumento completo, con cifras, está en la comparativa 1024 frente a 2048 bits.

Más allá de RSA, la RFC 8463 introdujo las claves Ed25519: mucho más cortas a robustez equivalente, caben sin división en un registro DNS. Su soporte del lado de los verificadores progresa pero sigue siendo parcial; la práctica recomendada es publicarlas como segundo selector, en doble firma junto a una clave RSA 2048, nunca como sustitución en seco.

DKIM y DMARC: la alineación del d=

Hay que decirlo sin rodeos: DKIM por sí solo no protege contra la suplantación de identidad. Una firma DKIM válida demuestra que el mensaje está íntegro y firmado por el dominio d= — pero nada, en DKIM, exige que ese d= corresponda al dominio que el lector ve en el campo From:. Un atacante puede firmar limpiamente con su propio dominio y mostrar el suyo en el From:: DKIM aparecerá en verde.

Ese es precisamente el eslabón que DMARC añade: la alineación. Para que un mensaje supere DMARC vía DKIM, la firma debe ser válida y su dominio d= debe estar alineado con el dominio del From:. En modo relaxed (el predeterminado), basta un dominio organizativo común — newsletter.ejemplo.es firmante se alinea con un From: en ejemplo.es; en modo strict (adkim=s), la igualdad debe ser exacta. Esta regla es la que transforma una prueba de integridad en una verdadera protección de identidad, y por eso DKIM se despliega siempre con DMARC en el horizonte — el funcionamiento completo de la política está descrito en la página de referencia DMARC.

La alineación DKIM tiene una propiedad decisiva: sobrevive al reenvío (forwarding). Cuando un correo se reencamina — de un buzón profesional a una dirección personal, por ejemplo —, es el servidor que reenvía quien lo entrega, y la dirección IP de origen ya no corresponde: el control de IP falla, como explica la página de referencia SPF. La firma DKIM, en cambio, viaja dentro del mensaje: mientras el contenido firmado no se modifique, sigue siendo válida tras uno o varios saltos. En el correo reenviado, DKIM es a menudo el único mecanismo todavía capaz de producir un resultado alineado — razón por la cual una política DMARC estricta sin un DKIM sólido es una política frágil. El límite también existe: las listas de distribución que reescriben el asunto o añaden un pie de página rompen la firma, un caso que el estándar ARC intenta recuperar. En la práctica, un DKIM firmado y alineado en todas las fuentes es la condición número uno para recorrer con serenidad el camino de p=none a p=reject.

Verificar una firma DKIM

Buena noticia: no hay nada que recalcular por su cuenta. Cada servidor destinatario verifica las firmas y consigna su veredicto en una cabecera Authentication-Results, visible en el código fuente de cualquier mensaje recibido:

Authentication-Results: mx.example.net;
  dkim=pass header.d=ejemplo.es;
  spf=pass ...; dmarc=pass ...

Dos informaciones cuentan. dkim=pass: la firma es criptográficamente válida. header.d=: el dominio firmante — es el que hay que comparar con el From: para juzgar la alineación. Un dkim=pass con el header.d= de un proveedor no aporta nada a DMARC: firma válida, identidad no alineada. La lectura detallada de estas cabeceras, etiqueta por etiqueta, con las causas de fallo típicas, se cubre en nuestra guía de verificación de una firma.

Ese control unitario, sin embargo, no dice nada del conjunto de los flujos. La vista exhaustiva viene de los informes agregados DMARC, que recogen, fuente por fuente, los resultados DKIM y su alineación tal como los grandes destinatarios los han evaluado realmente — el objeto de nuestra guía de los informes agregados. Y para un estado inmediato de su dominio — selectores detectados, claves publicadas, alineación, política DMARC — nuestro comprobador DKIM gratuito lo muestra todo en unos segundos, sin registro.

FAQ

¿Es DKIM obligatorio para enviar correos?

Formalmente, no: un mensaje sin firma DKIM puede entregarse. En la práctica, sí. Las exigencias para remitentes de Gmail y Yahoo imponen DKIM a los envíos masivos, DMARC no puede producir una alineación robusta sin él, y los destinatarios conceden menos confianza al correo sin firmar. Para cualquier dominio que envíe correo profesional, DKIM es un requisito de hecho.

¿DKIM cifra el contenido de los mensajes?

No. DKIM firma, no cifra: desde ese punto de vista el mensaje circula en claro, y la firma solo demuestra su origen y su integridad. La confidencialidad del transporte corresponde a otros mecanismos (TLS entre servidores, reforzado por MTA-STS), y el cifrado de extremo a extremo a otras herramientas (S/MIME, OpenPGP).

¿Qué ocurre cuando una firma DKIM falla?

Nada automático. Un dkim=fail aislado no provoca el rechazo del mensaje: es una señal, que el destinatario combina con SPF, la reputación y, sobre todo, la política DMARC del dominio. Es DMARC quien decide — si ni DKIM ni SPF producen un resultado alineado, se aplica la política publicada (none, quarantine o reject).

¿Cuántos selectores puede publicar un dominio?

Tantos como haga falta: el estándar no fija ningún límite. Un dominio activo publica habitualmente de cinco a diez selectores — uno o dos por servicio de envío, más los que coexisten temporalmente durante una rotación. La buena práctica no es limitarlos, sino inventariarlos: cada selector activo es una identidad capaz de firmar por el dominio, y un selector olvidado de un proveedor abandonado es una puerta que quedó abierta.

¿Con qué frecuencia hay que rotar la clave DKIM?

La referencia del sector es una rotación semestral, una vez al año como mínimo absoluto, y sin demora en caso de compromiso presunto o de separación de un proveedor. Gracias al doble selector, la operación se hace sin ninguna interrupción del flujo. Las claves delegadas en CNAME las rota el propio proveedor — compruebe que es realmente el caso, porque la delegación no es una garantía.

¿Puede un mensaje llevar varias firmas DKIM?

Sí, y es corriente: el estándar autoriza varias cabeceras DKIM-Signature en un mismo mensaje. Una plataforma de emailing firma a menudo con su propio dominio y con el de usted; una doble firma RSA + Ed25519 es también una práctica de transición. Para DMARC, basta una sola firma válida y alineada — las demás no estorban.