El 27,9% de los principales dominios sigue siendo vulnerable al spoofing de correo electrónico a finales de 2026

Un análisis reciente de los 1.000 principales dominios del Majestic Million muestra que el 27,9% sigue siendo vulnerable al spoofing de correo electrónico a fecha del 19 de octubre de 2026. El estudio destaca que, aunque las grandes plataformas han mejorado su adopción, muchas organizaciones aún dependen de registros DNS permisivos que no bloquean los correos falsificados.

Qué ha ocurrido

La investigación examinó los registros de Autenticación, Reporte y Conformidad de Mensajes Basada en Dominio (DMARC) de 974 dominios registrables de la lista Majestic Million. Esta clasificación mide la presencia global en la web mediante backlinks. El objetivo era determinar cuántos de estos dominios de alto perfil previenen eficazmente que los atacantes envíen correos electrónicos que parezcan originarse desde ellos. Los resultados indican que 272 dominios o bien no publican ningún registro DMARC, o utilizan una política no aplicada, o tienen configuraciones inválidas.

Mientras que el 72,1% de los dominios auditados ahora aplican DMARC, una parte significativa permanece expuesta. Dentro del grupo que aplica la política, el 53,1% utiliza la política estricta "reject" (rechazar), que indica a los servidores receptores descartar por completo los mensajes no autenticados. Otro 19,0% usa "quarantine" (cuarentena), que generalmente dirige el correo sospechoso a las carpetas de spam. Sin embargo, el 16,9% todavía usa "none" (ninguna), un modo solo de monitoreo que permite pasar todo el correo independientemente del estado de autenticación, y el 11,0% no tiene ningún registro.

Los datos también revelan una disparidad basada en la infraestructura de correo. Los dominios que utilizan proveedores hospedados importantes como Google Workspace o Microsoft 365 tienen tasas de suplantación más bajas, oscilando entre el 18,1% y el 20,5%. En contraste, los dominios que usan otras soluciones de correo auto-hospedadas son suplantables el 40,7% de las veces. Incluso los dominios sin registros de intercambio de correo (MX), que teóricamente no deberían recibir email, muestran una tasa de suplantación del 38,2% porque a menudo carecen de entradas DNS protectoras.

Detalles clave

• Definición de suplantable: Un dominio se considera suplantable si su política DMARC efectiva falta, está configurada como p=none o es inválida.
• Brecha entre proveedores: Los proveedores de correo auto-hospedados o de nicho muestran una tasa de suplantación doble (40,7%) en comparación con plataformas principales como Google (18,1%).
• Cumplimiento vs. seguridad: Proveedores principales como Gmail y Yahoo solo requieren p=none para remitentes masivos, lo que significa que el cumplimiento no equivale a protección total.
• Problemas de SPF: El 15,5% de los dominios carece por completo de un registro SPF, y el 1,0% supera el límite de 10 búsquedas DNS, causando errores de validación.
• Seguridad de transporte: Solo el 1,5% de los dominios aplica MTA-STS, un protocolo que asegura la entrega cifrada de correo.
• Dominios sin correo: Los dominios que no reciben correo deben publicar v=spf1 -all y p=reject para prevenir la suplantación, pero muchos no lo hacen.

Antecedentes

DMARC funciona junto con SPF (Sender Policy Framework) y DKIM (DomainKeys Identified Mail) para verificar la autenticidad del correo. SPF lista las direcciones IP autorizadas para enviar correo, mientras que DKIM añade una firma digital a los mensajes. DMARC une estos elementos indicando a los servidores receptores qué hacer si un correo falla estas comprobaciones. Una política de p=none instruye a los receptores a entregar el correo de todos modos, pero enviar un informe al propietario del dominio. Esto es útil para la configuración inicial pero no ofrece protección contra el phishing.

El cambio hacia una aplicación más estricta ha sido impulsado por nuevos requisitos de los principales proveedores de buzones de correo. Desde principios de 2024, Gmail y Yahoo han exigido que los remitentes masivos publiquen registros DMARC, aunque inicialmente aceptaban p=none. Microsoft siguió en mayo de 2025 con reglas similares para usuarios de Outlook.com. Estas regulaciones han aumentado con éxito el número de dominios que publican registros DMARC, pero no han empujado universalmente a las organizaciones a adoptar la política más estricta p=reject necesaria para detener el spoofing.

Por qué importa

Para equipos que gestionan su propio software e infraestructura, estos datos subrayan el riesgo de depender únicamente de configuraciones predeterminadas o de un cumplimiento mínimo. Si su organización utiliza un servidor de correo auto-hospedado o un proveedor de nicho, estadísticamente tiene más probabilidades de estar mal configurada que sus pares en plataformas principales. Los atacantes apuntan a dominios conocidos porque los usuarios confían en ellos. Una política p=none esencialmente invita a los phishers a suplantar su marca, ya que los servidores receptores no bloquearán sus mensajes falsificados.

Además, la baja adopción de estándares de seguridad de transporte como MTA-STS indica que muchas organizaciones no están protegiendo el correo en tránsito frente a ataques de degradación. Mientras que DMARC previene la suplantación, MTA-STS asegura que la conexión entre servidores de correo esté cifrada y no pueda ser interceptada. Ignorar estas capas deja tanto su reputación como sus comunicaciones vulnerables.

La distinción entre cumplimiento y seguridad es crítica. Cumplir con los requisitos mínimos de Gmail o Yahoo mantiene sus correos de marketing fuera de la carpeta de spam, pero no protege su dominio contra el abuso. Los líderes de TI deben reconocer que pasar una verificación de remitente masivo es meramente el primer paso en una estrategia de seguridad más amplia.

Qué puede hacer

• Audite su política DMARC: Compruebe si su dominio usa p=none y planifique una migración a p=quarantine y eventualmente a p=reject.
• Asegure dominios sin correo: Para cualquier dominio que no reciba correo, publique v=spf1 -all y p=reject para bloquear todo el correo saliente.
• Revise los registros SPF: Asegúrese de que su registro SPF incluya solo los servicios necesarios y permanezca bajo el límite de 10 búsquedas DNS para evitar errores permanentes.
• Habilite reportes: Use etiquetas rua en su registro DMARC para recibir informes agregados, ayudándole a identificar remitentes legítimos antes de aplicar políticas estrictas.
• Implemente MTA-STS: Despliegue MTA-STS y TLS-RPT para forzar conexiones cifradas y recibir reportes sobre negociaciones TLS fallidas.
• Monitoree continuamente: Revise regularmente sus registros DNS para detectar cambios accidentales o vencimientos, especialmente si gestiona múltiples subdominios.