SPF, DKIM y DMARC: fundamentos de seguridad del correo electrónico

Esta entrada explica los riesgos y la teoría que hay detrás de SPF, DKIM y DMARC, y por qué las permutaciones de dominios (dominios similares) son el amplificador silencioso que convierte «un solo correo electrónico suplantado» en un desastre para la marca, las finanzas y el robo de credenciales.

El problema principal: el correo electrónico se creó para la entrega, no para la identidad

El SMTP (el protocolo que mueve el correo electrónico) se diseñó en una época en la que la confianza era implícita. Por defecto:

El encabezado «De:» es solo texto.
Cualquiera puede intentar enviar un correo fingiendo serceo@yourcompany.com

Muchos sistemas de correo aceptaban históricamente los mensajes siempre que se pudieran entregar.

Las defensas modernas añaden autenticación a nivel de dominio sobre el SMTP. Eso es lo que hacen SPF, DKIM y DMARC.

SPF: «¿Qué servidores pueden enviar correo para mi dominio?»

SPF (Sender Policy Framework) es un registro DNS que enumera los servidores de correo (o servicios de envío) autorizados a enviar correo electrónico utilizando tu dominio en el campo «Envía por» / «Ruta de retorno».

Cómo funciona SPF (teoría)

Cuando un servidor de correo receptor recibe un mensaje, comprueba:

Qué dominio se utiliza en el remitente del sobre (Return-Path).
¿Publica ese dominio un registro SPF en el DNS?
¿Está permitida la IP de conexión por ese registro SPF?

Si sí → SPF pasa. Si no → SPF falla (o falla suavemente/es neutro, dependiendo de la política).

Ejemplo de registro SPF

example.com. TXT "v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -all"

Modos comunes de fallo de SPF (en los que ganan los atacantes)

Demasiado permisivo:v=spf1 +all

(básicamente «cualquiera puede enviar»).

Fallo suave permanente:~all

sin aplicación de DMARC, lo que lleva a un manejo «indiferente».

Incluidos que faltan: tu CRM, sistema de tickets o herramienta de boletines no aparece en la lista → el correo legítimo falla.
Límite de consultas DNS: SPF tiene un límite de 10 consultas DNS; las cadenas complejas deinclude:

pueden interrumpir la entrega.

SPF solo protege el dominio del sobre: los atacantes aún pueden hacer que el remitente visible parezca que eres tú, a menos que DMARC imponga la alineación.

En resumen: SPF es necesario, pero no suficiente para detener la suplantación de identidad.

DKIM: «¿Este correo lo envió realmente alguien con la clave privada del dominio?»

DKIM (DomainKeys Identified Mail) añade una firma criptográfica a los mensajes salientes. El remitente firma los encabezados seleccionados (y a veces el cuerpo) con una clave privada. El destinatario obtiene la clave pública del DNS y verifica la firma.

Cómo funciona DKIM (en teoría)

El servidor de correo saliente añade un encabezado como: -DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; ...
El destinatario consulta el DNS: -selector1._domainkey.example.com

→ clave pública

Si la firma coincide → DKIM pasa la prueba.

Ejemplo de registro DNS DKIM

selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Modos de fallo de DKIM (donde los atacantes ganan)

Ausencia total de DKIM: muchos dominios siguen sin firmar el correo de forma sistemática.
Firma selectiva: solo algunos sistemas firman (por ejemplo, Microsoft 365 sí lo hace, pero tu herramienta de marketing no).
Firmas rotas: los reenviadores o las listas de correo pueden modificar el contenido o los encabezados y romper DKIM.
Claves débiles o antiguas: las claves cortas o de larga duración aumentan el riesgo (si se ven comprometidas, la suplantación de identidad se vuelve trivial).
Dominio desalineado: DKIM pasa para un dominio diferente al que los usuarios ven en el campo «De».

En resumen: DKIM es potente porque es criptográfico, pero necesita alineación y política; esa es la función de DMARC.

DMARC: «¿Qué deben hacer los destinatarios si SPF/DKIM falla, y coincide con mi campo “De” visible?»

DMARC (Domain-based Message Authentication, Reporting & Conformance) lo une todo:

Requiere que SPF y/o DKIM pasen, y
Deben estar alineados con el dominio del campo De: que los usuarios ven realmente.

A continuación, indica a los destinatarios qué hacer si falla la autenticación:
-p=none

(solo supervisar)
-p=quarantine

(enviar el correo sospechoso a spam/correo no deseado)
-p=reject

(bloquear directamente)

Alineación DMARC (el concepto clave)

A los atacantes les encanta esta brecha:

SPF pasa pararandom-sender.com
«De:» muestraceo@yourcompany.com

Sin la alineación DMARC, un mensaje puede parecer que viene de ti aunque el dominio autenticado no tenga nada que ver.

DMARC dice: la identidad autenticada debe coincidir con el «De» visible, no solo «algo que ha pasado en algún sitio».

Ejemplo de registro DMARC (supervisión)

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"

Ejemplo de registro DMARC (aplicado)

_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-fail@example.com; fo=1; adkim=s; aspf=s"

Modos de fallo de DMARC (donde ganan los atacantes)

**Atascado enp=none

para siempre**: recibes informes, pero el spoofing sigue llegando.

Sin dirección de informe / informes ignorados: no sabes quién está abusando de tu dominio.
Alineación mal configurada: los servicios legítimos fallan y tienes que revertir la aplicación.
Lagunas en los subdominios: sin una política de subdominios, los atacantes suplantananything.yourcompany.com

Sin supervisión externa: DMARC no es algo que «se configura y se olvida» cuando cambian las herramientas.

En resumen: DMARC es la capa de aplicación que convierte SPF/DKIM de «señales» en «protección».

¿Qué hacen realmente los atacantes con una autenticación de correo débil?

Estas son las vías de abuso de alto impacto que SPF/DKIM/DMARC ayudan a prevenir:

1) Fraude al CEO / redireccionamiento de facturas (BEC)

Los atacantes envían correos que parecen provenir de la dirección o del departamento financiero para cambiar IBAN, aprobar pagos o solicitar tarjetas regalo. Incluso una sola suplantación exitosa puede costar más que un año de herramientas de seguridad.

2) Recolección de credenciales

Un correo electrónico con un aspecto perfecto «de TI» redirige a una página de inicio de sesión falsa de Microsoft 365. En cuanto se capturan las credenciales, el atacante puede acceder a buzones internos reales y enviar phishing legítimo desde dentro de tu tenant.

3) Suplantación de marca frente a clientes/socios

Aunque tu equipo interno esté formado, tus clientes no lo están. Los mensajes suplantados pueden dañar tu reputación, provocar fraudes y crear pesadillas de soporte técnico.

Permutaciones de dominio: el multiplicador de los «dominios similares»

Incluso con una aplicación perfecta de DMARC, los atacantes pueden simplemente registrar un dominio diferente que se parezca al tuyo y enviar mensajes desde allí.

Ejemplos: -examp1e.com

(1 en lugar de l) -exarnple.com

(rn en lugar de m) -example-support.com

-example.com-security.net

-exämple.com

(trucos con IDN / homógrafos)

TLD diferentes:example.co

,example.net

,example.io

A esto se le llama permutación de dominios / typosquatting (e incluye ataques de homógrafos, combo-squatting, bitsquatting y más).

Por qué las permutaciones son peligrosas

Los usuarios leen «formas», no cadenas: echar un vistazo rápido a la dirección del remitente no es fiable.
Los clientes móviles ocultan detalles: muchas interfaces ocultan o truncan la información del remitente.
SPF/DKIM/DMARC no sirven de nada: protegen tu dominio, no los dominios similares.
Los atacantes pueden crear una infraestructura que «parezca legítima»: certificados TLS, páginas de destino con tu marca, flujos de respuesta realistas.

Flujo típico de un ataque con un dominio similar

Registran un dominio parecido al tuyo.
Configura SPF/DKIM/DMARC correctamente (sí, los atacantes hacen esto).
Envía mensajes «urgentes» a finanzas, RR. HH., clientes o proveedores.
Recoge credenciales o redirige pagos.
Si hay una respuesta, mantén la conversación (al estilo de secuestro de hilo).

Conclusión: necesitas tanto supervisión de la autenticación como detección de dominios similares.

Cómo es una «buena» configuración: una referencia práctica

Si quieres una postura limpia y moderna:

SPF

Exactamente un registro TXT de SPF por dominio.
Incluye solo los remitentes que realmente utilizas.
Termina con-all

una vez que hayas validado todas las fuentes.

DKIM

Asegúrate de que todas las plataformas de envío firmen el correo.
Rota las claves periódicamente.
Usa claves lo suficientemente seguras (y no reutilices las mismas claves indefinidamente).

DMARC

Empieza conp=none

durante un tiempo para identificar a los remitentes legítimos.

Pasa ap=quarantine

y, después, ap=reject

Usa la alineación estricta siempre que sea posible (aspf=s; adkim=s

Considera la política de subdominios (sp=

) para que los subdominios no se conviertan en una laguna.

Permutaciones de dominios

Vigila los dominios similares en TLD comunes y los patrones de errores tipográficos obvios.
Da prioridad a aquellos que:
- tengan registros MX (puedan enviar/recibir correo electrónico),
- alojen páginas de phishing,
- sean de nuevo registro,
- se parezcan a la marca + «facturación / inicio de sesión / soporte».

Por qué es importante la supervisión continua (aunque lo «configure una sola vez»)

El DNS cambia por motivos aburridos —migraciones, cambios de proveedor, «soluciones rápidas», dominios caducados— y esos cambios aburridos pueden romper la autenticación sin que te des cuenta.

La supervisión continua detecta:

Fallos en la consulta de SPF después de que alguien añada una nueva herramienta
Selectores DKIM eliminados o rotados incorrectamente
DMARC rebajado a «p=none

Un dominio similar que aparece de repente y empieza a enviar correos a tu personal

Por eso AutoPhish ahora incluye un Escáner de seguridad de correo electrónico / DNS para comprobaciones rápidas, y monitoreo continuo con alertas para las organizaciones registradas.

Lista de verificación rápida que puedes copiar en tu manual de procedimientos interno

El SPF existe, es único y termina en-all

(tras la validación)

Se han tenido en cuenta todas las fuentes de correo (M365/Google + marketing + soporte + transaccional)
DKIM habilitado en todas las fuentes, claves no caducadas
DMARC existe con los informes habilitados
DMARC aplicado (quarantine

oreject

) con la alineación configurada

Subdominios cubiertos (sp=

o DMARC explícito en los subdominios)

Monitorización de dominios similares habilitada (errores tipográficos + cambios de TLD + combinaciones)
Alertas conectadas a un canal real (correo electrónico/Slack/Teams/sistema de tickets)

Comprueba tu dominio en segundos (gratis)

¿Quieres hacer una comprobación rápida ahora mismo? Usa el AutoPhish DNS Checker para analizar al instante tus registros SPF, DKIM y DMARC:

AutoPhish DNS Checker: https://autophish.io/dns-check

Si quieres protección continua, también puedes configurar la monitorización continua con una suscripción a AutoPhish, para recibir alertas cuando cambien los registros DNS o se detecten dominios similares.

Reflexiones finales

La autenticación del correo electrónico (SPF/DKIM/DMARC) es una de las pocas medidas de seguridad que mejora tanto la protección como la capacidad de entrega. Si añades la supervisión de dominios similares, cubrirás los dos principales vectores de suplantación de identidad: la suplantación de tu dominio y la suplantación de tu marca.

SPF, DKIM, DMARC y permutaciones de dominios: los fundamentos de la seguridad del correo electrónico que los atacantes aprovechan