Resumen

  • La revisión 00 propone un único resultado legible por máquinas para toda la cadena DKIM2, con header.d para el dominio inicial y header.i para ubicar ciertos fallos.
  • El campo que contiene ese resultado no está firmado por DKIM2. Solo es confiable dentro del ADMD que lo generó y no debe copiarse a un sistema posterior.
  • En resultados distintos de pass, header.d puede ser útil para diagnosticar sin constituir una identidad autenticada; el comentario por saltos es texto no confiable, no una API.

Una organización recibe un mensaje, comprueba todas las firmas DKIM2 y deja una nota: dkim2=pass. Luego reenvía el mensaje. Para la organización siguiente hay dos objetos posibles. Puede volver a verificar la cadena, o puede leer la nota. Solo el primero conserva la evidencia.

Esa separación da actualidad al borrador de revisión 00, anunciado el 5 de septiembre de 2026. El documento no inventa la cadena DKIM2; define cómo resumir su verificación en Authentication-Results. El resumen sirve para comunicar un cálculo dentro de un entorno de confianza. No recibe por ello la protección de las firmas resumidas.

La ficha del Datatracker en formato API registra un Internet-Draft individual sin respaldo formal del IETF. La fuente XML permite fijar el texto y el anuncio oficial documenta fecha, autor y alcance. La aspiración a Standards Track sigue siendo una aspiración.

El borrador base de DKIM2 produce cuatro estados después de intentar la verificación: PASS, FAIL, PERMERROR y TEMPERROR. La nueva propuesta los traduce a minúsculas y añade none cuando no había firma DKIM2 y no se intentó verificar. A diferencia de DKIM1, no ofrece un resultado independiente por cada firma: hay un resultado para el mensaje completo, porque la pregunta es si la cadena de custodia se sostiene. La ficha del documento del grupo DKIM muestra que este texto subyacente tiene una trayectoria distinta del informe individual.

El resultado general puede ocultar un recorrido parcial. La verificación comienza por la firma más reciente y puede detenerse al hallar un fallo. Las firmas anteriores se muestran como skipped en el comentario. Eso no significa que fallaron; significa que no fueron comprobadas.

header.d toma el dominio de la firma i=1. Puede aparecer incluso junto a fail, permerror o temperror para ayudar a investigar. Sin embargo, el propio borrador dice que solo es una identidad autenticada con resultado pass. En cualquier otro estado no debe alimentar reputación ni disposición. Conservar el dominio y perder el estado destruye la condición que daba significado probatorio al dato.

header.i tiene otra trampa de modelado. En DKIM2 indica el número de secuencia de la firma a la que se atribuye el fallo. En DKIM1, la misma grafía describe el Agent or User Identifier. Una tabla que trate header.i como una columna universal mezclará un entero de ubicación con una identidad. El método de autenticación forma parte del tipo del dato.

La autoridad del campo proviene de RFC 8601, y es deliberadamente local. Un ADMD reúne validadores y consumidores bajo una frontera administrativa. El mensaje que cruza desde Internet puede traer campos Authentication-Results fabricados. El MTA de borde debe eliminar los que aparentan pertenecer a sus servicios pero no llegaron por un trayecto confiable.

El authserv-id identifica quién afirma haber validado; no firma esa afirmación. La configuración local decide qué identificadores y qué rutas internas acepta. DKIM2 excluye el campo de sus firmas porque se añade después de la comprobación y suele retirarse al cruzar fronteras. Por eso cualquier manejador puede cambiarlo sin provocar un error DKIM2.

Incluso un informe auténtico caduca al salir de su contexto. La firma DKIM2 más reciente enlaza el mensaje con MAIL FROM y RCPT TO de una transacción SMTP concreta. El pass de un verificador cubre hasta la recepción que ese verificador observó. Tras un reenvío hay otra transacción, otros destinatarios posibles y un nuevo punto de responsabilidad. El reenviador no debe copiar el resultado para que el siguiente sistema lo crea. Debe añadir su propia firma DKIM2; el nuevo receptor verifica y redacta su propio informe.

El comentario recomendado enumera saltos, dominios, estados y un diagnóstico. Está pensado para una persona que busca el punto de ruptura. Un analizador conforme puede descartarlo. Por tanto, una regla automática que extrae palabras de ese comentario depende de una estructura que el borrador niega como interfaz estable.

Además, el texto puede contener valores influenciados por un atacante. Los paréntesis y la barra inversa tienen función gramatical en RFC 5322. Si no se escapan, un valor puede cerrar el comentario y hacer que texto elegido por el remitente parezca otro resultado de autenticación. Los valores deben limitarse en longitud y mostrarse como texto no confiable, nunca como marcado.

El detalle también tiene un costo de privacidad: puede enumerar dominios que manejaron el mensaje, relaciones de reenvío o direcciones RCPT TO. Replicarlo fuera del ADMD ensancha un registro que estaba diseñado para permanecer local.

El patrón se inspira en ARC: pocas propiedades operativas y detalle humano separado. DKIM conserva la semántica histórica de sus identificadores, mientras la arquitectura del correo sitúa cada ADMD dentro de una cadena de actores, no por encima de ella.

En la fecha de investigación, el registro IANA aún no mostraba el método dkim2. La propuesta solicita dos propiedades y cinco nombres de resultado. La solicitud describe el futuro deseado, no el estado presente.

La idea de Heng Lu de una especificación inicial mínima permite compartir sintaxis sin ceder las decisiones futuras de cada operador. Sus capas de realidad separan la firma, el cálculo, el informe y la acción. La primacía del código en ejecución obliga a observar si la frontera borró los campos externos y si el receptor realmente volvió a verificar.

El resultado cabe en una línea. Su autoridad no.