Cómo leer reportes DMARC XML y corregir outbound B2B

DMARC permite que el dueño de un dominio publique una política en DNS y solicite feedback agregado mediante la etiqueta rua. Según RFC 7489, ese feedback busca mostrar resultados de autenticación, acciones correctivas y el efecto de la política sobre los flujos que procesan los receptores.

El reporte suele llegar como XML —a menudo comprimido— y agrupa mensajes por características como IP de origen y resultado. No contiene el texto del correo ni una lista de destinatarios. Tampoco es un reporte de campaña: no te dirá si el asunto funcionó, si hubo interés o si se creó pipeline.

Hay otra limitación importante. El volumen observado en DMARC no debe presentarse como el total exacto enviado: la cobertura depende de los receptores que generan y entregan reportes. Úsalo para autenticar e inventariar flujos, no como sustituto de los eventos del secuenciador.

Un registro básico de monitoreo puede verse así: v=DMARC1; p=none; rua=mailto:dmarc@ejemplo.com. La etiqueta rua solicita reportes agregados. RFC 7489 establece que, si no se proporciona, los receptores no deben generar ese feedback; también fija 86,400 segundos como intervalo solicitado predeterminado y exige soporte para reportes diarios.

Google recomienda usar un buzón o grupo dedicado porque una organización puede recibir desde varios hasta cientos o miles de reportes al día. Si rua apunta a otro dominio, hace falta autorización adicional en DNS del dominio receptor. Enviar los adjuntos al inbox personal del fundador funciona hasta el día en que deja de funcionar, normalmente sin ceremonia.

Mantén cada dominio de envío en el inventario de dominios e inboxes con su registro DMARC, destino rua, proveedor, responsable y fecha de última revisión. La guía de inventario está enlazada al final. Un reporte sin propietario se convierte pronto en decoración XML.

report_metadata identifica a la organización que generó el reporte, el report_id y el periodo date_range. Confirma estos datos primero para evitar duplicar archivos o sumar dos veces el mismo intervalo.

policy_published registra la política que el receptor observó: domain, p, sp, pct y modos de alineación adkim y aspf. Si no coincide con lo que crees haber publicado, revisa DNS, caché, selector de dominio y fecha del reporte antes de diagnosticar el sender.

row contiene source_ip, count y policy_evaluated. Source_ip es la IP que se conectó con el receptor; count es la cantidad de mensajes representados por esa fila; disposition muestra none, quarantine o reject. Los resultados dkim y spf dentro de policy_evaluated resumen la evaluación usada por DMARC.

identifiers muestra dominios del mensaje, incluido header_from, la identidad visible sobre la que DMARC centra su evaluación. auth_results desglosa los dominios y resultados observados para SPF y DKIM. Esta separación ayuda a distinguir un mecanismo técnicamente válido de uno alineado con el From visible.

Una fila no equivale a un correo. Si una fila con pass tiene count=2 y otra con fail tiene count=2,000, el problema no está “mitad y mitad”: está concentrado en casi todo el volumen observado. Suma count por combinación de source_ip, header_from, resultado y disposition.

Construye al menos cuatro totales: mensajes observados, mensajes con DMARC pass, mensajes con fail desde fuentes autorizadas y mensajes desde fuentes desconocidas. Conserva también el receptor y el periodo para no mezclar ventanas con cobertura diferente.

La tasa operativa puede expresarse como mensajes con pass divididos entre mensajes observados en los reportes recibidos. Etiquétala como “sobre volumen reportado”, no como tasa universal de entrega. DMARC no concede privilegios de inbox y RFC 7489 dice expresamente que autenticar no produce trato elevado de entrega.

Primero mira header_from: ¿es el dominio que realmente querías usar? Después cruza source_ip y los dominios de auth_results con tu inventario de Google Workspace, Microsoft 365, CRM, formularios, soporte, facturación, marketing y secuenciadores. No declares una IP “maliciosa” solo porque no la reconociste de memoria.

Luego revisa SPF y DKIM. DMARC pasa cuando al menos uno de esos mecanismos pasa y está alineado con el dominio del From visible. Eso significa que SPF fail y DKIM pass alineado puede producir DMARC pass, y viceversa. Conviene tener redundancia, pero la reparación debe partir del mecanismo y dominio exactos.

Por último observa disposition y cualquier policy override. Un receptor puede aceptar un mensaje que falló por razones locales, por forwarding o por ARC. Esa excepción es contexto; no convierte un fail recurrente de una fuente autorizada en configuración sana.

Fuente autorizada, DMARC pass y volumen esperado. Marca el flujo como conocido y compáralo contra su rango normal. No requiere cambio inmediato. Sí requiere propietario, porque una integración correcta hoy puede cambiar de IP, selector o dominio de retorno.

Fuente autorizada, DMARC pass por un solo mecanismo. Revisa el mecanismo que falla. Quizá el Return-Path no está alineado para SPF o DKIM firma con un dominio ajeno. El envío puede pasar, pero una segunda ruta alineada reduce fragilidad ante cambios o forwarding.

Fuente autorizada, DMARC fail. Pausa cualquier endurecimiento de política que pueda afectar ese flujo. Corrige autorización SPF, firma DKIM, selector o alineación con header_from; después valida en headers reales y en reportes posteriores. Las guías de SPF, DKIM y DMARC y de diagnóstico de headers enlazadas al final cubren la configuración base y el análisis de un mensaje individual.

Fuente desconocida usando tu dominio. Confirma que no sea un SaaS olvidado, un servidor transaccional o un forwarder. Si sigue sin autorización, clasifícala como spoofing probable o abuso. DMARC ayuda contra suplantación exacta del dominio; no resuelve dominios visualmente parecidos ni valida la legitimidad del contenido.

Google recomienda comenzar con p=none durante una semana, revisar los reportes diariamente y, si no aparecen problemas, pasar quarantine a un porcentaje pequeño. Su ejemplo usa pct=5; la guía también señala que una organización pequeña podría empezar con 10% y una grande con 1%. Después propone aumentar gradualmente hasta 100% y, cuando corresponda, usar reject.

Una semana es una recomendación inicial de Google, no una ley universal. Si tienes campañas mensuales, sistemas de facturación esporádicos, múltiples regiones o remitentes de temporada, amplía la ventana hasta observar todos los flujos legítimos. La política debe cubrir el ciclo real del correo, no el calendario más cómodo.

Antes de cada cambio registra: porcentaje de pass sobre volumen reportado, fuentes autorizadas con fail, fuentes desconocidas, dominios afectados y responsable de rollback. Reject sin inventario puede bloquear correo legítimo. p=none perpetuo, en cambio, observa la suplantación sin pedir al receptor que la frene.

Los dominios de outbound suelen multiplicar remitentes, inboxes y proveedores. Esa separación puede contener riesgo reputacional, pero no elimina la obligación de autenticarlos y monitorearlos. Cada dominio visible en From necesita una política coherente y una ruta de reportes que alguien revise.

Cuida también los subdominios. La etiqueta sp define la política solicitada para subdominios cuando no existe una política específica; si no la usas, los subdominios heredan la política del dominio organizacional según la configuración aplicable. Documenta cuándo heredas y cuándo publicas un registro independiente.

No combines el análisis de autenticación con el de rebotes. DMARC responde “¿quién usó mi dominio y cómo autenticó?”. Los códigos SMTP responden por qué un intento concreto fue rechazado temporal o permanentemente; la guía está enlazada al final. Ambos diagnósticos se cruzan, pero no son intercambiables.

Un tablero útil no necesita veinte widgets. Necesita volumen reportado por dominio y receptor; porcentaje de DMARC pass sobre ese volumen; top fuentes autorizadas con fail; top fuentes desconocidas por count; disposition observada; y antigüedad del último reporte recibido.

Añade una cola de acciones con cuatro campos: fuente, hipótesis, evidencia y siguiente prueba. “IP desconocida” no es una conclusión. “IP no aparece en inventario, firma con dominio X y comenzó después de activar proveedor Y” sí es una hipótesis verificable.

Evita fijar un umbral universal de pass. El objetivo para flujos controlados debe ser eliminar fallas legítimas, pero la cobertura y las excepciones varían por receptor. Decide el cambio de política cuando puedas explicar el volumen relevante, no cuando el dashboard se vea suficientemente verde.

Minutos 0–5: confirma report_id, receptor, date_range, header_from y count. Minutos 5–10: agrupa por source_ip y compara contra inventario. Minutos 10–15: revisa auth_results para separar fallo técnico de falta de alineación.

Minutos 15–20: toma un mensaje real del flujo autorizado y revisa Authentication-Results, Return-Path y DKIM-Signature. Minutos 20–25: determina si el cambio coincide con una nueva integración, selector, dominio o política. Minutos 25–30: asigna corrección, limita envíos si el flujo está roto y define la evidencia necesaria para cerrar el incidente.

No cambies SPF, DKIM y DMARC a la vez. Una modificación por hipótesis conserva causalidad. También evita que el equipo celebre una mejora cuyo origen nadie puede explicar.

picos.Ai puede integrar reportes DMARC, inventario de dominios, eventos del secuenciador y señales de rebote en una misma rutina de control. El objetivo no es coleccionar XML: es detectar fuentes nuevas, priorizar fallas por volumen y endurecer políticas sin romper correo legítimo.

Si tus dominios envían desde varias herramientas y nadie puede explicar el mapa completo, usa el enlace Hablemos al final de esta página para pedir una revisión con picos.Ai. Empezamos por inventario y evidencia; la automatización viene después.