DKIM es una firma criptográfica que tu servidor añade a cada correo antes de enviarlo. Quien lo recibe busca en el DNS de tu dominio la clave pública que la verifica y comprueba dos cosas: que el mensaje salió de quien dice, y que nadie lo ha tocado por el camino.
Dicho de otra forma: es la tarjeta de embarque a tu nombre. No configurar DKIM es como intentar pasar el control del aeropuerto con la tarjeta de otra persona: puedes llegar hasta el mostrador, pero no vas a embarcar.
El registro SPF comprueba desde dónde salió el correo: si la IP que lo entregó estaba autorizada. No mira el mensaje.
DKIM comprueba el mensaje en sí. Firma la cabecera y el cuerpo con una clave privada que solo tienes tú, y el destinatario verifica esa firma con la clave pública que has publicado en tu DNS. Si algo del mensaje ha cambiado desde que se firmó, la verificación falla.
Y hay una diferencia que importa más de lo que parece: el dominio que DKIM valida es el que aparece en la firma, y ese sí puede coincidir con el que ve tu cliente. Por eso, cuando DMARC comprueba la alineación, lo que mira es precisamente ese dominio.
Cuando llega un correo firmado, el servidor que lo recibe hace esto:
DKIM-Signature del mensaje.d=) y el selector (etiqueta s=).Si algo de eso no cuadra, DKIM falla. Y a diferencia de otros mecanismos, aquí no hace falta ninguna autoridad certificadora: el que verifica pide la clave directamente al dominio que dice haber firmado.
Hay dos partes. La que publicas tú es un registro en el DNS —de tipo TXT o CNAME, según el proveedor— colgado de un nombre con esta forma:
selector._domainkey.tudominio.comLa otra parte viaja dentro de cada correo, en una cabecera que el destinatario lee y tú normalmente no ves:
DKIM-Signature: v=1; a=rsa-sha256; d=tudominio.com; s=selector;
h=from:to:subject:date; bh=...; b=...| Etiqueta | Qué contiene |
|---|---|
d= | El dominio que firma. Es el que cuenta para DMARC y para la reputación |
s= | El selector: dice en qué punto del DNS está la clave pública |
h= | Qué cabeceras se han firmado |
bh= | El resumen del cuerpo del mensaje |
b= | La firma propiamente dicha |
El selector es lo que permite tener varias claves a la vez en el mismo dominio: una por cada sistema que envíe en tu nombre. Tu plataforma de envíos usa la suya, tu correo corporativo la suya, y cada una publica su clave en un punto distinto del DNS.
Por eso, para comprobar el DKIM de un sistema concreto necesitas saber qué selector usa. Y no siempre te lo dicen.
Se encuentra en el propio correo. Abre un mensaje enviado desde ese sistema, entra en «Mostrar original» y busca la línea DKIM-Signature. El valor que va después de s= es el selector.
Es de lo que más me piden cuando alguien intenta comprobar su autenticación por su cuenta y se queda atascado: comprueba el dominio principal, le sale bien, y da por hecho que todo está firmado. Cada sistema hay que comprobarlo por separado, con su propio selector.
Aquí hay una diferencia que confunde a mucha gente. El registro SPF es uno solo, y todos los proveedores tienen que caber dentro de él. DKIM es lo contrario: una entrada por cada proveedor, cada una con su selector y su clave.
Lo que sí se mantiene es la regla de la unicidad: un selector, un registro. Si hay más de uno con el mismo nombre, la especificación dice que el resultado queda sin definir — cada servidor puede hacer una cosa distinta, y ninguna es la que tú esperas.
Sobre la longitud de la clave: se generan de 1024 o de 2048 bits. La recomendación es 2048, que es más segura. El problema es que algunos proveedores de DNS no admiten registros TXT tan largos, así que si al publicarla da error, la de 1024 sirve mientras se resuelve.
DKIM firma el contenido. Así que cualquier cosa que modifique el mensaje por el camino invalida la firma, aunque quien lo modifique no tenga mala intención.
Lo que más lo rompe:
Aun así, DKIM aguanta los reenvíos mucho mejor que el SPF: la firma viaja con el mensaje, no depende del servidor que lo entrega. Por eso a DMARC le basta con que pase uno de los dos.
Esto casi nadie lo cuenta y es lo que más consecuencias tiene.
La reputación de envío se acumula en el dominio que firma, el de la etiqueta d=. No en el que aparece en pantalla, ni en la IP.
La consecuencia es directa: si envías desde una plataforma y esa plataforma firma con su dominio en vez de con el tuyo, el historial de esos envíos —bueno o malo— se le acumula a ella, no a ti. Estás construyendo reputación para otro.
Y al revés: cuando configuras la firma con tu propio dominio, todo lo que envías empieza a sumar en el mismo sitio, aunque salga de cinco plataformas distintas. Es lo que convierte cinco historiales sueltos en uno solo que es tuyo.
Por eso, cuando alguien me dice que lleva años enviando y que su dominio «no tiene reputación», lo primero que miro es con qué dominio se está firmando. Muchas veces no es que la tenga mala: es que nunca ha tenido ninguna, porque llevaba años prestándosela a otro.
Todas las guías dicen lo mismo: configura DKIM cuanto antes. Falta el matiz que hace que a veces sea mala idea hacerlo hoy.
Al firmar con tu dominio, te haces responsable del historial de envío. Y si hasta ahora enviaba una plataforma firmando con el suyo, ese historial —bueno o malo— nunca había pasado por tu dominio.
Piensa en lo que ocurre cuando alguien lleva años enviando desde una herramienta que firmaba con su propio dominio. Los proveedores han estado juzgando a esa herramienta, no a él. Su dominio no tiene mala reputación: es que no tiene ninguna.
El día que activa DKIM con su dominio, todo ese tráfico empieza a contar en su casa. Si la lista está limpia, perfecto. Si la lista está sucia —contactos que no abren desde hace años, direcciones muertas, alguna trampa de spam por medio— hereda el problema entero de golpe, y lo nota en la siguiente campaña.
Es como estar parado en un semáforo con un coche de policía al lado y arrancar quemando rueda. Nadie te estaba mirando; ahora sí.
Las tres preguntas antes de activarlo son siempre las mismas:
Cuando el diagnóstico dice que la lista no está para eso, DKIM no se activa el primer día: primero se limpia y se calienta el dominio, y después se firma. El orden importa más que la prisa.
Sí, y es lo normal: uno por cada sistema que envíe en tu nombre, cada uno con su selector. Lo que no puede haber es más de un registro para el mismo selector; en ese caso el resultado queda sin definir.
Abre un correo enviado desde el sistema que quieras comprobar, entra en «Mostrar original» y busca la línea DKIM-Signature. Lo que va después de s= es el selector. Necesitas hacerlo con cada sistema por separado, porque cada uno usa el suyo.
Casi siempre porque algo modifica el mensaje por el camino: una lista de correo que añade un pie, un antivirus que inserta una línea, un reenvío que reescribe el contenido. La firma cubre el mensaje tal y como salió; si cambia, deja de cuadrar.
No son alternativas, comprueban cosas distintas. El SPF valida desde dónde salió el correo; DKIM valida el mensaje y quién lo firma. DKIM aguanta mejor los reenvíos, y su dominio es el que suele contar para la reputación, pero lo que se recomienda es tener los dos y que al menos uno alinee con DMARC.
Si la lista está limpia y se gestiona el compromiso, sí. Si no, conviene mirarlo antes: al firmar con tu dominio te haces responsable de un historial de envío que hasta ahora se le acumulaba a la plataforma. Con una lista descuidada y volumen alto, activar sin preparar el dominio empeora las cosas en la siguiente campaña. Primero limpiar y calentar, después firmar.
Pasa, sobre todo en las plataformas más baratas: no ofrecen forma de firmar con tu dominio. Es un motivo de peso para cambiar, porque sin DKIM propio no puedes alinear con DMARC ni acumular reputación en tu dominio, y con los requisitos actuales de Google, Yahoo y Microsoft eso se paga.
Sirve para que el correo esté firmado, pero conviene mirar con qué dominio firma. Si firma con el suyo, la reputación de esos envíos se acumula en su dominio y no en el tuyo, y además no alineará con DMARC. Casi todas las plataformas permiten configurar la firma con tu dominio; en algunas está en los planes básicos y en otras no.
Estar firmado no es lo mismo que estar bien firmado, ni que estar firmado con el dominio que te interesa. Ahí empieza el diagnóstico: con qué dominio firma cada sistema, qué selector usa y si eso cuadra con lo demás.
Nuria Palomo, la Dra. Spam
Experta en entregabilidad de email y reputación de dominio desde 2019.