08 Oct 20265 minutes read
Waseem OsmanEspecialista en DMARCResultados de la comprobación de DMARC: qué confirman y qué no muestran
Resumen:
- Un resultado correcto puede dejar que el correo suplantado llegue a las bandejas de entrada y que el correo legítimo falle DMARC
- Los resultados de la comprobación de DMARC confirman que un registro es válido, no cómo tratan los receptores su correo
- Un registro p=none supera una comprobación de DMARC, pero ofrece reportes, no protección
- Los fallos de alineación y de reenvío aparecen en los reportes agregados, no en los resultados de la comprobación de DMARC
Un dominio puede superar una comprobación de DMARC y aun así tener dos problemas. El correo suplantado que usa el dominio aún puede llegar a las bandejas de entrada. El correo legítimo de sus propios remitentes puede fallar DMARC. Los resultados de la comprobación de DMARC confirman que existe un registro y que es válido, no cómo tratan los servidores receptores el correo enviado en nombre de su dominio.
Las empresas envían correo a través de muchas plataformas y cada una debe alinearse con su dominio. Un remitente que falla la alineación ve bloqueado su correo en cuanto se llega a p=reject. Esta guía explica qué muestran los resultados de la comprobación de DMARC, qué dejan fuera y cómo deben actuar los CISO, los administradores de correo y los responsables de cumplimiento ante cada resultado.
Obtenga su punto de partida antes de seguir leyendo. Ejecute una comprobación de DMARC de su dominio con la herramienta gratuita de Sendmarc.
Si está en riesgo de suplantación, uno de nuestros expertos se pondrá en contacto para ayudarle.
Qué confirman los resultados de la comprobación de DMARC
Una comprobación de DMARC de un dominio consulta el DNS en busca de un registro TXT en _dmarc.sudominio.com. Después valida ese registro con la especificación DMARC.
Los resultados de la comprobación de DMARC suelen confirmar cuatro cosas:
- Hay un registro DMARC publicado
- La sintaxis es válida, con
v=DMARC1como primera etiqueta - Hay una etiqueta de política establecida en p=none, p=quarantine o p=reject
- Existen etiquetas de reporte como
rua=
Un registro válido tiene este aspecto:
| Host | Tipo | Valor |
|---|---|---|
_dmarc.sudominio.com | TXT | v=DMARC1; p=reject; rua=mailto:[email protected] |
Una comprobación de DMARC correcta es un punto de partida. Describe lo que ha publicado, no si su correo legítimo la supera.
Lo que los resultados de la comprobación de DMARC no muestran
Nivel de política frente a protección. Un registro p=none supera una comprobación de DMARC. Los servidores receptores siguen entregando el correo no autenticado que afirma proceder de su dominio. Obtiene reportes, pero ninguna protección.
Cobertura de subdominios. Los subdominios sin registro propio heredan la política del dominio principal, salvo que la etiqueta sp= establezca otra distinta. Una comprobación de DMARC del dominio raíz no mostrará los subdominios que publican sus propios registros más débiles.
Alineación de remitentes de terceros. DMARC solo se supera cuando el dominio del campo “From” se alinea con el dominio que superó SPF o DKIM. Muchas plataformas SaaS superan SPF con su propio dominio, no con el suyo. Sin una firma DKIM, ese correo legítimo falla DMARC.
Reenvío. Los servidores de reenvío envían desde direcciones IP que no están en su registro SPF, así que SPF falla. DKIM sobrevive al reenvío cuando el mensaje llega sin modificar. Las listas de correo que alteran el mensaje rompen DKIM, así que ambas comprobaciones pueden fallar. Los fallos de reenvío aparecen en los reportes agregados, no en una comprobación de DMARC.
Qué significa la comprobación de DMARC para cada equipo
Los mismos resultados de la comprobación de DMARC significan cosas distintas para equipos distintos. Cada rol necesita un siguiente paso diferente.
CISO
Para los responsables de seguridad, la etiqueta de política indica la exposición.
- p=none: el correo no autenticado que usa su dominio llega a las bandejas de entrada. Los reportes muestran el abuso, pero los receptores no toman ninguna medida.
- p=quarantine: los receptores envían el correo no autenticado a Spam o Correo no deseado. El mensaje sigue llegando al entorno del destinatario.
- p=reject: los receptores bloquean el correo no autenticado antes de que llegue a la bandeja de entrada. Es la aplicación total.
Una política p=reject solo protege al dominio que la publica y a los subdominios que la heredan, así que cada dominio registrado necesita su propio registro. Una comprobación de DMARC del dominio principal por sí sola no basta para el reporte al consejo.
Ejecute una comprobación de DMARC de cada dominio activo. Reporte el porcentaje de dominios activos en p=reject e indique los dominios que siguen en p=none.
Administradores de correo y de TI
Para los administradores, los resultados de la comprobación de DMARC confirman que el registro es correcto. El verdadero trabajo consiste en contrastar ese registro con sus remitentes reales.
Empiece por los reportes agregados. Los servidores receptores envían reportes XML a la dirección rua=, con cada fuente que envió correo usando su dominio. Estos reportes muestran qué remitentes se alinean, cuáles fallan y cuáles no reconoce. Las fuentes no reconocidas suelen apuntar a TI en la sombra: herramientas que una unidad de negocio adoptó sin revisión del DNS.
Resuelva cada fallo legítimo antes de avanzar la política. Pasar a p=reject con remitentes sin alinear bloquea el correo legítimo, incluidos los avisos de facturación y los restablecimientos de contraseña. Repita la comprobación de DMARC del dominio tras cada cambio de DNS o incorporación de una plataforma de envío.
Responsables de riesgos y cumplimiento
Para los equipos de cumplimiento, los resultados de la comprobación de DMARC son un elemento más de la evidencia de auditoría. Los auditores necesitan más que una sola comprobación de DMARC.
Documente cuatro cosas de cada dominio activo:
- La política actual y la política de subdominios
- La cobertura de reportes
- Los dominios que aún no están en p=reject
- Un calendario de corrección con responsables designados
Las reglas de los proveedores de buzones marcan el mínimo. Desde febrero de 2024, Google exige a los remitentes masivos (más de 5.000 mensajes al día a Gmail) que publiquen un registro DMARC alineado. Yahoo introdujo a la vez su propio requisito de DMARC para remitentes masivos y Microsoft lo siguió en mayo de 2025.
Cómo ayuda Sendmarc
Una sola comprobación de DMARC muestra un dominio en un momento dado. Los entornos empresariales cambian constantemente. Se lanzan nuevas herramientas, los registros DNS cambian y las unidades de negocio añaden remitentes sin avisar a TI.
Sendmarc aporta lo que los resultados de la comprobación de DMARC no pueden ofrecer: visibilidad continua de cada remitente. La plataforma de Sendmarc analiza los reportes agregados de todos los dominios. Saca a la luz remitentes no autorizados, errores de configuración y fallos de autenticación antes de que se conviertan en incidentes.
Esa visibilidad reduce la investigación manual de los equipos de TI y seguridad, ya sobrecargados. La gestión centralizada estandariza las políticas de autenticación entre departamentos, regiones y entidades adquiridas. Los registros de auditoría y los reportes listos para cumplimiento ofrecen a los equipos de riesgos evidencia creíble para los comités de auditoría y de riesgos.
El equipo de implementación de Sendmarc lleva cada dominio de p=none a p=reject por etapas, para que las comunicaciones críticas sigan fluyendo. La optimización continúa tras la aplicación a medida que cambia su entorno.
La aplicación de DMARC cubre los dominios que usted posee. Defensa contra dominios similares monitoriza los dominios recién registrados que imitan su marca. Detección de filtraciones monitoriza varias fuentes, incluida la dark web, en busca de credenciales de empleados comprometidas.
Explore la Gestión de DMARC para ver cómo Sendmarc sustituye una comprobación de DMARC puntual por una visibilidad continua de los remitentes y un camino hacia p=reject en todos los dominios.
