DMARC falla: elige una política sin romper el correo legítimo

El correo de tu CEO “no llegó”, el soporte tiene tres capturas de pantalla de mensajes de rebote que no coinciden, y Marketing jura que “no cambiaron nada”. Mientras tanto, suplantan tu dominio en campañas de phishing y el equipo de seguridad quiere p=reject ayer.

Esta es la trampa de DMARC: si aplicas la política demasiado pronto, bloqueas correo legítimo. Si no la aplicas, estás básicamente poniendo un buffet ilimitado para los suplantadores. El truco no es elegir una política. El truco es ganársela.

Qué hace realmente DMARC (y qué no)

DMARC es una capa de políticas e informes construida sobre SPF y DKIM. Responde una pregunta: ¿debe un receptor confiar en que el dominio del encabezado From visible está autenticado? DMARC comprueba si SPF o DKIM “pasan” y están alineados con el dominio del encabezado From. Si existe una autenticación alineada, DMARC pasa. Si no, DMARC falla y el receptor aplica la política que has solicitado: none, quarantine o reject.

Importante: DMARC no es un filtro anti-spam. No puntúa contenido. No evita que cuentas comprometidas envíen correo abusivo usando autenticación válida. No arregla tu reputación. Es más bien “protección de marca con perillas”, y girarlas mal puede hacer daño como a un DJ a las 2 a.m.

Hechos interesantes y contexto histórico (lo que explica por qué es raro)

• DMARC nació por dolor: surgió alrededor de 2012 como respuesta pragmática a la suplantación masiva de dominios que SPF y DKIM por sí solos no resolvían.
• SPF precede a DKIM: SPF ganó tracción a principios de los 2000 cuando los remitentes de sobre eran falsificados y SMTP no se preocupaba.
• DKIM vino de colaboración industrial: se desarrolló para preservar la integridad del mensaje a través de saltos entre proveedores de buzón.
• La alineación es el requisito “nuevo”: que SPF o DKIM pasen no basta; DMARC exige que el dominio autenticado coincida (o coincida de forma cercana) con el From visible.
• El reenvío rompe SPF por diseño: el reenvío estándar cambia la IP emisora, por lo que SPF suele fallar incluso cuando el remitente original era legítimo.
• Los informes DMARC hicieron observable al correo: los informes agregados son uno de los primeros canales de telemetría a escala de Internet para autenticación de correo.
• La adopción de políticas se aceleró tras la presión de grandes proveedores: cuando grandes buzones empezaron a marcar visiblemente correo no autenticado, a los ejecutivos les empezó a importar.
• La política para subdominios existe porque a los atacantes les encantan los subdominios: la etiqueta sp= es una admisión tácita de que “una política para todos” rara vez sobrevive en la realidad corporativa.

Una cita que la gente de operaciones repite por una razón: “La esperanza no es una estrategia.” — General Gordon R. Sullivan. La autenticación de correo es una clase magistral de esa idea.

Guion de diagnóstico rápido

Esta es la secuencia de “dejar de adivinar”. El objetivo es encontrar el cuello de botella en minutos, no producir un diagrama bonito que nadie leerá.

Primero: confirma el eje que falla (SPF, DKIM o alineación)

1. Consigue un mensaje real que falle (preferiblemente desde un proveedor de buzón, no una captura).
2. Inspecciona Authentication-Results y anota:
   • SPF pass/fail y el dominio usado.
   • DKIM pass/fail y el dominio que firmó (d=).
   • DMARC pass/fail y el dominio “header.from”.
3. Si SPF o DKIM pasan pero DMARC falla, tienes un problema de alineación, no de autenticación.

Segundo: identifica el sistema emisor que produjo el correo

1. Busca pistas en los encabezados: Received:, X-Mailer, encabezados específicos del proveedor.
2. Relaciona con un flujo conocido: Microsoft 365, Google Workspace, Salesforce/Marketo, Zendesk, Postfix en local, sistema de RR. HH., plataforma de facturas, etc.
3. Si no lo identificas rápido, los informes agregados DMARC lo harán—si los estás recopilando.

Tercero: decide si puedes arreglarlo por configuración o necesitas cambiar el enrutamiento

• Arreglable por configuración: añadir firma DKIM, corregir el From, añadir include en SPF, corregir selector, publicar registro DMARC, ajustar modo de alineación.
• Requiere cambio de enrutamiento: el tercero debe enviar a través de tu retransmisor autorizado, o debe usar su propio dominio, o debe soportar DKIM con tu dominio.

No empieces cambiando tu política DMARC. Empieza haciendo que tus flujos legítimos pasen. La política viene al final.

Elegir una política DMARC sin romper el correo

La política DMARC no es una postura moral. Es ingeniería de tráfico. Tu objetivo es: detener el correo suplantado mientras mantienes la entrega del correo legítimo. El camino más seguro es la aplicación por etapas con telemetría.

Qué significan en la práctica las tres políticas

p=none (monitorización)

Esto pide a los receptores que no hagan nada especial con los fallos. No es inútil—si tienes los informes configurados, es tu fase de visibilidad. Trata p=none como modo solo lectura: mides el radio de impacto, enumeras emisores y corriges alineación. Si te quedas aquí para siempre, los atacantes te agradecerán por contribuir a sus objetivos trimestrales.

p=quarantine (aplicación suave)

Esto pide a los receptores tratar los fallos como sospechosos—usualmente colocándolos en la carpeta de spam. El comportamiento varía por proveedor. Algunos ponen en cuarentena agresivamente, otros con suavidad, y algunos te ignoran más de lo que admiten. Quarantine es valioso porque muestra impacto visible al usuario con menos pérdida catastrófica que reject. También es peligroso porque la gente no siempre revisa la carpeta de spam, y los procesos de negocio no disfrutan la entrega probabilística.

p=reject (aplicación estricta)

Esto pide a los receptores rechazar de plano el correo que falla, idealmente en tiempo SMTP. Es la postura más limpia para prevenir suplantación. También es implacable: cualquier flujo legítimo que falle alineación se convierte en una interrupción. No se “prueba reject”. Se despliega como una regla de firewall en producción: con inventario, canarios y planeamiento de reversión.

Aplicación por etapas sin incendiar producción

Usa el despliegue por porcentaje con la etiqueta pct=. Empieza en pct=10 o pct=25 para quarantine o reject, según cuánta confianza tengas en tu inventario de emisores.

Una progresión segura típica:

1. Base: p=none + informes agregados funcionando (rua=) durante al menos 2–4 semanas.
2. Depuración: arregla o elimina flujos legítimos que fallan; habilita firma DKIM donde puedas.
3. Aplicación parcial: p=quarantine; pct=25, monitoriza impacto a usuarios y fuentes inesperadas.
4. Más fuerte: p=quarantine; pct=100 o pasar a p=reject; pct=25 si está todo limpio.
5. Objetivo: p=reject; pct=100, además de sp=reject si controlas subdominios.

Chiste #1: DMARC es como el cinturón de seguridad—todo el mundo lo quiere hasta que se atasca mientras alcanzas el café.

Qué hacer con los subdominios (donde la complejidad se reproduce)

Si tu organización usa subdominios para marketing, correo transaccional o marcas regionales, establece una política explícita para subdominios con sp=. Si no, podrías aplicar enforcement accidentalmente sobre subdominios que ni sabías que existían.

• Conservador: p=reject; sp=none para proteger el dominio principal dando espacio a subdominios.
• Estricta: p=reject; sp=reject una vez que sepas que los emisores de subdominios están limpios.

¿Qué tan estricta debe ser la alineación?

La alineación DMARC puede ser relajada o estricta:

• Alineación relajada (por defecto): permite alineación por dominio organizativo (p. ej., mail.example.com firma se alinea con From example.com).
• Alineación estricta: requiere coincidencia exacta de dominio. Aquí es donde configuraciones perfectamente legítimas empiezan a fallar.

En la mayoría de las empresas, la alineación estricta queda para más adelante—después de eliminar comportamientos extraños de proveedores y estandarizar dominios emisores. Empieza relajado a menos que tengas una razón fuerte para no hacerlo.

Alineación y modos de fallo que perjudican en producción

SPF: el remitente del sobre no es el encabezado From

SPF autentica el dominio en el remitente del sobre SMTP (Return-Path), no el header From. DMARC luego comprueba si ese dominio autenticado por SPF se alinea con el dominio del header From.

Patrón de fallo común:

• Return-Path: bounces.vendor-mail.example.net (dominio del proveedor)
• From: billing@example.com (tu dominio)
• SPF pasa para el dominio del proveedor, pero no se alinea con example.com → DMARC falla a menos que DKIM se alinee.

DKIM: existe firma, pero no con tu dominio

DKIM firma el contenido y lo liga a un dominio mediante la etiqueta d=. DMARC comprueba si ese dominio se alinea con el header From. Si un proveedor firma como d=vendor.com mientras envía From tu dominio, DKIM puede pasar pero DMARC seguirá fallando.

Reenvío: SPF falla, DKIM podría sobrevivir

El reenvío clásico rompe SPF porque la IP del reenvío no está en tu registro SPF. DKIM puede sobrevivir el reenvío si el mensaje no se modifica en tránsito. Muchos sistemas lo modifican (prefijos en el asunto, inserción de pie de página), lo que rompe DKIM también. Entonces DMARC falla y te toca la reunión de “¿por qué esto funcionaba el año pasado?”

Listas de correo: el triturador de DKIM

Las listas suelen reempaquetar o modificar mensajes (prefijos de asunto, pies de lista), lo que rompe DKIM. SPF rara vez se alinea porque el servidor de la lista lo envía. DMARC falla. Los gestores modernos de listas pueden mitigar esto, pero no controlas todas las listas a las que se suscriben tus usuarios.

Varios proveedores: muerte por mil “solo añade este include”

SPF tiene un límite duro: 10 búsquedas DNS durante la evaluación. Cada include: cuenta, además de redirecciones y algunos mecanismos. Si lo excedes obtienes permerror. DMARC no pregunta por qué SPF falló; solo ve el fallo. Puedes terminar rompiendo correo “autorizando” demasiadas cosas.

Informes DMARC: la diferencia entre control y superstición

Los informes agregados (RUA) muestran quién envía en nombre de tu dominio, qué autenticación pasan y en qué volumen. No son perfectos. Llegan con retraso, algunos proveedores los muestrean y a veces son difíciles de parsear. Pero sin ellos, haces cambios de política a ciegas.

Tareas prácticas: comandos, salidas, decisiones

Estas tareas están pensadas para un flujo de trabajo tipo SRE: verificar estado, interpretar salida, tomar una decisión, cambiar una cosa a la vez.

Tarea 1 — Comprueba que exista el registro DMARC y sea sintácticamente correcto

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

Qué significa: DMARC existe; la política es monitorización; los informes van a tus buzones; la alineación relajada está configurada.

Decisión: Si no hay registro o está mal formado, arréglalo antes de tocar otra cosa. Si sigues en p=none, estás en modo inventario.

Tarea 2 — Valida que DNS devuelva un único registro TXT DMARC

cr0x@server:~$ dig TXT _dmarc.example.com +noall +answer
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com"

Qué significa: Solo un registro. Bien.

Decisión: Si ves múltiples respuestas TXT, consolida. Múltiples registros DMARC es comportamiento indefinido, y los proveedores de buzón tienden a elegir el caos.

Tarea 3 — Comprueba el registro SPF y cuenta los includes (riesgo de lookup)

cr0x@server:~$ dig +short TXT example.com
"v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:mailgun.org -all"

Qué significa: SPF autoriza a Google, Microsoft y Mailgun. Potencialmente aceptable, pero cada include consume búsquedas.

Decisión: Si tienes más de unos pocos includes, haz una prueba de conteo de búsquedas (tarea siguiente). Si estás cerca de 10, deja de añadir includes y cambia de estrategia (alineación DKIM por proveedores, o consolidar a través de un relé).

Tarea 4 — Detecta permerror de SPF por límite de búsquedas DNS

cr0x@server:~$ spfquery -ip=203.0.113.10 -sender=bounce@example.com -helo=mx.example.com
pass (lookup_count=7)

Qué significa: La evaluación SPF pasó y usó 7 búsquedas DNS. Tienes margen.

Decisión: Si ves permerror (lookup limit exceeded), debes reducir la complejidad del SPF. Eso no es trabajo de “luego”; es trabajo de “hoy” antes de la aplicación.

Tarea 5 — Extrae el encabezado de un mensaje que falla y lee Authentication-Results

cr0x@server:~$ sed -n '1,120p' failing-message.eml | egrep -i 'authentication-results|dmarc=|spf=|dkim=|from:|return-path'
Return-Path: <bounces@vendor.example.net>
From: "Billing" <billing@example.com>
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounces@vendor.example.net designates 198.51.100.20 as permitted sender) smtp.mailfrom=bounces@vendor.example.net;
       dkim=none (message not signed);
       dmarc=fail (p=quarantine sp=quarantine dis=none) header.from=example.com

Qué significa: SPF pasó para el dominio del proveedor, pero DMARC falló porque no hay DKIM y SPF no se alinea con example.com.

Decisión: Necesitas firma DKIM con d=example.com (preferible), o cambiar al proveedor para que envíe con su propio dominio (menos ideal para marca), o enrutar a través de tu infraestructura.

Tarea 6 — Comprueba que exista la clave pública DKIM para un selector

cr0x@server:~$ dig +short TXT s1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw..."

Qué significa: El selector s1 está publicado. Eso es necesario, no suficiente.

Decisión: Si falta, DKIM fallará para el correo firmado con ese selector. Publícalo o corrígelo antes de la aplicación.

Tarea 7 — Verifica que un mensaje esté realmente firmado por DKIM y alineado

cr0x@server:~$ grep -i '^DKIM-Signature:' -m 1 good-message.eml
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s1; h=from:to:subject:date:message-id; bh=...; b=...

Qué significa: El dominio que firma d=example.com se alinea con From example.com. Este flujo debería pasar DMARC incluso si SPF falla (reenvío).

Decisión: Si d=vendor.com, DKIM puede pasar pero la alineación DMARC puede fallar. Corrige la configuración del proveedor para firmar con tu dominio.

Tarea 8 — Prueba la evaluación DMARC desde una herramienta tipo receptor (OpenDMARC)

cr0x@server:~$ opendmarc-testmsg < failing-message.eml | sed -n '1,25p'
opendmarc-testmsg: EnvelopeFrom: bounces@vendor.example.net
opendmarc-testmsg: HeaderFrom: example.com
opendmarc-testmsg: SPF: pass
opendmarc-testmsg: DKIM: fail
opendmarc-testmsg: DMARC: fail (policy=quarantine)

Qué significa: La lógica DMARC del lado receptor concuerda con lo que ves en producción.

Decisión: No discutas con producción. Arregla DKIM o la alineación.

Tarea 9 — Inspecciona logs de Postfix para comportamiento del milter DKIM (on-prem)

cr0x@server:~$ sudo tail -n 30 /var/log/mail.log
Jan  3 10:12:11 mx1 postfix/cleanup[22190]: 9F3C42C10D: message-id=<20260103101210.9F3C42C10D@mx1.example.com>
Jan  3 10:12:11 mx1 opendkim[1187]: 9F3C42C10D: DKIM-Signature field added (s=s1, d=example.com)
Jan  3 10:12:11 mx1 postfix/qmgr[1120]: 9F3C42C10D: from=<billing@example.com>, size=28412, nrcpt=1 (queue active)

Qué significa: Tu MTA está añadiendo firmas DKIM usando el selector y dominio esperados.

Decisión: Si no ves “DKIM-Signature field added”, tu ruta de firmado está rota (milter caído, socket incorrecto, permisos de clave equivocados).

Tarea 10 — Confirma que el buzón de informes DMARC recibe informes agregados

cr0x@server:~$ sudo -u postfix mailq | head
Mail queue is empty

Qué significa: No es directamente sobre DMARC, pero te indica que el buzón de informes no está acumulando en la cola del MTA. Si haces entrega local, esto importa.

Decisión: Si la cola crece y el destino es tu buzón rua, estás perdiendo informes y volando a ciegas. Arregla la entrega de correo antes de cambiar la política.

Tarea 11 — Extrae el XML de informes agregados DMARC y resume las fuentes principales que fallan

cr0x@server:~$ unzip -p rua-archive/aggregate-report-001.zip '*.xml' | grep -Eo '<source_ip>[^<]+' | head
<source_ip>192.0.2.55
<source_ip>198.51.100.20
<source_ip>203.0.113.99

Qué significa: Tienes una lista rápida de IPs fuente que envían en nombre de tu dominio.

Decisión: Para cada IP principal, identifica el sistema/proveedor. Las IPs desconocidas son shadow IT o suplantación activa. Ambas merecen atención; solo una merece ticket a proveedor.

Tarea 12 — Verifica qué sistemas se conectan a tu MX entrante (detección de suplantación y relays)

cr0x@server:~$ sudo grep -h "connect from" /var/log/mail.log | awk '{print $NF}' | sed 's/[][]//g' | cut -d: -f1 | sort | uniq -c | sort -nr | head
  412 203.0.113.77
  198 198.51.100.20
   76 192.0.2.55

Qué significa: IPs que más se conectan. Esto no prueba suplantación, pero muestra quién habla con tu sistema.

Decisión: Si ves emisores inesperados o picos enormes, correlaciona con fallos DMARC y eventos de seguridad. Podrías estar bajo campañas activas de suplantación.

Tarea 13 — Comprueba que tu política DMARC sea la que crees (DNS cache miente)

cr0x@server:~$ dig TXT _dmarc.example.com @8.8.8.8 +short
"v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-rua@example.com; adkim=r; aspf=r"

Qué significa: Un resolvedor público ve quarantine al 25%. Bien para despliegue por etapas.

Decisión: Si diferentes resolvedores discrepan, tu TTL o propagación DNS está en juego. No pases a reject hasta ver resultados consistentes.

Tarea 14 — Inspecciona SPF para un flujo de proveedor específico (¿se alinea?)

cr0x@server:~$ dig +short TXT vendor.example.net
"v=spf1 ip4:198.51.100.0/24 -all"

Qué significa: El proveedor autoriza su propio rango IP para su dominio. Eso no hace nada por la alineación con tu dominio From.

Decisión: Deja de intentar “salir por SPF” de emisores externos desalineados. Exige firma DKIM alineada con tu dominio o cambia el From.

Tarea 15 — Verifica que la rotación de selectores DKIM no dejó registros muertos (común durante la “limpieza”)

cr0x@server:~$ for s in s1 s2 s2024; do echo "== $s =="; dig +short TXT ${s}._domainkey.example.com; done
== s1 ==
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG..."
== s2 ==
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG..."
== s2024 ==

Qué significa: El selector s2024 falta. Si algún emisor aún lo usa, DKIM fallará.

Decisión: O republicas la clave temporalmente o migras al emisor a un selector existente antes de aplicar. Borrar selectores antiguos no es “higiene” si todavía se usan.

Tarea 16 — Confirma el límite de dominio organizativo para alineación relajada (comportamiento de sufijos públicos)

cr0x@server:~$ python3 - <<'PY'
import sys
from email.utils import parseaddr
print("example.co.uk aligns with sub.example.co.uk under relaxed mode, but not with example.com")
PY
example.co.uk aligns with sub.example.co.uk under relaxed mode, but not with example.com

Qué significa: La alineación relajada usa la lógica de dominio organizativo (basada en reglas de sufijos públicos). Los dominios con código de país pueden sorprender.

Decisión: Si operas bajo dominios como example.co.uk, verifica la configuración y expectativas de proveedores; la alineación estricta se vuelve dolorosa rápidamente.

Chiste #2: SPF es el plan de dieta de la seguridad del correo—simple en papel, destrozado por “solo un include más”.

Tres mini-historias corporativas (porque nunca aprendemos la forma fácil)

Mini-historia 1: La interrupción causada por una suposición incorrecta

La empresa tenía una configuración que parecía limpia: Microsoft 365 para empleados, una plataforma de marketing de renombre y un relé on-prem para impresoras y “sistemas especiales”. Seguridad quería p=reject. El administrador de correo estuvo de acuerdo, porque los informes DMARC mostraban “mayormente pass”.

La suposición errónea fue sutil: asumieron que “mayormente pass” significaba “el resto es suplantación”. No lo era. Una herramienta regional de RR. HH. estaba enviando cartas de oferta usando From: hr@example.com pero enroutando por la infraestructura del proveedor sin DKIM alineado. SPF pasaba—simplemente no para el dominio correcto. DMARC falló. Bajo p=none aún llegaba. Bajo p=reject rebotó sin remedio.

El lunes por la mañana, candidatos no recibieron ofertas. Reclutadores escalaron. Legal preguntó si la empresa había “retirado” ofertas. Seguridad fue culpada porque pidió reject, y el equipo de correo fue culpado por implementarlo. La gerencia hizo lo que hace: programó una reunión, luego otra reunión sobre la primera reunión.

La solución fue directa: configurar al proveedor de RR. HH. para firmar DKIM con d=example.com usando un selector delegado, luego reactivar la aplicación. La lección fue más fea: el éxito de DMARC consiste en enumerar cada emisor legítimo. Cualquier suposición de que “desconocido = malicioso” es una política que tarde o temprano te hará sonar la alarma.

Mini-historia 2: La optimización que se volvió en contra

Otra organización decidió “simplificar DNS”. Alguien notó que el registro SPF se había convertido en una pequeña novela. Eliminó lo que parecían “includes de proveedores antiguos” y consolidó selectores DKIM porque “no necesitamos tantos”. Fue bien intencionado. También no se probó contra la realidad.

Dos semanas después, las tasas de fallo DMARC subieron. No en todas partes—solo en un par de proveedores de buzón. El equipo perdió tiempo culpando “cambios del proveedor” y “reputación”. La verdad: un “include” antiguo aún cubría un flujo de correo transaccional usado para restablecer contraseñas en una app heredada. Enviaba raramente, así que no aparecía en los dashboards diarios. Cuando lo hizo, SPF falló y la app heredada no firmaba DKIM. Con mayor aplicación, los correos de restablecimiento desaparecieron en cuarentena o fueron rechazados, según el receptor.

Mientras tanto, consolidar selectores DKIM rompió una integración de proveedor que tenía el selector codificado. Ese proveedor siguió firmando con el selector antiguo, que ya no existía en DNS. DKIM falló de inmediato. Los fallos DMARC se dispararon para ese emisor.

El equipo revertió, luego escribió una regla: no hacer “limpieza” de SPF/DKIM sin mapear cada include y selector a un responsable, un sistema y un mensaje de prueba. La optimización es buena, pero la autenticación de correo castiga la astucia. Prefiere papeleo aburrido y DNS estable.

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

Una empresa SaaS mediana volcaba informes DMARC a un buzón interno, luego a un parser que producía un inventario semanal de emisores. Nada sofisticado. Sin ML. Solo una lista de fuentes, tasas de paso y “nuevos emisores desde la semana pasada”. Era el tipo de proceso que la gente llama “trabajo ocupado” hasta que importa.

Un martes, el informe marcó una nueva IP de origen enviando un pequeño pero no nulo volumen de correos usando From: finance@example.com. SPF falló. DKIM ausente. DMARC falló. Bajo su p=quarantine actual, gran parte aterrizaba en spam. Bien, pero no suficiente.

Seguridad investigó y encontró una campaña de phishing dirigida a clientes. Porque el equipo tenía telemetría y una línea base, no discutieron si era real. Pasaron a p=reject; pct=25 durante 24 horas, verificaron que ningún flujo legítimo se viera afectado, luego subieron a 100% reject. También pusieron sp=reject tras confirmar que los subdominios estaban limpios.

Los clientes reportaron menos intentos de phishing usando el nombre de la empresa en días. La práctica aburrida—informes consistentes e inventario—convirtió la aplicación en un cambio controlado en lugar de un salto de fe. Nadie recibió una alerta. Las mejores interrupciones son las que nunca ocurren.

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

1) “SPF pasa pero DMARC falla”

Síntoma: Authentication-Results muestra spf=pass, DMARC falla.

Causa raíz: SPF pasó para un dominio que no se alinea con el header From (común con terceros).

Solución: Habilitar firma DKIM alineada con tu dominio From (mejor), o cambiar el From al dominio del proveedor, o enrutar al emisor por tu infraestructura alineada.

2) “DKIM pasa pero DMARC falla”

Síntoma: dkim=pass pero DMARC falla.

Causa raíz: El dominio de firma DKIM d= no se alinea con el header From; el proveedor firma como sí mismo.

Solución: Configurar al proveedor para firmar con tu dominio vía DKIM delegado (publicar su selector bajo tu dominio), o ajustar el From.

3) “Todo funcionaba hasta que pusimos p=reject”

Síntoma: Rebotes inmediatos para correo legítimo de negocio.

Causa raíz: Emisores legítimos desconocidos, selectores DKIM rotos o permerror de SPF estaban enmascarados bajo p=none/quarantine.

Solución: Revertir a quarantine con pct=, arreglar el inventario de emisores, luego volver a desplegar reject por etapas.

4) “El correo reenviado empezó a rebotar tras la aplicación de DMARC”

Síntoma: Usuarios que reenvían a buzones personales se quejan; entregas en listas fallan.

Causa raíz: Los reenviadores rompen SPF; las modificaciones de listas rompen DKIM; DMARC falla.

Solución: Asegura que tu correo saliente esté firmado por DKIM alineado; para listas, considera mitigaciones específicas (p. ej., reescritura de From) o permitir comportamientos conocidos en sistemas downstream donde sea factible.

5) “Aparece permerror de SPF aleatoriamente”

Síntoma: Algunos receptores muestran SPF permerror o fail; otros pasan.

Causa raíz: Límite de búsquedas DNS excedido; algunos evaluadores hacen short-circuit de otra manera, o timeouts DNS te empujan a errores temporales.

Solución: Reduce búsquedas DNS en SPF consolidando emisores, eliminando includes no usados, o usando alineación DKIM en lugar de depender de SPF.

6) “Los informes DMARC dejaron de llegar”

Síntoma: El buzón RUA está silencioso; los dashboards se quedan obsoletos.

Causa raíz: Buzón lleno, enrutamiento cambiado, dirección rua inválida o filtrado que bloquea archivos zip grandes.

Solución: Asegura que el buzón de informes acepte mensajes grandes, no borre automáticamente y que la dirección rua sea correcta y esté monitorizada.

7) “Tenemos DMARC pero la suplantación sigue ocurriendo”

Síntoma: Clientes reciben phishing usando tu marca a pesar de tener registro DMARC.

Causa raíz: Estás en p=none, o los receptores no aplican uniformemente, o los atacantes usan dominios lookalike.

Solución: Pasa a reject una vez que los flujos legítimos pasen; añade política para subdominios; monitorea dominios lookalike por separado (DMARC no te salvará de examp1e.com).

Listas de verificación / plan paso a paso

Paso a paso: llegar a p=reject de forma segura

1. Inventario de emisores mediante informes agregados DMARC durante al menos 2–4 semanas. Etiqueta cada fuente con un responsable.
2. Clasifica los flujos:
   • Correo de empleados (M365/Workspace)
   • Transaccional (correo de apps, facturas, restablecimiento de contraseñas)
   • Marketing (plataformas de campañas)
   • Soporte/ticketing
   • Infraestructura (alertas, monitorización)
3. Estandariza dominios From: decide qué dominios pueden aparecer en From para cada flujo. Sé estricto. A los proveedores les encantan los From creativos.
4. Habilita firma DKIM alineada en todas partes donde sea posible. Prefiere DKIM sobre SPF para flujos de terceros porque la alineación es más fácil y la supervivencia ante reenvíos es mejor.
5. Arregla SPF pero manténlo ligero:
   • Elimina includes muertos
   • Mantente por debajo de 10 búsquedas
   • Usa -all cuando estés seguro; ~all es una muleta, no una estrategia
6. Publica DMARC con informes: p=none + rua. Verifica que los informes lleguen y se parseen.
7. Establece política de subdominios explícita usando sp=. No permitas que subdominios hereden enforcement accidentalmente.
8. Despliega a quarantine con pct: empieza pct=25, luego 50, luego 100 a medida que las tasas de fallo bajen y el ruido de soporte sea aceptable.
9. Despliega a reject con pct: empieza 10–25, vigila nuevos fallos. Aumenta deliberadamente.
10. Fija gobernanza: cualquier nuevo emisor proveedor debe suportar DKIM alineado o usar un dominio del proveedor; “no podemos” significa “no te incorporamos”.
11. Mantén monitorización: DMARC no es configurar y olvidar. Los proveedores rotan IPs, las integraciones cambian, alguien compra una empresa y otra vez tu postura DMARC se enfrenta a la realidad.

Lista de verificación: antes de cambiar la política DMARC

• ¿Tenemos al menos un destino RUA funcionando y recibe informes?
• ¿Tenemos un inventario de emisores actual con responsables?
• ¿Los flujos principales pasan DMARC (no solo SPF o DKIM)?
• ¿SPF está por debajo del límite de búsquedas DNS y es estable?
• ¿Los selectores DKIM están publicados para todos los firmantes activos?
• ¿Tenemos un plan de reversión (registro previo y conciencia de TTL)?
• ¿Hemos comunicado los impactos esperados a soporte y seguridad?

Lista de verificación: cuando un proveedor “debe enviar como tu dominio”

• ¿Puede el proveedor DKIM-firmar con d=yourdomain usando un selector delegado?
• ¿Pueden soportar Return-Path personalizado alineado con tu dominio (rara vez la mejor ruta, pero a veces posible)?
• ¿Pueden enviar a través de tu relé (envío SMTP) para que tú firmes el correo?
• ¿Tienen DKIM por cliente y patrones de envío estables?
• ¿Pueden proporcionar mensajes de prueba y un contacto técnico que entienda autenticación?

Preguntas frecuentes

1) ¿Debemos ir directamente a p=reject para detener la suplantación?

Sólo si estás seguro de que tus flujos legítimos ya pasan DMARC. Si no, cambias suplantación por pérdida de correo auto-infligida. Hazlo por etapas con pct y telemetría.

2) ¿Es p=quarantine “seguro”?

Más seguro que reject, no seguro. Parte del correo crítico de negocio puede desaparecer en carpetas de spam, lo cual es funcionalmente igual a perderlo—solo con negación añadida.

3) ¿Por qué SPF pasa pero DMARC aún falla?

Porque SPF autenticó el dominio del sobre, y DMARC se preocupa por el dominio del header From. Si no coinciden, SPF no ayuda a DMARC. La firma DKIM alineada suele ser la solución.

4) El reenvío está rompiendo nuestro correo. ¿DMARC es incompatible con el reenvío?

DMARC expone la fragilidad del reenvío. SPF se rompe en reenvío; DKIM puede sobrevivir si el mensaje no se modifica. Para tus flujos salientes, firma DKIM alineado para que al menos un mecanismo pueda pasar.

5) ¿Necesitamos ruf= informes forenses?

Generalmente no. Los informes forenses son soportados de forma inconsistente y pueden plantear problemas de privacidad. Los informes agregados (RUA) son el caballo de batalla operativo.

6) ¿Cuál es la razón más grande por la que DMARC “de repente falla” tras años?

Un emisor nuevo o cambio de enrutamiento. Disparadores comunes: el equipo de marketing añade una plataforma, soporte cambia de proveedor, una herramienta SaaS empieza a enviar “desde tu dominio”, o se rota mal un selector DKIM.

7) ¿Necesitamos alineación estricta (adkim=s, aspf=s)?

No al principio. La alineación estricta reduce ambigüedad, pero eleva la exigencia para cada emisor. Empieza relajado, llega a reject y luego considera estricta donde no rompa nada.

8) ¿Y los subdominios: deberíamos poner sp=reject?

Sólo cuando sepas qué usa los subdominios. Si tienes muchos subdominios gestionados por proveedores, empieza con sp=none o sp=quarantine y haz inventario.

9) Si usamos Microsoft 365 o Google Workspace, ¿aún necesitamos DMARC?

Sí. Esas plataformas pueden autenticar tu correo saliente, pero DMARC es la forma en que el resto del mundo sabe qué hacer cuando alguien suplanta tu dominio.

10) ¿Cuánto tiempo deberíamos quedarnos en p=none?

El tiempo suficiente para capturar ciclos normales de negocio: al menos dos semanas, a menudo un mes. Ciclos de facturación trimestrales y flujos raros son donde se esconden tus “emisores desconocidos”.

Conclusión: siguientes pasos que puedes ejecutar

Si DMARC está fallando, no empieces preguntando “¿quarantine o reject?” Empieza preguntando “¿qué flujo legítimo está fallando la alineación?” Corrige eso, luego aplica. La política es el último paso, no el primero.

Pasos prácticos siguientes

1. Extrae un mensaje que falla y lee Authentication-Results. Decide si el problema es SPF, DKIM o alineación.
2. Verifica registros DMARC y SPF en DNS desde múltiples resolvedores. Corrige sintaxis y elimina duplicados.
3. Convierte informes DMARC en inventario: cada emisor, propietario y tasa de paso.
4. Impulsa firma DKIM alineada para cada proveedor que deba usar tu dominio en From.
5. Aplica la política por etapas con pct: primero quarantine, luego reject, con plan de reversión y soporte informado.

Haz eso, y “DMARC falla” se convierte en un problema de ingeniería resoluble en lugar de un hilo de correo interminable titulado “URGENTE”.