Qué significa realmente «dkim=pass»

Si ha abierto las cabeceras de un correo, ha encontrado una línea como dkim=pass header.d=supplier.com; spf=pass; dmarc=pass y quiere saber si eso significa que el mensaje es seguro: significa que el mensaje vino realmente de ese dominio, y nada más. No dice nada sobre si la factura es auténtica, si los datos bancarios son correctos o si la persona que escribía era su proveedor.

No es un tecnicismo. El fraude de facturas más caro de Europa supera las tres comprobaciones, siempre, porque se envía desde el buzón real del proveedor. Si tiene delante una petición de pago, la comprobación de correo del proveedor lee el mensaje y dice cuáles de estas cosas ha podido establecer realmente y —igual de importante— cuáles no.

Qué pregunta en realidad cada una de las tres comprobaciones

A menudo se escriben como si fueran un solo veredicto. Son tres preguntas distintas, y ninguna de ellas es «¿es honesto este correo?».

SPF pregunta si el servidor que entregó el mensaje es uno de los que el titular del dominio declaró autorizados para enviar. Es una pregunta sobre una dirección IP. No dice nada sobre quién escribió el mensaje ni sobre lo que contiene.

DKIM pregunta si una firma criptográfica sobre partes del mensaje coincide con una clave pública publicada en el DNS del dominio. Que pase significa que alguien en posesión de la clave privada de ese dominio firmó esas partes, y que no se han alterado desde entonces. Es la más fuerte de las tres, y es una afirmación sobre el dominio, no sobre la intención de quien envía.

DMARC pregunta si SPF o DKIM pasaron para un dominio que coincide con la dirección From: que ve el lector, y dice a los servidores receptores qué hacer cuando no pasa ninguno de los dos. Ata los otros dos al remitente visible. Eso vale de verdad, y sigue sin ser una afirmación sobre el contenido.

Así que dkim=pass header.d=supplier.com significa: esto es realmente el dominio de su proveedor. Que es exactamente lo que cabe esperar cuando un delincuente está sentado en el buzón de su proveedor.

El fraude que supera todas las comprobaciones

La versión del fraude de facturas que triunfa no es un dominio clon. Es un correo real desde el buzón real del proveedor real, alcanzado normalmente con una contraseña de una filtración ajena o con una página de phishing rellenada semanas antes.

Todo autentica, porque todo es auténtico:

• el mensaje lo firma el propio dominio del proveedor, así que DKIM pasa;
• sale del servicio de correo del propio proveedor, así que SPF pasa;
• la dirección From: coincide, así que DMARC pasa;
• el historial del hilo es real, porque es el hilo real.

Solo los datos bancarios son nuevos. La autenticación de correo no tiene opinión sobre los datos bancarios.

Por eso «el correo autenticó» nunca es una razón para pagar, y por eso todos los resultados de este sitio —también los limpios— terminan con la misma frase sobre llamar a un número que ya tuviera. Hay un recorrido más largo en un proveedor pide cambiar sus datos bancarios.

Quién escribió la línea que está leyendo

Hay una segunda trampa, y es fácil pasarla por alto.

Authentication-Results: es una cabecera escrita por el servidor de correo que recibió el mensaje, normalmente su propio proveedor. Cuando lee ahí dkim=pass, está leyendo el veredicto de otro, registrado en el momento de la entrega. Eso suele ser fiable, porque lo escribió su propio proveedor.

Pero las cabeceras no son más que texto. Si el bloque le llegó reenviado, pegado en un ticket, copiado de la captura de pantalla de un compañero o entregado por quien pide cobrar, entonces la línea que dice dkim=pass es una afirmación de quien produjo ese texto, y cualquiera puede teclearla. No hay criptografía que proteja una cabecera que dice que la criptografía funcionó.

La distinción honesta es entre tres situaciones bastante distintas:

Qué tiene	Qué puede establecerse
El mensaje original completo, con su firma	La firma puede verificarse ahora, por usted
Solo cabeceras, con una línea Authentication-Results	El veredicto registrado por el servidor receptor, aceptado por confianza
Ninguna de las dos cosas: solo el correo visible	Solo lo que publica el dominio: SPF, DMARC, MX

Cualquier herramienta que le enseñe lo segundo y lo llame lo primero le está diciendo algo que usted no tiene modo de comprobar. La comprobación de correo del proveedor indica cuál de las tres está haciendo, y nunca asciende una a otra: un dkim=pass que aparece en un bloque de cabeceras pegado se informa como el veredicto del receptor, dicho con esas palabras.

Cuándo un «fail» importa más que un «pass»

Un «pass» es prueba débil. Un «fail» es prueba fuerte, y merece que se pare.

Si la verificación DKIM se ejecuta de verdad y no cuadra —la firma no coincide con el contenido—, el mensaje se alteró después de firmarse, o ese dominio nunca lo firmó. Si DMARC está en p=reject y el mensaje falló de todos modos, no debería haberse entregado.

Hay una asimetría que conviene llevar puesta: no se pudo comprobar no es lo mismo que falló. Una consulta DNS inalcanzable, una clave revocada, una firma caducada o una firma que solo cubre parte del cuerpo significan todas que la aritmética no pudo completarse. Eso no es un hallazgo en contra de quien envía, y una herramienta que lo presenta como tal desperdicia la única señal sobre la que habría valido la pena actuar.

Qué hacer con un mensaje que no le convence

1. No responda. Si el buzón está comprometido, su respuesta va al atacante, y una regla de buzón puede ocultársela al proveedor real.
2. Llame al proveedor a un número de una factura antigua, de su sistema contable, o de su web a la que haya llegado tecleando usted mismo la dirección.
3. Compruebe los identificadores por separado: el número de IVA, la inscripción en el registro mercantil y, para un proveedor polaco, si la cuenta está en la lista blanca. El verificador de facturas hace todo eso a partir del propio documento.
4. Trate el cambio de datos bancarios como el acontecimiento, no el correo que lo rodea. Eso es lo que merece una llamada, digan lo que digan las cabeceras.

Qué no puede decirle esto

La autenticación de correo comprueba el canal, no la afirmación. No puede decirle que la mercancía se pidió, que el importe es correcto, que la persona que escribe siga trabajando allí, ni que la cuenta sea de su proveedor. Polonia es el único país de la UE que publica una respuesta a esa última pregunta, y por eso la lista blanca merece usarse donde sea aplicable.

En todo lo demás, el control que detiene esto es una llamada de voz a un número que ya tuviera.