En marzo de 2026, durante una prueba de enrutamiento interna, un equipo de deliverability de un ESP europeo observa que sus correos electrónicos hacia listas de distribución Mailman fallan sistemáticamente en la verificación DKIM, a pesar de tener claves correctamente configuradas. El mensaje es legítimo, el dominio está limpio, la lista es opt-in. Pero Mailman reescribió el encabezado From y la firma DKIM1 se rompe en ese preciso momento. DKIM2 busca corregir este tipo de ruptura. El grupo de trabajo IETF dkim adoptó los primeros borradores del protocolo en marzo de 2026: aún no es un RFC, cero implementación en producción, pero una arquitectura que distribuye la verificación a lo largo de todo el camino de entrega.
Por qué DKIM1 alcanza sus límites en 2026
DKIM1, formalizado en la RFC 6376 en 2011, cubre un ámbito preciso: demuestra que el dominio firmante realmente emitió el mensaje original. La especificación no sobrevive a los intermediarios. Cada servidor que toca el mensaje puede invalidar la firma: una lista de correo que agrega un pie de página, un gateway de seguridad que reescribe las URLs, un reenviador que modifica el sobre SMTP. Con una adopción DKIM cercana al 90% en correos directos en 2026, uno podría pensar que el problema está resuelto. Pero esta tasa mide el éxito en los correos que llegan directamente, no aquellos que transitan por listas de correo o reenviadores.
El borrador IETF draft-ietf-dkim-dkim2-motivation documenta tres fallas estructurales que DKIM1 no puede corregir. Primera: un correo electrónicamente firmado puede recibirse sin prueba de que el destinatario era realmente el destinatario previsto. Segunda: la dirección de rebote puede referenciar dominios que no jugaron ningún rol en el tránsito del mensaje. Tercera: no existe un mecanismo para documentar las modificaciones legítimas de los reenviadores o de las listas de correo. Estas lagunas son inherentes al diseño mismo del protocolo original, no a errores de configuración.
Desde 2024, Google y Yahoo han hecho obligatorios SPF, DKIM y DMARC para los envíos masivos. Esta presión ha acelerado la adopción sin resolver los problemas arquitecturales. El trabajo ha sido delegado al WG IETF dkim, que opera sobre varios borradores complementarios: especificación principal, documento de motivación, perfil de despliegue vía interfaz Milter y guía de buenas prácticas.
La cadena de firmas: sobrevivir a los intermediarios
El mecanismo central de DKIM2 se llama la cadena de firmas. En lugar de pedir a cada servidor que valide una única firma emitida al origen, el protocolo pide a cada intermediario que documente las modificaciones que ha hecho y firme esa documentación. El destinatario final reconstruye así la secuencia completa de transformaciones y verifica la legitimidad de cada una.
Richard Clayton, coautor de la especificación DKIM2, describe el enfoque como una «modificación algebra»: los intermediarios especifican la naturaleza exacta de sus modificaciones en lugar de simplemente estampar un sello de aceptación. Una lista de correo que agrega un pie de página lo declara en su firma. Un gateway de seguridad que reescribe URLs hace lo mismo. El destinatario evalúa entonces si cada transformación era esperada y autorizada.
En la práctica, los falsos positivos relacionados con las listas de distribución, hoy una fuente frecuente de invalidez DKIM1, salen del ámbito de responsabilidad del remitente. Clayton indicó en abril de 2026 que ya existe código funcional y que se esperan pruebas en proveedores de buzón en los próximos meses. La especificación técnica principal (draft-ietf-dkim-dkim2-spec-01) está fechada el 20 de abril de 2026.
NSD asíncronos y VERP: terminar con el backscatter
El segundo ángulo técnico de DKIM2 aborda un problema menos visible pero costoso para la reputación de los remitentes: el backscatter. Cuando un spammer falsifica la dirección de retorno con el dominio de un tercero inocente, los rebotes generados por servidores legítimos caen en la bandeja de entrada de ese inocente. IPs y dominios limpios terminan en listas negras debido a tráfico que nunca emitieron.
Steve Atkins de Word to the Wise, que sigue el caso desde hace varias semanas, señala que DKIM2 resuelve este problema mediante dos mecanismos combinados. Las Notificaciones de Estado de Entrega (NSD) asíncronas permiten que un servidor acepte un mensaje en SMTP y luego notifique el fallo más tarde, tras un análisis completo. VERP (Variable Envelope Return Path) codifica los metadatos necesarios directamente en la dirección de retorno, lo que evita la necesidad de interpretar el cuerpo del rebote. La combinación de ambos, según Word to the Wise del 27 de abril de 2026, permite “registrar el rebote inmediatamente e ignorar el NSD asíncrono sin procesamiento ni almacenamiento adicional.”
Para los managers de deliverability, los rebotes en DKIM2 siguen un camino firmado criptográficamente, regresando al servidor anterior en la cadena en lugar de a una dirección falsificada. El backscatter pierde su principal superficie de ataque. Atkins advierte que los volúmenes de rebotes asíncronos podrían aumentar varios órdenes de magnitud durante el despliegue inicial. Será necesaria un aumento de capacidad de entrada del lado de ESP.
Anti-replay: marcas de tiempo y vinculación de destinatarios
DKIM1 presenta una vulnerabilidad conocida pero subestimada: el ataque de replay. Una firma DKIM válida puede reutilizarse para enviar el mismo mensaje a destinatarios no previstos. El atacante recupera un correo legítimo, conserva su firma intacta y lo redistribuye a gran escala. Los filtros anti-spam detectan una firma válida y lo dejan pasar.
DKIM2 cierra esta ventana mediante dos mecanismos complementarios. Las firmas ahora incluyen los datos del sobre SMTP: remitente y destinatario. Un mensaje firmado para alice@example.com no puede ser reenviado a bob@example.com sin invalidar la firma. Las flags también controlan la distribución autorizada del mensaje. Este mecanismo de vinculación de destinatarios, como lo destaca Al Iverson de SpamResource (que sigue los trabajos del WG IETF DKIM), podría modificar la superficie de ataque de las campañas de spam más sofisticadas.
Los sellos de tiempo completan el dispositivo. Una firma DKIM2 tiene una validez temporal explícita, lo que evita la reutilización de un mensaje legítimo antiguo en una campaña maliciosa. Iverson señala que las claves DKIM en sí mismas no necesariamente cambian con DKIM2. Los remitentes podrían no tener que hacer ninguna modificación significativa en su lado de DNS. Lo que evoluciona es la infraestructura de verificación y la cadena de firmas, no la configuración de los remitentes.
Lo que DKIM2 no reemplaza: la calidad de lista
DKIM2 asegura el camino de entrega, sin cambiar nada en cuanto a la calidad de los destinatarios. Una firma que sobrevive a los intermediarios, rebotes enrutados criptográficamente y una protección contra el replay suponen que las direcciones de destino son válidas y comprometidas. En una lista que contiene un 20% de direcciones inválidas o inactivas, DKIM2 no mejora la tasa de entrada en bandeja de entrada. Autentica mejor los correos que los filtros seguirán rechazando por otras razones.
Los benchmarks públicos de deliverability publicados por los routers principales convergen en este punto: las tasas de entrada a la bandeja varían más en función de la calidad de compromiso de la lista que de los parámetros de autenticación solamente. DKIM2 refuerza la capa de autenticación sin compensar una lista mal mantenida. La verificación de direcciones antes del envío sigue siendo el prerrequisito de todo pipeline de deliverability. El protocolo asegura el camino una vez los destinatarios son validados, nunca antes.
Comparación DKIM1 y DKIM2 en los criterios clave
| Criterio | DKIM1 (RFC 6376) | DKIM2 (borrador IETF 2026) |
|---|---|---|
| Resistencia a los intermediarios | Ninguna: cualquier modificación invalida la firma | Cadena de firmas: cada intermediario documenta sus cambios |
| Protección anti-replay | Ausente: una firma válida es reutilizable | Vinculación de destinatarios + marcas de tiempo: firma ligada al destinatario y a un intervalo temporal |
| Gestión de rebotes | Rebotes asíncronos no criptográficos, backscatter posible | NSD asíncrono + VERP firmado: retorno al servidor anterior en la cadena |
| Listas de correo y reenviadores | Rotura sistemática de la firma | Modificaciones documentadas a través de modificación algebra, firma mantenida |
| Visibilidad RSSI | Limitada: sin trazabilidad de las modificaciones de tránsito | Auditoría completa de la cadena de tránsito documentada |
| Estado | RFC publicada, desplegada desde 2011 | Borrador adoptado por el WG IETF en marzo de 2026, aún no RFC |
Lo que hay que vigilar antes del despliegue
Cuatro documentos han sido adoptados por el WG IETF dkim: la especificación principal, un documento de motivación (draft-ietf-dkim-dkim2-motivation), un perfil de despliegue vía interfaz Milter y una guía de buenas prácticas. Todos están prefijados draft-ietf-dkim, lo que indica que están oficialmente en el pipeline del grupo de trabajo, no son propuestas individuales.
- Seguimiento de la especificación principal: el draft-ietf-dkim-dkim2-spec expira en octubre de 2026. Su renovación o avance hacia el estatus de Proposed Standard será la primera señal concreta de una trayectoria hacia RFC.
- Pruebas en proveedores de buzón: Richard Clayton mencionó despliegues en proveedores de buzón en los próximos meses. Si Gmail, Yahoo o Outlook anuncian soporte DKIM2, cambiarán de inmediato las prioridades del lado ESP.
- Infraestructura de entrada de los ESP: el aumento esperado en los volúmenes de rebotes asíncronos durante el despliegue requiere una capacidad de entrada reforzada. Los ESP que preparen su infraestructura por adelantado tendrán menos presión operacional.
- Política de eliminación de direcciones: los rebotes asíncronos DKIM2 pueden llegar 24 horas o más después del envío inicial. Las reglas de eliminación automática deberán revisarse para integrarse este retraso sin generar falsos positivos en las listas de desuscripción.
Al Iverson recuerda en abril de 2026 que la especificación aún no está finalizada y que los detalles son susceptibles de cambiar. El WG IETF ha organizado sesiones interinas en 2026 para acelerar los trabajos. La agenda del meeting interino del 29 de abril de 2026 documenta los borradores en curso de revisión.
Para seguir el avance en tiempo real: suscríbase a la lista de distribución ietf-dkim@ietf.org y verifique el estado de los borradores en datatracker.ietf.org/group/dkim, el ámbito donde se decide el calendario efectivo de DKIM2.
