Guía técnica: cómo proteger tu dominio con SPF y DMARC

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.

Guía técnica: cómo proteger tu dominio con SPF y DMARC

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:

  1. Identifica un dominio sin SPF o con SPF laxo

  2. Envía correos usando cualquier servidor SMTP

  3. El correo aparenta venir de usuario@empresa.com

  4. El receptor confía en el remitente

  5. 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:

  1. Extrae el dominio del MAIL FROM

  2. Consulta el registro SPF del dominio

  3. Evalúa si la IP emisora está autorizada

  4. 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.

Asesoramiento personalizado para tu negocio

Un especialista de nuestro equipo te contactará a la brevedad.

Paraguay 643 3º A - CABA, Argentina

Escaneá vulnerabilidades de
manera continua con Vulseek

Registrate ahora y empezá a usarlo gratis.

Conocé más