La suplantación de identidad por correo electrónico (email spoofing) sigue siendo una de las técnicas más utilizadas en fraudes, phishing e ingeniería social.
En muchos casos, no requiere comprometer servidores ni credenciales, sino simplemente aprovechar una mala configuración de SPF y DMARC.
En esta guía técnica repasamos:
-
Cómo funcionan SPF y DMARC a nivel práctico
-
Qué errores de configuración son más comunes
-
Ejemplos reales de registros DNS
-
Buenas prácticas para reducir el riesgo de suplantación
Modelo de ataque típico
Desde el punto de vista del atacante, el escenario es simple:
-
Identifica un dominio sin SPF o con SPF laxo
-
Envía correos usando cualquier servidor SMTP
-
El correo aparenta venir de
usuario@empresa.com -
El receptor confía en el remitente
-
Se ejecuta el fraude o phishing
Sin SPF y DMARC bien configurados, el dominio no tiene forma de “defender su identidad”.
SPF en detalle
¿Qué hace SPF exactamente?
SPF permite declarar, mediante DNS, qué servidores están autorizados a enviar correos para un dominio.
Cuando un servidor recibe un correo:
-
Extrae el dominio del MAIL FROM
-
Consulta el registro SPF del dominio
-
Evalúa si la IP emisora está autorizada
-
Decide si el correo pasa o falla SPF
Ejemplo básico de SPF
v=spf1 ip4:203.0.113.10 include:_spf.google.com -all
Este registro indica:
-
v=spf1: versión -
ip4:203.0.113.10: servidor propio autorizado -
include:_spf.google.com: autoriza Google Workspace -
-all: rechaza todo lo demás
👉 Este -all es clave: sin él, el SPF no protege realmente el dominio.
Errores comunes en SPF
1. SPF demasiado permisivo
v=spf1 +all
Esto equivale a:
“Cualquiera puede enviar correos por este dominio”
Desde el punto de vista de seguridad, es lo mismo que no tener SPF.
2. SPF incompleto
v=spf1 include:_spf.google.com ~all
-
~all(softfail) no bloquea -
Muchos proveedores siguen aceptando estos correos
Sirve como etapa de prueba, pero no como configuración final.
3. Demasiados include
SPF tiene un límite de 10 consultas DNS.
Excederlo provoca fallos SPF incluso si los servidores son legítimos.
Este problema es muy común cuando:
-
Se agregan herramientas de marketing
-
Se usan múltiples proveedores externos
-
Nadie revisa el SPF históricamente
DMARC en detalle
¿Qué agrega DMARC?
DMARC actúa como una capa de control y política sobre SPF (y DKIM).
Permite:
-
Definir qué hacer si SPF falla
-
Recibir reportes de abuso del dominio
-
Reducir drásticamente el spoofing
Ejemplo básico de DMARC
v=DMARC1; p=none; rua=mailto:dmarc@empresa.com; ruf=mailto:dmarc@empresa.com; fo=1
Este registro:
-
Activa DMARC
-
No bloquea correos (
p=none) -
Habilita reportes agregados (
rua) -
Habilita reportes forenses (
ruf)
Es ideal como primer paso.
Políticas DMARC
Modo monitoreo
p=none
-
No bloquea correos
-
Permite ver quién está enviando emails
-
Recomendado como etapa inicial
Cuarentena
p=quarantine
-
Correos sospechosos pueden ir a spam
-
Reduce ataques sin ser demasiado agresivo
Rechazo
p=reject
-
Correos no alineados son rechazados
-
Máxima protección contra suplantación
-
Requiere que SPF esté bien configurado
Error común: DMARC “activo” pero inefectivo
Muchos dominios tienen DMARC así:
v=DMARC1; p=none
Esto no protege, solo observa.
Si nunca se avanza de p=none, el dominio sigue siendo suplantable.
Alineación SPF + DMARC
DMARC no solo verifica SPF, sino que exige alineación:
-
El dominio del MAIL FROM
-
Debe coincidir (o alinearse) con el dominio visible
Errores de alineación:
-
Subdominios mal definidos
-
Proveedores externos mal configurados
-
Reenvíos de correo
Este es uno de los puntos donde más errores se cometen.
Riesgos reales de una mala configuración
En escenarios reales hemos visto:
-
Facturas falsas enviadas desde dominios legítimos
-
Correos de “cambio de CBU” a proveedores
-
Phishing interno a empleados
-
Caída de reputación del dominio (emails legítimos a spam)
Todo esto sin comprometer infraestructura interna.
¿Por qué no basta con “seguir un tutorial”?
Aunque SPF y DMARC parecen simples:
-
Cada entorno es distinto
-
Cada proveedor agrega complejidad
-
Un error puede bloquear correos críticos
Los problemas más comunes aparecen cuando:
-
Se endurece DMARC sin analizar reportes
-
Se olvida autorizar un proveedor externo
-
Se rompe la alineación SPF
-
Se superan límites de DNS
¿Cómo puede ayudar Securetia?
En Securetia ayudamos a:
-
Analizar SPF y DMARC existentes
-
Detectar riesgos reales de suplantación
-
Corregir configuraciones sin impacto operativo
-
Definir políticas progresivas y seguras
-
Dejar todo documentado y mantenible
Si querés revisar el estado de tu dominio o necesitás ayuda para corregirlo correctamente, podés contactarnos y lo vemos en conjunto.
Conclusión
SPF y DMARC son controles simples en concepto, pero críticos en impacto.
Una mala configuración deja el dominio expuesto a suplantación, fraude y pérdida de confianza.
Detectar el problema es fácil.
Corregirlo bien es lo que realmente protege.