Durante casi una década, el argumento a favor de DMARC descansó sobre un único pilar: era lo correcto. Los equipos de seguridad señalaban estadísticas de phishing. Los consultores de entregabilidad advertían sobre daños reputacionales. Los proveedores creaban paneles de control para hacer que el camino de p=none a p=reject pareciera manejable.
Nada de eso movió la aguja con suficiente rapidez.
Lo que sí la está moviendo en 2026 es algo a lo que las organizaciones responden de manera mucho más fiable que las orientaciones de buenas prácticas: la amenaza de sanciones económicas. DMARC ha cruzado de recomendación a regulación, y los marcos que ahora lo exigen conllevan consecuencias financieras reales.
Si su organización maneja datos de tarjetas de pago, opera infraestructuras críticas en la Unión Europea o está bajo el alcance del Reglamento de Resiliencia Operativa Digital, ya no le están pidiendo que implemente DMARC. Se lo están exigiendo.
PCI DSS v4.0: El Mandato Más Claro Hasta la Fecha
El estándar de seguridad de datos de la industria de tarjetas de pago versión 4.0 se convirtió en la única versión vigente el 31 de marzo de 2024. El requisito 5.4.1 de PCI DSS v4.0 introduce una obligación explícita para que las organizaciones utilicen controles técnicos anti-phishing en todo el tráfico de correo electrónico. La guía complementaria del PCI Security Standards Council concreta la expectativa: DMARC, junto con SPF y DKIM, es el mecanismo técnico para satisfacer ese requisito.
El requisito 10.4.1.1 va más lejos. Exige que el correo enviado desde el dominio de una organización se autentique de manera verificable por los sistemas receptores. Un registro DMARC en p=quarantine o p=reject, combinado con autenticación SPF y DKIM alineada, es el mecanismo que satisface esta cláusula.
Las matemáticas del cumplimiento son sencillas. El incumplimiento de PCI DSS puede generar multas de las marcas de tarjetas y bancos adquirentes que oscilan entre $5,000 y $100,000 por mes por infracción. El p=none que satisface los requisitos de remitentes masivos de Gmail y Outlook no satisface PCI DSS. La política de nivel de aplicación es el requisito.
NIS2: La Unión Europea Establece el Estándar para Infraestructuras Críticas
La Directiva de Seguridad de Redes e Información 2, que los estados miembros de la UE debían transponer a la legislación nacional antes de octubre de 2024, establece requisitos de ciberseguridad para operadores de servicios esenciales y entidades importantes en dieciséis sectores: energía, transporte, banca, infraestructura de mercados financieros, salud, agua potable, aguas residuales, infraestructura digital, gestión de servicios TIC, administración pública, espacio, servicios postales, gestión de residuos, productos químicos, alimentación y fabricación.
NIS2 no menciona DMARC en su texto. Lo que sí hace es exigir que las entidades cubiertas implementen “medidas técnicas y organizativas apropiadas y proporcionales” para gestionar los riesgos de ciberseguridad. Los reguladores nacionales que implementan NIS2 han sido explícitos sobre lo que incluyen esas medidas. La Directiva Técnica BSI TR-03108 de la Oficina Federal Alemana para la Seguridad de la Información especifica DMARC en nivel de aplicación como un control requerido para los operadores de infraestructura de correo electrónico.
El marco de sanciones de NIS2 está a la altura de la ambición de la directiva. Las entidades esenciales se enfrentan a multas de hasta 10 millones de euros o el 2% de la facturación anual mundial, la que sea mayor. Las entidades importantes se enfrentan a multas de hasta 7 millones de euros o el 1,4% de la facturación anual mundial. Estas son consecuencias de escala similar al RGPD por incumplimiento de ciberseguridad.
DORA: Las Entidades Financieras Bajo el Microscopio
El Reglamento de Resiliencia Operativa Digital, que se convirtió en directamente aplicable en todos los estados miembros de la UE el 17 de enero de 2025, se aplica a las entidades financieras: bancos, empresas de inversión, aseguradoras, instituciones de pago, entidades de dinero electrónico, proveedores de servicios de criptoactivos y otros participantes del sector financiero.
El artículo 9 de DORA exige que las entidades financieras implementen políticas y procedimientos para proteger sus sistemas TIC y datos, incluidos controles que aborden la seguridad de la información en la capa de comunicación. Los estándares técnicos regulatorios complementarios identifican específicamente los protocolos de autenticación de correo electrónico como componentes de los marcos de seguridad TIC requeridos.
La implicación práctica para las entidades financieras bajo el ámbito de DORA es clara: una política DMARC en p=none es una brecha documentada en la gestión de riesgos TIC que las autoridades supervisoras pueden citar como infracción de DORA durante una inspección. Las sanciones pueden alcanzar el 2% de la facturación anual mundial total para las entidades financieras.
Por Qué los Países con Mandatos Nacionales de DMARC Registran Tasas de Phishing Dramáticamente Menores
El Centro Nacional de Ciberseguridad del Reino Unido exigió DMARC en p=reject para todos los dominios del gobierno central en 2021. Los resultados son medibles: los países con mandatos formales de DMARC para dominios gubernamentales han visto caer las tasas de éxito del phishing que apunta a dominios gubernamentales del 69% al 14%, en comparación con una tasa de vulnerabilidad del 97% en los países sin mandatos.
Este dato es significativo para los responsables de cumplimiento del sector privado. La eficacia de DMARC en nivel de aplicación no es teórica. Los países y sectores que lo han exigido han demostrado la reducción en la superficie de ataque que proporciona. Los reguladores que escriben requisitos de ciberseguridad en 2026 no están especulando sobre si DMARC funciona. Están respondiendo a la evidencia de que sí lo hace.
La Brecha de Cumplimiento que Ahora Es una Responsabilidad
El informe de EasyDMARC de 2026 encontró que de los 937,931 dominios con registros DMARC, solo 411,935 están en quarantine o reject. Menos de uno de cada cuatro dominios que se molestaron en publicar un registro DMARC han llegado realmente al nivel de política que los reguladores exigen ahora. Para las organizaciones en el ámbito de PCI DSS, NIS2 o DORA, cada día que p=none permanece en DNS es un día de incumplimiento documentado.
Lo que Requiere DMARC en Nivel de Aplicación
Pasar de p=none a p=reject no es un cambio de registro DNS. Es un proyecto de infraestructura de correo electrónico. El camino es metódico:
Recopilación y análisis de informes agregados. Los informes agregados de DMARC (RUA) contienen una contabilidad detallada de cada servidor que envió correo reclamando ser de su dominio durante el intervalo de informe. No se puede aplicar de forma segura hasta haber analizado varias semanas de estos informes.
Descubrimiento de fuentes y autenticación. Los informes descubrirán fuentes de envío que no sabía que existían: una plataforma de automatización de marketing de un proveedor anterior, una integración SaaS que envía recibos transaccionales bajo su dominio, una oficina regional que utiliza un relay de correo local. Cada fuente legítima debe autenticarse antes de la aplicación.
Aplicación por fases. La transición de p=none a p=quarantine y luego a p=reject debe realizarse por etapas, con monitoreo en cada paso para detectar cualquier fuente legítima que se haya pasado por alto en la fase de descubrimiento.
La Documentación como Activo de Cumplimiento
Un aspecto subestimado del cumplimiento de DMARC bajo marcos regulatorios es la documentación. Los evaluadores de PCI DSS y los auditores supervisores de NIS2 no se limitan a verificar si existe un registro DMARC en el nivel de política correcto. Evalúan si la organización tiene un proceso repetible y documentado para mantener ese cumplimiento.
Eso significa:
- Registros de la fase de monitoreo y el análisis de informes agregados que precedió a la aplicación
- Documentación de todas las fuentes de envío autenticadas y el proceso para añadir nuevas
- Evidencia de revisión periódica de los informes DMARC para detectar fallos de autenticación de fuentes nuevas o modificadas
- Una política que regule cómo se aprueban e implementan los cambios de configuración de DMARC
Las organizaciones que logran p=reject pero no pueden demostrar el proceso que las llevó allí y los controles que lo mantienen solo están parcialmente en cumplimiento con los marcos que ahora requieren DMARC. El registro en DNS es el resultado. El proceso es el requisito.
La Intersección con las Leyes Globales de Marketing por Correo Electrónico
La presión regulatoria sobre la autenticación del correo electrónico llega junto con una presión paralela y separada sobre las prácticas de marketing por correo electrónico. La aplicación de la Ley de Spam de Australia produjo una multa de A$702,900 contra Lululemon en marzo de 2026. La CEMA del Estado de Washington ha desencadenado aproximadamente 115 demandas colectivas que apuntan a líneas de asunto engañosas.
Estas son marcos legales separados de PCI DSS, NIS2 y DORA, pero refuerzan la misma realidad organizacional: la infraestructura de correo electrónico está bajo escrutinio regulatorio en múltiples niveles simultáneamente. Las organizaciones que tratan estos como flujos de trabajo separados encontrarán que gestionan brechas de cumplimiento separadas. Las organizaciones que abordan el correo electrónico como una superficie de cumplimiento integrada, donde DMARC, la higiene de listas, los mecanismos de cancelación de suscripción y la documentación operativa forman parte del mismo programa, son las que están posicionadas para demostrar cumplimiento en toda la gama de marcos aplicables.
Gestionar el cumplimiento de DMARC en el ámbito de PCI DSS, NIS2 y DORA no es un proyecto puntual. Excello Mail ofrece a su equipo monitoreo continuo, análisis de informes agregados y orientación de aplicación que se documenta sola a medida que avanza. Comience su prueba gratuita en excello.email →