Resumen

  • La revisión 01 de las buenas prácticas de DKIM2 quedó disponible el 9 de septiembre de 2026. Es un Internet-Draft del grupo DKIM, no una BCP aprobada ni una orden de migración de IETF.
  • El texto recomienda firmar el correo saliente con DKIM1 y DKIM2 hasta que DKIM2 sea «efectivamente ubicuo», pero no fija porcentaje, universo medido, intervalo, cohortes ni responsable de declarar ese momento.
  • La mezcla diaria que ve un receptor sirve para ajustar su política. No demuestra la preparación de remitentes, reenviadores y receptores que están fuera de su campo de observación.
  • Un acta de salida agregada y respetuosa con la privacidad puede conservar denominador, excepciones, umbral, decisión y reversión. Es una propuesta de Daniel Kade, no parte del borrador.

La revisión cambia mucho texto, no el vacío de medición

La revisión 01 apareció el 9 de septiembre y su registro de cambios reconoce una reorganización extensa, nuevos títulos y modificaciones generalizadas. El historial de Datatracker sitúa la versión 00 como documento del grupo desde el 18 de junio de 2026. La ficha actual mantiene el estado WG Document y I-D Exists, sin shepherd, director de área responsable ni fecha de telechat.

El encabezado del archivo propone Best Current Practice; Datatracker muestra ahora Intended RFC status: None. Lo importante no es resolver aquí esa diferencia, sino no ascender el texto antes de tiempo. Sigue siendo trabajo en curso y puede cambiar, caducar o no avanzar.

En ese marco, la recomendación central de transición dice que el firmante debería aplicar DKIM1 y DKIM2 hasta que el despliegue de DKIM2 sea «efectivamente ubicuo». La expresión aparece dos veces y sustituye a un criterio de salida. No define si se cuentan mensajes, dominios, organizaciones o trayectos completos. Tampoco define qué regiones, tipos de remitente o intermediarios deben entrar en la muestra.

La flexibilidad protege una adopción descentralizada. El correo mundial no puede esperar una señal emitida por un único operador. Sin embargo, una condición flexible necesita más procedencia, no menos. Dos plataformas pueden declarar que han llegado al mismo estado utilizando ventanas y poblaciones incompatibles.

Contar firmas no equivale a contar preparación

El borrador propone que, si no llega DKIM2, un receptor capaz de DKIM1 aplique su política habitual. Esa política puede evolucionar observando cada día el porcentaje de mensajes con y sin DKIM2 y la interacción de los usuarios con cada conjunto. Al mismo tiempo, durante la transición no se debería rechazar un mensaje solo por carecer de DKIM2.

La combinación es razonable: permite aprender sin convertir la no adopción en falta automática. También limita lo que puede inferirse. La ausencia puede significar que el origen no participa, que un reenviador interrumpió la cadena, que existe una excepción conocida, que se retiró una firma o que el receptor clasifica mal el trayecto.

Además, el porcentaje cambia con el denominador. Un puñado de grandes emisores puede dominar el conteo por mensajes. Un conteo por dominios puede ocultar el volumen. Una organización empresarial ve a sus proveedores y clientes; un correo gratuito ve población de consumo; una lista de distribución ve un patrón de reenvío peculiar. Ninguna vista es falsa, pero ninguna es el ecosistema completo.

Por eso conviene separar tres afirmaciones: preparación local, preparación de una cohorte de interconexión definida y evidencia comunitaria más amplia. La primera puede bastar para una política local. Las otras exigen describir quién quedó dentro y fuera.

«Nunca salió», «entró y salió» y «nunca entró» son estados de trayecto

La sección 6 ofrece tres condiciones observables. “Never Left” indica que cada dominio administrativo firmó al sacar el mensaje. “In and Out” señala participación incompleta. “Never Entered” corresponde a la ausencia total de DKIM2 al llegar. Son categorías útiles para el análisis de un mensaje, no niveles universales de adopción.

El detalle operativo está en los reenviadores. Un reenviador participante debe intentar verificar las firmas DKIM2 y DKIM1 existentes y firmar con DKIM2 todo mensaje que maneje, incluso cuando no modifique su contenido. La firma se coloca en el último salto antes de abandonar la infraestructura del firmante. Por tanto, una transición no se puede evaluar mirando solo al remitente inicial y al receptor final.

La sección 7.1 imagina que, a medida que madura el despliegue, el receptor dependerá principalmente de DKIM2 y evitará mantener para siempre dos rutas de verificación. No ofrece una prueba de madurez. Del mismo modo, las secciones entre signos de interrogación sobre DMARC y SPF son, según la introducción, preguntas abiertas y texto especulativo. No anuncian el retiro de DKIM1, DMARC ni SPF.

El riesgo de degradación obliga a clasificar la ausencia

La sección de seguridad plantea que quien pueda retirar una firma DKIM2 podría hacer que un receptor que todavía no la exige vuelva a un tratamiento más débil basado solo en DKIM1. Recomienda examinar con mayor atención el correo de un dominio conocido por usar DKIM2 cuando de pronto llega con DKIM1 plausible y sin DKIM2.

No hay en las fuentes un ataque medido ni una tasa de explotación. El valor del ejemplo es lógico: la ausencia de un dominio que nunca se observó con DKIM2 no tiene el mismo significado que la desaparición en un dominio ya conocido. Una estadística única las mezcla y reduce la capacidad de detectar una degradación.

La decisión de cerrar la convivencia debe conservar, por tanto, una salida de emergencia. El disparador puede ser un aumento de dominios DKIM2 conocidos que llegan solo con DKIM1, una caída de cadenas completas o problemas de entrega en una población exceptuada. Debe declararse antes del cambio para evitar que la interpretación se ajuste después del daño.

Una constancia pequeña para una decisión acotada

No propongo un certificado mundial ni un umbral único. Propongo que quien retire una parte de la doble firma o de la verificación paralela conserve una constancia con:

  1. operador declarante, función y decisión bajo su control;
  2. cohortes de remitentes, reenviadores y receptores examinadas;
  3. denominador, ponderación, exclusiones y ventana;
  4. tasas de presencia, cadena completa, cadena parcial y ausencia;
  5. resultados de verificación y señales de entrega o interacción realmente utilizadas;
  6. anomalías de dominios conocidos por DKIM2 que llegan sin él;
  7. excepciones que aún dependen de DKIM1;
  8. umbral y versión de la política;
  9. momento de la decisión, condición de reversión y próxima revisión.

Los datos públicos pueden ser agregados. No es necesario exponer destinatarios, conducta individual ni contenido. Sí es necesario impedir que una conclusión local pierda su etiqueta de alcance al circular entre organizaciones.

La idea sigue la especificación inicial mínima de Heng Lu: compartir solo la evidencia mínima que permite coordinar decisiones futuras, sin centralizar la adopción voluntaria.

Límite de la evidencia

La ficha de Datatracker y el historial prueban el estado del documento. La diferencia oficial entre 00 y 01 prueba la magnitud de la edición. La especificación base y el documento DNS también son borradores activos.

Los RFC citados explican DKIM, SPF, Authentication-Results y DMARC, no miden DKIM2. No existe en este paquete un censo representativo, un coste total o un incidente cuantificado. Por ello no se publica porcentaje de adopción, fecha de ubicuidad ni calendario de retiro.

Fuentes