Cuando hablamos de postura anti-spoofing débil, nos referimos a que el dominio no expresa (o no hace cumplir) políticas DNS suficientes para que los receptores distingan con confianza entre:

  • correo legítimo enviado por su infraestructura y proveedores autorizados, y
  • correos falsificados que solo “parecen” venir de su dominio.

En la práctica, esto suele ocurrir por una combinación de:

  • SPF ausente o permisivo,
  • DKIM no implementado o no alineado, y
  • DMARC ausente o en modo solo monitor (p=none).

SPF existe precisamente porque el SMTP no restringe el uso del “MAIL FROM”/HELO y el email puede falsificarse; el RFC de SPF lo explica como motivación central del estándar.

DMARC, por su parte, es el mecanismo para publicar una política de dominio y preferencias de validación/disposición/reporting para mejorar el manejo del correo por parte de los receptores.

1) Por qué SPF y DMARC no son “opcionales” hoy

A nivel de riesgo, el correo es uno de los canales principales para:

  • phishing,
  • BEC (Business Email Compromise), y
  • abuso de marca (suplantación del “From” para engañar a clientes o empleados).

A nivel de operación, los grandes proveedores están empujando activamente a la autenticación. Google, por ejemplo, recomienda siempre configurar DMARC y admite un arranque de “enforcement mínimo” (p=none aplicado a 0% con pct=0) como fase inicial.

Microsoft lo enmarca de forma explícita: DMARC valida correo enviado desde la organización y ayuda a evitar remitentes suplantados usados en BEC, ransomware y phishing; además explica la importancia de la alineación entre dominios (MAIL FROM vs From).

2) Señales típicas de una postura débil (lo que solemos ver en auditoría)

2.1 SPF ausente, “neutral” o “softfail” permanente

SPF define resultados como none, neutral, softfail y fail. Por ejemplo:

  • neutral: el dominio no afirma si la IP está autorizada.
  • softfail: el dominio sugiere que probablemente no está autorizada, pero no emite una política fuerte (fail).

Una postura débil aparece cuando:

  • no hay registro SPF (frecuente none),
  • existe pero termina en ~all durante años sin evolucionar, o
  • se usa +all (equivalente a “autorizar todo”, que neutraliza SPF).

2.2 SPF con errores operativos: permerror por diseño (demasiadas búsquedas DNS)

SPF tiene un límite explícito: los mecanismos/modificadores que causan consultas DNS (include/a/mx/ptr/exists/redirect) deben limitarse a 10, y si se excede, el verificador debe devolver permerror.

Esto es crítico porque un SPF “sobrecargado” no solo es débil: puede convertirse en inestable, generando fallos intermitentes o permanentes en entregabilidad/autenticación.

2.3 DKIM ausente o mal alineado

DKIM permite que el dominio firmante “reclame responsabilidad” sobre el mensaje asociando un dominio al email mediante una firma verificable por receptores.
Sin DKIM (o con DKIM solo en parte del flujo), DMARC queda cojo.

2.4 DMARC ausente o “solo observación” indefinida

DMARC puede pedir desde “no acción” hasta cuarentena o rechazo para los mensajes que fallan autenticación.
Una postura débil suele ser:

  • sin DMARC (no existe _dmarc.), o
  • p=none sin plan de transición, o
  • p=none con pct=0 eternamente (cero enforcement).

Además, DMARC sin reporting (rua) suele dejar a la organización “ciega” sobre quién está enviando en su nombre.

2.5 Falta de alineación (el fallo más habitual en organizaciones con varios proveedores)

Microsoft lo explica con claridad: SPF y DKIM no exigen por sí mismos que el dominio de MAIL FROM y el dominio visible en From coincidan; DMARC sí usa alineación, y esto es clave para evitar suplantación.

3) Riesgo real: qué ataques habilita y qué no

Qué habilita

Con postura débil, un atacante puede enviar correos que:

  • muestren su dominio en el campo From (suplantación de marca),
  • lleguen a bandejas con apariencia “legítima” según el cliente de correo,
  • incrementen la tasa de éxito de phishing/BEC (especialmente si el objetivo confía en el dominio).

Qué NO “arregla” SPF/DMARC

Incluso con DMARC en reject, no “eliminamos”:

  • phishing desde dominios parecidos (typosquatting),
  • cuentas legítimas comprometidas enviando correo real,
  • ni campañas desde dominios nuevos.

Por eso lo tratamos como un control esencial de higiene de identidad del dominio, no como la única defensa.

4) Cómo cerrarlo: plan seguro por fases (SPF → DKIM → DMARC)

El error más caro aquí es “poner p=reject y rezar”. El plan profesional minimiza roturas y maximiza evidencia.

Fase 0 — Inventario (imprescindible)

Antes de tocar DNS, listamos todas las fuentes que envían con su dominio:

  • Microsoft 365 / Google Workspace
  • plataformas de marketing (newsletters)
  • CRM / facturación / tickets
  • servidores web (formularios, transaccional)
  • proveedores (outsourcing)

Sin inventario, un SPF “duro” o DMARC “estricto” puede bloquear correo legítimo.

Fase 1 — SPF correcto y estable

Objetivo: que el MAIL FROM esté autorizado, con un registro único y mantenible. SPF está diseñado para autorizar hosts que pueden usar el dominio en MAIL FROM/HELO.

Fase 2 — DKIM en todos los flujos relevantes

Objetivo: firma DKIM consistente y verificable desde los proveedores reales. DKIM asocia el dominio firmante con el mensaje.

Fase 3 — DMARC con reporting y escalado gradual de política

Objetivo: publicar política y recibir visibilidad; luego endurecer. DMARC contempla desde none hasta reject, con reporting como parte crítica.
Google incluso recomienda un arranque “mínimo” (p=none, pct=0) como fase inicial para cumplir sin romper.

5) SPF bien hecho: reglas prácticas, límite de lookups y errores comunes

5.1 Un solo registro SPF por dominio

SPF debe publicarse como TXT y no se permiten múltiples registros SPF para el mismo nombre (causa típica de permerror).

5.2 Diseñar el SPF para no exceder 10 lookups

Este es el punto técnico que más problemas crea a medio plazo.

SPF lista qué mecanismos hacen consultas DNS y exige limitar el total a 10; si se excede, el resultado debe ser permerror.

Buenas prácticas:

  • reduzcan include: innecesarios,
  • eviten cadenas de redirect profundas,
  • segmenten por subdominios para distintos usos (ej. marketing.su-dominio.com), lo que además Microsoft recomienda para servicios masivos externos para proteger reputación del dominio principal.

5.3 Elegir ~all vs -all con criterio (y fecha de caducidad)

  • ~all (softfail) puede ser útil solo durante transición corta.
  • -all (fail) es el objetivo cuando ya inventariamos todas las fuentes.

El propio RFC define fail como declaración explícita de “no autorizado”, mientras softfail es una declaración débil.
Nuestra recomendación: ~all con una ventana definida (por ejemplo, 2–4 semanas de observación) y luego endurecer a -all tras validar que no queda tráfico legítimo fuera.

5.4 Ejemplo de SPF (plantilla, no “copiar y pegar”)

@  IN TXT  "v=spf1 include:spf.proveedor1.example include:spf.proveedor2.example ip4:203.0.113.10 -all"

Esto solo es correcto si esos includes existen, son necesarios y no rebasan lookups. El límite de 10 es normativo.

6) DMARC bien hecho: alineación, políticas y despliegue gradual

6.1 Alineación: la diferencia entre “autentica” y “protege”

Microsoft lo detalla: DMARC comprueba alineación entre dominios de MAIL FROM y From; SPF/DKIM por sí solos no exigen esa coincidencia.
Esto es lo que convierte DMARC en control anti-spoofing efectivo sobre el From visible.

6.2 Empezar con p=none para obtener visibilidad (pero con plan)

DMARC permite “no acción” (p=none) y enfatiza el valor del feedback/reporting para poder avanzar a cuarentena y rechazo.
Google recomienda incluso una configuración mínima: p=none con pct=0 para enforcement mínimo inicial.

Ejemplo de DMARC inicial (monitorización):

_dmarc  IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@su-dominio.com; adkim=r; aspf=r"

El RFC incluye ejemplos de registro p=none con rua para recibir informes agregados.

6.3 Escalado controlado: quarantine → reject con pct

DMARC contempla endurecimiento gradual y permite muestrear con pct. El RFC muestra escenarios con pct y políticas más estrictas.

Propuesta de escalado típica (siempre basada en reportes):

  1. Semana 1–2: p=none (recogida de reportes, limpieza de flujos)
  2. Semana 3: p=quarantine; pct=25
  3. Semana 4: p=quarantine; pct=100
  4. Semana 5+: p=reject; pct=25 → pct=100

6.4 Cerrar el “spoofing de subdominios”

Si no publicamos política para subdominios, pueden quedar huecos. En muchos casos definimos sp= (política para subdominios) y/o publicamos DMARC por subdominio cuando segmentamos envíos (recomendación operativa coherente con el enfoque de subdominios).

7) Checklist de validación y métricas

DNS y autenticación

  • SPF único y sintácticamente válido; sin permerror por lookups > 10.
  • DKIM activo en los proveedores reales (firma consistente).
  • DMARC publicado con rua y política definida (aunque sea none inicial).

Evidencia y observabilidad

  • Revisamos reportes DMARC (quién envía, qué falla, dónde falta alineación).
  • Para Gmail, utilizamos Postmaster Tools y validamos paneles de autenticación (SPF/DKIM).

Gobierno y prevención

  • Cada nuevo proveedor de envío entra por un subdominio o proceso controlado (evitar inflar SPF del dominio principal).
  • Existe una política interna: “nadie envía con el dominio sin pasar por autenticación y alineación”.

8) FAQs

“Tenemos SPF y aún así nos suplantan”

SPF por sí solo autentica MAIL FROM/HELO; el atacante puede falsificar el From visible si no hay DMARC que exija alineación. Microsoft explica precisamente esta diferencia y por qué DMARC es el que cierra el hueco del From.

“¿Podemos ir directo a p=reject?”

Podemos, pero solo lo recomendamos cuando:

  • el inventario de fuentes está completo,
  • DKIM está desplegado,
  • y los reportes (o pruebas) confirman alineación alta.
    DMARC está diseñado para despliegue gradual y feedback; el RFC enfatiza que los reportes ayudan a poder usar políticas quarantine/reject con confianza.

“¿Qué pasa si excedemos el límite de 10 lookups en SPF?”

El verificador debe devolver permerror. Es un requisito explícito del estándar para evitar carga irrazonable sobre DNS.