Email herramientas
Cómo funciona de verdad la autenticación del correo: las dos direcciones From, qué demuestra cada uno de SPF, DKIM y DMARC, cómo leer una cadena Received, y qué herramienta usar con encabezados o con un .eml.
3 herramientas
Las dos direcciones From
Casi toda pregunta sobre suplantación de correo se reduce a confundir dos
identidades de remitente. El remitente del sobre es la dirección que se aporta en
el comando SMTP MAIL FROM: ahí van los rebotes, y quien recibe la registra como
Return-Path: o smtp.mailfrom= dentro de Received-SPF:. El remitente del
encabezado es el campo From: que va dentro del mensaje, el único que ve una
persona. Nada en SMTP exige que ambos coincidan.
SPF autoriza el sobre: ¿tenía permiso la IP que conecta para enviar por el dominio del
MAIL FROM? DKIM autoriza el contenido: quien envía firma una lista elegida de campos
de encabezado (h=) más un hash del cuerpo (bh=), y publica la clave pública en el
DNS. Ninguno dice nada sobre la dirección que lee el destinatario. DMARC cierra ese
hueco exigiendo alineación: el dominio del From: visible debe coincidir con el
dominio de SPF o con el dominio d= de DKIM. Un spf=pass en un correo que dice venir
de tu banco es perfectamente normal en un phishing; un dmarc=pass no lo es.
La tercera idea que hay que interiorizar: no eres tú quien verifica nada de esto. El
MTA receptor ejecuta las comprobaciones en el momento de la entrega y escribe su
veredicto en un encabezado Authentication-Results:. A partir de ahí, el resultado es
una afirmación en un archivo de texto, fiable solo si el salto que lo escribió
pertenece a tu propia infraestructura. Un encabezado escrito por el servidor de un
desconocido puede haberlo inventado ese desconocido. Lee hacia fuera desde tu MTA de
frontera y trata todo lo que hay más allá como entrada no confiable.
Qué demuestra cada mecanismo
| Mecanismo | Se publica en | Autentica | Sobrevive al reenvío | Impide suplantar el From: visible |
|---|---|---|---|---|
| SPF | TXT en el dominio del sobre, v=spf1 … | La IP que conecta para el MAIL FROM | No — la IP del relé no está en la lista | No |
| DKIM | TXT en <selector>._domainkey.<d=> | Los encabezados de h= + el hash del cuerpo bh= | Sí, salvo que se altere el cuerpo o el Subject | Solo si hay alineación |
| DMARC | TXT en _dmarc.<dominio> | La alineación del From: con SPF o DKIM, más la política | Sí, a través del DKIM que sobrevive | Sí — es toda su razón de ser |
| ARC | Encabezados ARC-Seal / ARC-Message-Signature | Preserva los resultados previos a través de un relé | Diseñado exactamente para esto | No — y solo cuentan los selladores de confianza |
| MTA-STS / DANE | TXT en _mta-sts.<dominio> / TLSA | El transporte: que TLS era obligatorio | no aplica | No |
Los tokens de resultado son vocabulario común a las tres comprobaciones, y cada uno señala una solución distinta:
| Token | Significado | Causa habitual |
|---|---|---|
pass | La comprobación fue correcta | — |
fail | No autorizado, en firme (-all) | Suplantación, o un relé emisor que falta en el registro |
softfail | No autorizado, solo marcar (~all) | Registro dejado permisivo a mitad de despliegue |
neutral | Explícitamente sin opinión (?all) | La política no dice nada útil |
none | No hay registro publicado | El dominio nunca configuró SPF ni DMARC |
temperror | Fallo de DNS, se puede reintentar | Resolutor o servidor autoritativo inestable |
permerror | El registro no se puede evaluar | Más de 10 consultas DNS, v=spf1 duplicado, error de sintaxis |
Qué herramienta para cada trabajo
Si tienes el bloque de encabezados en bruto — «Mostrar original» en Gmail, «Ver código
fuente» en otros clientes — empieza por
Análisis de Encabezados. Despliega las líneas de continuación,
invierte la pila Received: para que el salto 1 sea el servidor de origen y el último
salto tu proveedor, y muestra los segundos entre saltos contiguos, de modo que
Delay: 1800s señala el relé que retuvo el mensaje media hora. Bajo la ruta imprime
Authentication-Results, Received-SPF, DKIM-Signature y
ARC-Authentication-Results literalmente: el veredicto de DMARC vive dentro del
primero, como dmarc=pass (p=REJECT …). El análisis se queda en el navegador, y eso es
justamente lo importante: esos encabezados llevan IP de remitentes y nombres de host
internos.
Con un archivo .eml completo en cambio — un rebote, un adjunto guardado, la salida de
un formulario de correo — usa el Visor EML. Separa los encabezados
del cuerpo, descodifica las palabras codificadas de la RFC 2047 (=?UTF-8?B?…?=) para
que los asuntos no ASCII se lean como texto, y destaca From, To, Cc, Subject,
Date, Reply-To y Message-ID. Un Reply-To en un dominio distinto del From: es
una señal clásica de fraude del CEO. El cuerpo se muestra en bruto, así que las
fronteras MIME quedan visibles; pasa las partes en base64 por
Base64 para leer una.
Con solo un dominio y ningún mensaje, pasa al DNS.
DNS Lookup resuelve TXT (tu cadena v=spf1), MX (el
enrutamiento, con prioridad) y más, junto con el TTL que determina cuánto tarda en
surtir efecto un arreglo; el hub de dns trata la caché en profundidad.
Es una herramienta de servidor: el nombre de dominio va a api.sitekits.dev para su
resolución y no se almacena. Solo acepta etiquetas de nombre de host, así que los
nombres con guion bajo como _dmarc.example.com y
selector._domainkey.example.com se rechazan; esos léelos con
dig TXT _dmarc.example.com.
Para los enlaces que van dentro de un mensaje sospechoso, el
Parseador de URL descompone una URL en host, ruta y parámetros de
consulta descodificados sin solicitarla nunca, y el
Convertidor IDN expone los dominios homógrafos mostrando la forma
xn-- que se resuelve de verdad. Los dos se ejecutan en el navegador, y ambos están
reunidos en /es/for/security/ junto al analizador de encabezados y
el visor de .eml. Las marcas de tiempo de los saltos en desplazamientos ajenos
encajan más rápido con el
Convertidor de Zona Horaria, también local al navegador,
pero reunido en /es/for/sre/ y no en la página de seguridad. Antes de
adjuntar pruebas a un ticket, censura a mano: el
Sanitizador HAR cubre las exportaciones HAR, no los encabezados
de correo.
Dónde se suele torcer
p=none no protege nada
p=none solo pide informes. Publicarlo es el primer paso correcto, pero hasta que
llegues a p=quarantine o p=reject, quien recibe no aplica ninguna política ante un
fallo. Revisa también pct=: un despliegue parcial solo aplica la política a esa
proporción del correo.
Reventar el presupuesto de diez consultas
include:, a, mx, ptr y redirect= cuestan cada uno consultas DNS, y las
cadenas de include: anidadas de los proveedores SaaS suman las suyas de forma
recursiva. Pasa de diez y el registro se convierte en permerror, que quien recibe
interpreta como ausencia total de SPF. Aplánalo o quita los proveedores que ya no uses.
Leer todos los fallos como un ataque
Los reenvíos y las listas de correo rompen la autenticación de forma legítima: la IP
del relé falla el SPF, y un prefijo de asunto [lista] o un pie añadido invalidan el
hash del cuerpo de DKIM. Juzga por la alineación y por el relé que sella, no por un
único fail.
Confiar en saltos que no son tuyos
Solo significan algo las líneas Received: y Authentication-Results: añadidas en tu
MTA de frontera o después; los saltos anteriores son texto que controla el atacante.
Los retardos que salen negativos o como — son desfase de reloj o falta de marca de
tiempo, no pruebas.
Dejar abiertos los dominios que no envían
Los dominios aparcados y los subdominios que nunca envían correo necesitan igualmente
v=spf1 -all, un registro DMARC en _dmarc.<dominio> con p=reject y, a ser posible,
un MX nulo (MX 0 .). p= es la etiqueta de política obligatoria: un registro que
solo lleve sp=reject no es válido, así que quien recibe no aplica nada y el propio
dominio aparcado sigue sin protección. Añade sp=reject junto a p= cuando quieras
declarar de forma explícita la política de los subdominios; si falta sp=, los
subdominios heredan p= de todas formas. Si se deja abierto, el dominio es material de
suplantación gratuito con tu marca.