El replay de DKIM: cuando una firma válida alimenta el spam

Las cabeceras no firmadas, un ángulo de ataque

El replay básico reexpide el mensaje idéntico. Una variante más fina explota lo que la firma no cubre. La etiqueta h= enumera con precisión las cabeceras firmadas; toda cabecera ausente de esa lista escapa a la protección y puede, por tanto, añadirse o modificarse sin invalidar la firma.

Las consecuencias son concretas. Si Subject no figura en el h=, el asunto del mensaje se reescribe a voluntad para encajar en cada campaña, sin tocar la huella. Si To no está firmado, el destinatario mostrado se falsea. Más retorcido aún: la inyección de una cabecera duplicada. Muchos programas de correo muestran la primera — o la última — aparición de una cabecera; si el firmante firmó solo una, añadir un segundo Subject o un segundo From se cuela ante la verificación y a la vez cambia lo que el humano ve en pantalla. El mensaje reproducido se personaliza así para cada víctima, mientras la firma original permanece técnicamente intacta: solo cubría lo que el firmante quiso incluir.

Las defensas, sobre todo del lado del firmante

La dificultad se resume en un desequilibrio: el destinatario solo ve una firma válida y no dispone de casi ninguna palanca. Las verdaderas defensas viven en quien firma — un gran remitente, un ESP, un proveedor de correo.

• Firmar amplio. La primera defensa consiste en incluir en h= toda cabecera que lleve sentido: From, To, Cc, Subject, Date, Message-ID, Reply-To, Content-Type y más. Cuanta más amplia sea la cobertura, menos superficie no firmada queda para manipular. Un h=from reducido al mínimo deja todo lo demás abierto al falseo.
• La cabecera sobredeclarada (oversigning). La técnica consiste en firmar una cabecera más veces de las que aparece realmente en el mensaje — por ejemplo declarando h=from:from:to:to:subject:subject:…. Añadir una aparición suplementaria de una de esas cabeceras rompe entonces el recuento esperado, y la verificación falla. Es el contraataque directo a la inyección de duplicados: impide añadir un segundo Subject o un segundo From sin romper la firma.
• Claves de vida corta y rotación regular. Un mensaje reproducido solo sigue siendo verificable mientras la clave pública asociada esté publicada. Rotar las claves y retirar los selectores antiguos acorta la ventana durante la cual una firma capturada sigue siendo válida — uno de los beneficios de la rotación de las claves DKIM. El límite es nítido: la rotación no bloquea un replay inmediato, ya que lo esencial del daño se produce en las horas siguientes a la captura, mucho antes de cualquier rotación razonable.
• La etiqueta x=, con sus límites. DKIM permite fechar la caducidad de una firma mediante la etiqueta x= (una marca de tiempo). Pasado ese plazo, un verificador puede rechazar la firma. En teoría, una ventana corta reduce el tiempo útil para el replay. En la práctica, tres reservas: no todos los verificadores aplican x=; una ventana demasiado ceñida hace fallar el correo legítimo retrasado (colas, reenvíos, demoras de greylisting); y unos minutos bastan a menudo para lanzar una difusión masiva. La etiqueta reduce el riesgo, no lo suprime.
• Vigilar los picos anómalos. Del lado del dominio firmante, un replay deja el rastro descrito arriba: una oleada de mensajes «solo DKIM» desde direcciones ajenas al parque de envío habitual. Un dominio legítimo emite desde un conjunto estable de IP; un pico que se aparta de él señala un replay en curso, y la lectura regular de los informes es el único medio de detectarlo pronto.

Un punto merece una afirmación clara, porque invita a la confusión: alargar la clave de 1024 a 2048 bits protege contra la falsificación de una firma, no contra el replay. Aquí la clave nunca se rompe — una firma auténtica simplemente se reutiliza. Confundir ambas amenazas lleva a reforzar la cerradura equivocada.

Qué cambia DMARCbis (y qué no)

DMARCbis, el estándar vigente descrito por las RFC 9989, 9990 y 9991, moderniza varios mecanismos: la Public Suffix List cede el paso al recorrido del árbol DNS (DNS Tree Walk), la etiqueta pct desaparece en favor de un modo de prueba llevado por t=, y nuevas etiquetas como np o psd afinan el tratamiento de los subdominios. Ninguna de estas evoluciones toca el replay.

La razón es estructural: DMARCbis razona todavía en el nivel de la alineación, y sigue devolviendo pass ante una firma DKIM válida y alineada. El replay opera una capa por debajo, en el propio DKIM, donde DMARCbis no añade ni contador ni noción de destinatario único. Migrar al estándar vigente sigue siendo conveniente por otras razones, pero no cierra esta puerta. La comunidad IETF trabaja por su parte en extensiones destinadas a hacer DKIM resistente al replay — atar una firma a un envío, a un volumen o a una trayectoria —, pero ese trabajo no constituye aún un estándar desplegado a gran escala en 2026. Tal como está, la defensa sigue siendo organizativa, no protocolaria.

Quién está realmente afectado

El replay apunta ante todo a las identidades que vale la pena tomar prestadas. Los grandes remitentes, las plataformas de emailing y los proveedores de correo que ofrecen cuentas gratuitas o de prueba concentran el problema: su buena reputación es el activo codiciado, y la cuenta de prueba es el vector de captura. Para ellos el asunto es operativo y permanente — su nombre sirve de vehículo al spam, y su entregabilidad se resiente. Ahí es donde se justifican la firma amplia, el oversigning, la detección de abuso de cuentas de prueba y la limitación de tasa.

El dominio de una pyme está en otra posición. Su reputación no tiene, por lo general, suficiente valor para convertirlo en objetivo de replay: un atacante no gana nada difundiendo bajo el nombre de un dominio pequeño y desconocido. La pyme rara vez es, por tanto, la fuente de un replay. En cambio, puede ser destinataria — y allí, ningún ajuste DMARC filtrará un mensaje que legítimamente pasa todas las comprobaciones; solo queda en juego el filtrado antispam clásico. La lección útil para un dominio pequeño es más amplia: firmar con limpieza y sobredeclarar las cabeceras clave sigue siendo una higiene poco costosa, y sobre todo, una firma válida autentica un dominio, nunca una intención. Es el mismo cimiento que sirve para prevenir la suplantación de correo: la autenticación prueba el origen, no la buena voluntad. Para ver en concreto qué cubre una firma y qué deja abierto, leer una firma DKIM en un mensaje recibido es el ejercicio de base.

En resumen

El replay de DKIM explota una propiedad buscada del protocolo: una firma válida lo sigue siendo mientras el cuerpo y las cabeceras firmadas no cambian, sin vínculo con el envío original ni con la lista de destinatarios. Un mensaje firmado una vez por un dominio con reputación — a menudo mediante una cuenta de prueba — se redistribuye en masa y franquea los filtros gracias a una reputación prestada. DMARC no ve nada, porque todo es técnicamente correcto; las cabeceras no firmadas añaden un ángulo de disfraz. Las defensas viven del lado del firmante: un h= amplio, el oversigning, la rotación de claves, la etiqueta x= de efecto parcial, y la vigilancia de picos. DMARCbis no cierra esta puerta, y el riesgo pesa sobre todo en los grandes remitentes, mucho más que en el dominio de una pyme.

Un primer diagnóstico no cuesta nada: el análisis DMARC gratuito revela el estado de las firmas de un dominio, la estabilidad de sus fuentes de envío y las alineaciones vigentes. Para seguir en el tiempo la cobertura de las cabeceras firmadas y detectar los picos anómalos en los informes — la señal discreta de un replay —, crear una cuenta abre el seguimiento continuo que esta amenaza, silenciosa por naturaleza, hace necesario.