DKIM: el sello que demuestra quién escribió el mensaje

DKIM firma cada mensaje con una clave que solo usted tiene. Cómo es el registro, por qué el selector es el punto débil de cualquier comprobación y qué hacer con cada hallazgo.

Si SPF es una lista de invitados, DKIM es un sello de lacre. Al salir, su servidor de correo calcula una firma sobre el mensaje con una clave privada que solo él conoce. La clave pública correspondiente está publicada en su DNS. El servidor que recibe el mensaje la busca, recalcula y comprueba dos cosas a la vez: que el mensaje salió de donde dice y que nadie lo ha alterado por el camino.

Esa segunda parte es la que hace a DKIM imprescindible. Una lista de servidores deja de servir en cuanto alguien reenvía el mensaje desde otra máquina; una firma, no. Por eso una empresa cuyo correo se reenvía mucho —asociaciones, despachos, cualquiera con alias de reenvío— nota la diferencia entre tener DKIM y no tenerlo mucho antes que el resto.

Cómo es el registro

La clave pública se publica en un nombre con dos partes fijas y una variable: el selector, la etiqueta _domainkey y su dominio.

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

Muchos proveedores no publican el registro TXT directamente, sino un CNAME que apunta a su infraestructura. Microsoft 365 lo hace con selector1 y selector2 apuntando a su inquilino en onmicrosoft.com; IONOS, con s1-ionos y s2-ionos apuntando a dkim.ionos.com. Para quien comprueba desde fuera es equivalente: se sigue el alias y se lee la clave al final. La ventaja para usted es que la rotación de claves la hace el proveedor sin que tenga que tocar nada.

El selector es el punto ciego

Aquí está la limitación que cualquier comprobación de DKIM tiene y que casi ninguna herramienta reconoce: en el DNS no está escrito en ningún sitio qué selector usa un dominio. SPF y DMARC viven en nombres fijos, así que se encuentran siempre. DKIM no. Solo se puede preguntar por nombres concretos y ver cuáles responden.

Nuestra comprobación prueba los selectores habituales de los proveedores de cinco mercados, que son estos para el mercado español:

Con Amazon SES adivinar no sirve de nada: asigna tres selectores aleatorios. Lo mismo ocurre con HubSpot, que añade el número de portal, y con OVH, que añade una referencia numérica. En esos casos el informe lo dice en lugar de fingir un resultado.

Cómo se configura

DKIM se activa casi siempre en el panel del proveedor de buzones, que genera la clave y le indica qué publicar en el DNS. Usted no crea la clave a mano.

Paso a paso en Microsoft 365

1. Abra el portal de Microsoft Defender y vaya a Directivas y reglas → Directivas de amenazas → DKIM.
2. Elija su dominio. Si nunca se ha activado, verá dos registros CNAME con sus valores.
3. Publique esos dos CNAME en el DNS del dominio, con los nombres selector1._domainkey y selector2._domainkey.
4. Vuelva al portal y ponga el interruptor Firmar mensajes para este dominio en activado. Si sale un error, es que los CNAME todavía no se ven desde fuera: espere y repita.
5. Envíese un mensaje desde ese dominio a una cuenta externa y mire las cabeceras: debe aparecer dkim=pass.

Los hallazgos, uno por uno

No se ha encontrado ninguna clave DKIM

Hemos probado los selectores habituales de los proveedores que conocemos y ninguno ha respondido con una clave.

Esto no significa que su dominio no tenga DKIM. Significa que no hemos acertado con el nombre. Es la diferencia más importante de toda esta página: en el DNS no hay forma de averiguar qué selector usa un dominio, solo se pueden probar nombres conocidos. Un proveedor pequeño o un selector propio se nos escapan.

Qué hacer. Antes que nada, consiga una respuesta segura. Envíese un mensaje desde el dominio a una cuenta externa, abra sus cabeceras y busque la línea DKIM-Signature: el valor de s= es el selector. Péguelo en el campo del formulario, o pegue las cabeceras enteras, y repita la comprobación. Si de verdad no hay firma, actívela en el panel de su proveedor de buzones con la tabla de arriba.

Clave DKIM revocada

Uno de los selectores existe, pero su registro no contiene clave: el campo p= está vacío.

Es lo que se hace al retirar un selector antiguo después de un cambio de claves. Publicar el registro vacío en lugar de borrarlo es correcto: indica expresamente que las firmas antiguas ya no valen, en vez de dejar que el receptor no sepa qué pensar.

Qué hacer. Compruebe que existe otro selector con clave y que sus mensajes se firman con él. Si es así, no hay nada urgente; el registro vacío puede borrarse pasadas unas semanas. Si ese era el único selector, lea el hallazgo siguiente.

Todas las claves DKIM encontradas están revocadas

Todos los selectores que hemos encontrado tienen el campo de clave vacío. No queda ninguna clave utilizable.

Esto importa porque su correo saliente ya no lleva firma válida. Mientras SPF aguante, la mayoría de mensajes seguirá entregándose, pero en cuanto alguien reenvíe uno o el SPF falle por cualquier motivo, DMARC no tendrá nada a lo que agarrarse y el mensaje se apartará o se rechazará.

Qué hacer. Genere una clave nueva en el panel de su proveedor de buzones y publique el registro que le indique. Si el cambio de claves se quedó a medias, es probable que el paso que falta sea activar el nuevo selector en el servidor de envío, no publicarlo.

Clave DKIM demasiado corta

La clave publicada tiene menos de 1024 bits.

Esto importa porque una clave por debajo de 1024 bits se considera insegura desde hace años, y varios proveedores grandes ya no evalúan esas firmas: para ellos, el mensaje llega sin DKIM. Suele venir de una configuración antigua hecha a mano en un servidor propio.

Qué hacer. Genere una clave nueva de 2048 bits y publíquela con un selector nuevo. Deje el selector antiguo publicado unos días, hasta que el servidor de envío firme con el nuevo, y retírelo después.

Clave DKIM de 1024 bits

La clave tiene 1024 bits. Se sigue aceptando en todas partes, así que no hay nada roto.

Importa como mantenimiento, no como incidencia: 2048 bits es el estándar actual, y las claves de 1024 son el resto de una activación de hace años. Hay una razón práctica por la que sobreviven: una clave de 2048 bits no cabe en el límite de 255 caracteres de una cadena TXT y hay que partirla en dos, cosa que algunos paneles antiguos hacían mal.

Qué hacer. Cámbiela en la próxima ocasión en que toque el DNS del dominio. Si su proveedor publica DKIM por CNAME, el cambio ya lo hace él y no tiene que hacer nada.

DKIM en modo de prueba (t=y)

El registro contiene el indicador t=y, que pide a los receptores que traten un fallo de firma como si no hubiera pasado nada.

Esto importa porque, mientras esté puesto, DKIM no protege. Es la bandera que se activa durante la puesta en marcha para no romper nada y que después nadie retira, porque todo funciona igual y no hay ningún síntoma.

Qué hacer. Compruebe primero que sus mensajes se firman correctamente: envíese uno a una cuenta externa y confirme dkim=pass en las cabeceras. Después edite el registro y quite t=y, dejando el resto intacto.

Clave DKIM ilegible

El registro existe, pero su contenido no se puede interpretar como clave.

La causa casi siempre es el copiado: un salto de línea dentro de la clave, un espacio en medio, comillas de más, o una clave de 2048 bits partida en dos cadenas que el panel ha vuelto a unir con un espacio por el medio.

Qué hacer. Vuelva a copiar el valor desde el panel de su proveedor y péguelo en una sola línea, sin espacios dentro de la clave. Si el panel exige partir el valor, respete el formato de dos cadenas entre comillas que indique el propio proveedor. Después compruébelo de nuevo: un registro ilegible equivale exactamente a no tener DKIM.

Preguntas frecuentes

¿Puedo tener varios selectores a la vez?

Sí, y es lo normal. Cada servicio que envía por usted publica el suyo: uno del proveedor de buzones, otro del boletín, otro de la tienda. No se estorban, porque cada mensaje lleva en su firma el selector con el que se hizo. A diferencia de SPF, aquí no hay ningún límite de consultas.

¿Cada cuánto hay que cambiar la clave?

Si su proveedor publica DKIM por CNAME, la rota él y usted no tiene que intervenir. Si la clave está publicada como TXT y la gestiona usted, una rotación al año es una práctica razonable: se publica el selector nuevo, se cambia el servidor de envío y se retira el viejo unos días después.

El informe dice que no encuentra DKIM, pero mi proveedor asegura que está activo.

Las dos cosas pueden ser ciertas: solo significa que su selector no está entre los nombres que probamos. Mire las cabeceras de un mensaje suyo, copie el valor de s= de la línea DKIM-Signature y repita la comprobación con ese selector.

¿Sirve DKIM sin DMARC?

Ayuda, pero a medias. DKIM demuestra que el mensaje es auténtico; sin DMARC nadie ha dicho qué debe hacer el receptor cuando la firma falta o falla. La instrucción la da DMARC.