SPF, DKIM y DMARC en Authentication-Results · Análisis de phishing en 40 minutos

El From se escribe a mano. Para saber si un correo viene de verdad del dominio que dice, los servidores aplican tres controles, SPF, DKIM y DMARC, y dejan el resultado en una cabecera: Authentication-Results. No necesita configurarlos para analizarlos; necesita leer esa línea sin equivocarse, y el error más común es justamente leerla a medias.

Los tres controles

Sigla	Nombre original	En español
SPF	Sender Policy Framework	Marco de políticas del remitente
DKIM	DomainKeys Identified Mail	Correo identificado con claves del dominio
DMARC	Domain-based Message Authentication, Reporting and Conformance	Autenticación, reporte y cumplimiento basados en el dominio

SPF responde: ¿esta IP tiene permiso para mandar correo de este dominio? El dueño publica en DNS la lista de servidores autorizados. Se evalúa sobre el dominio del Return-Path, no sobre el From.

DKIM responde: ¿el mensaje viene firmado por este dominio y llegó sin cambios? El emisor firma cabeceras y cuerpo con una clave privada, y el receptor verifica con la clave pública publicada en DNS. El dominio firmante aparece en d=.

DMARC junta los dos con el From visible. Exige que SPF o DKIM pasen y que su dominio coincida (esté alineado) con el del From. El dueño del dominio dice además qué hacer si falla: none (solo reportar), quarantine (a spam) o reject (rechazar).

Cómo leer Authentication-Results

Siempre tiene la misma forma: el servidor que verificó y un resultado por control, con el dominio evaluado.

Authentication-Results: SERVIDOR; spf=RESULTADO smtp.mailfrom=DOMINIO; dkim=RESULTADO header.d=DOMINIO; dmarc=RESULTADO header.from=DOMINIO

Resultado	Qué significa
`pass`	El control se cumplió para el dominio indicado
`fail`	Falló: no autorizado, firma inválida o sin alineación
`softfail`	Solo SPF: el dominio dice "probablemente no autorizado" (`~all`)
`none`	No hay registro publicado o el correo no venía firmado
`temperror` / `permerror`	Error temporal de DNS / registro mal escrito

El correo de la lección anterior:

Authentication-Results: mx1.ejemplo.cr;
       spf=pass (sender IP is 198.51.100.23) smtp.mailfrom=bancoceiba-seguridad.example;
       dkim=pass header.d=bancoceiba-seguridad.example header.s=s1;
       dmarc=fail (p=reject) header.from=bancoceiba.ejemplo.cr

Campo por campo. spf=pass con smtp.mailfrom=bancoceiba-seguridad.example: la IP sí está autorizada, pero para el dominio del atacante. dkim=pass con header.d=bancoceiba-seguridad.example: firma válida, otra vez del dominio del atacante. dmarc=fail con header.from=bancoceiba.ejemplo.cr: ninguno de los dominios que pasaron coincide con el From visible. El banco publicó p=reject; si el correo llegó al buzón igual, el servidor receptor no aplicó esa política, y eso también va en el reporte.

He visto a analistas nuevos cerrar tickets como "legítimo" porque vieron dos pass en verde. Un pass en SPF y DKIM solo dice que el atacante configuró bien su propio dominio, cosa que cuesta diez minutos. Lo que importa es la alineación, y eso lo dice DMARC.

Un correo legítimo, para comparar

Authentication-Results: mx1.ejemplo.cr;
       spf=pass smtp.mailfrom=bancoceiba.ejemplo.cr;
       dkim=pass header.d=bancoceiba.ejemplo.cr header.s=sel2026;
       dmarc=pass (p=reject) header.from=bancoceiba.ejemplo.cr

Los tres dominios coinciden. Aun así, un correo legítimo puede salir de una cuenta comprometida del propio banco o de un proveedor suyo: DMARC en verde dice de dónde salió, no que el contenido sea inofensivo. Los enlaces y adjuntos se revisan igual.