DKIM2: en qué punto está la normalización y cómo prepararse
Por CaptainDNS
Publicado el 3 de noviembre de 2025
Actualizado el 27 de julio de 2026
- DKIM2 no es un estándar: ninguna RFC, ningún documento en última llamada y un calendario de la carta del IETF con unos siete meses de retraso.
- El trabajo se hace en el grupo de trabajo
dkimhistórico, con carta revisada en febrero de 2025. No existe ningún grupo «dkim2». - La especificación actual (
draft-ietf-dkim-dkim2-spec-04, 5 de julio de 2026) se apoya en dos encabezados:DKIM2-Signaturepor salto yMessage-Instancepara describir las modificaciones en forma de recetas JSON. - Casi toda la sintaxis de 2025 ha desaparecido:
mv=,pp=,a=,b=,bh=, el encabezadoMail-Version:. - Tres implementaciones (Rust, Python, Go) demostraron su interoperabilidad en julio de 2026, y desde entonces se ha anunciado una cuarta, en C: el cambio de estado más concreto en un año.
- Propietario de dominio: nada que hacer. Tus claves y tus registros
_domainkeysiguen siendo válidos tal cual.
ℹ️ Los términos replay DKIM, backscatter, Message-Instance y receta se definen en el glosario al final del artículo.
DKIM2 arrastra una reputación contradictoria. Se lee que sustituirá a DKIM «pronto», que dejará DMARC obsoleto o, al contrario, que solo existe sobre el papel. La realidad de julio de 2026 es más sencilla: el protocolo sigue sin estar normalizado, pero ha dejado de ser teórico, porque tres implementaciones independientes firman, verifican y reconstruyen mensajes juntas.
¿Por qué existe DKIM2?
DKIM (STD 76, RFC 6376) firma el contenido de un mensaje. Es su fuerza y, tras veinte años de explotación, su límite: la firma no dice nada del camino recorrido ni de las direcciones realmente utilizadas en cada salto SMTP.
El replay que DKIM no cierra
Un atacante que se hace con un mensaje firmado legítimamente puede reexpedirlo masivamente sin tocar nada de lo que cubre la firma: esta sigue siendo válida, DMARC sigue pasando, y es el dominio firmante quien carga con la reputación degradada. Es el replay DKIM, que ninguna rotación de claves elimina de verdad.
El reenvío que rompe la firma
Una lista de distribución que añade un pie de página, prefija el asunto o inserta un encabezado de baja invalida el hash firmado. DKIM no ofrece ningún medio para describir la modificación, ni, por tanto, para dar marcha atrás y verificar la firma original.
Los rebotes que salen hacia un tercero
Cuando un servidor acepta un mensaje y luego genera un rebote a posteriori, ese rebote sale hacia la dirección del sobre, posiblemente suplantada. Es el backscatter: una víctima inocente recibe informes de no entrega por correo que nunca ha enviado.
DKIM2 ataca los tres a la vez: cada salto pone su propia firma numerada, declara el sobre que ha utilizado y documenta lo que ha modificado. El camino se vuelve verificable y las modificaciones, reversibles.
¿Tu DKIM actual está sano antes de pensar en DKIM2?
¿En qué punto está la normalización?
Un grupo con carta revisada, tres documentos
No existe ningún grupo de trabajo «dkim2» en el IETF, y esa es la primera fuente de error. El trabajo se desarrolla en el grupo dkim histórico, cuya carta revisada aprobó el IESG el 20 de febrero de 2025, bajo la presidencia de Murray Kucherawy y Pete Resnick.
Hay tres documentos de grupo activos:
draft-ietf-dkim-dkim2-spec-04(5 de julio de 2026), Standards Track, 43 páginas, caduca el 6 de enero de 2027. Autores: Richard Clayton (Yahoo), Wei Chuang (Google), Bron Gondwana (Fastmail).draft-ietf-dkim-dkim2-bcp-00(18 de junio de 2026), Todd Herr. Adoptado, pero deliberadamente en espera mientras el grupo no acumule experiencia operativa.draft-ietf-dkim-dkim2-dns-00(20 de julio de 2026), Wei Chuang.
Lo que dice el calendario
Ninguno de estos documentos está en última llamada del grupo (WG Last Call), ninguno se ha enviado al IESG, no existe ninguna RFC. Ahora bien, los hitos de la carta apuntaban a «todos los documentos enviados al IESG para el 31 de diciembre de 2025»: el retraso es de unos siete meses, y el calendario no se ha revisado.
Los hitos reales del período transcurrido son escasos. Noviembre de 2025: los borradores motivation, header y mailversion dejan de mantenerse. 20 de marzo de 2026, en el IETF 125: la especificación de Richard Clayton pasa a ser el documento principal y se elige el formato JSON para describir las modificaciones. 24 de marzo de 2026: primer borrador de grupo de la especificación. 24 de junio de 2026: spec-03 introduce el tag nd=. 24 de julio de 2026: sesión DKIM en el IETF 126, en Viena.
Los documentos muertos
Todo contenido escrito en 2025 sobre DKIM2 remite a borradores hoy abandonados o sustituidos: comprueba siempre los nombres y las revisiones que cita. draft-ietf-dkim-dkim2-motivation-02 ha caducado; draft-ietf-dkim-dkim2-header-00 y draft-gondwana-dkim2-mailversion-00 están marcados como «Dead WG Document». Su contenido se ha absorbido, reescrito o abandonado.
Otro error que circula: varias publicaciones afirman que el grupo adoptó un «perfil de despliegue vía milter». Es falso. El 8 de mayo de 2026, el presidente del grupo escribió que «the working group does not wish to pursue adoption at this time».
Lo que DKIM2 cambia en concreto
La mecánica se apoya en dos encabezados distintos.
El encabezado DKIM2-Signature
Cada salto añade una línea. El apartado 8 de la especificación fija las obligaciones: «The i=, m=, t=, d= and s= tags MUST be present. There MUST be either an nd= tag or both mf= and rt= tags. The other tags are optional.»
| Tag | Obligatorio | Función |
|---|---|---|
i= | sí | Número de secuencia del salto. El emisor de origen firma con i=1, y cada salto siguiente lo incrementa. Basta un hueco en la numeración para que el mensaje entero se considere sin firmar. |
m= | sí | Número del Message-Instance más alto en el momento de la firma. |
t= | sí | Marca de tiempo, expresada en segundos epoch UTC (un entero, no una fecha con formato). |
d= | sí | Dominio firmante. Es el que sirve para construir la consulta DNS de recuperación de la clave. |
s= | sí | Tripleta selector:algoritmo:firma-base64. |
mf= | condicional | MAIL FROM utilizado en la emisión, codificado en base64, corchetes angulares incluidos. |
rt= | condicional | RCPT TO, en base64, con corchetes angulares incluidos. Se pueden listar varios destinatarios. |
nd= | condicional | Dominio que firmará el salto siguiente. Mutuamente excluyente con mf= y rt=. |
n= | no | Nonce libre, 64 caracteres como máximo. |
f= | no | Flags. |
El tag s= sigue la ABNF sig-set = selector ":" sig-name ":" message-sig, donde sig-name vale rsa-sha256 o ed25519-sha256; pueden coexistir varias firmas de algoritmos distintos, pero «a different selector MUST necessarily be used for each signature». El d=, por su parte, debe corresponder exactamente a las etiquetas más a la derecha del dominio que lleva mf=: dicho de otro modo, d= es o bien idéntico a ese dominio, o bien uno de sus dominios padre. Así, mf=<user@mail.example.com> encaja con d=example.com, mientras que lo contrario, mf=<user@example.com> con d=mail.example.com, se rechaza. Solo un mf= vacío, es decir <>, el caso de los informes de no entrega, queda exento de esa correspondencia.
En cuanto a la criptografía, la especificación impone RSA de al menos 1024 bits para firmar y exige que los verificadores acepten de 1024 a 2048 bits, siendo opcional la compatibilidad con claves más grandes. El exponente público es 65537, el relleno PKCS#1 v1.5, el hash sin truncar, SHA256 obligatorio, y Ed25519 en variante PureEdDSA (RFC 8032, apartado 5.1): «Signers SHOULD implement both RSA-SHA256 and Ed25519-SHA256, Verifiers MUST implement both». Una firma de más de 14 días puede ignorarse, pero es un MAY, no una obligación.
Los flags f= se han rediseñado. exploded indica que el mensaje sale hacia más de una dirección; su ausencia permite a un MTA suponer que solo existe una copia, y ahí está precisamente la palanca anti-replay. donotexplode y donotmodify son prohibiciones dirigidas a los intermediarios. feedback pide un retorno, su ausencia significa que ese retorno no se desea, y feedhere permite a un intermediario retransmitir ese retorno sin revelar el destino final. Todo flag desconocido debe ignorarse.
Un verificador produce uno de los cuatro estados PASS, FAIL, PERMERROR o TEMPERROR, alineados con la RFC 8601.
El Message-Instance
El segundo encabezado describe el estado del mensaje y el medio de volver al estado anterior: «The m= and h= tags MUST be present. The r= tag is optional.»
El tag m= es el número de revisión: 1 en el origen, incrementado en cada nueva instancia; un hueco vuelve el mensaje inverificable. El tag h= toma la forma sha256:<hash de los encabezados>:<hash del cuerpo>, ambos en base64, y pueden coexistir varios juegos. El tag r= contiene «the base64 encoded version of the JSON object that contains the recipes that allow the previous instance of the message to be recreated».
Punto importante para los operadores: si no modificas nada, no añades ningún Message-Instance; un relé que transmite el mensaje tal cual no tiene nada que describir.
Las recetas forman un objeto JSON, identificado por el esquema https://dkim2.org/schemas/recipe-v1, con una clave "h" para los encabezados o "b" para el cuerpo, o ambas. Cada receta es un array de pasos, cada uno con exactamente una clave: {"c": [inicio, fin]} copia un rango de líneas o de instancias, {"d": ["..."]} emite datos literales. Un "b": null señala un cuerpo anterior no reconstruible; un array vacío asociado a un nombre de campo significa «elimina todas sus instancias». Trampa clásica: los encabezados se numeran de abajo arriba y las líneas del cuerpo de arriba abajo.
Tus claves DNS no cambian
La clave pública se recupera en <selector>._domainkey.<d=>, exactamente igual que hoy: «these keys are no different, and are stored in the same locations as those for DKIM1». Ningún tipo de registro nuevo, ninguna migración DNS que preparar.
nd= o mf=/rt=: la cadena de custodia
Una secuencia de varias DKIM2-Signature con nd= está permitida, pero «MUST end with a DKIM2-Signature that contains mf= and rt= tags», y el dominio declarado en nd= debe corresponder exactamente al d= de la firma siguiente en el orden de los i=.
El apartado 9.3 presenta esta variante como una cadena de custodia para saltos imaginarios. Piensa en un sistema que recibe correo en un dominio y lo reexpide desde otro: la continuidad entre el rt= del salto anterior y el mf= del salto siguiente se rompe. En lugar de fabricar una firma con mf= y rt= inventados, que contaminarían la cadena con direcciones ficticias, el sistema anuncia con nd= cuál será el próximo firmante. Es la opción que la especificación fomenta.
Ejemplo de encabezados
spec-04 no contiene ningún ejemplo de mensaje ni de encabezado: el borrador que debía proporcionarlos, draft-robinson-dkim2-message-examples-00, caducó en 2025. El ejemplo siguiente está, por tanto, reconstruido a partir de la gramática ABNF del documento, y no tiene ningún valor normativo.
Escenario de dos saltos: un remitente escribe a una lista de distribución, la lista añade un encabezado List-Unsubscribe y reexpide.
DKIM2-Signature: i=2; m=2; t=1740001000; d=test2.dkim2.com;
mf=PGJvdW5jZUB0ZXN0Mi5ka2ltMi5jb20+; rt=PHJlY2lwaWVudEBleGFtcGxlLmNvbT4=;
s=ed25519:ed25519-sha256:FDYZopU8W+c7...;
DKIM2-Signature: i=1; m=1; t=1740000000; d=test1.dkim2.com;
mf=PHNlbmRlckB0ZXN0MS5ka2ltMi5jb20+; rt=PGxpc3RAdGVzdDIuZGtpbTIuY29tPg==;
s=ed25519:ed25519-sha256:oKZmf7rabJv4...;
Message-Instance: m=2; h=sha256:u4RFAizDeEqt...:SgG5fNGEg1x2...;
r=eyJoIjp7Imxpc3QtdW5zdWJzY3JpYmUiOltdfX0=;
Message-Instance: m=1; h=sha256:SLtzk6LO68CC...:SgG5fNGEg1x2...;
Received: from test1.dkim2.com by relay.example.com; ...
List-Unsubscribe: <mailto:unsub@relay.example.com>
From: sender@test1.dkim2.com
To: list@test2.dkim2.com
Subject: ...
Descodifiquemos. Los valores del sobre están en base64, corchetes angulares incluidos, como exige la especificación. En el primer salto, mf= vale <sender@test1.dkim2.com> y rt= vale <list@test2.dkim2.com>. En el segundo, la lista reexpide: mf= vale <bounce@test2.dkim2.com> y rt= vale <recipient@example.com>. La continuidad de la cadena se ve a simple vista, y ahí reside todo el interés del mecanismo.
El pasaje más instructivo es el r= del Message-Instance número 2. Descodificado desde base64, da:
{"h":{"list-unsubscribe":[]}}
Traducido al castellano: «para volver a la instancia anterior, elimina todas las apariciones del campo List-Unsubscribe». Un verificador que quiera validar la firma i=1 aplica esta receta, recupera el mensaje tal como lo emitió el remitente, recalcula el hash y compara. La modificación no ha roto la cadena: se ha declarado y se ha hecho reversible.
Los valores de s= y los hashes del h= están truncados: dependerían de claves privadas y de un mensaje real, así que el lector no puede recalcularlos. El ejemplo sirve para mostrar la estructura de los encabezados, no para verificarse.
Lo que ha cambiado desde los borradores de 2025
Si has leído una guía sobre DKIM2 publicada a finales de 2025, prácticamente toda la sintaxis que describía ha desaparecido.
| Elemento de 2025 | Estado en spec-04 |
|---|---|
Encabezado único DKIM2: (Active/Historical) | Eliminado, sustituido por la pareja DKIM2-Signature y Message-Instance |
Encabezado Mail-Version: | Eliminado, rediseñado como Message-Instance; las recetas compactas dejan paso a JSON codificado en base64 |
mv= | Renombrado m= |
v= | No existe ni existirá |
pp= (delegación) | Eliminado; nd= ocupa su lugar desde spec-03 (24 de junio de 2026) |
a= | Eliminado, fusionado en s= |
b= | Eliminado, absorbido por s= |
bh= | Trasladado al h= del Message-Instance |
h= (lista de campos firmados) | Sentido invertido: DKIM2 firma todo salvo una lista de exclusión |
t= | Pasa de una fecha con formato a un entero epoch |
f=modifiedbody, f=modifiedheader | Eliminados, considerados redundantes con los datos de versión |
f=donotforward | Eliminado |
f=feedhere | Nuevo, aparecido en spec-03 |
La ausencia de v= es deliberada
El apartado 8 lo justifica: «Experience from IMF onwards shows that it is essentially impossible to change version numbers. If it becomes necessary to change DKIM2 in the sort of incompatible way that a v=2 / v=3 version number would support, it is expected that header fields will be labelled as DKIM3 instead.» Una ruptura mayor produciría, por tanto, un encabezado DKIM3-Signature, no un número de versión interno.
La inversión del h=
DKIM enumera los campos que firma. DKIM2 hace lo contrario: firma todo, salvo siete familias de campos listadas en el apartado 4.1, a saber: ARC-*, Authentication-Results, Delivered-To, DKIM-Signature, Received, Return-Path y X-*. Exactamente los campos que un intermediario está legítimamente llamado a añadir o modificar en tránsito.
ARC se jubila
ARC respondía al mismo síntoma: el reenvío rompe SPF y DKIM. Pero se limitaba a transportar un testimonio sellado de los resultados de autenticación constatados antes del relé, sin cerrar nunca el fallo de replay. Es trazabilidad, no integridad de extremo a extremo. El IETF lo reclasifica hoy en estado «Historic» y concentra el esfuerzo en DKIM2, que trata la causa en lugar del síntoma. El detalle de esta reclasificación y sus consecuencias prácticas son objeto de un artículo dedicado.
¿En qué punto están las implementaciones?
Aquí es donde el año ha sido decisivo: se ha pasado de cero implementaciones a tres que se entienden entre sí, y desde entonces se ha anunciado una cuarta.
El 4 de julio de 2026, una demostración de interoperabilidad reunió tres implementaciones independientes: mail-auth en Rust (Stalwart Labs), la implementación Python de Bron Gondwana y la implementación Go de Steve Atkins. Firma, verificación y reconstrucción mediante recetas se probaron en ambos sentidos, incluso en cadenas de varios saltos. Resultado anunciado: con el plegado de encabezados desactivado, todas las combinaciones pasan. De paso se identificaron dos bugs de plegado, uno del lado Go (base64 estricto, sin eliminar los espacios) y otro del lado Python (división por : sin desplegado previo).
El 8 de julio de 2026, Bron Gondwana centralizó el conjunto de pruebas en la organización de GitHub dkim2wg y mencionó una cuarta implementación, en C (PhoenixDKIM).
Sobre el calendario existen pronósticos, fechados y atribuidos. Laura Atkins (Word to the Wise, 23 de abril de 2026) espera ver DKIM2 funcionando en los grandes proveedores de aquí a finales de 2026. Al Iverson (Spam Resource, 21 de abril de 2026) recuerda que la especificación todavía no está finalizada y que las cosas pueden cambiar, y subraya que las claves, por su parte, no cambian de momento. Ninguna fuente primaria anuncia una fecha de obligación para los remitentes, y los calendarios de obligación que circulan no se apoyan en ninguna fuente primaria.
Lo que todavía no está decidido
El grupo se reunió en el IETF 126, en Viena, el 24 de julio de 2026. Los puntos siguientes se plantearon, pero no se zanjaron; las actas de la sesión aún no se han publicado.
- Recetas nulas para los encabezados: ¿hay que eliminarlas, a falta de un caso de uso identificado?
Message-Instanceengañosos: los MUST NOT actuales son demasiado estrictos y provocaron rechazos de mensajes durante las pruebas de interoperabilidad.- Algoritmo poscuántico: el grupo busca la opinión de expertos; la dificultad identificada es que las claves muy largas pasan mal por el DNS sobre UDP.
- Mayúsculas y minúsculas en los nombres de campo: ¿hay que imponer las minúsculas en las recetas JSON?
- Informes de no entrega: ¿hacen falta un flag dedicado y la omisión del
Message-Instance? - Alineación y DMARC: «The DKIM2 spec deliberately stays away from saying anything about DMARC», el tema se remite al documento de buenas prácticas. La expectativa expresada es una alineación entre el
From:de origen, el MAILFROM inicial y eld=de la primeraDKIM2-Signature, mientras que hoy DKIM2 solo exige la alineación de los dos últimos. - Mensajes retransmitidos solo con DKIM1: ¿hay que firmarlos en DKIM2?
- Bucles de retorno: ¿hay que estandarizar su formato?
Esta lista es la mejor medida de la madurez real del protocolo, y la razón por la que el documento de buenas prácticas sigue congelado.
Impactos operativos
Las consecuencias no son las mismas según tu papel, y el reparto es desigual.
Propietario de dominio: nada que hacer
Ninguna acción que emprender hoy. Lo único útil es mantener un DKIM1 sano, con una rotación de claves controlada, y un DMARC en marcha: es el cimiento sobre el que se apoyará DKIM2.
Una precisión que surge a menudo: DMARC no desaparece. Conserva un valor propio, en particular los informes agregados a nivel de dominio y la detección de la suplantación del dominio del From:, que DKIM2 no replica.
ESP, relés y listas de distribución: el verdadero trabajo
Firmar en cada salto, registrar las modificaciones en forma de recetas y, sobre todo, anticipar un efecto secundario subestimado: la avalancha de rebotes asíncronos entrantes. DKIM2 devuelve el mensaje al salto anterior, lo que cambia el volumen y la naturaleza de los retornos que hay que tratar, un punto que Laura Atkins subraya especialmente.
Otro punto de atención: la doble firma (la de la marca y la de la plataforma), tal como se practica hoy en DKIM, no se traslada directamente. Al Iverson señalaba el 9 de mayo de 2026 que no existen, en sentido estricto, firmas múltiples directas.
Verificadores: empezar por arriba
La verificación es inversa a lo que dicta la intuición: se parte del i= más alto, la firma más reciente, y luego se remonta la cadena aplicando las recetas para reconstruir las instancias anteriores.
Plan de preparación
- Inventaría tus flujos: dónde firmas, dónde verificas, qué saltos intermedios existen, qué mecanismos de reescritura del sobre (SRS, VERP) hay en marcha.
- Sanea DKIM1: selectores al día, claves de un tamaño correcto, rotación documentada.
- Prototipa del lado del relé si operas alguno:
mf=yrt=en base64 con corchetes angulares incluidos, numeracióni=, marca de tiempo epoch, elección de algoritmos. - Modela tus modificaciones habituales en recetas JSON: pie de página, prefijo de asunto,
List-Unsubscribe. Es el ejercicio que revela los casos difíciles. - Dimensiona el tratamiento de los rebotes asíncronos entrantes, el punto que más se olvida.
- No toques tu DNS para DKIM2: no hay nada nuevo que publicar.
- Establece un seguimiento de
draft-ietf-dkim-dkim2-specy prevé interruptores de funcionalidad: cuatro revisiones en algo más de tres meses, la sintaxis todavía se mueve.
FAQ
¿DKIM2 es un estándar en 2026?
No. A 25 de julio de 2026 no existe ninguna RFC DKIM2: la especificación está en la fase draft-ietf-dkim-dkim2-spec-04, publicada el 5 de julio de 2026, y ningún documento del grupo está en última llamada ni se ha enviado al IESG. Los hitos de la carta apuntaban a un envío para el 31 de diciembre de 2025, es decir, unos siete meses de retraso.
¿Tengo que modificar mis registros DNS para DKIM2?
No. La especificación precisa que las claves DKIM2 no son diferentes y se almacenan en las mismas ubicaciones que las de DKIM1, bajo selector._domainkey.tudominio. Ningún tipo de registro nuevo, ninguna migración DNS que prever.
¿Cuál es la diferencia entre DKIM2-Signature y Message-Instance?
DKIM2-Signature lo añade cada salto SMTP: número de secuencia i=, marca de tiempo, dominio firmante, firma y sobre utilizado. Message-Instance describe el estado del mensaje y el medio de volver al anterior, mediante recetas JSON codificadas en base64 en el tag r=. Un intermediario que no modifica nada añade una firma, pero no un Message-Instance.
¿DKIM2 sustituye a DMARC?
No. DMARC conserva un valor propio que DKIM2 no replica: informes agregados a nivel de dominio y detección de la suplantación del dominio del From:. De hecho, la especificación evita deliberadamente hablar de DMARC y remite la cuestión de la alineación al documento de buenas prácticas.
¿Existen implementaciones de DKIM2 que funcionen?
Sí: tres implementaciones han demostrado su interoperabilidad, y desde entonces se ha anunciado una cuarta que no participó en la demostración. El 4 de julio de 2026, una demostración de interoperabilidad reunió mail-auth en Rust (Stalwart Labs), una implementación Python de Bron Gondwana y una implementación Go de Steve Atkins, incluso en cadenas de varios saltos. Una cuarta implementación en C, PhoenixDKIM, se mencionó después, el 8 de julio de 2026, cuando el conjunto de pruebas se centralizó en la organización de GitHub dkim2wg.
¿Qué tengo que hacer hoy si simplemente gestiono un dominio de empresa?
Nada específico de DKIM2: comprueba que tu DKIM actual está correctamente publicado y firmado, que tu DMARC está en marcha y vigilado, y que tu rotación de claves está documentada. El trabajo real de migración concierne a los ESP, a los relés y a las listas de distribución, no a los propietarios de dominio.
📖 Glosario
Replay DKIM
Reexpedición masiva, o hacia otros objetivos, de un mensaje ya firmado por un dominio legítimo, sin alterar lo que cubre la firma: esta sigue siendo válida, porque DKIM firma el contenido pero ni el sobre SMTP ni la ruta. El dominio firmante ve degradarse su reputación por correo que no ha enviado, y ninguna mitigación de DKIM1 (limitación de caudal por selector, rotación de claves, endurecimiento de DMARC) cierra el fallo. En DKIM2, la firma incluye el sobre del salto y encadena la ruta mediante el número i=.
Backscatter
Rebotes no deseados (NDR, DSN) o respuestas automáticas enviados a un tercero inocente cuya dirección se ha suplantado en el MAIL FROM o en el Return-Path: su buzón se inunda de informes de no entrega. En DKIM1 se rechaza durante el intercambio SMTP y no después, con SRS o VERP para trazar los rebotes; en DKIM2, los retornos remontan la cadena firmada hasta el salto anterior, es decir, hacia un actor realmente implicado.
Message-Instance
Encabezado DKIM2 que describe el estado de un mensaje en un momento de su recorrido: m= (número de revisión) y h= (hash de los encabezados y del cuerpo) obligatorios, r= (recetas) opcional.
Receta
Descripción JSON, codificada en base64 en el tag r= de un Message-Instance, que permite reconstruir la instancia anterior del mensaje.
Fuentes
- draft-ietf-dkim-dkim2-spec, la especificación
- draft-ietf-dkim-dkim2-bcp, las buenas prácticas
- draft-ietf-dkim-dkim2-dns, la parte DNS
- Documentos del grupo de trabajo dkim del IETF
- Acta de la sesión DKIM en el IETF 125
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
- RFC 8463: un nuevo método de firma para DKIM (Ed25519)
- Laura Atkins, «DKIM2: What it means for the future of email»
- Al Iverson, «What is DKIM2?»
- Al Iverson, «More on DKIM2: VERP, async bounces, signatures and hops»
DKIM2 sigue siendo un trabajo en curso. Esta página se actualizará conforme avancen las revisiones del borrador de especificación.
Verifica tu DKIM actual
Es tu configuración DKIM (RFC 6376) actual la que se reutilizará. Inspecciona tus selectores en vivo con el DKIM Record Checker y valida la sintaxis de cada registro publicado con el DKIM Syntax Validator.
Guías de autenticación de email relacionadas
- ARC pasa al estado «Historic» en el IETF - Lo que la reclasificación cambia de verdad, y lo que no
- DMARCbis: las novedades del futuro estándar - Las evoluciones de DMARC con DMARCbis
- ¿Qué es ARC (Authenticated Received Chain)? - Entender la cadena de autenticación ARC
- BIMI, VMC y CMC: compatibilidad DNS - Guía completa sobre BIMI y los certificados de marca
- Gmail Bulk Sender: los nuevos requisitos - Cumplimiento de las reglas de envío masivo de Gmail
