Informes DMARC: Cómo leerlos y detectar la suplantación temprano

Qué son realmente los informes DMARC (y qué no son)

Los informes DMARC son bucles de retroalimentación enviados por proveedores de buzones (y algunos intermediarios) al propietario del dominio que publica un registro DMARC. Te indican, a escala, cómo el correo que dice provenir de tu dominio está rindiendo frente a SPF y DKIM, y si cumpliría la política DMARC.

Hay dos tipos de informes que importan:

• Informes agregados (a.k.a. RUA): resúmenes periódicos, típicamente diarios, que muestran recuentos de mensajes por IP de origen, resultados de autenticación y la disposición aplicada por el receptor. Son los que usas para monitoreo y detección de tendencias.
• Informes forenses/de fallos (a.k.a. RUF): detalles de fallo por mensaje (o por muestra). Muchos proveedores los limitan o no los envían por preocupaciones de privacidad y abuso. Si los habilitas sin un plan, terminarás con un buzón lleno de datos personales que no querías poseer.

Qué no son los informes DMARC:

• Una garantía de que la suplantación es imposible. DMARC ayuda a prevenir la suplantación directa en receptores que lo cumplen; no impide dominios que se parecen, fraudes con nombre para mostrar o proveedores comprometidos.
• Una verdad absoluta de “quién envió el correo”. Los informes muestran lo que los receptores observaron. Reenvíos, pasarelas y listas de correo distorsionarán la realidad a menos que entiendas la alineación y cómo se rompe la autenticación.
• Un reemplazo de los registros. Los informes DMARC son una vista desde el lado del receptor. Aún necesitas telemetría del lado del remitente para cerrar el ciclo.

Piensa en los informes DMARC como alertas de tasa de consumo de SLO para la confianza de marca. No apagarán el incendio, pero te dirán dónde está el humo y qué tan rápido se está propagando.

Datos interesantes y un poco de historia

• DMARC surgió a comienzos de los 2010 cuando los grandes proveedores de buzones intentaron reducir el phishing a escala de Internet sin romper el ecosistema de correo existente de la noche a la mañana.
• SPF precede a DMARC y fue diseñado en torno al dominio del sobre SMTP (Return-Path), no al encabezado From visible por humanos. Ese desajuste es la razón por la que DMARC necesitó “alineación”.
• DKIM nació de DomainKeys e Identified Internet Mail; estandarizó la firma criptográfica de cabeceras/cuerpo del mensaje, pero no definió cómo los receptores deberían tratar fallos de forma consistente. DMARC añadió política.
• La etiqueta “pct” de DMARC existe porque el mundo funciona con despliegues por etapas. Es la perilla de despliegue canario para la autenticación de correo.
• “Relaxed” vs “strict” de alineación es básicamente “se permiten subdominios o no”, lo que suena simple hasta que tu organización tiene 47 plataformas de marketing y un ERP heredado que cree que es 2003.
• Los informes agregados son XML por tradición, no porque a alguien le guste. El formato tiene amplio soporte y se comprime bien, lo que importaba cuando los informes se escalaron originalmente.
• Los grandes proveedores limitan u omiten informes forenses debido al riesgo de privacidad; algunos ya no envían muestras completas de mensajes.
• ARC (Authenticated Received Chain) existe en gran parte porque flujos legítimos como las listas de correo rompen SPF/DKIM; ARC ofrece una forma para que los intermediarios preserven resultados de autenticación aguas abajo.

Una idea para llevar contigo, parafraseada y atribuida a Werner Vogels: Todo falla eventualmente; diseña para que puedas recuperarte rápido y aprender del fallo.

Fundamentos de DMARC que importan en producción

DMARC es política + alineación + reportes

Un registro DMARC vive en _dmarc.example.com en DNS. Define:

• Política: qué deben hacer los receptores cuando DMARC falla (p=none, p=quarantine, p=reject).
• Alineación: si el “pass” de SPF/DKIM debe alinearse con el dominio From (relaxed/strict).
• Puntos de reporte: dónde enviar informes agregados (rua) y/o forenses (ruf).

La alineación es donde la mayoría de organizaciones sangran

DMARC no requiere que SPF y DKIM pasen ambos. Requiere o que SPF o DKIM pasen y se alineen con el dominio From.

Realidad común en producción:

• SPF pasa pero no se alinea porque el proveedor usa su propio dominio de rebote (Return-Path), no el tuyo.
• DKIM pasa pero no se alinea porque el proveedor firma con d=vendor.example en lugar de d=yourdomain.com.
• Ambos fallan tras el reenvío, porque SPF se rompe con el cambio de IP y DKIM se rompe con modificaciones en cabeceras/cuerpo.

La política no es una medalla

p=reject no es un trofeo. Es un cambio en producción con consecuencias para usuarios. Se gana instrumentando y estabilizando tus remitentes primero.

Verdad seca: si no puedes nombrar a tus remitentes legítimos, no estás listo para rechazar a los desconocidos.

Broma #1: La autenticación de correo es como usar hilo dental: todos coinciden en que es bueno, y nadie lo hace hasta que empieza a sangrar.

Agregados vs forenses: elegir lo que puedes manejar

Agregados (RUA): tu pulso diario

Los informes agregados llegan como adjuntos comprimidos (a menudo ZIP o GZIP) que contienen XML. Cada informe cubre una ventana temporal e incluye múltiples “registros”, cada uno resumiendo correo que compartió:

• IP de origen (o a veces una abstracción de bloque de red)
• Dominio From (encabezado From)
• Resultados de autenticación y estado de alineación
• Recuentos y la disposición aplicada por el receptor

Son excelentes para detectar:

• Nuevas fuentes que envían como tu dominio
• Picos repentinos de fallos DMARC por un cambio legítimo en una plataforma
• Receptores aplicando quarantine/reject inesperadamente por desalineación

Forenses (RUF): alta señal, alta responsabilidad

Los informes de fallo pueden contener cabeceras del mensaje y a veces porciones del mensaje. Eso puede incluir datos personales, contenido interno o identificadores sensibles. Trátalos como datos de registro con PII y aplica retención y control de acceso en consecuencia.

En muchos entornos, la decisión correcta es: no habilitar RUF a menos que tengas un caso de uso específico y un proceso seguro para manejarlo.

Cómo leer un informe agregado como un SRE

Empieza con la pregunta: “¿Qué cambió?”

El reporte DMARC se trata menos de eventos individuales y más de deltas. Estás cazando IPs nuevas, emisores nuevos y modos de fallo nuevos. Trátalo como análisis de tráfico:

• Base: fuentes conocidas, tasas de paso esperadas, mezcla de receptores esperada.
• Detección de cambios: fuentes nuevas, caídas bruscas en alineación o anomalías específicas de un proveedor.
• Atribución: mapea IPs a proveedores/MTAs y decide si autorizar o bloquear.

Entiende los tres dominios en juego

Te confundirás a menos que mantengas estas separadas:

• Dominio Header From: lo que ven los usuarios; lo que DMARC usa para la política.
• Dominio SPF: el dominio del sobre (Return-Path / MAIL FROM) verificado por SPF.
• Dominio de firma DKIM: el valor d= en la DKIM-Signature.

DMARC pregunta: ¿SPF pasa y se alinea con Header From? ¿O DKIM pasa y se alinea con Header From? Si ninguno se alinea, DMARC falla aunque algo técnicamente “pasó”.

La disposición es comportamiento del receptor, no tu intención

Los informes DMARC incluyen lo que hizo el receptor: none/quarantine/reject. Eso está influenciado por tu política publicada, pero también por políticas locales y heurísticas de spam. Si publicas p=none, los receptores aún pueden mover a junk basura obvia. A la inversa, incluso con p=reject, algunos receptores pueden aceptar correo si confían en una cadena de reenvío o ARC.

Enfócate primero en “falla pero debería haber pasado”

La suplantación existe, claro. Pero tu victoria más rápida es arreglar el correo legítimo que falla DMARC. Ese fallo causa problemas de entrega y te obliga a mantener la política débil porque temes auto-contradecir el correo de tu negocio.

El orden operativo que recomiendo:

1. Arreglar las fuentes legítimas que fallan DMARC (alineación, claves DKIM, problemas de “flattening” de SPF).
2. Mover a p=quarantine con aumento gradual por pct.
3. Entonces y solo entonces: p=reject (también en aumento), con monitorización que avise cuando suban los fallos.

Tareas prácticas: comandos, salidas y decisiones (12+)

Abajo están los tipos de tareas que puedes ejecutar en una caja Linux o en un trabajo de CI que extrae informes DMARC de un buzón/almacen tipo S3. Cada tarea incluye: un comando, salida de ejemplo, qué significa y la decisión que tomas a partir de ello.

Task 1 — Fetch your DMARC record and sanity-check the policy

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

Qué significa: DMARC está habilitado, solo monitorización (p=none), alineación relajada, muestreo completo.

Decisión: Si ya estás estable y aún en p=none, programa mover a p=quarantine con un aumento por pct. Si no estás estable, mantén p=none pero prioriza arreglos de alineación.

Task 2 — Verify the reporting mailbox exists and is receiving mail

cr0x@server:~$ ls -lh /var/mail/dmarc-agg
-rw------- 1 dmarc dmarc 218M Jan  3 08:40 /var/mail/dmarc-agg

Qué significa: Los informes están llegando y acumulándose.

Decisión: Si el buzón es enorme, no estás procesando informes. Automatiza la ingestión y fija retención. Si está vacío, tu dirección rua puede estar mal o bloqueada.

Task 3 — Identify attachment types (zip/gz) before parsing

cr0x@server:~$ file /srv/dmarc/inbox/*
/srv/dmarc/inbox/report-001.xml.gz: gzip compressed data, was "report.xml", last modified: Thu Jan  2 00:00:00 2026, from Unix
/srv/dmarc/inbox/report-002.zip: Zip archive data, at least v2.0 to extract, compression method=deflate

Qué significa: Tienes formatos mixtos. Tu pipeline necesita manejar ambos.

Decisión: Normaliza a XML sin comprimir como primer paso (descomprimir), luego parsea.

Task 4 — Decompress and validate XML is present

cr0x@server:~$ gunzip -c /srv/dmarc/inbox/report-001.xml.gz | head -n 8
<?xml version="1.0" encoding="UTF-8"?>
<feedback>
  <report_metadata>
    <org_name>ExampleMailboxProvider</org_name>
    <email>noreply-dmarc@provider.example</email>
    <report_id>abc123</report_id>

Qué significa: Es un informe agregado DMARC (XML de feedback).

Decisión: Procede al parseo. Si ves HTML o un rebote, tu ingestión apunta al buzón equivocado o estás recibiendo DSNs.

Task 5 — Extract key fields quickly using xmllint and XPath

cr0x@server:~$ gunzip -c /srv/dmarc/inbox/report-001.xml.gz | xmllint --xpath 'string(/feedback/report_metadata/org_name)' -
ExampleMailboxProvider

Qué significa: Este informe vino de un receptor específico. Las peculiaridades por receptor importan.

Decisión: Etiqueta los datos ingeridos por org_name para detectar “solo falla en Microsoft” vs “falla en todas partes”.

Task 6 — Pull the date range to correlate with incidents or deploys

cr0x@server:~$ gunzip -c /srv/dmarc/inbox/report-001.xml.gz | xmllint --xpath 'concat(/feedback/report_metadata/date_range/begin, " ", /feedback/report_metadata/date_range/end)' -
1704153600 1704240000

Qué significa: Timestamps epoch para la ventana del informe (inicio/fin). Es una porción diaria aprox.

Decisión: Convierte a tiempo humano en tus herramientas y sobreponlo a las líneas de tiempo de despliegue. Si no puedes correlacionar, culparás el cambio equivocado.

Task 7 — Summarize sources (IP + count) to find new senders

cr0x@server:~$ gunzip -c /srv/dmarc/inbox/report-001.xml.gz | \
xmllint --xpath '//record/row/source_ip/text() | //record/row/count/text()' - 2>/dev/null | \
tr ' ' '\n' | paste - - | head
192.0.2.10	1450
198.51.100.23	12
203.0.113.77	980

Qué significa: Tres IPs emisoras fueron observadas, con conteos de mensajes.

Decisión: Cualquier IP nueva con volumen no trivial se investiga. Las IPs desconocidas de bajo volumen aún pueden ser spearphishing, así que no las ignores—simplemente triéalas distinto.

Task 8 — Look specifically for DMARC failures at scale

cr0x@server:~$ gunzip -c /srv/dmarc/inbox/report-001.xml.gz | \
xmllint --xpath '//record[row/policy_evaluated/dkim="fail" and row/policy_evaluated/spf="fail"]/row/source_ip/text()' - 2>/dev/null | \
sort | uniq -c | sort -nr | head
3 198.51.100.23

Qué significa: Una IP de origen aparece en múltiples registros de “ambos fallan”. Eso es o suplantación o un remitente legítimo completamente mal configurado.

Decisión: Si la IP no es tuya ni de un proveedor conocido, trátala como suplantación. Si es un proveedor conocido, escala para arreglar alineación DKIM/SPF de inmediato.

Task 9 — Check SPF record size and lookup count risk

cr0x@server:~$ dig +short TXT example.com | tr ' ' '\n' | grep -E '^"v=spf1' -n
1:"v=spf1 include:_spf.mailvendor.example include:_spf.crmvendor.example include:_spf.payroll.example -all"

Qué significa: SPF usa includes (normal). El riesgo es el conteo oculto de búsquedas DNS.

Decisión: Si los informes DMARC muestran permerror/temperror de SPF, puede que estés excediendo el límite de 10 búsquedas SPF. Empieza a inventariar includes y reduce la complejidad; no “añadas solo un include más”.

Task 10 — Query DKIM selectors that vendors commonly use

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

Qué significa: El selector s1 existe. Si tu proveedor firma con s1 y se alinea, estás bien.

Decisión: Si los informes DMARC muestran DKIM fail, verifica que el selector exista, que la clave sea correcta y que el proveedor realmente firme con tu dominio (d=example.com).

Task 11 — Confirm alignment settings (strict vs relaxed) and evaluate risk

cr0x@server:~$ dig +short TXT _dmarc.example.com | sed 's/"//g' | tr ';' '\n' | sed 's/^ *//'
v=DMARC1
p=none
rua=mailto:dmarc-agg@example.com
ruf=mailto:dmarc-fail@example.com
adkim=r
aspf=r
pct=100

Qué significa: Alineación relajada para SPF y DKIM. Los subdominios pueden alinear según reglas del dominio organizacional.

Decisión: Mantén relaxed durante el despliegue salvo que tengas una estrategia disciplinada de subdominios. La alineación estricta es una herramienta afilada; no la uses cerca del marketing.

Task 12 — Identify top “disposition=quarantine/reject” and treat as deliverability incident

cr0x@server:~$ gunzip -c /srv/dmarc/inbox/report-001.xml.gz | \
xmllint --xpath '//record/row/policy_evaluated/disposition/text()' - 2>/dev/null | \
sort | uniq -c | sort -nr
1200 none
230 quarantine
12 reject

Qué significa: Una porción está siendo cuarentenada/rechazada. Eso puede ser esperado (suplantación) o un daño autoinfligido.

Decisión: Si quarantine/reject es no trivial y se correlaciona con fuentes legítimas, detente y arregla la alineación antes de aumentar el rigor de la política.

Task 13 — Extract “header_from” domains to detect subdomain abuse

cr0x@server:~$ gunzip -c /srv/dmarc/inbox/report-001.xml.gz | \
xmllint --xpath '//record/identifiers/header_from/text()' - 2>/dev/null | \
tr ' ' '\n' | sort | uniq -c | sort -nr
2100 example.com
45 billing.example.com
7 security-update.example.com

Qué significa: El correo afirma venir también de subdominios. Algunos son legítimos (correo departamental), otros son creatividad de atacantes.

Decisión: Si no envías intencionalmente desde un subdominio, añade registros DMARC para subdominios o políticas organizacionales, y asegura la delegación DNS de esos nombres.

Task 14 — Reverse-lookup suspicious IPs (quick triage, not proof)

cr0x@server:~$ dig +short -x 198.51.100.23
mailout-23.somehost.example.

Qué significa: PTR sugiere un proveedor de hosting. Atacantes y proveedores legítimos viven allí ambos.

Decisión: Usa esto como pista y luego verifica con inventario de proveedores y registros de envío. No whitelistes basándote en PTR; así terminas confiando en un desconocido con un nombre bonito.

Task 15 — Spot SPF permerror/temperror in DMARC auth results

cr0x@server:~$ gunzip -c /srv/dmarc/inbox/report-001.xml.gz | \
grep -Eo '<spf>(permerror|temperror)</spf>' | sort | uniq -c
18 <spf>permerror</spf>

Qué significa: Los receptores no pudieron evaluar SPF correctamente (a menudo por demasiadas búsquedas DNS, registros malformados o problemas DNS transitorios).

Decisión: Trata permerror como un bug de configuración. Arregla la complejidad de SPF y la fiabilidad DNS antes de endurecer la política DMARC.

Task 16 — Confirm your inbound pipeline is not dropping reports (basic mail log check)

cr0x@server:~$ sudo grep -E "dmarc-agg@example.com|dmarc-fail@example.com" /var/log/mail.log | tail -n 5
Jan  3 08:40:12 mx1 postfix/lmtp[22091]: 9B2C312345: to=<dmarc-agg@example.com>, relay=local, delay=0.22, delays=0.05/0/0/0.17, dsn=2.0.0, status=sent (delivered to mailbox)
Jan  3 08:40:14 mx1 postfix/lmtp[22092]: 1A7D912346: to=<dmarc-agg@example.com>, relay=local, delay=0.18, delays=0.04/0/0/0.14, dsn=2.0.0, status=sent (delivered to mailbox)

Qué significa: Los informes se entregan localmente; tu problema de pipeline (si hay) es posterior a la entrega.

Decisión: Si ves rebotes o rechazos aquí, arregla el enrutamiento/los límites de tamaño de correo primero. Un programa DMARC sin informes es básicamente monitoreo con las baterías quitadas.

Guía rápida de diagnóstico

Cuando alguien te dice “DMARC está fallando” o “Nos están suplantando”, necesitas un camino corto a la claridad. Aquí está el orden que minimiza el tiempo para llegar a la verdad.

Primero: confirma si es suplantación o autodaño

1. Revisa la política DMARC y las configuraciones de alineación en DNS. Si estás en p=none, mayormente estás observando, no bloqueando.
2. Desde los informes agregados, lista las IPs principales que fallan por conteo y disposición. Volumen alto + SPF y DKIM fallando suele significar intentos de suplantación.
3. Mapea las IPs que fallan a remitentes conocidos. Si una IP fallida es tu ESP/CRM, probablemente tengas un problema de alineación, no un atacante.

Segundo: aisla el mecanismo que falla (SPF vs DKIM vs alineación)

1. Si DKIM pasa pero DMARC falla, suele ser alineación DKIM (valor d= equivocado) o que el From es distinto de lo que crees (subdominio vs dominio raíz).
2. Si SPF pasa pero DMARC falla, suele ser alineación SPF (el dominio Return-Path difiere) o estás autenticando un dominio distinto al From visible.
3. Si ambos fallan, sospecha suplantación, rotura por reenvío o un remitente totalmente sin configurar.

Tercero: decide el camino de mitigación

• Remitente legítimo fallando: arregla la firma DKIM y/o configura un dominio de rebote personalizado para la alineación SPF; luego revisa informes durante 24–48 horas.
• Remitente desconocido (probable suplantación): sigue recogiendo evidencia (mezcla de receptores, rangos de IP, volúmenes) y mueve la política hacia quarantine/reject una vez que el tráfico legítimo esté limpio.
• Ruptura por reenvíos/listas de correo: evalúa soporte ARC y considera usar DKIM como mecanismo alineado principal en lugar de SPF.

Tres mini-historias corporativas desde las trincheras

Mini-historia 1: El incidente causado por una suposición equivocada

La compañía tenía una configuración que parecía limpia: SPF, DKIM y DMARC. El equipo de seguridad estaba orgulloso; TI estaba cansado; marketing era felizmente ignorante de ambos.

Asumieron que su plataforma CRM “manejaba DKIM” porque una casilla lo decía. Firmaba correo—pero no con el dominio de la empresa. El DKIM d= era el dominio del proveedor. SPF también “pasaba”, pero con el Return-Path del proveedor. Así que el correo se autenticó, pero no se alineó con el From visible. DMARC falló silenciosamente porque la política era p=none.

Luego pasaron a p=quarantine en un solo cambio porque “hemos estado monitoreando por meses.” Monitoreo, sí. Leer los informes, no. Un grupo de correos legítimos del ciclo de vida del cliente comenzó a llegar a spam. Ventas lo notó primero, como siempre, en forma de pipeline que misteriosamente se ralentizó.

La solución fue simple pero molesta: configurar el CRM para firmar DKIM con d=example.com usando un selector que controlaran, y establecer un dominio de rebote personalizado para que SPF también se alineara. La lección real: “autenticación pasando” no es lo mismo que “DMARC pasando.” Esa suposición cuesta dinero.

Mini-historia 2: La optimización que salió mal

Otra organización tenía un registro SPF que parecía un árbol de Navidad: includes para cada herramienta que alguna vez envió correo en su nombre. Les dijeron que SPF tiene un límite de 10 búsquedas DNS, así que un ingeniero decidió “optimizar” aplanando SPF a una larga lista de IPs generada cada noche.

Al principio funcionó. Las búsquedas bajaron. El correo pasaba. Todos siguieron con su trabajo.

Luego la contra: un proveedor rotó sus IPs. El trabajo nocturno no recogió el cambio por un fallo DNS transitorio durante la construcción. Por el día siguiente, una porción significativa del correo falló SPF en los receptores. DKIM debería haberlos salvado, pero ese proveedor no firmaba con DKIM alineado. DMARC falló. La cuarentena aumentó. Llegaron tickets de soporte.

Revirtieron el aplanado y construyeron un enfoque más seguro: consolidar proveedores, mantener SPF simple y forzar DKIM alineado en todas partes para que SPF no sea el único punto de fallo de entregabilidad. Optimizar está bien. Optimizar sin modelar fallos es arte performático.

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

Un negocio regulado administraba DMARC como un programa de operaciones, no como una casilla para marcar. Tenían una revisión semanal: principales fuentes, fuentes nuevas, fallos por receptor y una breve lista de decisiones “autorizar o bloquear”. También mantenían un inventario vivo de todos los sistemas autorizados para enviar correo como el dominio, con propietario, propósito y mecanismo de autenticación.

Un lunes, el informe mostró un rango de IP nuevo enviando un pequeño número de mensajes con el From de la compañía, todos fallando SPF y DKIM. El volumen no era enorme; no habría activado las alarmas habituales de “caída de correo”. Pero la fuente nueva destacó porque la línea base era limpia y estable.

Contactaron a su equipo de seguridad con evidencia: org del receptor, IP de origen, header_from y conteos. Seguridad lo correlacionó con reportes de clientes sobre una campaña de phishing dirigida a nóminas. Como la política DMARC ya era p=reject, los receptores que cumplen rechazaron el correo. El radio de la campaña quedó limitado a sistemas marginales y capturas de pantalla reenviadas por empleados vigilantes.

No hubo heroísmos. No hubo war room. Solo monitoreo aburrido y un dominio que ya había ganado aplicación. Esto es lo que parece la “madurez operativa”: menos historias excitantes.

Broma #2: Los informes DMARC son los únicos correos que recibirás que se quejan de otros correos que envían correos.

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

1) Síntoma: DMARC falla, pero SPF muestra “pass” en los informes

Causa raíz: SPF pasa para el dominio del sobre, pero no se alinea con el dominio Header From (dominio de rebote del proveedor).

Solución: Configura un Return-Path / dominio de rebote personalizado bajo tu dominio con el proveedor, o apóyate en DKIM alineado. Verifica la alineación en los informes antes de endurecer la política.

2) Síntoma: DKIM pasa, pero DMARC aún falla

Causa raíz: El dominio de firma DKIM (d=) no se alinea con el Header From (el proveedor firma con su propio dominio).

Solución: Configura firma DKIM con tu dominio y publica los registros TXT del selector requeridos. Confirma enviando un correo de prueba y revisando cabeceras en un buzón que controles.

3) Síntoma: Pico repentino de permerror de SPF

Causa raíz: SPF excedió límites de búsquedas DNS por demasiados includes/redirects, o sintaxis SPF malformada.

Solución: Reduce includes, elimina proveedores obsoletos y fuerza DKIM alineado para que SPF no sea tu único método alineado. Valida SPF con un linter en CI.

4) Síntoma: Todo funciona excepto cuando los destinatarios están en un proveedor específico

Causa raíz: Peculiaridades de cumplimiento del receptor, políticas locales o diferencias en cómo se trata el reenvío/ARC.

Solución: Segmenta informes por org_name del receptor. Para el receptor problemático, verifica si el reenvío es común y si tu correo está DKIM-alineado (más resiliente que SPF).

5) Síntoma: Fallos DMARC solo para tráfico de listas de correo

Causa raíz: Las listas modifican mensajes (rompiendo DKIM) y reenvían desde su propia infraestructura (rompiendo la alineación SPF).

Solución: Prefiere firmas DKIM que sobrevivan modificaciones esperadas cuando sea posible, y evalúa receptores conscientes de ARC. Operativamente, acepta algunos fallos para listas o usa estrategias de subdominio.

6) Síntoma: Nunca recibes informes DMARC

Causa raíz: Dirección rua incorrecta, buzón que rechaza adjuntos grandes, MX faltante o el proveedor requiere verificación para direcciones de reporte externas.

Solución: Asegúrate de que el buzón exista, acepte correos grandes y sea enrutable. Considera usar un subdominio y una infraestructura de buzón dedicada para reportes DMARC.

7) Síntoma: Los informes muestran tus propias IPs salientes fallando SPF

Causa raíz: El registro SPF no incluye las IPs reales de envío (nuevo MTA, nuevo relay o tráfico movido a un proveedor cloud).

Solución: Actualiza includes/IPs de SPF, pero también despliega DKIM alineado para que una falla SPF no se convierta en un incidente de entregabilidad.

8) Síntoma: Recuentos duplicados o inconsistentes entre receptores

Causa raíz: Diferentes receptores muestrean diferente, agregan distinto o atribuyen fuentes de forma distinta (especialmente en infraestructuras compartidas grandes).

Solución: Usa informes para tendencias y detección de fuentes nuevas, no para contabilidad exacta. Correlaciona con tus registros de envío para conteos precisos.

Listas de verificación / plan paso a paso

Paso a paso: construir un flujo de trabajo de reportes DMARC que no se pudra

1. Crea direcciones dedicadas para reportes (agregados y forenses opcional) y ponlas detrás de un sistema de buzón que controles. No vuelques informes en el buzón personal de alguien.
2. Automatiza la ingestión: extrae adjuntos, descomprime, guarda XML crudo, parsea a datos estructurados (tablas o JSON) y conserva los originales por tiempo limitado.
3. Etiqueta cada registro con receiver org_name, report_id, date range, header_from, source_ip y resultados de política.
4. Mantén un inventario de remitentes: cada remitente legítimo (MTAs, plataformas SaaS, sistemas de ticketing, herramientas de monitoreo), propietario y si usa DKIM alineado o SPF alineado.
5. Baselínea y alerta sobre:
   • IPs nuevas
   • Dominios/subdominios header_from nuevos
   • Tasa de fallos DMARC por receptor
   • Cualquier aumento en disposiciones de quarantine/reject
6. Arregla la alineación primero, luego endurece la política. Si intentas aplicar antes de estar alineado, tu equipo de entregabilidad inventará nuevas palabras para describirte.
7. Despliega la aplicación gradualmente: p=quarantine; pct=10 luego 25/50/100, luego considera p=reject con otra rampa.
8. Configura retención y controles de acceso para los informes, especialmente si habilitas reportes forenses. Trátalos como telemetría sensible.
9. Realiza una revisión semanal con seguridad + propietario de mensajería: principales fallos, fuentes nuevas, cambios de proveedores y decisiones pendientes de autorización.

Checklist operativo: cuando añades un nuevo proveedor que envía correo

• Confirma si el proveedor puede firmar DKIM con d=yourdomain. Si no, piénsalo dos veces antes de permitirles enviar como tú.
• Publica los selectores DKIM que provean, con control de cambios y propiedad.
• Configura dominio de rebote personalizado (para alineación SPF) si está soportado.
• Envía mensajes de prueba a múltiples proveedores de buzón y verifica que las cabeceras muestren pass alineado.
• Observa los informes DMARC durante 48 horas tras la activación; revisa fallos de alineación e IPs inesperadas.
• Documenta el remitente en el inventario: propietario, propósito, dominios From esperados, selectores y camino de escalación de soporte.

Checklist de gestión de cambios: pasar de p=none a enforcement

• Lista todas las fuentes legítimas conocidas de los últimos 30 días de informes agregados.
• Para cada fuente, asegura al menos un mecanismo alineado (DKIM preferido) que pase consistentemente.
• Confirma que SPF está bajo límites de búsquedas y no depende de aplanados frágiles.
• Empieza con p=quarantine con un pct bajo y alerta sobre cambios en la tasa de cuarentena.
• Sólo mueve a p=reject después de que la cuarentena sea estable y los fallos legítimos estén casi a cero.

Preguntas frecuentes

1) ¿Necesito que SPF y DKIM pasen ambos para que DMARC pase?

No. DMARC pasa si SPF o DKIM pasa y se alinea con el dominio Header From. En la práctica, apunta a tener DKIM alineado en todas partes y trata SPF como útil pero más frágil.

2) ¿Por qué los informes DMARC muestran “pass” para DKIM pero “fail” para DMARC?

Porque DKIM puede pasar criptográficamente mientras falla la alineación. Si la firma DKIM usa d=vendor.com y tu From es example.com, DMARC falla.

3) ¿Los informes agregados DMARC son en tiempo real?

No. Son resúmenes periódicos, generalmente diarios. Úsalos para tendencias y detección de fuentes nuevas, no para respuesta a incidentes minuto a minuto.

4) ¿Debemos habilitar informes forenses (RUF)?

Sólo si puedes manejar las implicaciones de privacidad y retención y tienes una necesidad investigativa específica. Muchos proveedores no los enviarán, y los que lo hacen pueden incluir contenido sensible.

5) Si publicamos p=reject, ¿la suplantación se detendrá en todas partes?

Reducirá la suplantación directa en receptores que respeten DMARC. Los atacantes aún pueden usar dominios parecidos, cuentas comprometidas o canales fuera del correo. DMARC es necesario, no suficiente.

6) ¿Por qué el reenvío rompe la autenticación?

SPF se comprueba contra la IP remitente; el reenvío cambia la IP remitente. DKIM puede romperse si los intermediarios modifican el mensaje (cabeceras o cuerpo). ARC puede ayudar a algunos receptores a entender el estado de autenticación original.

7) ¿Cuál es la forma más rápida de detectar una nueva campaña de suplantación en los informes agregados?

Busca IPs nuevas que envíen tu dominio Header From con ambos SPF y DKIM fallando, especialmente si los conteos suben rápido o aparecen en múltiples orgs de receptores.

8) Tenemos muchos subdominios. ¿Cómo debe DMARC manejarlos?

Decide si los subdominios pueden enviar correo y publica registros DMARC explícitos para ellos cuando sea necesario. Si ignoras subdominios, eventualmente descubrirás que alguien más los está “usando”.

9) ¿Por qué los recuentos de informes DMARC son distintos a nuestros logs de salida?

Los receptores agregan de forma diferente, muestrean y pueden excluir cierto correo. Tus logs son la verdad del lado del remitente; los informes son observaciones del receptor. Usa ambos; no esperes igualdad perfecta.

10) ¿Puedo usar informes DMARC para encontrar a todos los proveedores terceros que envían correo?

Puedes encontrar muchos, especialmente los que envían con volumen y llegan a los grandes receptores. Pero aún necesitas disciplina en compras/procesos porque algún correo nunca llega a los receptores que te reportan.

Conclusión: siguientes pasos que no desperdician un trimestre

Los informes DMARC no son un artefacto de cumplimiento. Son una señal operativa. Si los tratas como logs—ingerir, parsear, baselinar, alertar—captarás suplantaciones y malas configuraciones temprano, cuando la solución es un correo al proveedor en lugar de un incidente de marca.

Haz esto a continuación:

1. Verifica tu registro DMARC y asegúrate de que los informes agregados realmente estén llegando.
2. Construye un inventario de remitentes y mapea cada IP de envío significativa en los informes a un propietario.
3. Arregla la alineación para remitentes legítimos (preferir DKIM alineado), luego escala la política de none → quarantine → reject con etapas pct.
4. Configura alertas para fuentes nuevas y aumentos en tasas de fallo, y revisa semanalmente con seguridad.

Si quieres que el correo sea aburrido—y lo quieres—haz que los reportes DMARC también lo sean. Aburrido significa que tienes el control.