DKIM2: qué es nuevo, qué cambia y fechas clave

TL;DR — DKIM2 es una reescritura que avanza actualmente en el IETF (Internet-Drafts). Busca firmar el origen y el destino de cada salto SMTP, encadenar firmas (i=1, i=2, ...), documentar las modificaciones de los intermediarios y hacer que los rebotes (DSN) sean trazables a lo largo de la cadena. DKIM2 aún no es un estándar: evoluciona rápidamente, pero los principales ladrillos ya están presentes.

ℹ️ Los términos DKIM replay y backscatter se definen en el glosario al final del artículo.

¿Por qué hablar de DKIM2 ahora?

DKIM (STD 76, RFC 6376) está desplegado masivamente para firmar el contenido del correo. Pero muestra sus límites frente al DKIM replay, las modificaciones aplicadas por listas de distribución/reenviadores y el backscatter (rebotes enviados a terceros). DKIM2 propone un modelo en el que cada relay añade su propia firma numerada y declara explícitamente el par origen → destino del siguiente salto, lo que permite:

• detectar y limitar los replays;
• encaminar rebotes e informes a lo largo de la ruta autenticada;
• describir y, cuando sea posible, revertir los cambios de cuerpo/encabezados para validar la firma original.

Principales novedades (frente a DKIM "v1")

1. Nuevo encabezado DKIM2-Signature (sin campo de versión)

   • Numeración con i= (1, 2, ...). Un hueco en la secuencia invalida la cadena.
   • Marca de tiempo t=; un verificador puede considerar una firma caducada tras cierta ventana (p. ej., 14 días).
   • Algoritmos: se apuntan RSA-SHA256 y Ed25519-SHA256, con agilidad criptográfica prevista.
   • Claves en el DNS: igual que en DKIM, bajo selector._domainkey.dominio.

2. Encadenado y alineación con el sobre SMTP

   • mf= (MAIL FROM) y rt= (RCPT TO) describen el sobre usado en el salto firmado.
   • Cada nuevo salto debe corresponder al destino anterior (o firmarse en "proxy" mediante pp=).
   • El verificador valida primero la firma más reciente (el i más alto).

3. Modelado de modificaciones

   • El borrador introduce un encabezado MailVersion para describir cómo volver a la versión anterior (recetas de cuerpo/encabezados).
   • La firma lleva mv= para la versión del mensaje cubierta.
   • Un campo f= (flags) puede indicar modifiedbody, modifiedheader, exploded, donotmodify, feedback, etc.

4. Rebotes y feedback

   • Los DSN y el feedback se reenvían hacia arriba de la cadena a un actor implicado, lo que limita el backscatter.
   • Posibilidad de indicar preferencias de feedback (según la versión del borrador).

5. Compatibilidad y coexistencia

   • DKIM2 no deja obsoleto a DKIM (RFC 6376) de inmediato: se espera una fase de transición con coexistencia.
   • Los registros DNS siguen bajo _domainkey. Se prevé la firma por delegación (pp=), con restricciones de alineación y pruebas de autorización vía DNS (p. ej., registro dedicado o relación MX), según los borradores.

Qué desaparece o cambia de manera significativa

• Sin v= en DKIM2-Signature (si llegara una ruptura mayor, se crearía un futuro "DKIM3-Signature" en lugar de aumentar un número de versión interno).
• Lista simplificada de encabezados firmados: se fija un conjunto base de campos obligatorios; h= sigue disponible para casos específicos.
• Gestión de expiración simplificada: se apoya en t= y en recomendaciones lado verificador en lugar de un campo normativo estricto.
• Parámetros heredados de DKIM considerados demasiado complejos (p. ej., z=) se abandonan en los primeros borradores.

⚠️ DKIM2 está en redacción: la sintaxis exacta (nombres de tags, flags, plazos) aún puede cambiar. Comprueba las versiones de los borradores citados más abajo.

Ejemplo de encabezados (borradores actuales)

DKIM2-Signature: i=1; t=2025-10-24T08:01:02Z; d=example.com; s=sel2025;
  a=ed25519-sha256; bh=BASE64(...); b=BASE64(...);
  rt=user@dest.tld; mf=bounce@example.com; mv=2; f=modifiedheader,feedback

MailVersion: v=2; bh=BASE64(...);
  h.Subject=d:*,t:[Re] Oferta especial;
  h.From=d:*,b=am9obi5kb2VAZXhhbXBsZS5jb20=

Impacto operativo (resumen)

• ESP / relays: firmar cada salto, gestionar mf=/rt=, registrar/revertir modificaciones sencillas (recetas) y reenviar hacia dominios de destino alineados.
• Destinatarios: verificar primero la firma más reciente (i=Max) y retroceder si hace falta; rechazar pronto ante fallos graves.
• DNS: selectores y claves sin cambios bajo _domainkey; planificar autorizaciones "proxy" según el mecanismo DNS que definan los borradores.
• DMARC: mientras DMARCbis haga referencia a DKIM (RFC 6376), DMARC sigue apoyándose en DKIM. El paso de DMARC a DKIM2 no es inmediato.

Cronología: hitos recientes

• 5 nov. 2024: primeros artículos de análisis público sobre DKIM2 (p. ej., Red Sift).
• 20 nov. 2024: notas de anuncio por parte de actores DMARC.
• 3 sept. 2025: el grupo de trabajo del IETF adopta el documento Motivation (draft-ietf-dkim-dkim2-motivation-01).
• 17–20 oct. 2025: publicación de los borradores -spec-02 (especificación), -dns-03 (DNS), -header-04 (encabezados) y -modification-algebra-04 (MailVersion).

Plan de preparación

1. Inventariar dónde ya firmas/verificas DKIM (flujos, saltos, SRS/VERP, listas).
2. Prototipar en los relays: calcular mf=/rt=, añadir i=, elegir algoritmos (Ed25519 recomendado) y gestionar t=.
3. Rastrear las modificaciones habituales (footers de listas, reescritura de From:) y probar su reversión mediante MailVersion.
4. DNS: normalizar el ciclo de rotación de claves; preparar el mecanismo de autorización "proxy" si hace falta.
5. Verificación: implementar la estrategia "último i= primero", emitir rechazos 5xx durante el intercambio SMTP si la firma falla, 4xx ante TEMPFAIL de DNS.
6. Vigilar los borradores (más abajo) y planificar feature flags para seguir los cambios de campos.

Glosario

DKIM replay

• Definición: reutilización (replay) de un mensaje ya firmado con DKIM por un dominio legítimo para reenviarlo masivamente o hacia otros objetivos sin alterar lo cubierto por la firma. La firma se mantiene válida porque DKIM firma el contenido (cuerpo/encabezados) pero no el sobre SMTP ni la ruta.
• ¿Por qué?: un atacante obtiene una copia de un correo firmado (p. ej., un boletín) y lo redistribuye tal cual; DMARC puede seguir pasando si From: permanece alineado.
• Síntomas: picos de volumen en la misma firma (bh= idéntico), quejas de spam, reputación deteriorada del dominio firmante.
• Mitigaciones: limitar el caudal por selector, rotar claves, firmar con caducidades cortas, endurecer DMARC (p=reject), filtrado conductual en recepción.
• Qué cambia con DKIM2: la firma incluye el sobre por salto (mf=/rt=) y encadena la ruta (número i=), lo que hace el replay detectable (ruta incoherente) y permite sanciones específicas.

Backscatter

• Definición: rebotes no solicitados (NDR/DSN) o autorespuestas enviados a un tercero inocente cuya dirección fue suplantada en MAIL FROM/Return-Path.
• ¿Por qué?: los servidores aceptan primero el mensaje y luego generan un rebote posterior; con una dirección suplantada, el rebote vuelve a la víctima.
• Síntomas: avalanchas de DSN/autorespuestas en un buzón legítimo, reputación dañada, posibles listados.
• Mitigaciones: rechazar durante el intercambio SMTP (no después), SPF/DMARC estrictos, SRS/VERP para trazar rebotes, reglas contra autorespuestas.
• Qué cambia con DKIM2: los DSN/feedback se pueden encaminar hacia arriba mediante la cadena firmada, lo que reduce el backscatter y hace llegar el aviso al actor implicado.

Fuentes y lecturas recomendadas

• DKIM2 – especificación: draft-clayton-dkim2-spec-02 (20 de octubre de 2025, expira el 23 de abril de 2026).
• DKIM2 – DNS: draft-chuang-dkim2-dns-03 (20 de octubre de 2025).
• DKIM2 – encabezados: draft-gondwana-dkim2-header-04 (20 de octubre de 2025).
• DKIM2 – álgebra de modificaciones / MailVersion: draft-gondwana-dkim2-modification-algebra-04 (17 de octubre de 2025).
• Motivation (documento del grupo de trabajo del IETF): draft-ietf-dkim-dkim2-motivation-01 (3 de septiembre de 2025, sustituye las versiones individuales).
• Recordatorio DKIM: RFC 6376; actualizaciones: RFC 8301, RFC 8463.

DKIM2 sigue siendo un trabajo en curso. Actualizaremos esta página cuando los borradores avancen hacia una RFC.