Lo que revelan 99 300 dominios sobre la autenticación del correo electrónico y la resiliencia del DNS
En resumen:
- Los principales proveedores de correo electrónico y las pasarelas se encargan de la entrega de los mensajes, pero los propietarios de los dominios son, en última instancia, los responsables de configurar y mantener las políticas DMARC para evitar la suplantación de dominios.
- Un estudio de Palisade realizado sobre 99 300 dominios reveló que dos de cada cinco dominios carecen de una política DMARC, y que más de un tercio de los dominios que cuentan con DMARC permanecen en modo de supervisión pasiva en lugar de aplicar medidas de protección.
- Más del 20 % de los dominios que publican DMARC omiten las direcciones de informes agregados, lo que priva a los administradores de la visibilidad necesaria para corregir los fallos de autenticación y pasar a una aplicación estricta.
Las organizaciones suelen considerar que la elección entre Microsoft 365, Google Workspace o una pasarela de seguridad de correo electrónico es la decisión más importante para proteger el correo electrónico empresarial. Esos servicios son importantes, pero no bastan para garantizar la seguridad.
El dominio visible de una dirección de correo electrónico se rige por el Sistema de Nombres de Dominio (DNS), y el propietario del dominio debe publicar una política en la que se especifique cómo deben gestionar los sistemas receptores los mensajes que no superen la autenticación.
Dicha política es la Autenticación, Notificación y Conformidad de Mensajes Basadas en Dominio (DMARC).
DMARC vincula el dominio que aparece en el campo «De» con los dos mecanismos principales que se utilizan para autenticar el correo electrónico: el Sender Policy Framework (SPF) y el DomainKeys Identified Mail (DKIM). Cuando no se cumple la alineación, una política DMARC en vigor solicita a los destinatarios participantes que pongan en cuarentena o rechacen el mensaje. Sin un registro DMARC válido, los destinatarios no disponen de ninguna solicitud de gestión de DMARC por parte del propietario del dominio. Un delincuente aún puede intentar falsificar el dominio exacto de la organización en una factura, un aviso de restablecimiento de contraseña o una solicitud de un directivo.
Para comprobar el alcance de la implementación de dicho control, mis colegas de Palisade analizaron los registros DNS públicos de un corpus fijo compuesto por los 100 000 dominios web más importantes. Observamos 99 300 dominios durante un único periodo de análisis el 14 de agosto de 2026, resolviendo los registros DMARC, SPF, Brand Indicators for Message Identification (BIMI) y Mail Exchange (MX) a través de los mismos resolutores públicos.
2 de cada 5 dominios carecen de una política DMARC
El resultado general fue desigual. Solo el 58,1 % de los dominios analizados publicaban DMARC. De entre esos emisores, el 64,0 % solicitaba a los receptores que pusieran en cuarentena o rechazaran los mensajes con errores. Dicho de otro modo, aproximadamente dos de cada cinco dominios analizados carecían de política DMARC, mientras que más de un tercio de los emisores DMARC permanecían en modo de supervisión.
Asimismo, comparamos los dominios en función de la infraestructura de correo entrante observada. Dado que los dominios mejor clasificados pueden presentar perfiles de seguridad distintos a los de menor clasificación, estandarizamos cada grupo de proveedores según la misma distribución de bandas de clasificación. Tras ese ajuste, la adopción de DMARC fue del 89,4 % entre los dominios de Microsoft 365 observados y del 80,6 % entre los dominios de Google Workspace. El cumplimiento entre los emisores de DMARC fue del 68,3 % y del 62,1 %, respectivamente. Las pasarelas de correo electrónico reconocidas registraron una adopción del 94,7 % y un cumplimiento del 76,0 %.
Se trata de diferencias observacionales, no de pruebas de que elegir un proveedor concreto garantice una mejor autenticación. Un registro MX indica dónde parece gestionarse el correo entrante. Es posible que no revele la plataforma de buzones de correo subyacente, especialmente cuando hay una pasarela situada delante de ella. Y lo que es más importante, la política DMARC sigue perteneciendo al propietario del dominio. Contratar una plataforma de correo electrónico líder no garantiza que la política se publique o se aplique de forma segura.
La brecha en la presentación de informes podría ser tan importante como la brecha normativa
DMARC puede enviar informes agregados al propietario del dominio, indicando qué servicios envían correo utilizando dicho dominio y si dichos mensajes se ajustan a las normas del dominio. Sin embargo, el 20,7 % de los emisores de DMARC incluidos en el estudio carecían de una dirección para la recepción de informes agregados. Sin ese circuito de retroalimentación, los operadores disponen de menos pruebas para identificar a los remitentes olvidados, corregir los fallos de autenticación y pasar de forma segura de la supervisión a la aplicación de medidas.
SPF ha vuelto a recordar que la resiliencia del correo electrónico depende del funcionamiento del DNS. Entre los dominios que publicaron registros SPF, el 2,6 % sufrió fallos en las consultas recursivas. Estos errores pueden producirse cuando un registro depende de demasiados servicios externos o cuando cambia una de esas dependencias. Es posible que exista una política en el DNS y que, aun así, falle al evaluarse.
La respuesta práctica no consiste en perseguir una puntuación perfecta en la evaluación de proveedores
Los propietarios de dominios deben mantener un inventario de remitentes legítimos, recopilar informes DMARC, corregir la alineación de SPF y DKIM, y avanzar de forma deliberada hacia la cuarentena o el rechazo. Asimismo, deben volver a realizar pruebas tras cualquier cambio en el DNS o en el proveedor, en lugar de considerar la autenticación como un proyecto puntual.
Las mediciones de DNS público ofrecen una visión útil del grado de preparación, pero su interpretación requiere establecer límites con cuidado. Un registro DNS no demuestra que una organización haya sido objeto de un ataque, que un proveedor haya provocado el resultado ni que todos los mensajes sean seguros. Lo que sí muestra es si el propietario del dominio ha publicado una política explícita, ha mantenido una vía de notificación y ha evitado varios errores de configuración habituales.
El correo electrónico depende de una infraestructura compartida, pero la responsabilidad sigue estando repartida. Los proveedores pueden ofrecer sistemas robustos; los destinatarios pueden evaluar la autenticación; los organismos de normalización pueden mejorar los protocolos. El propietario del dominio sigue teniendo que publicar, supervisar y mantener la política. Ese paso final es lo que convierte un servicio de buzón de correo en una capa de identidad más resistente.
Samuel Chenard es el director ejecutivo y cofundador de Palisade, donde colabora con equipos de TI y proveedores de servicios gestionados en materia de autenticación y entregabilidad del correo electrónico. Dirige la investigación reproducible de Palisade sobre el DNS público en lo relativo a DMARC, SPF, BIMI y la implementación de registros MX.
Las opiniones expresadas por los autores de esta entrada del blog son propias y no reflejan necesariamente las opiniones de Internet Society.