Glosario de la autenticación de email (SPF, DKIM, DMARC, BIMI…)
Por Thomas · CISO virtual · 17 de agosto de 2026
La autenticación de email arrastra una jerga densa: SPF, DKIM, alineación, RUA, Tree Walk, BIMI, VMC… Un montón de siglas que se solapan, se condicionan y que terminamos confundiendo. Este glosario pone cada término en su sitio, en una definición corta y autónoma — la que se puede citar, pegar en un ticket o exponer ante una dirección sin equivocarse. Avanzamos de los cimientos hacia los mecanismos avanzados, y luego hacia las amenazas que todo este dispositivo trata de cortar. Cada entrada remite al artículo que la desarrolla en profundidad.
Los cimientos
SPF (Sender Policy Framework)
SPF es un registro DNS de tipo TXT que lista los servidores autorizados a enviar correo por un dominio. En la recepción, el servidor destinatario compara la dirección IP emisora con esa lista: si no figura en ella, el mensaje falla el control SPF. Es la primera de las tres capas de autenticación, pero tiene un límite nativo: valida el sobre (MAIL FROM), no la dirección From: que ve el humano. Para el detalle de los mecanismos y las trampas, ver cómo funciona SPF.
DKIM (DomainKeys Identified Mail)
DKIM añade una firma criptográfica a cada mensaje saliente: el remitente firma con una clave privada, y el destinatario verifica esa firma gracias a una clave pública publicada en DNS. Si el mensaje fue alterado en tránsito o forjado sin la clave, la firma no se sostiene. DKIM prueba, por tanto, tanto el origen como la integridad del mensaje. El funcionamiento detallado está descrito en qué es DKIM.
La clave privada DKIM es un secreto de primerísima importancia: quien la tenga puede firmar correo en nombre del dominio y franquear sus defensas haciéndose pasar por su titular. No tiene, por tanto, nada que hacer en un fichero de configuración versionado, un ticket o un canal de chat — su sitio es una caja fuerte de secretos dedicada como Hucency Vault, editada por el especialista en ciberseguridad Hucency, que centraliza este tipo de secreto bajo acceso controlado y registrado.
Selector DKIM
El selector es un simple identificador que permite a un dominio alojar varias claves DKIM en paralelo. Aparece en la cabecera DKIM-Signature (campo s=) y apunta al registro DNS de la clave pública correspondiente, en la dirección selector._domainkey.ejemplo.es. Gracias a él, cada proveedor (la mensajería, la herramienta de marketing, la facturación) puede firmar con su propia clave, y esas claves se rotan sin romperlo todo de golpe. Detallamos su papel en lo que el selector nombra en realidad.
DMARC
DMARC es la capa que vincula SPF y DKIM al dominio visible del campo From: y les dice a los destinatarios qué hacer en caso de fallo. Es un registro DNS (v=DMARC1) que define una política — no hacer nada, poner en cuarentena o rechazar — y solicita informes. Sin DMARC, SPF y DKIM protegen identificadores técnicos que el usuario no ve jamás; DMARC es lo que por fin protege la dirección mostrada. Los principios completos están en los fundamentos, explicados sin jerga.
Alineación (alignment)
La alineación es el corazón de DMARC: exige que el dominio validado por SPF o DKIM se corresponda con el dominio del From: visible. Un mensaje puede perfectamente pasar SPF y DKIM sobre dominios técnicos de un tercero mientras suplanta la dirección mostrada; la alineación cierra esa brecha imponiendo la concordancia. DMARC tiene éxito en cuanto al menos uno de los dos (SPF o DKIM) está alineado. El mecanismo se disecciona en SPF, DKIM y DMARC explicados juntos.
Política (p=none / quarantine / reject)
La etiqueta p del registro DMARC dicta el destino de los mensajes no autenticados. p=none observa sin actuar (los mensajes suplantados pasan, pero los informes siguen llegando); p=quarantine los coloca en correo no deseado; p=reject los bloquea en la puerta. Solo p=reject protege realmente un dominio — p=none no es más que una etapa de diagnóstico, no un destino. La elección entre los dos niveles de aplicación se trata en quarantine o reject.
Los informes
RUA (informe agregado)
Los informes RUA son síntesis XML diarias que los destinatarios devuelven a la dirección declarada en la etiqueta rua=. Recopilan, por fuente de envío, los volúmenes de correo y los resultados SPF/DKIM/DMARC — sin exponer jamás el contenido de los mensajes. Son el radar del dominio: revelan quién emite en su nombre, legítimamente o no, y guían la subida hacia p=reject. Su lectura está explicada en entender los informes agregados DMARC.
RUF (informe de fallo)
Los informes RUF (o forenses) se envían sobre la marcha, mensaje a mensaje, cuando un email falla la autenticación. Son mucho más detallados que los RUA — hasta incluir cabeceras y fragmentos del mensaje — lo que plantea serias cuestiones de privacidad, hasta el punto de que la mayoría de los destinatarios ya no los emiten. La diferencia de naturaleza entre ambos canales se desarrolla en qué aporta cada tipo de informe.
DMARCbis y las novedades
DMARCbis
DMARCbis es la revisión de DMARC publicada en 2026, que reemplaza la RFC 7489 original (2015) y lleva el protocolo por la vía oficial de los estándares. Mismo principio, mismo identificador v=DMARC1: no es una ruptura, sino un texto reescrito con nuevas etiquetas (np, t) y un mecanismo de atribución de dominio más robusto. Un registro existente sigue siendo válido. Lo que realmente cambia se detalla en qué es DMARCbis.
Etiqueta np
La etiqueta np fija la política aplicada a los subdominios que no existen. Es un objetivo de suplantación clásico: un atacante puede forjar factura.ejemplo.es aunque ese subdominio nunca se haya creado, porque nada lo protege por defecto. Poner np=reject cierra esa puerta sin ningún riesgo para el correo legítimo, ya que esos subdominios no emiten nada. Su funcionamiento está descrito en la etiqueta np de DMARC.
Etiqueta t
La etiqueta t reemplaza al antiguo pct e introduce un modo de prueba binario: t=y señala que el dominio está experimentando y que los destinatarios no deben aún aplicar estrictamente su política. Sirve para observar el efecto de un endurecimiento antes de activarlo de verdad, apoyándose en los informes en lugar de en un porcentaje aleatorio de mensajes. Su uso está explicado en la etiqueta t de DMARC.
DNS Tree Walk
El DNS Tree Walk es el mecanismo que, en DMARCbis, determina el dominio organizativo mediante una serie de consultas DNS sucesivas (ocho como máximo), remontando el árbol de nombres. Reemplaza la Public Suffix List, una lista externa mantenida a mano de la que DMARC dependía antes. Resultado: más previsibilidad, ninguna dependencia de un fichero de terceros. El recorrido exacto se detalla en el DNS Tree Walk explicado.
Dominio organizativo
El dominio organizativo es el dominio «raíz» bajo el que viven sus subdominios — por ejemplo mi-banco.es para mail.mi-banco.es. DMARC se apoya en esta noción para dos cosas: decidir si SPF o DKIM está alineado (alineación relajada), y saber qué política de subdominio (sp) se aplica. La forma en que DMARCbis lo calcula ahora — mediante el Tree Walk en lugar de una lista — está en el corazón de lo que cambia en DMARCbis.
Transporte y trazabilidad
MTA-STS
MTA-STS (Mail Transfer Agent Strict Transport Security) fuerza el cifrado TLS del transporte entre servidores de correo e impide que un atacante haga caer la conexión en texto claro. Se publica una política (mediante un registro DNS y un fichero servido en HTTPS) que exige que el correo entrante llegue únicamente por una conexión cifrada y autenticada. Es el complemento «transporte» de la autenticación «contenido» que aseguran SPF, DKIM y DMARC. Su puesta en marcha está descrita en MTA-STS explicado.
TLS-RPT
TLS-RPT (TLS Reporting) es el canal de informe asociado a MTA-STS: pide a los servidores remotos que señalen los fallos de negociación TLS encontrados al entregar correo. Se declara una dirección en un registro DNS _smtp._tls, y llegan síntesis que revelan los problemas de cifrado antes de que degraden silenciosamente la seguridad de transporte. El detalle está en el estándar de informes de transporte.
ARC (Authenticated Received Chain)
ARC preserva el resultado de autenticación de un mensaje cuando transita por un intermediario — una lista de distribución, un servicio de reenvío — que modifica legítimamente el contenido y que, de lo contrario, rompería SPF y DKIM. Cada relevo conforme a ARC firma una «cadena» que atestigua que la autenticación era válida a su llegada, lo que permite al destinatario final tenerlo en cuenta. ARC no reemplaza a DMARC; evita que flujos legítimos indirectos sean rechazados por error.
BIMI y la visualización de marca
BIMI (Brand Indicators for Message Identification)
BIMI muestra el logo de la marca junto a sus mensajes en las bandejas de entrada que lo soportan (Gmail, Yahoo, Apple Mail…). Es la recompensa visible de un dominio bien llevado: BIMI solo se concede a los dominios en p=quarantine o p=reject, lo que lo convierte en una señal de confianza tanto como en una palanca de marketing. Se publica un registro DNS que apunta al logo en formato SVG. La puesta en marcha completa está en instalar BIMI en Gmail.
VMC (Verified Mark Certificate)
El VMC es un certificado que prueba la posesión legítima del logo mostrado mediante BIMI. Emitido por una autoridad de certificación tras verificar la marca registrada, es exigido por Gmail y otros para mostrar el logo. Es la pieza que impide a un defraudador usurpar la identidad visual de una marca conocida. Su papel y su coste se detallan en el certificado VMC para BIMI.
CMC (Common Mark Certificate)
El CMC es una alternativa más accesible al VMC, destinada a los logos que no son marcas registradas (por ejemplo, una administración o una organización sin marca registrada). Permite mostrar un logo mediante BIMI sin pasar por el registro de marca exigido para un VMC, a cambio de otras formas de verificación. Los casos en los que se aplica se exponen en el logotipo sin certificado.
Las amenazas
Spoofing (suplantación de identidad)
El spoofing consiste en falsificar la dirección de remitente de un email para hacer creer que viene de una organización legítima. Técnicamente trivial — la dirección From: no es más que un campo de texto libremente modificable — es la amenaza fundamental que SPF, DKIM y sobre todo DMARC existen para neutralizar. Mientras un dominio no esté en p=reject, cualquiera puede enviar correo bajo su nombre. Los mecanismos y las defensas se detallan en qué es la suplantación de identidad de email.
Phishing
El phishing es un ataque que manipula a la víctima para sacarle credenciales, un pago o una acción sensible, a menudo mediante un email que se hace pasar por una fuente de confianza. La suplantación de dominio es su combustible más eficaz: un mensaje que parece venir de verdad de su banco o de su empleador baja todas las defensas. Cortar la suplantación en origen reduce en la misma medida la superficie de ataque, como explica prevenir el phishing de dominio.
BEC (fraude del CEO)
El BEC (Business Email Compromise), o fraude del CEO, apunta a una organización haciéndose pasar por un directivo o un proveedor para ordenar una transferencia fraudulenta o una fuga de datos. Es uno de los fraudes más costosos, porque juega con la autoridad y la urgencia en lugar de con un fallo técnico — pero la suplantación de un dominio legítimo lo hace temiblemente creíble. El modo de operar y las defensas se detallan en el fraude del CEO (BEC).
Por dónde empezar
Este glosario describe un dispositivo; ponerlo en marcha empieza siempre por un diagnóstico. La forma más rápida de saber en qué punto está un dominio — qué política DMARC, qué alineación SPF/DKIM, qué fuentes emiten en su nombre — es pasarlo por un analizador DMARC gratuito. El veredicto sobre la postura actual es inmediato, y luego puede compararse con la del sector en el Observatorio DMARC.
Transformar ese diagnóstico en acción — nombrar cada fuente, generar el DNS que hay que publicar, franquear cada nivel de p=none hasta p=reject sin romper un solo flujo legítimo — es exactamente lo que Thomas, el RSSI virtual, automatiza. Análisis DMARC gratuito de un dominio · explorar el Observatorio · empezar con Thomas.
Guías relacionadas
- Llegar a p=reject sin romper el correo legítimo
Un camino progresivo y seguro desde la vigilancia DMARC (p=none) hasta la aplicación completa (p=reject) — sin bloquear un solo mensaje legítimo.
- Lista de comprobación de elegibilidad: ¿cuándo un dominio está listo para p=reject?
Elegibilidad para p=reject: las siete condiciones concretas que hay que reunir antes de endurecer DMARC, sin bloquear ni un solo correo legítimo.
- p=quarantine o p=reject: ¿cuál elegir?
p=quarantine y p=reject no tienen el mismo perfil de riesgo. Qué le hace cada política al correo que falla DMARC, y cómo decidir para un dominio dado.
Sobre el autor
Thomas — Thomas es el CISO virtual de DMARC.com: un copiloto especializado en la autenticación de correo que acompaña a las organizaciones de p=none hasta p=reject, sin romper su correo. Sus guías se basan en los datos reales del Observatorio DMARC y de los informes RUA analizados por la plataforma.