DMARC cuarentena vs rechazo: cuándo cambiar y cómo implementarlo de forma segura

Tu CEO acaba de reenviar un correo que “parece venir de Finanzas” y pregunta si la transferencia es legítima.
Las cabeceras indican que no proviene de vosotros. Tus usuarios no pueden distinguirlo. Y tu dominio está a punto de convertirse en el disfraz favorito del atacante.

DMARC es la solución madura. Pero pasar de p=none a p=reject no es una casilla de verificación valiente: es un cambio en producción que puede romper silenciosamente correo legítimo.
Así es como lo despliegas como un SRE: medible, reversible y aburrido de la mejor manera.

DMARC en producción: el modelo mental que evita cortes autoinfligidos

DMARC no es “un protocolo de autenticación”. Es una política y una canalización de informes que se sitúa encima de SPF y DKIM.
Indica a los receptores qué hacer cuando un correo que afirma ser de tu dominio falla la autenticación y, crucialmente, falla la alineación.

La alineación es la parte que la gente recuerda a medias y luego lamenta.
A DMARC no le importa que SPF pase para bounce.vendor-mail.example si el mensaje afirma ser de yourbrand.com.
Tampoco le importa que DKIM pase para mailer.thirdparty.com si el From visible es yourbrand.com y no firmaron con tu dominio (o con uno correctamente alineado).

Aquí tienes el modelo operativo más claro:

• Identidad en el encabezado From es lo que ven los usuarios y lo que DMARC protege.
• SPF autentica el remitente del sobre SMTP (Return-Path / MAIL FROM), no el encabezado From.
• DKIM autentica un dominio firmante (d=), no el encabezado From.
• DMARC requiere que al menos SPF o DKIM pasen y se alineen con el dominio From.
• Política: p=none observa, p=quarantine empuja a tratar como sospechoso, p=reject cierra la puerta.

La verdad operacional: DMARC no es difícil, es amplio. Probablemente tu dominio envía correo desde lugares que no recuerdas:
sistemas de tickets, herramientas de RR. HH., CRM, plataformas de marketing, páginas de estado, automatizaciones de contratistas, impresoras, escáneres y esa aplicación que un equipo creó en 2018 y que todavía “temporalmente” funciona.

Un despliegue bien gestionado de DMARC es básicamente descubrimiento de activos para correo saliente, con cambios DNS al final.

Datos interesantes y breve historia (lo que explica las rarezas actuales)

• SPF precede a DMARC por casi una década. SPF empezó a principios de los 2000 como respuesta al spoofing rampante, pero nunca autenticó lo que los usuarios ven en From.
• DKIM surgió de la fusión de dos enfoques competidores. DomainKeys (Yahoo) e Identified Internet Mail (Cisco) convergieron en DKIM, por eso cierta terminología todavía suena a comité.
• DMARC surgió de “estamos cansados de que nos phisheen a nuestros propios usuarios”. Grandes proveedores de buzones y remitentes impulsaron su adopción para detener el spoofing de dominios directos, no para arreglar todos los problemas de spam.
• La característica clave de DMARC es el reporte. Los informes agregados (RUA) convierten a los receptores en fuentes de telemetría. Eso es raro en el mundo del correo, que normalmente funciona con intuiciones y culpas.
• El reenvío de correo es anterior a gran parte de tu pila SaaS. El ecosistema original de correo asumía que el reenvío y el remailing eran normales. La aplicación estricta de DMARC puede chocar con esa historia.
• ARC existe porque “el reenvío rompe SPF/DKIM” no acababa. Authenticated Received Chain es un parche para preservar resultados de autenticación a través de intermediarios.
• Los grandes receptores han endurecido gradualmente su comportamiento. La conformidad con DMARC no se volvió general de la noche a la mañana; los proveedores fueron aplicando la política y señales en UI a lo largo de los años, por eso los consejos de 2016 a menudo fallan hoy.
• DMARC no es solo para rechazo. Muchas organizaciones de alto volumen viven en p=quarantine con la rampa de pct, porque algunos ecosistemas de correo nunca son perfectamente deterministas.

Cuarentena vs rechazo: lo que realmente cambia en la comunicación

En teoría, la política DMARC es “elección del receptor”. En la práctica, los grandes proveedores de buzones tratan tu política como una señal fuerte.
Les estás diciendo: “Tengo control de mi dominio y estoy listo para que lo hagan cumplir”.

Qué suele significar cuarentena

Cuarentena es una instrucción de “tratar como sospechoso”. Más comúnmente: carpeta de spam, clasificación como correo basura o filtrado adicional.
Algunos receptores todavía entregarán en la bandeja de entrada dependiendo de su propio modelo.

Operativamente, cuarentena es un carril de preparación:

• Empiezas a ver quejas de usuarios (“mis facturas van a spam”) sin el corte drástico del rechazo total.
• Puedes descubrir remitentes desalineados que “funcionaban” solo porque los receptores eran permisivos.
• Puedes aumentar la aplicación con pct mientras reparas la alineación subyacente.

Qué suele significar rechazo

Rechazo es que el receptor se niega a entregar durante SMTP (ideal) o descarta después (menos ideal).
Si tu correo legítimo falla DMARC bajo una política de rechazo, a menudo obtendrás:

• Rebotes duros para correo transaccional.
• No entrega silenciosa según el comportamiento del receptor (raro, pero ocurre).
• Simulacros de emergencia: “los correos no llegan” es una interrupción del negocio, no un ticket de TI.

Rechazo es el objetivo para dominios de alta confianza (ejecutivos, nóminas, finanzas, legal) y para marcas que son frecuentemente suplantadas.
También es una promesa: estás diciendo a los receptores que tu postura de autenticación es lo suficientemente madura como para que los mensajes que fallan probablemente sean hostiles.

Una regla opinionada: no pases a rechazo hasta que puedas responder, con evidencia, “¿Qué sistemas envían correo como nuestro dominio y están alineados?”
Si tu respuesta es “principalmente Microsoft 365”, no estás listo. “Principalmente” es como ocurren los cortes.

Broma #1: DMARC es como poner un cerrojo en la puerta principal—gran idea—hasta que recuerdas que tu compañero de piso sigue usando la ventana.

Comprobaciones previas: requisitos antes de tocar la política DMARC

El despliegue más seguro comienza con inventario aburrido y termina con política. En medio: correcciones de alineación.
Esto es lo que deberías tener antes de aumentar la aplicación.

1) Posees y puedes cambiar DNS de forma fiable

DMARC vive en DNS. Si tu flujo de trabajo DNS es “alguien en otro departamento hace clics”, necesitas un proceso de cambios:
control de versiones, revisión y ventanas de propagación predecibles. El modo de fallo es simple: registro TXT equivocado, autenticación rota, horas de incertidumbre.

2) SPF no es perfecto, pero es razonable

SPF necesita cubrir tus remitentes legítimos y evitar exceder el límite de 10 búsquedas DNS. Además: minimiza con el tiempo la ambigüedad de ~all.
Que SPF pase no es suficiente para DMARC, pero el caos de SPF hace el análisis de DMARC miserable.

3) Existe firmado DKIM para las plataformas principales

DKIM es tu mejor amigo cuando el correo se reenvía o se reencamina.
Si puedes firmar con d=yourbrand.com (o subdominio alineado), hazlo.

4) Tienes un buzón de informes y alguien lo lee

Los informes agregados DMARC son XML. No son “amigables para humanos”, pero son oro operacional.
Necesitas un buzón para recibirlos, un parser/flujo de trabajo (comercial o interno) y una expectativa de tipo on-call: alguien revisa cuando cambias la política.

5) Entiendes tu tolerancia al riesgo

La tolerancia de un banco no es la de una agencia creativa. Decide:

• Qué dominios deben llegar a rechazo rápido (orientados a ejecutivos, pagos).
• Qué dominios pueden quedarse más tiempo en cuarentena (mucho marketing, muchos terceros).
• ¿Necesitas políticas para subdominios (sp=)?

Tareas prácticas (con comandos, salidas y decisiones)

Estas son tareas reales que puedes ejecutar desde una shell. No arreglarán DMARC por sí solas, pero te evitarán adivinar.
Cada tarea incluye: comando, salida de ejemplo, qué significa y la decisión que tomas.

Task 1: Inspect the current DMARC record

cr0x@server:~$ dig +short TXT _dmarc.yourbrand.com
"v=DMARC1; p=none; rua=mailto:dmarc-rua@yourbrand.com; ruf=mailto:dmarc-ruf@yourbrand.com; fo=1; adkim=r; aspf=r; pct=100"

Significado: La política actual es solo de monitorización (p=none). Alineación relajada para SPF y DKIM. El informe está configurado.

Decisión: Si falta rua, detente y añádelo antes de la aplicación. Sin telemetría, no hay despliegue.

Task 2: Validate the DMARC record syntax from DNS

cr0x@server:~$ python3 - <<'PY'
import re, subprocess, shlex
domain="_dmarc.yourbrand.com"
out=subprocess.check_output(["dig","+short","TXT",domain],text=True).strip()
print(out)
if "v=DMARC1" not in out:
    raise SystemExit("Missing v=DMARC1")
if " p=" not in out and ";p=" not in out:
    raise SystemExit("Missing p=")
print("Looks like DMARC-ish TXT is present.")
PY
"v=DMARC1; p=none; rua=mailto:dmarc-rua@yourbrand.com; ruf=mailto:dmarc-ruf@yourbrand.com; fo=1; adkim=r; aspf=r; pct=100"
Looks like DMARC-ish TXT is present.

Significado: Al menos tienes un registro tipo DMARC que se devuelve de forma consistente.

Decisión: Si aparecen múltiples cadenas TXT para DMARC (más de un registro), corrige el DNS inmediatamente; los receptores pueden comportarse de forma impredecible.

Task 3: Inspect the current SPF record

cr0x@server:~$ dig +short TXT yourbrand.com | sed -n 's/^"//; s/"$//; /v=spf1/p'
v=spf1 include:spf.protection.outlook.com include:mailgun.org ip4:203.0.113.10 ~all

Significado: SPF existe y lista un par de proveedores más una IP, terminando en softfail.

Decisión: Si ves múltiples registros SPF, consolida. Si ves una larga cadena de includes, debes comprobar el recuento de búsquedas DNS a continuación.

Task 4: Count SPF DNS lookups (avoid the 10-lookup cliff)

cr0x@server:~$ python3 - <<'PY'
import dns.resolver, re
domain="yourbrand.com"
visited=set()
def get_spf(d):
    txt=[]
    for r in dns.resolver.resolve(d,"TXT"):
        s="".join([b.decode() for b in r.strings])
        if s.startswith("v=spf1"):
            txt.append(s)
    return txt[0] if txt else None

lookups=0
def walk(d):
    global lookups
    if d in visited: return
    visited.add(d)
    spf=get_spf(d)
    if not spf: return
    for token in spf.split():
        if token.startswith("include:"):
            lookups += 1
            walk(token.split(":",1)[1])
        if token.startswith("redirect="):
            lookups += 1
            walk(token.split("=",1)[1])

walk(domain)
print("Estimated include/redirect lookups:", lookups)
print("Visited domains:", len(visited))
PY
Estimated include/redirect lookups: 2
Visited domains: 3

Significado: Estás por debajo del límite común de 10 búsquedas SPF (este script solo aproxima; la evaluación real incluye otros mecanismos).

Decisión: Si estás cerca/superas 10, simplifica SPF antes de endurecer DMARC. De lo contrario “arreglarás” el spoofing rompiendo el correo.

Task 5: Check DKIM selector records for a known sender

cr0x@server:~$ dig +short TXT selector1._domainkey.yourbrand.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx...snip..."

Significado: Existe una clave pública DKIM para selector1. Eso es necesario para que los receptores validen las firmas DKIM de ese selector.

Decisión: Si no sabes qué selectores se usan, extrae un encabezado de un mensaje saliente reciente y busca s= y d=.

Task 6: Verify DMARC alignment on a sample message (from headers)

cr0x@server:~$ awk 'BEGIN{RS="";FS="\n"} {for(i=1;i<=NF;i++) if($i ~ /Authentication-Results:/) print $i}' sample.eml
Authentication-Results: mx.google.com;
       dkim=pass header.i=@yourbrand.com header.s=selector1 header.b=abc123;
       spf=pass (google.com: domain of bounce@mg.yourbrand.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=bounce@mg.yourbrand.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yourbrand.com

Significado: DMARC pasa porque al menos SPF o DKIM pasan y se alinean con header.from=yourbrand.com. Aquí la alineación DKIM es perfecta.

Decisión: Si DMARC falla pero SPF pasa, probablemente SPF está pasando para un dominio distinto (desalineación). Corrige la alineación, no “más SPF”.

Task 7: Locate top failing sources in RUA aggregate XML (quick and dirty)

cr0x@server:~$ ls -1 dmarc-rua/ | head
google.com!yourbrand.com!1735516800!1735603200.xml
outlook.com!yourbrand.com!1735516800!1735603200.xml

cr0x@server:~$ grep -RhoE '<source_ip>[^<]+' dmarc-rua/*.xml | sed 's/<source_ip>//' | sort | uniq -c | sort -nr | head
  482 203.0.113.10
  117 198.51.100.25
   41 192.0.2.77

Significado: Tienes unas pocas IPs principales generando tráfico visto por DMARC.

Decisión: Identifica cada IP (tu MTA, tu proveedor, un misterio). IPs desconocidas y de alto volumen bloquean la aplicación.

Task 8: Map a suspicious IP to a provider (reverse + ASN hint)

cr0x@server:~$ whois 198.51.100.25 | egrep -i 'OrgName|org-name|descr|netname|origin|aut-num' | head
NetName:        EXAMPLE-NET
OrgName:        Example Email Services
OriginAS:       AS64500

Significado: Esa IP probablemente pertenece a un proveedor o al menos a una red identificable.

Decisión: Si no es tuya, averigua por qué envía correo que afirma ser tuyo. O la autorizas y alineas, o la bloqueas con la aplicación DMARC.

Task 9: Check whether your subdomains have their own DMARC records

cr0x@server:~$ for d in marketing.yourbrand.com status.yourbrand.com hr.yourbrand.com; do
  echo "== $d =="
  dig +short TXT _dmarc.$d
done
== marketing.yourbrand.com ==
"v=DMARC1; p=none; rua=mailto:dmarc-rua@yourbrand.com"
== status.yourbrand.com ==

== hr.yourbrand.com ==

Significado: Un subdominio tiene su propia política; otros heredan del dominio organizacional a menos que se establezca sp= en el padre.

Decisión: Decide si quieres una aplicación diferente para subdominios. Si no, elimina registros DMARC sueltos en subdominios que conflijan con tu plan.

Task 10: Simulate a policy change safely (use pct=10 with quarantine)

cr0x@server:~$ cat <<'EOF'
_dmarc.yourbrand.com. 3600 IN TXT "v=DMARC1; p=quarantine; pct=10; adkim=r; aspf=r; rua=mailto:dmarc-rua@yourbrand.com"
EOF
_dmarc.yourbrand.com. 3600 IN TXT "v=DMARC1; p=quarantine; pct=10; adkim=r; aspf=r; rua=mailto:dmarc-rua@yourbrand.com"

Significado: Este es el registro que propones publicar: cuarentena, pero solo para el 10% del correo que falle.

Decisión: Si tu organización no tolera ninguna mala clasificación, mantiene pct bajo más tiempo y arregla la alineación primero. Si estás bajo spoofing activo, acelera la rampa.

Task 11: Verify DNS propagation from multiple resolvers

cr0x@server:~$ for r in 1.1.1.1 8.8.8.8 9.9.9.9; do
  echo "== resolver $r =="
  dig +short @$r TXT _dmarc.yourbrand.com
done
== resolver 1.1.1.1 ==
"v=DMARC1; p=quarantine; pct=10; adkim=r; aspf=r; rua=mailto:dmarc-rua@yourbrand.com"
== resolver 8.8.8.8 ==
"v=DMARC1; p=quarantine; pct=10; adkim=r; aspf=r; rua=mailto:dmarc-rua@yourbrand.com"
== resolver 9.9.9.9 ==
"v=DMARC1; p=quarantine; pct=10; adkim=r; aspf=r; rua=mailto:dmarc-rua@yourbrand.com"

Significado: El cambio es visible desde resolvers públicos importantes.

Decisión: Si los resolvers discrepan por horas, tu DNS está cacheando mal o publicaste múltiples registros. No aumentes la política hasta que el DNS sea estable.

Task 12: Watch mail logs for DMARC-related bounces (Postfix example)

cr0x@server:~$ sudo grep -E 'dmarc|policy|reject|quarantine' /var/log/mail.log | tail -n 20
Jan 04 10:21:16 mx1 postfix/smtp[18233]: host gmail-smtp-in.l.google.com[142.250.102.27] said: 550-5.7.26 Unauthenticated email from yourbrand.com is not accepted due to domain's DMARC policy. (in reply to end of DATA command)

Significado: Un receptor rechazó un mensaje explícitamente debido a tu política DMARC. Esto puede ser un spoof bloqueado (bueno) o un remitente legítimo fallando alineación (malo).

Decisión: Extrae el mensaje encolado, inspecciona cabeceras, identifica el sistema real de envío y corrige la alineación o evita que use tu dominio From.

Task 13: Confirm a third-party is signing with aligned DKIM

cr0x@server:~$ grep -Eo 'dkim=[a-z]+|header.i=@[^;]+|header.s=[^;]+' sample-vendor.eml
dkim=pass
header.i=@vendor-mail.example
header.s=s1

Significado: DKIM pasó, pero está firmado como vendor-mail.example, no tu dominio. Eso no se alineará con From yourbrand.com.

Decisión: Configura DKIM personalizado en el proveedor para firmar con tu dominio (preferido), o mueve ese tráfico a un subdominio que controles para ese proveedor (también válido), o cambia el From a un dominio que ellos posean (a menudo políticamente difícil, técnicamente limpio).

Task 14: Detect “From domain” vs “envelope from” mismatch in an outbound message

cr0x@server:~$ egrep -i '^(From:|Return-Path:)' sample.eml
Return-Path: <bounce@mg.yourbrand.com>
From: Billing <billing@yourbrand.com>

Significado: El sobre es mg.yourbrand.com y el From visible es yourbrand.com. La alineación SPF depende de si la alineación relajada trata mg.yourbrand.com como alineado (lo hace, bajo relajado, porque es un subdominio). La alineación estricta fallaría.

Decisión: Si planeas ir a estricto (aspf=s), necesitas que envelope-from coincida exactamente (o confiar en la alineación DKIM).

Task 15: Confirm your DMARC record includes an explicit subdomain policy decision

cr0x@server:~$ dig +short TXT _dmarc.yourbrand.com | tr -d '"' | tr ';' '\n' | sed 's/^ *//'
v=DMARC1
p=quarantine
pct=10
adkim=r
aspf=r
rua=mailto:dmarc-rua@yourbrand.com

Significado: No hay etiqueta sp=. Los subdominios heredan p= por defecto, salvo que publiquen su propio registro DMARC.

Decisión: Si tienes muchos subdominios “salvajes”, considera sp=none mientras el padre va a cuarentena/rechazo. O haz lo contrario si los subdominios son abusados.

Task 16: Smoke-test outbound from each known system (minimal, but effective)

cr0x@server:~$ swaks --to dmarc-test@externalmailbox.example --from noreply@yourbrand.com --server smtp.office365.com --auth-user noreply@yourbrand.com --auth-password 'REDACTED' --data "Subject: DMARC smoke test

hello"
=== Trying smtp.office365.com:587...
=== Connected to smtp.office365.com.
<** 220 ...
>** EHLO ...
<** 250-...
>** MAIL FROM:<noreply@yourbrand.com>
<** 250 2.1.0 Sender OK
>** RCPT TO:<dmarc-test@externalmailbox.example>
<** 250 2.1.5 Recipient OK
>** DATA
<** 354 Start mail input; end with <CRLF>.<CRLF>
>** .
<** 250 2.0.0 OK

Significado: El mensaje es aceptado por tu sistema saliente. La comprobación real ocurre en el receptor cuando inspeccionas Authentication-Results.

Decisión: Haz esto para cada plataforma (O365, Gmail, proveedor de marketing, sistema de tickets). Si alguna no puede producir correo alineado, arréglalo antes del rechazo.

Guía rápida de diagnóstico

Cuando endureces DMARC y algo falla, recibirás informes vagos: “los correos no llegan”.
Tu trabajo es convertir eso en un único flujo que falla y en una única condición de alineación que falla, rápido.

Primero: determina si es rechazo, cuarentena u otra cosa

• Pide un rebote. Si hay un mensaje de rebote, léelo. Si menciona DMARC o “unauthenticated”, estás en la zona correcta.
• Revisa la respuesta SMTP del receptor en los logs. Los logs de tu MTA suelen tener el código de estado y el texto exacto.
• Comprueba si el usuario simplemente lo está perdiendo (cuarentena). Si la política es cuarentena, puede que esté en carpetas de spam.

Segundo: identifica qué remitente está realmente enviando el mensaje

• Extrae el mensaje del sistema de envío si es posible (correo en cola, elementos enviados archivados, logs de la aplicación).
• Extrae Return-Path, From y DKIM d=.
• Cruza con los informes RUA para encontrar volumen y tasa de fallo por IP fuente.

Tercero: decide si arreglas alineación SPF, DKIM o el dominio From

• Si DKIM está presente y falla: la firma se rompió (modificación de contenido, clave mala, selector incorrecto) o es una mala configuración del proveedor.
• Si DKIM pasa pero no está alineado: el proveedor firma como sí mismo; necesitas DKIM personalizado o una estrategia con subdominio.
• Si SPF pasa pero DMARC falla: el dominio envelope-from no está alineado con From, o el reenvío causó la falla SPF y dependías de SPF.

Cuarto: controla el radio de impacto mientras arreglas

• Reduce pct temporalmente si es necesario (especialmente durante la rampa de cuarentena).
• Para emergencias, retrocede de reject a quarantine mientras reparas—pero trátalo como un rollback, no como una vida a largo plazo.
• Comunica claramente: qué remitente, qué flujos y tiempo estimado para restaurar.

Listas de verificación / plan paso a paso: de none → quarantine → reject

El despliegue más seguro de DMARC es una migración controlada con puertas medibles. Este es el plan que tiende a sobrevivir la realidad corporativa.

Fase 0: Monitorización que realmente monitoriza (1–4 semanas)

• Publica DMARC con p=none, rua y (opcional) ruf si puedes manejar datos forenses sensibles. Muchas organizaciones omiten ruf.
• Asegura que SPF exista y DKIM esté habilitado para tus plataformas principales.
• Establece un flujo para informes agregados:
  • Revisión diaria durante la primera semana.
  • Revisión semanal después hasta estabilizar.
• Crea un inventario:
  • Cada remitente legítimo.
  • Qué dominios usan en From y en envelope-from.
  • Con qué dominio firman DKIM.
  • Quién posee la configuración.

Puerta para continuar

• Puedes atribuir el 90–95% del volumen visto por DMARC a sistemas conocidos.
• Para los sistemas conocidos, tienes un plan explícito para arreglar cualquier fallo de alineación.
• Tienes al menos un “buzón externo” que puedes usar para comprobaciones de cabeceras.

Fase 1: Cuarentena con un porcentaje bajo (1–3 semanas)

• Establece p=quarantine; pct=10 (o 5 si eres cauto).
• Mantén la alineación relajada (aspf=r; adkim=r) a menos que tengas razón para estricta.
• Monitorea:
  • Tasas de fallo en RUA por fuente.
  • Tickets de soporte mencionando correos perdidos o cambios en carpetas de spam.
  • Logs de rebotes salientes.

Puerta para aumentar pct

• No hay fuentes desconocidas de alto volumen fallando DMARC.
• Todos los remitentes críticos para el negocio (transaccional, facturación, autenticación, RR. HH.) pasan DMARC de forma fiable.
• El impacto en usuarios es manejable y comprendido (falsos positivos en cuarentena vinculados a un remitente y arreglados).

Fase 2: Cuarentena a 25 → 50 → 100 (2–6 semanas)

• Aumenta a 25%, luego 50%, luego 100% con al menos varios días entre pasos.
• Cada paso debe tener:
  • Un ticket de cambio con instrucciones de rollback.
  • Un responsable nombrado que vigile RUA y logs de correo.
  • Una lista de remitentes “watchlist” (proveedores, apps legacy).

Fase 3: Rechazo con rampa de pct (1–4 semanas)

• Pasa a p=reject; pct=10, luego haz la rampa como antes.
• Mantén cuarentena como paso de rollback (más rápido que volver a none).
• Una vez estable en reject, considera:
  • Alineación estricta para SPF/DKIM si tu ecosistema lo soporta.
  • Bloquear comportamiento de subdominios con sp=.

Qué no hacer

• No pases de none a reject porque “encendimos DKIM en Microsoft 365”. Tienes más remitentes de los que crees.
• No uses DMARC para cubrir “no sabemos quién envía correo”. DMARC te obligará a saberlo. Ese es el punto.
• No establezcas alineación estricta pronto a menos que estés muy seguro sobre envelope-from y DKIM de los proveedores.

Tres microhistorias corporativas (anonimizadas, dolorosamente plausibles)

Microhistoria 1: El incidente causado por una suposición errónea

Una fintech mediana decidió que era hora de p=reject. Habían estado en p=none durante meses, vieron mucho spoofing y tenían presión de auditorías de seguridad.
El equipo de correo asumió simplemente: “Todo el correo viene de Microsoft 365, más la plataforma de marketing que ya firmamos con DKIM.”

El lunes por la mañana pasaron a reject al 100%. En una hora, los correos de onboarding de clientes dejaron de llegar a varios proveedores de buzones grandes.
Ventas lo llamó “un problema de entregabilidad”. Soporte lo llamó “el sistema de correo está caído”. Ingeniería dijo “no cambiamos nada”.

La causa raíz fue un tercer sistema: un proveedor de identidad que enviaba “magic links” de inicio de sesión. Usaba From: noreply@yourbrand.com pero firmaba DKIM con el dominio del proveedor.
SPF también pasaba—también para el dominio del proveedor. Bajo p=none, los receptores entregaban de todas formas. Bajo reject, DMARC falló por alineación y fue rechazado.

La solución no fue heroica. Activaron DKIM personalizado del proveedor para yourbrand.com y ajustaron el envelope-from a un subdominio alineado.
La parte difícil fue organizativa: el equipo de identidad era propietario del proveedor y el equipo de correo no había sido invitado a la implementación.

La lección duradera: tus mayores riesgos DMARC no son los sistemas que conoces. Son los que se compraron con tarjeta y fecha límite.

Microhistoria 2: La optimización que salió mal

Un minorista global tenía un SPF complicado: múltiples includes, remitentes regionales y algunas IPs legacy.
Alguien intentó “optimizar” aplanando SPF a una larga lista de IPs para evitar límites de búsquedas DNS y reducir latencia del receptor.

Funcionó un tiempo. Luego un proveedor rotó IPs salientes. Como el proceso de aplanado era manual y mal documentado, el registro SPF quedó desactualizado.
Algunos receptores empezaron a fallar SPF; DMARC todavía pasaba a veces gracias a DKIM, pero no siempre—porque algunos sistemas no firmaban DKIM consistentemente.

Cuando el equipo finalmente pasó a p=quarantine, esos casos marginales comenzaron a ir a spam. Lo más molesto:
era intermitente, ligado a la IP saliente que el proveedor usara esa hora.

Revirtieron a p=none temporalmente. Luego hicieron el trabajo poco glamuroso:
estandarizar DKIM entre remitentes transaccionales, automatizar actualizaciones SPF donde fuera necesario y dejar de depender de SPF como único método alineado.

Lección de optimización: si “simplificas” SPF de una manera que lo hace menos mantenible, no simplificaste nada. Solo moviste el dolor a la respuesta a incidentes.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Una empresa de software B2B llevó a cabo un despliegue lento de DMARC. Seguridad quería rechazo. Marketing estaba nervioso. Finanzas gritaba más fuerte que ambos.
El responsable de correo insistió en un calendario de cambios y rampas pequeñas de pct con un plan de rollback y una lista explícita de remitentes a vigilar.

Durante la rampa de cuarentena de 25% a 50%, los informes agregados mostraron una nueva IP fuente fallando con bajo volumen pero alta tasa de fallo.
No era spoofing. Era una nueva herramienta de customer success enviando “resúmenes de reuniones” como from=yourbrand.com a nombre del personal.

Porque el despliegue tenía puertas, no ocurrió nada catastrófico. El equipo pausó en 50% y no continuó.
Redirigieron esa herramienta para usar un subdominio dedicado, habilitaron DKIM personalizado y verificaron la alineación con mensajes de prueba.

Dos semanas después reanudaron la rampa, alcanzaron reject y nadie fuera del equipo de correo lo notó—mi tipo favorito de éxito silencioso.

Cita (idea parafraseada) de Gene Kranz: “Failure isn’t an option” es menos un eslogan que una disciplina—prepárate para no depender de la suerte.

Errores comunes: síntomas → causa raíz → solución

Estos son los reincidentes. Puedes identificarlos por el patrón de quejas.

1) Síntoma: “Solo algunos destinatarios no reciben nuestros correos” tras pasar a reject

Causa raíz: Rutas de envío mixtas. Un camino se alinea (DKIM o SPF), otro no (a menudo un proveedor o sistema regional).

Solución: Usa informes RUA para segmentar por IP fuente e identificar el sistema que falla. Habilita DKIM alineado para ese remitente o mueve el From a un subdominio alineado.

2) Síntoma: Los correos van a spam justo después de cuarentena, pero DMARC pasa en tus pruebas

Causa raíz: Cuarentena no garantiza solo colocación en spam por fallos DMARC; cambia la puntuación del receptor. Además, tus pruebas podrían cubrir solo un remitente.

Solución: Prueba cada ruta de remitente importante. Confirma que DMARC pase y la alineación en Authentication-Results. Si el pase es consistente, mira reputación/contenido, no la política DMARC.

3) Síntoma: DMARC falla aunque SPF indique “pass” en cabeceras

Causa raíz: SPF pasó para un dominio distinto al From visible (desalineación). Común con proveedores que usan su propio dominio de bounce.

Solución: Configura un return-path / envelope-from personalizado bajo tu dominio (subdominio alineado) o confía en DKIM alineado.

4) Síntoma: DKIM pasa a veces y falla otras para el mismo sistema

Causa raíz: Modificación de mensaje en tránsito (pies de página, disclaimers, reescritura de enlaces), múltiples firmantes DKIM con configuración inconsistente, o desajuste de clave/selector durante rotación.

Solución: Firma después de la modificación (en el último salto que controlas), reduce la reescritura downstream y asegura que selectores y claves estén desplegados antes de cambiar de firmante.

5) Síntoma: Picos de fallo DMARC tras habilitar alineación estricta

Causa raíz: La alineación estricta requiere coincidencia exacta de dominios. Un envelope-from en subdominio (por ejemplo, mg.yourbrand.com) ya no se alinea con yourbrand.com para SPF.

Solución: Mantén alineación relajada a menos que tengas razones sólidas. Si vas a estricto, asegura que DKIM firme con el dominio From exacto, o cambia el envelope-from en consecuencia.

6) Síntoma: Parte del correo reenviado (especialmente a cuentas personales) empieza a fallar tras reject

Causa raíz: Los reenviadores pueden romper SPF y a veces DKIM. DMARC entonces falla en el receptor final.

Solución: Prefiere la alineación DKIM para correo importante y considera flujos conscientes de ARC. Para listas de correo, considera configurar la lista para respetar DMARC (puede implicar reescritura de From).

7) Síntoma: Los informes RUA están vacíos o con volumen extremadamente bajo

Causa raíz: La dirección rua no es aceptada por los receptores (algunos validan), problemas con el buzón, error DNS, o tienes muy poco tráfico a través de receptores que envían informes.

Solución: Verifica que rua es correcto, que el buzón recibe mensajes y que el registro DMARC es visible. Considera añadir múltiples buzones RUA si es operativo útil.

8) Síntoma: Publicas DMARC pero nada cambia

Causa raíz: Pruebas con correo que ya pasa DMARC, o los receptores ignoran la política por registro malformado, múltiples registros TXT DMARC o dominio equivocado.

Solución: Valida un único registro TXT DMARC en _dmarc.yourbrand.com y prueba un mensaje que falle deliberada y éticamente con cuidado.

Broma #2: La autenticación de correo es el único proyecto de seguridad donde puedes estar “completamente conforme” y aun así perder frente a un boletín reenviado.

FAQ

1) ¿Cuándo debo cambiar de cuarentena a rechazo?

Cambia cuando tus informes agregados muestren que los remitentes legítimos de alto volumen pasan DMARC de forma consistente y las fuentes desconocidas que fallan son de bajo volumen o claramente maliciosas.
Prácticamente: cuando puedes nombrar cada remitente significativo y tienes un responsable para cada configuración.

2) ¿Es seguro pasar directamente de p=none a p=reject?

Solo si tienes una superficie de envío muy pequeña y controlada y ya validaste la alineación para todos los remitentes.
La mayoría de organizaciones creen que son pequeñas y controladas. La mayoría se equivoca. Usa cuarentena y rampas de pct salvo que estés en una crisis de spoofing activo.

3) ¿Qué hace realmente pct?

pct solicita a los receptores que apliquen la política solo a un porcentaje de los mensajes que fallen la evaluación DMARC.
No es un algoritmo de muestreo garantizado y distintos receptores lo implementan de forma diferente, pero sigue siendo útil como palanca gradual de aplicación.

4) ¿Necesito tanto SPF como DKIM para DMARC?

Estrictamente: no, DMARC puede pasar con SPF o DKIM. Operacionalmente: sí, quieres ambos.
DKIM es especialmente importante porque SPF es frágil ante el reenvío y el relaying.

5) ¿Debería establecer aspf=s y adkim=s (alineación estricta)?

No al principio. Comienza relajado. La alineación estricta es para cuando quieres reducir abusos de casos límite y tienes control fuerte sobre proveedores y subdominios.
La alineación estricta también es una gran forma de descubrir dependencias ocultas a las 2 a.m.

6) ¿Y los subdominios—heredan la política del padre?

Por defecto, los subdominios usan la política DMARC del dominio organizacional a menos que publiquen su propio registro DMARC.
Si pones sp= en el registro padre, puedes definir una política separada específicamente para subdominios.

7) ¿Por qué algunos proveedores “soportan DMARC” pero aun así fallan alineación?

Muchos proveedores quieren decir “soportamos SPF y DKIM para nuestro dominio”. Eso no basta si quieres enviar como tu dominio.
Normalmente necesitas DKIM personalizado (firmar con tu dominio) y a veces un return-path personalizado bajo tu dominio.

8) ¿DMARC detendrá todo el phishing con mi marca?

Detiene el spoofing de dominio directo (el atacante usa From: ceo@yourbrand.com mientras envía desde otro lugar) para los receptores que aplican DMARC.
No detiene dominios similares, suplantación de nombre visible o cuentas legítimas comprometidas.

9) ¿Cuál es el mayor riesgo operacional de DMARC reject?

Romper correo legítimo desde un sistema que no sabías que usaba tu dominio From, o desde un proveedor que no puede alinear.
Esto afecta primero al correo transaccional, que es exactamente el correo que no puedes permitirte perder.

10) Si estoy bajo spoofing activo hoy, ¿cuál es el movimiento seguro más rápido?

Pasa rápidamente a p=quarantine; pct=100 si tienes alineación básica para tus plataformas principales, luego acelera la remediación y sube a reject.
Si puedes afirmar con confianza la alineación DKIM para tu correo central, puedes ir a reject más rápido—pero hazlo con monitoreo atento y personal disponible.

Conclusión: próximos pasos que puedes ejecutar esta semana

DMARC cuarentena y rechazo no son posiciones filosóficas. Son modos de aplicación.
Cuarentena es cómo aprendes sin tumbar el negocio. Rechazo es cómo aprovechas ese aprendizaje y haces que el spoofing sea realmente más difícil.

Pasos prácticos:

1. Revisa tus registros DNS DMARC/SPF/DKIM actuales y confirma que hay exactamente un registro DMARC.
2. Activa el reporte RUA si falta y empieza a recolectar informes agregados a diario.
3. Construye tu inventario de remitentes a partir de IPs fuente en RUA y cabeceras Authentication-Results.
4. Arregla primero el remitente legítimo con más fallos (normalmente un proveedor con DKIM desalineado).
5. Pasa a p=quarantine; pct=10 con un plan de rollback, luego escala deliberadamente.
6. Gradúa a p=reject una vez que tus flujos críticos conocidos pasen DMARC de forma consistente y las fuentes desconocidas claramente no sean tuyas.

La condición de éxito es silenciosa: menos mensajes suplantados llegan, menos usuarios tienen que adivinar y tu correo deja de ser una alucinación compartida entre remitentes y receptores.