DMARC RUA indica en tu registro DMARC dónde solicitar informes agregados a los destinatarios. Sin ese destino, la política puede existir, pero pierdes una fuente de información sobre autenticación y alineación. Los informes son parciales: no identifican automáticamente todos los servicios ni demuestran suplantación por sí solos. Para revisar las bases, empieza por correo empresarial para pequeñas empresas.
Un CRM mal configurado, un complemento WordPress olvidado o un reenvío que afecta a SPF pueden complicar el diagnóstico. RUA aporta datos para investigar esas situaciones, sin explicar por sí solo todas las decisiones de filtrado de Gmail.
Esta guía explica qué es RUA, cómo publicarlo, qué significan los informes XML y cómo priorizar las correcciones.
Qué es DMARC RUA
RUA es la etiqueta que indica el destino solicitado de los informes agregados de autenticación. Resumen SPF, DKIM, alineación, IP de origen y disposición durante un periodo, habitualmente diario, para el tráfico de destinatarios participantes.
En un registro DMARC, rua=mailto:... solicita enviar allí los informes agregados. Según RFC 7489, rua especifica destinos de información sobre autenticación, alineación, dominios, cantidad de mensajes y política aplicada.
Observar tráfico ayuda a evaluar p=none, p=quarantine o p=reject. RUA aporta evidencia, pero no demuestra que todos los emisores legítimos estén preparados para una política restrictiva.
Qué muestran realmente los informes RUA
Son resúmenes agregados, no copias de mensajes. Muestran fuentes observadas, autenticación SPF y DKIM y alineación DMARC. Distingue los resultados de autenticación sin procesar de los evaluados para la política, que incorporan la alineación.
No recibes cuerpos de mensajes, sino datos útiles para investigar proveedores, alineación y posible abuso. Compleméntalos con inventario y pruebas.
| Etiqueta | Función | Datos | Uso habitual |
|---|---|---|---|
rua | Solicita informes agregados | Resúmenes XML por IP y autenticación | Supervisión y evaluación de políticas |
ruf | Solicita informes de fallos | Muestras de mensajes cuando se admite | Diagnóstico específico |
Conviene empezar por RUA y valorar ruf solo para necesidades concretas. Los informes forenses tienen soporte irregular y plantean más cuestiones de privacidad.
Ejemplo: envías por Google Workspace, una aplicación de facturación y soporte. RUA puede mostrar fuentes observadas de esos servicios, sin garantizar que aparezcan todos. Un fallo de alineación requiere investigación; la ubicación de una IP en otro país no demuestra suplantación.
Cómo publicar RUA
Añade un TXT en _dmarc.yourdomain.com con un destino válido rua=mailto:. Si todavía no conoces todos tus emisores, empieza por supervisión.
Este ejemplo incluye alineación estricta opcional, que puede afectar a subdominios legítimos y no es la opción inicial más adecuada para todos:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s"Esta alternativa mínima utiliza la alineación relajada predeterminada; publica solo un registro, no ambos:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"Utiliza un buzón dedicado o un servicio de análisis. Evita mezclar informes XML comprimidos con la bandeja habitual de soporte.
Para TrekMail, consulta Registros DNS necesarios. Las comprobaciones disponibles de SPF, DKIM y DMARC ayudan a revisar la configuración, pero no garantizan detectar todos los errores o emisores externos.
Cómo verificar RUA
Consulta DNS directamente y después revisa la recepción de informes. Un registro incorrecto puede impedir que los destinatarios participantes obtengan un destino válido; un buzón vacío también puede tener otras causas.
Utiliza dig o nslookup:
dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.comLa respuesta debería mostrar tu TXT DMARC. Según RFC 7489, este es otro ejemplo válido, no un registro adicional que debas publicar junto a los anteriores:
"v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com"Los informes suelen enviarse a diario, pero el calendario y la participación varían. La ausencia de informes no demuestra ausencia de tráfico ni confirma por sí sola un error DNS.
Cómo leer un informe RUA
Revisa origen, SPF, DKIM, alineación y disposición. La autenticación válida debe combinarse con alineación para contribuir a DMARC; por sí sola no demuestra que el mensaje sea legítimo o seguro.
Una secuencia útil es:
- Revisa IP y DNS inverso, y contrástalos con tus proveedores: PTR no demuestra identidad ni legitimidad.
- Valora volumen y criticidad: una fuente con 2 mensajes puede ser esencial aunque otra envíe 20,000.
- Comprueba autenticación y alineación SPF/DKIM. Un resultado válido no alineado puede no servir para DMARC.
- Revisa disposición:
noneno demuestra entrega o modo de supervisión;quarantineno identifica una carpeta fija;rejectno garantiza bloqueo. - Investiga si la fuente es conocida, está mal configurada, es un intermediario o constituye abuso.
Google exige SPF o DKIM para remitentes generales a cuentas personales de Gmail; para remitentes masivos, ambos y DMARC con la alineación aplicable al From: visible. RUA ayuda a localizar problemas en tráfico observado, sin garantizar la bandeja de entrada.
Tres patrones que merece la pena investigar
Los informes pueden revelar emisores legítimos sin autenticar, reenvíos y posible suplantación, pero también relays compartidos u otras rutas. Investiga antes de clasificarlos o bloquearlos.
1. Emisor legítimo mal configurado
Un servicio puede enviar con tu dominio sin SPF o DKIM válidos y alineados. Para DMARC basta que uno pase alineado; corrige el emisor y prueba su configuración antes de cambiar la política.
En TrekMail, sigue las instrucciones correspondientes a la ruta real. Para un proveedor externo, consulta SMTP propio. Con envío incluido en el plan, consulta Managed TrekMail SMTP y verifica la firma disponible y su alineación.
2. SPF falla por un reenvío
Puede ocurrir porque conecta el servidor reenviador. No prueba que el mensaje sea malicioso. Si DKIM conserva los datos firmados según su canonicalización, pasa y está alineado, DMARC pasa. Comprueba esa ruta en vez de descartar todos los fallos SPF automáticamente.
Consulta reenvío de correo y reenviar correo de dominio a Gmail. Distinguir el fallo SPF del resultado DMARC evita cambios innecesarios.
3. Fuente desconocida o posible suplantación
Una IP o un proveedor no reconocido exige investigación: puede ser un servicio olvidado, un relay compartido o un reenvío. No lo autorices en SPF ni lo bloquees sin identificarlo. Valora restricciones después de comprobar tus fuentes legítimas.
¿Conviene utilizar un servicio externo para RUA?
Puede facilitar el análisis, pero debes comprender su configuración DNS y tratamiento de datos. Los destinos externos requieren la autorización correspondiente para que los generadores participantes los acepten.
Según RFC 7489, cuando el destino rua está fuera de tu dominio organizativo, el dominio que recibe informes debe publicar la autorización en un nombre como este:
example.com._report._dmarc.thirdparty.example.net. IN TXT "v=DMARC1"Sin la confirmación requerida, algunos generadores ignoran el destino externo. Sigue las instrucciones exactas del analizador y comprueba que la autorización exista en el DNS del destino.
Cuándo pasar de p=none a quarantine o reject
Usa los datos junto con inventario y pruebas. Los fallos observados deben investigarse antes de solicitar restricciones; unos informes favorables no demuestran que todos los flujos legítimos estén cubiertos.
Una ruta orientativa es:
- Publicar RUA con
p=none. - Observar informes durante 1 a 2 semanas como referencia inicial y ampliar para cubrir flujos raros.
- Corregir autenticación y alineación de cada emisor legítimo para que al menos SPF o DKIM pase alineado.
- Valorar
p=quarantinetras resolver fallos legítimos e investigar los desconocidos. - Valorar
p=rejectdespués de probar también los procesos críticos y los reenvíos.
Sin observación y pruebas, un cliente podría revelar un emisor olvidado antes que tus informes. Planifica una respuesta a incidencias durante la transición.
Operación RUA dispersa frente a un flujo coordinado
Revisar XML por separado para cada dominio exige coordinación. Un flujo con DNS coherente y un panel de dominios, buzones, migración y envío puede facilitar las correcciones, según las funciones disponibles.
| Problema habitual | Enfoque con TrekMail |
|---|---|
| Configuraciones SPF, DKIM y DMARC dispares | Panel para seguir DNS de dominios y operaciones de buzones |
| Emisor responsable de la falta de alineación desconocido | Flujo DNS y documentación para orientar el diagnóstico |
| Reenvíos atribuidos únicamente a SPF | Configuración que considera DMARC, DKIM y rutas indirectas |
| Costes por usuario al ampliar dominios | Planes anunciados desde $3.50 al mes, con almacenamiento compartido y sin cargos por usuario según condiciones |
TrekMail no sustituye un analizador DMARC. Puede coordinar dominios propios, buzones IMAP, catch-all, reenvío, migración IMAP y SMTP propio o incluido según el plan. Comprueba qué funciones necesitas para actuar sobre los problemas observados.
Los planes se anuncian desde $3.50 al mes. Nano se ofrece gratuito sin tarjeta. Los planes de pago pueden incluir una prueba de 14 días con tarjeta requerida; confirma los términos vigentes.
Conclusión: RUA aporta visibilidad parcial
RUA crea un canal de información útil para investigar autenticación, reenvíos y posible suplantación. Compleméntalo con otras evidencias para valorar si tu dominio está preparado para medidas restrictivas.
Tanto con un dominio como con cincuenta o quinientos, mantén las decisiones vinculadas a pruebas. Revisa los informes periódicamente, actualiza el inventario y corrige los emisores antes de modificar la política.
Para coordinar el resto de la infraestructura, TrekMail ofrece alojamiento multidominio, almacenamiento compartido, creación de buzones mediante invitaciones y migración IMAP según el plan. Consulta las condiciones en trekmail.net y elige según tus necesidades operativas.
