Cómo verificar la firma DKIM de un email

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

Verificarlo a mano, sin esperar un email

La mitad de la ecuación se controla sin siquiera enviar un mensaje: la clave pública. El selector se consulta en DNS:

dig TXT selector._domainkey.ejemplo.es

Ahí debe figurar un registro v=DKIM1; k=rsa; p=... con una clave pública completa y no vacía. Una clave ausente, truncada o un p= vacío (clave revocada) garantiza el fallo. Para la verificación de extremo a extremo —firma incluida— un analizador lo abarca todo: nuestro analizador DMARC gratuito confirma la presencia y la validez de la clave, y, junto con los informes, la alineación real de cada fuente.

La alineación: lo único que cuenta para DMARC

Repitámoslo, porque es el error nº 1: una firma DKIM válida solo le sirve a DMARC si está alineada. La alineación DKIM significa que el dominio d= de la firma corresponde al dominio del From:. Muchas plataformas firman por defecto con su propio dominio (d=plataforma.com): dkim=pass, pero sin alineación, así que DMARC no se apoya en ello. La prueba definitiva de la alineación se lee en los informes agregados, fuente por fuente. Para el concepto completo, cómo funcionan juntos los tres protocolos recompone el cuadro.

Por qué una firma legítima falla a veces

Una firma puede fallar aunque el mensaje sea perfectamente legítimo. Las causas clásicas:

• El cuerpo del mensaje se ha modificado en tránsito. Una lista de distribución que añade un pie de página, una pasarela que reescribe el contenido: el hash bh= ya no coincide, la firma se rompe. Es frecuente con las listas y algunos reenvíos.
• La clave pública está ausente o truncada en el selector indicado (por falta de publicación, clave cortada al copiar y pegar).
• El selector no corresponde a nada: típicamente tras una rotación donde el antiguo selector se retiró demasiado pronto.
• La clave está revocada (p= vacío) o la propagación DNS no ha terminado para una clave recién publicada.

Buena noticia: DKIM sobrevive mejor al reenvío que SPF (la firma viaja con el mensaje), lo que lo convierte en el anclaje más fiable para la alineación DMARC, cuando el cuerpo no se modifica.

El caso de los reenvíos y las listas

Un punto que desconcierta: un mensaje reenviado o pasado por una lista de distribución puede ver su firma DKIM romperse si el contenido se altera. No es un defecto de la configuración de origen: es la lista la que modifica el mensaje tras la firma. Para estos casos, existen mecanismos complementarios (como ARC, que preserva el resultado de autenticación a través de los intermediarios), pero lo esencial a recordar es que no hay que entrar en pánico ante fallos DKIM aislados que proceden manifiestamente de reenvíos: el volumen y la fuente se miran antes de concluir que hay un problema.

Desmenuzar un Authentication-Results completo

Esta cabecera condensa el veredicto de los tres mecanismos, y saber leerla ahorra muchas suposiciones. Un ejemplo:

Authentication-Results: mx.exemple.com;
  dkim=pass header.d=empresa.es header.s=mail2025;
  spf=fail smtp.mailfrom=router.com;
  dmarc=pass (p=reject) header.from=empresa.es

Descodifiquemos. dkim=pass header.d=empresa.es: la firma es válida y alineada con el dominio del From:, perfecto. spf=fail: aquí SPF falla, porque el sobre pertenece al enrutador, no al emisor; no es grave, porque DMARC solo necesita una única alineación. dmarc=pass (p=reject): pese al fallo SPF, el mensaje satisface DMARC gracias al DKIM alineado. Es la ilustración concreta de por qué la alineación DKIM es el caballo de tiro de los despliegues reales: salva la autenticación allí donde SPF, a causa del sobre de un tercero, no se alinea. Leer esta cabecera entera, en lugar de detenerse en el primer pass, dice exactamente por qué un mensaje pasa o falla.

Cuando un mensaje lleva varias firmas

Encontrar varias cabeceras DKIM-Signature en un mismo mensaje no tiene nada de sorprendente: es común y perfectamente legítimo. Muchas plataformas firman dos veces: una vez con su propio dominio, para el seguimiento de su reputación, y una vez con el del cliente, para la alineación DMARC. Cada firma se verifica de forma independiente, y Authentication-Results muestra entonces un veredicto dkim= por firma. La regla a recordar: DMARC solo necesita una única firma válida y alineada para pasar. Una firma fallida o no alineada junto a un pass alineado no es un problema que corregir: es simplemente la firma propia de la plataforma haciendo su trabajo por su lado. Al leer las cabeceras, la firma que hay que localizar es aquella cuyo d= corresponde al From:: es esa cuya suerte cuenta.

Cuando DKIM por sí solo no basta

DKIM verifica la integridad y el origen, pero no dice nada, por sí solo, de lo que un destinatario debe hacer con un mensaje sin firmar o suplantado. Ese es el papel de DMARC, que se apoya en la alineación DKIM (o SPF) y aplica su política. Dicho de otro modo, verificar que una firma DKIM pasa es necesario pero no suficiente: mientras la política DMARC siga en p=none, un mensaje que suplanta el dominio —sin ninguna firma válida detrás— llega igualmente a los buzones. La verificación DKIM es, pues, una pieza de un edificio más amplio; una vez las firmas fiables y alineadas, el siguiente paso es endurecer DMARC hasta p=reject, para que la ausencia de firma válida tenga por fin consecuencias reales para los suplantadores.

Preguntas frecuentes

¿Dónde se ve si DKIM pasa? En la cabecera Authentication-Results del mensaje recibido (dkim=pass/fail), y de forma agregada en los informes DMARC. «Mostrar original» en la mayoría de los webmails da acceso a las cabeceras.

¿Basta con dkim=pass? Para la validez de la firma, sí. Para DMARC, no: hace falta además que header.d (el dominio firmante) se alinee con el From:. Los dos se comprueban siempre juntos.

¿Por qué mi DKIM falla solo en algunos emails? A menudo porque esos mensajes pasan por una lista o un reenvío que modifica el cuerpo, rompiendo el hash. Los envíos directos, en cambio, pasan. El perfil (listas, bajo volumen disperso) delata la causa.

¿Se puede verificar el DKIM de un dominio de un tercero? Sí: su clave pública es consultable (el DNS es público) y el resultado se lee en las cabeceras de un email procedente de ese dominio. Es útil para diagnosticar a un socio.

Una clave con p= vacío, ¿es normal? No: un p= vacío señala una clave revocada. Unas firmas que apunten a un selector cuya clave está vacía fallarán: hay que volver a publicar una clave válida.

¿Cuánto tiempo hace falta para que DKIM sea visible en los informes? Los informes DMARC se envían al final del periodo de informe (a menudo 24 h). Las primeras firmas verificadas aparecen al día siguiente de la activación. Si el volumen de envío es bajo, quizá hagan falta unos días para tener una muestra representativa.

Integrar la verificación en la rutina

La verificación DKIM no debería ser un gesto puntual que se hace en el momento de la configuración y luego se olvida. Tres momentos clave merecen una verificación activa: al activar (confirmar que la clave está publicada, la firma pasa y se alinea); tras cada rotación (confirmar que el nuevo selector firma correctamente y que el antiguo no ha dejado ningún fallo); y periódicamente, a través de los informes agregados DMARC (confirmar que todas las fuentes mantienen su alineación en el tiempo, sin deriva silenciosa). Los informes agregados son especialmente útiles porque cubren el conjunto de las fuentes de envío sin necesidad de mandar un email de prueba a cada una: dan una visión sistemática, dominio por dominio, fuente por fuente. Poner la lectura de los informes en una rutina mensual —aunque sea rápida, aunque sea parcial— es la única forma de detectar una firma que se degrada antes de que impacte en la entregabilidad o en la postura DMARC.

Thomas confirma las firmas

Leer cabeceras a mano para cada fuente es tedioso e incompleto. Thomas, el CISO virtual, verifica que cada fuente firma en DKIM, que la firma es válida y está alineada con el dominio, y señala las fuentes cuya firma se rompe —listas y reenvíos aparte— antes de que hundan la preparación para p=reject.

Analizar un dominio gratis o crear una cuenta para firmas DKIM verificadas de forma continua.