El registro DMARC se publicó hace un mes. La dirección rua apuntaba a un buzón real, y ese buzón ya acumula cuarenta archivos comprimidos. Cada uno trae una página de XML. Nadie abrió el segundo.
Así encontramos a la mayoría de las empresas pequeñas, y no es por descuido. El reporteo funciona. La lectura nunca empieza, porque el formato se escribió para máquinas. Imagina un despacho contable de doce personas: las facturas salen del sistema contable, las campañas de una herramienta de marketing y el correo diario de Google Workspace. Los reportes conocen a los tres remitentes. El equipo no.
No hace falta aprender el XML para sacar la respuesta. Este es el camino corto que seguimos en el dominio de un cliente: qué contiene el archivo, cómo convertir uno en una lista legible en un minuto, los tres veredictos que salen de esa lista y qué te cuesta cada uno si lo dejas pasar.
Qué trae el archivo en realidad
Un reporte agregado es un conteo, no una copia. El receptor agrupa todos los mensajes que vio diciendo ser de tu dominio por IP de origen y por resultado de autenticación, y te manda los totales del período. Sin asuntos, sin destinatarios, sin cuerpos de mensaje.
El formato tiene su propia especificación. El RFC 9990, publicado en mayo de 2026 en la vía de estándares, cubre el reporteo agregado; junto con el RFC 9989 y el RFC 9991 reemplazó al RFC 7489, que fue la referencia desde 2015. Según el RFC 9990, cada registro lleva un elemento row con la source_ip que conectó, un count de mensajes y un bloque policy_evaluated con la disposición y los resultados de DKIM y SPF, además de identifiers y auth_results.
Los reportes llegan porque tu registro publicado los pidió:
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"La ayuda de administrador de Google Workspace lo dice sin rodeos: los reportes se envían normalmente una vez al día, por correo, a las direcciones del registro, y cada servidor que recibe correo de tu dominio manda el suyo. Por eso se llena el buzón. Un dominio con volumen real recibe reportes de proveedores de los que nunca oyó hablar. Apunta rua a un grupo, no a la persona que un día se va de la empresa.
Si quieres el XML explicado elemento por elemento, lo escribimos aparte: cómo leer un reporte agregado de DMARC. Para la decisión de hoy puedes saltártelo.
Convierte un reporte en una lista legible
Toma el adjunto más reciente del receptor al que le mandas más correo. Será un archivo .xml, .xml.gz o .zip. Súbelo o pégalo, y lee la lista que sale en lugar del marcado.
Nuestro analizador de reportes DMARC es gratis y no pide registro. Descomprime y procesa el archivo en tu navegador, en memoria, y te muestra la política que publicaste de verdad, el volumen total del reporte, tu tasa de aprobación DMARC, cada fuente de envío ordenada por volumen y, lo más importante, cuáles remitentes que parecen legítimos no están alineados y quedarían en cuarentena o rechazados el día que actives la aplicación de la política.
Las tres columnas que deciden todo
Sea cual sea la herramienta, estás leyendo tres cosas por fila.
- Fuente. La IP que conectó, y casi siempre un dueño reconocible detrás: tu proveedor de correo, una plataforma de marketing, un hosting, algo que no ubicas.
- Alineación de SPF. No solo si SPF pasó, sino si el dominio para el que pasó coincide con el dominio de tu encabezado From.
- Alineación de DKIM. La misma pregunta aplicada a la firma del mensaje.
La distancia entre pasó y alineado es donde se pierde la tarde. El RFC 9989 define dos modos: la alineación relajada exige que los dos dominios compartan el dominio organizacional, y la estricta que sean idénticos. Las etiquetas adkim y aspf vienen en relajado por defecto, así que sin tocarlas tienes la versión indulgente y aun así no es automático.
DMARC pasa cuando al menos uno de SPF o DKIM pasa y está alineado. Las guías para remitentes de Google dicen lo mismo para el correo masivo hacia Gmail: hay que configurar SPF y DKIM, pero basta con que uno de los dos alinee. Una fila con SPF en pass y sin alineación es una fila que falla.
Los tres veredictos, y lo que cuesta cada uno
Alineado y pasando
Tu propio proveedor, casi siempre el bloque más grande de volumen. Nada que hacer. Anota el volumen para saber cómo se ve lo normal el mes que viene.
Legítimo, pero sin alinear
Aquí está el trabajo, y casi siempre es el mismo reparto: el sistema de facturación, el CRM, la mesa de ayuda, la herramienta de boletines, la tienda en línea, la impresora de la oficina que manda escaneos. Envían con tu dominio usando su propia autenticación, que pasa para el dominio de ellos y no para el tuyo.
El arreglo es remitente por remitente y vive en el panel del proveedor, no en un solo cambio de DNS. La mayoría de las plataformas ofrecen un return path personalizado o un par de registros CNAME de DKIM para publicar; a algunas conviene moverlas a un subdominio dedicado para que su reputación no se mezcle con tu correo diario. Cada remitente que dejes sin alinear es una categoría de correo que deja de llegar el día que endurezcas la política. Ese es el costo real de no leer los reportes.
Sin autenticar y ajeno a ti
IPs dispersas, conteos pequeños, ninguna autenticación que coincida con algo tuyo. Parte es suplantación y parte es ruido viejo de listas y rastreadores. Esto no se arregla en DNS, porque no hay nada tuyo que arreglar. Lo que lo detiene es la aplicación de la política, que es justamente el objetivo del ejercicio.
Las filas que te engañan una vez
El reenvío es la falsa alarma de siempre. Cuando un mensaje pasa por un alias o una lista de correo, el servidor que reenvía conecta desde su propia IP, así que SPF se rompe, mientras la firma DKIM suele sobrevivir intacta. La fila se ve alarmante y es un reenviador haciendo su trabajo. Si DKIM sigue alineado, DMARC sigue pasando.
Un reporte es la vista de un receptor sobre un día, no tu tráfico. Un cien por ciento de aprobación en un domingo tranquilo no dice nada. Y las filas de conteo bajo con IPs desconocidas merecen una mirada, pero rara vez un susto: la señal es el volumen.
De un archivo a un inventario de remitentes
El entregable de este ejercicio no es un reporte limpio. Es una lista accionable, y sale de una o dos semanas de reportes, no de uno.
- Junta reportes de al menos una semana para que aparezcan los días tranquilos y las corridas de facturación mensual.
- Anota cada fuente con su volumen, y marca si alinea SPF, si alinea DKIM o si no alinea ninguno.
- Clasifica en tres cubetas: se queda como está, hay que alinear, y no es nuestro.
- Dale un responsable y una fecha a cada remitente de la cubeta de alinear. Alguien tiene que entrar a ese panel del proveedor.
Esa lista es lo primero que construimos en cada proyecto de entregabilidad, porque no puedes endurecer con seguridad una política que no inventariaste.
Cuándo mover la política
Quédate en p=none hasta que cada remitente legítimo del inventario alinee por SPF o por DKIM. Luego pasa a cuarentena, observa una semana completa de reportes y solo entonces rechaza. El orden y el despliegue por porcentaje los explicamos en cómo pasar DMARC de p=none a p=reject.
Vale la pena saberlo si envías con volumen: desde el 1 de febrero de 2024, quien manda más de 5,000 mensajes al día a cuentas de Gmail debe tener SPF, DKIM y un registro DMARC, y mantener la tasa de spam que reporta Postmaster Tools por debajo del 0.3%. La política puede quedarse en none para cumplir ese mínimo, así que leer tus reportes no es cuestión de aprobar una auditoría. Es saber qué se rompe antes de decidir endurecer.
Cómo ayuda Guanacos Tech
Hacemos esto en dominios de clientes casi todas las semanas: juntar quince días de reportes, armar el inventario de remitentes, alinear los que valen la pena y mover la política por etapas observando qué cambia. Si tienes un buzón de XML sin abrir, o ya los leíste y quieres un segundo par de ojos antes de endurecer, de eso se trata nuestra consultoría de entregabilidad de correo. Una llamada corta basta para saber si tu inventario está limpio o si algo se rompería el día que actives la política.