Un dominio puede tener un registro DMARC que parece perfectamente válido en todos los sentidos, estar en p=reject, citar una dirección de reportes real, y aun así no proteger nada. Sucede en el momento en que aparece un segundo registro TXT en el mismo host _dmarc. La especificación no promedia los dos registros, ni prefiere el más estricto, ni marca un conflicto. Descarta ambos y trata el dominio como si DMARC nunca se hubiera configurado.
Lo Que la Especificación Realmente Exige
El descubrimiento de la política DMARC es más estricto de lo que la mayoría supone. Un servidor de correo receptor consulta los registros TXT de _dmarc.tudominio.com, y la regla que gobierna lo que debe devolverse no ha cambiado desde el RFC 7489 original y continúa en el RFC 9989: debe existir exactamente un registro TXT que comience con v=DMARC1. Cero registros que coincidan significa que no hay política. Más de un registro que coincida también significa que no hay política, sin excepción, sin importar lo que diga cada uno de ellos.
Esto no es un caso extremo que los redactores pasaron por alto. Es una regla deliberada contra la ambigüedad. Si un receptor encontrara dos registros, uno diciendo p=reject y otro diciendo p=none, no habría una forma fundamentada de decidir cuál pretendía realmente el propietario del dominio, así que la especificación se niega a adivinar. Descarta ambos y regresa a no tener ninguna política DMARC para ese dominio.
Cómo Terminan Dos Registros en el Mismo Dominio
Nadie se sienta a publicar deliberadamente un registro DMARC duplicado. Se acumula a través de actividad operativa ordinaria que nadie considera que esté tocando el DNS al mismo tiempo que otra persona.
Un proveedor de concienciación en seguridad o de autenticación de correo ejecuta un asistente de configuración guiada durante la activación y escribe un registro TXT en _dmarc como parte del proceso. Meses después, una plataforma de email marketing distinta ejecuta su propio asistente de “autentica tu dominio de envío”, no verifica si ya existe un registro, y escribe el suyo propio. Ambas herramientas creen haber configurado DMARC correctamente, porque desde la vista aislada de cada herramienta, así fue.
Lo mismo ocurre durante las migraciones de proveedor de DNS, cuando un archivo de zona se exporta de un registrador y se importa a otro sin deduplicación, y un registro antiguo que debió retirarse meses antes termina viajando junto a su reemplazo. Ocurre tras fusiones y consolidaciones de dominios, cuando dos equipos de TI aportan cada uno sus propias convenciones de DNS a una zona compartida. Ocurre cuando un contratista configura un registro temporal para un proyecto de migración y nadie lo elimina una vez terminada.
Ninguna de estas personas está cometiendo un error obvio. Cada una, por su cuenta, publicó un registro DMARC sintácticamente correcto. El dominio termina desprotegido por lo que sucede cuando esas dos acciones, correctas de forma individual, coinciden en la misma zona DNS.
Por Qué Nada Te Avisa de Lo Ocurrido
Un registro DMARC mal configurado suele dejar un rastro visible. Un error de sintaxis aparece si pasas el registro por un validador. Una política en p=none es visiblemente permisiva si la lees. Un registro duplicado no produce ninguna de estas señales, porque no hay un único registro que inspeccionar para encontrar el error; el error existe solo en la relación entre dos registros que, por separado, se ven completamente correctos.
Ejecuta dig TXT _dmarc.tudominio.com y verás ambas entradas impresas, una tras otra, y a menos que estés contando específicamente cuántas comienzan con v=DMARC1, dos cadenas de política que parecen válidas se leen como algo tranquilizador, no alarmante. La mayoría de las herramientas de verificación de registros DMARC pensadas para una comprobación manual rápida muestran el registro que analizan primero y nunca señalan el segundo como un conflicto.
El canal de reportes que normalmente detectaría una configuración así también queda comprometido por el mismo fallo. Los reportes agregados se generan según la política que el receptor cree que está en vigor, y un receptor que ha determinado correctamente que no existe una política válida no tiene obligación de tratar el correo de ese dominio de forma distinta, y a menudo no tiene motivo para seguir enviando reportes agregados detallados a una dirección vinculada a una política que acaba de descartar. El mecanismo de visibilidad que debería revelar el hueco queda desactivado por la misma condición que lo creó.
Lo Que Esto Te Cuesta
Mientras dos registros permanecen en _dmarc, el dominio se comporta, desde la perspectiva de cualquier servidor de correo receptor, exactamente como un dominio que nunca adoptó DMARC. La alineación de SPF y DKIM no se aplica, porque la aplicación de alineación es una función de DMARC y DMARC no está en vigor. El correo falsificado que dice provenir del dominio se evalúa únicamente por los resultados de SPF y DKIM, sin ninguna verificación de alineación que los vincule con el encabezado From visible, que es precisamente el hueco que DMARC existe para cerrar. Un dominio que cree estar en p=reject puede ser suplantado activamente en intentos de phishing y compromiso de correo empresarial sin que se aplique ninguna medida, durante todo el tiempo que persista el duplicado.
Lo Que Esto Significa Para Tu Programa
Cuenta los registros, no solo su contenido. Consulta directamente _dmarc.tudominio.com con dig o una herramienta equivalente y confirma que existe exactamente un registro TXT que comienza con v=DMARC1. No te detengas en confirmar que el valor de la política se ve correcto; confirma que solo hay un valor que revisar.
Trata la “configuración automática de DMARC” de cualquier proveedor como una escritura en el DNS que necesitas verificar, no confiar ciegamente. Cualquier herramienta que se ofrezca a configurar DMARC, SPF o DKIM por ti como parte de la incorporación puede escribir un registro en conflicto si no verifica primero qué ya existe. Verifica el estado resultante del DNS después de cada incorporación de este tipo, no solo después de tus propios cambios manuales.
Vuelve a revisar tras migraciones de DNS y consolidaciones de dominios. Una importación de archivo de zona es exactamente el tipo de operación masiva que puede arrastrar silenciosamente un registro obsoleto junto a uno vigente. Audita los registros _dmarc de cada dominio en una zona inmediatamente después de cualquier migración o fusión, no solo de los dominios que alguien recuerda revisar.
Monitorea de forma continua, no solo en la configuración inicial. Un registro que era único y correcto el día en que configuraste DMARC puede volverse duplicado meses después por un equipo completamente distinto que adopta una herramienta completamente distinta. Una verificación única al momento del despliegue no te dice nada sobre el estado de tu DNS seis meses después.
La Conclusión
Que DMARC falle en detener un ataque suele dar lugar a una historia dramática que involucra una evasión ingeniosa o un remitente malicioso genuinamente autenticado. Este modo de fallo no tiene ningún atacante de por medio. Dos equipos bien intencionados, o un equipo y el script de incorporación de un proveedor, hacen cada uno algo razonable de forma aislada, y el resultado es un dominio que parece protegido a primera vista y no está protegido en absoluto. La solución no cuesta más que un comando dig y el hábito de contar.
Un registro DMARC que dejó de funcionar silenciosamente hace meses se ve idéntico a uno que nunca funcionó, hasta que sabes exactamente qué revisar. Excello Mail monitorea de forma continua el estado real de tu DNS, no solo la política que configuraste una vez, para que un registro duplicado se detecte antes de que un atacante encuentre el hueco primero. Regístrate gratis en Excello Mail y conoce hoy tu verdadera postura de autenticación.