Un mensaje firmado puede seguir siendo spam. Su dominio de firma también puede diferir de la dirección que se muestra al destinatario.
¿Qué cubre una firma DKIM?
Una firma DKIM protege campos de encabezado seleccionados y un hash del cuerpo.
La etiqueta h= lista los campos de encabezado firmados. La etiqueta bh= contiene el hash del cuerpo. El servidor de envío produce la firma con su clave privada. Los receptores la verifican con la clave pública correspondiente.
El receptor recalcula el hash del cuerpo. También verifica la firma sobre los encabezados seleccionados y el encabezado de firma, que contiene ese hash.
RFC 6376 requiere firmar el encabezado From. Otros campos de encabezado pueden permanecer sin firmar. Agregar un Reply-To sin firmar puede, por lo tanto, dejar DKIM válido.
Los encabezados repetidos necesitan tratamiento separado. El firmante puede listar un nombre de encabezado más veces de las que aparece, para evitar que se agregue otra ocurrencia sin ser detectada.
¿Dónde encuentra el receptor la clave pública?
El receptor localiza la clave pública usando el dominio de firma y el selector, el nombre que identifica esa clave. La etiqueta d= indica el dominio. La etiqueta s= indica el selector.
Para d=example.com y s=foo.bar, el nombre de consulta es foo.bar._domainkey.example.com. El selector permite diferentes claves bajo el mismo dominio de firma.
Durante la rotación, publica la clave de reemplazo antes de firmar con ella. Mantén la clave de verificación anterior disponible mientras los mensajes firmados con ella sigan en tránsito. Eliminarla prematuramente impide que los receptores verifiquen esos mensajes.
¿Por qué los cambios de formato pueden romper una firma?
La canonicalización, la normalización aplicada antes de la firma y la verificación, determina qué cambios de formato tolera DKIM.
La etiqueta c= elige algoritmos separados para encabezado y cuerpo. En relaxed/relaxed, ambos usan normalización relaxed.
| Algoritmo | Comportamiento de encabezado | Comportamiento del cuerpo |
|---|---|---|
simple | Preserva el formato del encabezado | Ignora líneas vacías al final |
relaxed | Normaliza mayúsculas del nombre de encabezado, plegado y espacios en blanco | Normaliza espacios en blanco y líneas vacías al final |
Un encabezado plegado continúa en otra línea. El procesamiento relaxed de encabezados tolera ese plegado. El procesamiento simple puede fallar después de que un servidor vuelva a plegar el mismo encabezado.
Compara el contenido firmado antes y después del relay que falla, porque un cambio de formato invisible puede explicar el resultado.
¿Qué algoritmos de firma soporta DKIM?
DKIM soporta los algoritmos de firma RSA y Ed25519, ambos combinados con SHA-256.
RSA tiene un tamaño mínimo de clave de 1024 bits según RFC 8301. Las claves más cortas ofrecen resistencia insuficiente al compromiso de clave.
El tamaño RSA recomendado es de al menos 2048 bits, lo que ofrece mayor resistencia al compromiso de clave. Elige ese tamaño cuando tu sistema de firma lo soporte. La especificación prohíbe rsa-sha1 para firma y verificación.
RFC 8463 agrega ed25519-sha256. Un mensaje puede llevar firmas RSA y Ed25519 para compatibilidad con receptores que soportan diferentes algoritmos.
La guía de Yahoo también requiere una clave DKIM de al menos 1024 bits.
¿Qué sucede cuando una lista de correo edita el mensaje?
Una edición puede invalidar DKIM cuando cambia contenido cubierto por la firma.
El reenvío por sí mismo no cambia el contenido firmado. Una firma intacta puede sobrevivirlo. Un pie de página agregado puede cambiar el hash del cuerpo. Un Subject firmado que se reescribe puede invalidar la firma del encabezado.
La etiqueta opcional l= limita la cobertura del cuerpo a un número especificado de bytes. Con l=100, el contenido después de los primeros 100 bytes normalizados queda desprotegido. Agregar texto engañoso puede, por lo tanto, dejar la firma válida.
Evita ese límite cuando necesites proteger todo el cuerpo. ARC permite a los intermediarios preservar evidencia firmada de autenticación antes de sus ediciones.
¿Cómo configuras DKIM con Bird?
Publicas el registro DKIM que se devuelve cuando registras tu dominio de envío.
El campo dkim.mode de API tiene como valor predeterminado txt. Con ese modo, publica la clave pública en un registro TXT. El esquema también lista delegated. Ese valor devuelve HTTP 422 cuando registras un dominio de envío, así que usa txt.
Bird crea una clave y un selector separados para cada organización que usa un dominio de envío. Las organizaciones que usan el mismo dominio no necesitan compartir una clave de firma.
La guía de autenticación explica el registro devuelto.
¿Una firma exitosa demuestra que el mensaje es seguro?
Una firma exitosa establece responsabilidad sobre el contenido firmado. No establece si el mensaje es deseado o confiable.
Tampoco requiere que el dominio de firma coincida con el dominio From visible. DMARC proporciona esa regla de coincidencia a través del alineamiento. La reputación del remitente, la evaluación que hace el receptor del tráfico de un remitente, sigue siendo una consideración separada.
En resumen
Solo se protege el contenido seleccionado.
DKIM cubre los campos de encabezado listados y un hash del cuerpo. El contenido no protegido puede cambiar sin invalidar la firma.
Los selectores localizan las claves de verificación.
El selector y el dominio de firma identifican el registro DNS que contiene la clave pública.
La normalización afecta la verificación.
Los algoritmos simple y relaxed tratan los cambios de formato de manera diferente.
El reenvío no garantiza un resultado exitoso.
Una firma intacta puede sobrevivir al reenvío, pero los cambios en el contenido firmado pueden romperla.