Resumen

  • DKIM válido demuestra una firma sobre material canónico seleccionado con la clave s= y el dominio d=; no autoriza por sí solo el dominio visible en From.
  • RFC 9989 añade alineación DMARC. Incluso ese resultado no prueba verdad, inocuidad, vigencia ni permiso para una operación comercial.

Un pase unido al nombre equivocado

El verificador obtuvo por DNS la clave del atacante, recalculó bh= y validó b=. El error llegó cuando una regla leyó «pass» sin conservar el dominio que había pasado.

d= identifica el dominio firmante; s= selecciona la clave; h= enumera cabeceras; bh= resume el cuerpo canonicalizado; b= firma las cabeceras elegidas y el propio campo DKIM con su valor de firma vacío. From debe estar firmado, pero eso sólo impide cambiar el texto después. No demuestra que d= controle el dominio escrito en From.

Si el resumen del cuerpo no coincide, RFC 6376 exige que falle toda la firma, aunque la parte de cabeceras pareciera válida. Por eso la traza debe conservar canonicalización, entrada exacta, cobertura y cada resultado, no un único verde.

Canonicalizar no juzga el mensaje

Los modos simple y relaxed toleran cambios distintos. Un espacio inocuo puede romper una firma y una orden dañina sin cambios puede pasar. La operación protege una forma de bytes, no su significado.

El l= opcional limita el cuerpo firmado a un prefijo. Un tercero puede añadir texto después sin alterar bh=; l=0 deja todo el cuerpo sin firmar. Si la interfaz muestra el sufijo bajo el mismo distintivo, exagera el alcance criptográfico.

DMARC une los dominios

RFC 9989, vigente desde mayo de 2026 y sustituta de RFC 7489, compara el dominio autor de RFC5322.From con un identificador DKIM o SPF autenticado. La alineación estricta exige igualdad; la relajada, el mismo dominio organizativo.

Así, el mensaje inicial pasa DKIM para el atacante y falla alineación con el banco. Y aun cuando DMARC pase, la norma limita el resultado a uso autorizado del dominio autor: no declara seguro ni deseable el contenido.

Envelope SMTP, SPF, d=, i=, From y cuenta SMTP autenticada siguen separados. Authentication-Results sólo merece confianza si procede de un productor autorizado dentro del dominio receptor. ARC conserva evaluaciones anteriores a las modificaciones de listas, pero su cadena también necesita confianza local.

Repetir conserva la firma

t= puede registrar creación y x= caducidad, pero RFC 6376 aclara que x= no impide repetición. Un correo íntegro puede volver a activar una acción. El flujo comercial necesita identificadores, estado e idempotencia propios.

Pruebe un dominio atacante con From ajeno, contenido hostil pero alineado, un sufijo después de l=, cambios en cabeceras firmadas y no firmadas, canonicalización simple/relaxed, varias firmas, rotación DNS, un Authentication-Results falso, una lista que modifica el mensaje y un replay. Cada resultado debe conservar su sustantivo.