Publicaste un registro DMARC con una dirección rua=, esperaste unos días y tu buzón está vacío. Ni informes, ni errores, nada que te diga si el registro está roto o si simplemente es pronto. Las causas son pocas y fáciles de comprobar una vez que sabes en qué orden hacerlo. Esta guía recorre la lista de comprobación, desde la prueba más barata (paciencia) hasta las más técnicas, como la autorización de destinos externos, y explica cómo se ve cada fallo.
La respuesta corta#
Los informes DMARC que no llegan casi siempre se deben a una de siete cosas: aún no has esperado de 24 a 48 horas, el registro está en el nombre DNS equivocado, hay más de un registro DMARC, el valor de rua= está mal formado (debe empezar por mailto:), la dirección de informes está en otro dominio sin autorización, tu dominio envía muy poco correo para que los receptores informen, o el buzón filtra los adjuntos comprimidos. Compruébalas en ese orden. Una consulta en vivo de _dmarc.tudominio.com resuelve las cuatro primeras en menos de un minuto. dig TXT _dmarc.tudominio.com +short es lo que revela un segundo registro, porque el verificador de SPF, DKIM y DMARC muestra solo el primero que encuentra y no comprueba la sintaxis de rua=. Si el registro está limpio y han pasado unos días, mira el buzón de destino.
Paso 1: Dale tiempo y sabe quién envía informes#
Los proveedores agrupan lo que vieron durante un día y envían un informe por dominio, así que los primeros informes llegan de 24 a 48 horas después de que el registro esté activo, y a veces más tarde. El primer día no llegará nada.
Dos puntos más ajustan las expectativas:
- No todos los receptores envían informes. Los grandes proveedores de buzones sí. Muchos más pequeños nunca lo harán. Estás recogiendo una muestra de proveedores, no un registro completo.
- Un receptor informa solo si vio correo tuyo. Si tu dominio no envió nada a un proveedor ayer, ese proveedor no tiene nada que informar.
Si has esperado tres días completos, pasa al registro.
Paso 2: Confirma que el registro está donde debe#
Los registros DMARC viven en un nombre concreto: _dmarc. delante de tu dominio. Un registro publicado en el dominio sin prefijo, o en dmarc.example.com, se ignora. Consulta lo que está realmente publicado:
dig TXT _dmarc.example.com +short
"v=DMARC1; p=none; rua=mailto:reports@example.com"
Cosas que revisar en la respuesta:
- Que el registro exista. Algunos proveedores de DNS quieren solo
_dmarcen el campo host, no el nombre completo. Si escribes el nombre completo, añaden tu dominio dos veces. Los pasos específicos de cada proveedor están en guías como Cloudflare y GoDaddy. - Que empiece por
v=DMARC1, exactamente, sin nada antes. - Que incluya una etiqueta
p=. Según el RFC 9989, un registro sinp=válido pero con unrua=válido se trata comop=noney sigue recibiendo informes, así que normalmente no es la causa de que falten informes, pero publica la etiqueta de forma explícita de todos modos. - Que las etiquetas estén separadas por punto y coma.
Recuerda el caché de DNS. Si acabas de editar el registro, los receptores pueden usar la copia antigua hasta que venza su TTL.
Paso 3: Asegúrate de que solo hay un registro DMARC#
Un dominio debe publicar un único registro DMARC. Si dos registros TXT en _dmarc empiezan ambos por v=DMARC1, los receptores normalmente ignorarán los dos y los informes se detienen. Esto ocurre cuando alguien añade un registro nuevo sin borrar el antiguo, o cuando una migración de DNS copia el registro dos veces.
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:old@example.com"
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:new@example.com"
Borra uno, conserva el otro y fusiona las direcciones en una sola lista rua=. Varios destinos de informes se separan con comas dentro de un solo registro, no publicando más registros.
Paso 4: Revisa la sintaxis de rua#
El valor de rua= es una lista de URI, y cada una debe empezar por mailto:. Errores típicos:
| Lo que está publicado | Problema |
|---|---|
rua=reports@example.com | Falta mailto: |
rua=mailto:reports@example.com mailto:other@example.com | Dos direcciones sin una coma entre ellas |
rua=mailto:reports@exmaple.com | Error tipográfico en el dominio, así que los informes no van a ninguna parte |
v=DMARC1; rua=mailto:reports@example.com | Sin etiqueta p=. El RFC 9989 lo trata como p=none cuando el rua es válido, pero un receptor que siga las reglas anteriores puede ignorar el registro, así que publica p= de forma explícita |
Solo ruf=mailto:reports@example.com | ruf pide informes de fallos, que muchos proveedores no envían. Los informes agregados necesitan rua |
La última fila sorprende a mucha gente. Los informes agregados vienen de rua. Si solo defines ruf, recibirás casi nada. La lista completa de etiquetas está en cómo configurar DMARC.
Paso 5: Autoriza los informes hacia otro dominio#
Esta es la causa que más se pasa por alto. Si tu dirección rua= está en un dominio distinto del que protege el registro, los receptores comprueban que el otro dominio aceptó recibir los informes. Si no, cualquiera podría dirigir avalanchas de informes al buzón de una víctima.
Toma este registro para example.com:
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:reports@thirdparty.example.net"
Como la dirección está fuera de example.com, el dominio receptor debe publicar un registro de autorización con un nombre construido a partir de tu dominio:
example.com._report._dmarc.thirdparty.example.net. TXT "v=DMARC1;"
Si ese registro TXT no existe, los receptores que cumplen el estándar descartan el informe. Puedes verificarlo con:
dig TXT example.com._report._dmarc.thirdparty.example.net +short
Dos notas prácticas:
- Si controlas ambos dominios, simplemente añade el registro de autorización en el destino. Si un proveedor recibe los informes por ti, normalmente es él quien lo publica o te dice que lo hagas.
- Enviar los informes a un buzón de tu propio dominio evita la comprobación por completo, por eso un simple reenvío
dmarc@tudominio.comes la configuración menos frágil.
Paso 6: Revisa el buzón de destino#
Si el registro es válido y la autorización está en su sitio, puede que los informes estén llegando y perdiéndose:
- Filtrado de adjuntos. Los informes llegan como adjuntos
.gzo.zip, a veces como XML sin comprimir. Los filtros de correo que eliminan adjuntos comprimidos los descartarán en silencio. Revisa spam, cuarentena y cualquier regla que borre archivos comprimidos. - Buzón lleno. Un dominio con mucha actividad puede generar decenas de informes al día. Un buzón compartido pequeño se llena rápido y empieza a rechazarlos.
- Alias o reenvío que reescribe. Un alias de grupo que bloquea remitentes externos rechazará los informes de los proveedores.
Busca asuntos que incluyan "Report Domain" y el nombre de tu dominio. Si no ves ninguno tras revisar el filtrado, el problema está aguas arriba.
Un buzón dedicado, o un servicio que reciba los informes por ti, evita la mayoría de estos problemas. Además, el XML en bruto en una bandeja personal entierra la señal, como se explica en cómo leer los informes DMARC.
Si usas una dirección de informes de Qualisend#
Si tu rua= apunta a una dirección <key>@dmarc.qualisend.com de DMARC Reports, nosotros nos encargamos de las comprobaciones de destino. Qualisend publica un registro de autorización comodín, así que los proveedores enviarán a esa dirección para cualquier dominio, y no necesitas añadir el registro de autorización del paso 5. Esto es lo que aún puede bloquear los datos:
- El dominio no está cubierto. Los informes se guardan solo para dominios con la cobertura activada en tu espacio de trabajo, o para un subdominio de uno de ellos. Un informe de un dominio no cubierto se acepta pero no se guarda, así que el panel sigue vacío.
- La suscripción no está activa. Los informes enviados a una dirección cuyo espacio de trabajo no tiene una suscripción DMARC activa se rechazan.
- La dirección se rotó. Tras una rotación, la dirección antigua deja de aceptar correo de inmediato, así que cada
rua=que aún la liste perderá informes hasta que actualices el DNS. - El registro no lista la dirección. Si ya existe un registro DMARC, añade
,mailto:<address>a su listarua=y conserva la política y las demás direcciones.
Qualisend nunca edita tu DNS. El cambio del registro te toca hacerlo a ti en tu proveedor de DNS. La página te indica que los primeros informes suelen llegar en 24 a 48 horas, lo que coincide con lo que hacen los proveedores.
Subdominios y el registro que manda#
Si los informes que faltan son de un subdominio, mira qué está publicado realmente ahí. Un subdominio con su propio registro DMARC usa ese registro, y si no tiene rua=, no se envía nada a la dirección del dominio padre. Un subdominio sin registro recurre al registro del dominio padre y a su política sp=. Los informes nombrarán el dominio de la política, así que búscalos con ese nombre y no con el de tu dominio principal.
Conviene pasar todo el dominio por una comprobación de salud del dominio tras cualquier cambio de DNS. Señala un registro DMARC ausente, un registro sin etiqueta de política y una política p=none, y muestra el registro publicado para que puedas leer tú mismo el valor de rua=. El monitoreo de salud del dominio de pago también avisa cuando una política válida no tiene rua= en absoluto. Si esto sigue pasando tras editar el DNS, la guía de monitoreo de salud del dominio explica cómo detectarlo antes de que los informes se detengan.
Una lista de comprobación final#
- Espera 48 horas después de que el registro esté activo.
- Ejecuta
dig TXT _dmarc.tudominio.comy lee el resultado. - Confirma un solo registro, que empiece por
v=DMARC1, con unp=explícito. - Confirma
rua=mailto:con comas entre direcciones. - Si la dirección está en otro dominio, verifica el registro de autorización
_report._dmarc. - Revisa spam, cuarentena, límites de tamaño y filtros en el buzón de destino.
- Asegúrate de que el dominio realmente envió correo a proveedores que informan.
Cuando por fin lleguen los informes, el siguiente trabajo es entenderlos, algo que se explica en el monitoreo DMARC y en quién envía con tu dominio.
Preguntas frecuentes
01¿Cuánto tardan en llegar los informes DMARC?
Los proveedores agrupan lo que vieron durante un día y envían un informe por dominio, así que los primeros informes normalmente llegan de 24 a 48 horas después de que el registro esté activo, y a veces más tarde. Si has esperado tres días completos, revisa el registro, su sintaxis y el buzón de destino en lugar de esperar más.
02¿Por qué necesito un registro TXT en _report._dmarc para direcciones externas?
Si tu dirección rua está en un dominio distinto del que protege el registro, los receptores comprueban que el otro dominio aceptó recibir los informes. El destino publica un registro TXT con el nombre de tu dominio, seguido de _report._dmarc y su propio dominio, con el valor v=DMARC1;. Sin él, los receptores que cumplen el estándar descartan los informes.
03¿Por qué recibo informes DMARC de algunos proveedores pero no de otros?
No todos los receptores envían informes agregados, y un receptor solo informa cuando vio correo de tu dominio en el periodo. Los grandes proveedores de buzones los envían con fiabilidad, muchos más pequeños nunca lo hacen. Tus informes describen a los proveedores que informan, no todo tu correo.
04¿Pueden dos registros DMARC en el mismo dominio detener los informes?
Sí. Un dominio debe publicar un único registro DMARC. Si dos registros TXT en _dmarc empiezan ambos por v=DMARC1, los receptores normalmente ignorarán los dos y los informes se detienen. Borra uno y fusiona las direcciones en una sola lista rua, separadas por comas, dentro del registro que quede.
Conseguir que fluyan los informes DMARC te muestra quién envía con tu dominio, pero no si tu lista está limpia. Si quieres revisar después la lista, el plan gratuito de la página de precios te da 100 créditos para la verificación completa, y el verificador de correo gratuito sirve para direcciones sueltas. Una autenticación que funciona sigue necesitando una lista sana para llegar a la bandeja de entrada.
