El correo electrónico sigue siendo la vulnerabilidad más explotada en los fallos de protección de datos que conducen a sanciones del RGPD. Las multas de más de 400 millones de euros impuestas desde 2020 por brechas relacionadas con el correo electrónico comparten patrones comunes: las organizaciones no implementaron controles básicos de autenticación, no monitorizaron remitentes no autorizados ni detectaron compromisos antes de que ocurriera una exfiltración masiva de datos.

La sanción a Coupang en 2024 ejemplifica este patrón. El minorista surcoreano enfrentó una multa de 15 M€ no porque fallara el cifrado, sino porque los controles de acceso y monitorización inadecuados permitieron que partes no autorizadas accedieran a datos de clientes a través de canales de correo electrónico comprometidos. La brecha no fue sofisticada: explotó brechas de autenticación que DMARC, la validación de remitentes y la detección de accesos no autorizados podrían haber detectado.

El RGPD no exige DMARC específicamente. Los Artículos 32 y 5(1)(f) requieren «medidas técnicas y organizativas apropiadas» y seguridad en el tratamiento «apropiada al riesgo». Los controles de autenticación de correo electrónico respaldan esos objetivos. Cuando las autoridades de aplicación investigan una brecha donde el phishing, la suplantación de identidad o el acceso de remitentes no autorizados contribuyeron a la exposición de datos, evalúan si la organización implementó medidas razonables para prevenirlo.

Este informe identifica siete brechas de seguridad en el correo electrónico que aparecen en las decisiones de sanción del RGPD, conecta cada una con fallos de autenticación prevenibles y explica cómo las organizaciones pueden cerrarlas.

I. Brecha 1: Sin Autenticación a Nivel de Dominio → Suplantación No Detectada

El Fallo de Cumplimiento:
Las organizaciones no publican registro SPF, ni política DMARC, o dejan DMARC en p=none indefinidamente. Los actores maliciosos suplantan dominios internos para dirigirse a empleados, socios o clientes. Cuando el correo electrónico suplantado conduce al robo de credenciales o exfiltración de datos, los reguladores preguntan: «¿Implementó medidas para prevenir la suplantación de dominio?»

Qué Puede Salir Mal:
SPF puede fallar silenciosamente cuando se agotan los tiempos de espera de búsquedas DNS (temperror) o cuando el registro excede 10 búsquedas DNS (permerror). DMARC puede pasar la autenticación pero fallar la alineación cuando el remitente del sobre difiere de la dirección From del encabezado. Que pase la autenticación no garantiza la colocación en la bandeja de entrada, y que falle la autenticación no siempre significa rechazo inmediato, pero la falta de aplicación elimina un control de detección crítico.

Prevención:
Inicie la monitorización DMARC, avance hacia la aplicación de p=quarantine o p=reject, y documente el cronograma. La aplicación de DMARC no garantiza la colocación en la bandeja de entrada, pero cuando es respetada por los servidores receptores, p=reject les instruye a rechazar mensajes no autenticados durante la entrega SMTP.

Las organizaciones sujetas al RGPD comúnmente implementan la aplicación de DMARC como parte de su programa de seguridad de correo electrónico. Use Skysnag Protect para identificar remitentes legítimos, detectar fuentes no autorizadas y escalonar la aplicación por subdominio, unidad de negocio y grupo de remitentes.

Conexión con el Artículo 32 del RGPD:
El Artículo 32 requiere «un proceso para probar, evaluar y valorar regularmente la eficacia de las medidas técnicas y organizativas». Un dominio sin aplicación no tiene mecanismo para bloquear o siquiera detectar la suplantación en tiempo real.

II. Brecha 2: Remitentes Externos No Monitorizados → Email de TI en la Sombra

El Fallo de Cumplimiento:
Plataformas de marketing, herramientas CRM, sistemas de tickets de soporte y aplicaciones SaaS envían correos electrónicos en nombre de la organización. TI no mantiene un inventario. Los empleados autorizan herramientas sin revisión de TI. Servicios fraudulentos o comprometidos envían mensajes suplantados, y la organización solo descubre el problema después de una brecha.

Qué Puede Salir Mal:
Los remitentes externos que no publican firmas DKIM o fallan la alineación SPF fallarán DMARC incluso cuando el servicio sea legítimo. Si la organización aplica DMARC en p=reject, el correo legítimo de servicios no verificados puede ser rechazado. Si la organización no lo aplica, los atacantes pueden suplantar usando servicios que la organización nunca autorizó.

Prevención:
Mantenga un inventario de remitentes. Requiera aprobación de TI antes de autorizar cualquier servicio para enviar en nombre de dominios corporativos. Use informes agregados de DMARC para descubrir remitentes no autorizados. Skysnag Protect muestra cada fuente que envía en su nombre e identifica fuentes que no están en su inventario aprobado.

Conexión con el Artículo 28 del RGPD:
El Artículo 28 requiere que las organizaciones utilicen encargados que «ofrezcan garantías suficientes» e implementen «medidas técnicas apropiadas». Si TI no puede identificar qué encargados envían correo electrónico, no pueden evaluar esas garantías.

III. Brecha 3: Registro DMARC Estático Sin Recopilación de Informes → Teatro de Cumplimiento

El Fallo de Cumplimiento:
La organización publica un registro DMARC que incluye rua=mailto:[email protected], pero nadie monitoriza el buzón. Los informes se acumulan sin leer. La organización no puede identificar nuevas amenazas, remitentes no autorizados o fallos de autenticación. Cuando ocurre una brecha, la organización no puede demostrar que la monitorización estaba activa.

Qué Puede Salir Mal:
Los informes agregados de DMARC llegan en formato XML desde cientos de fuentes diariamente. Sin análisis automatizado, los datos de los informes son inutilizables. Los fallos de entrega DNS, problemas de cuota de buzón y enrutamiento incorrecto pueden hacer que los informes dejen de llegar silenciosamente. Un registro estático sin monitorización no proporciona ningún beneficio de seguridad.

Prevención:
Use monitorización DMARC gestionada. En una implementación de Skysnag, el destino de informes es generado y mantenido por Skysnag. Los informes se analizan, normalizan y muestran en un panel que muestra el cumplimiento de remitentes, resultados de autenticación y nuevas fuentes en tiempo real.

Un registro estático tradicional como:

v=DMARC1; p=none; rua=mailto:[email protected]

puede funcionar, pero solo si los informes se reciben, analizan y se actúa sobre ellos activamente. El mejor enfoque es iniciar la monitorización DMARC a través de Skysnag y obtener un registro gestionado generado para su dominio.

Conexión con el Artículo 32 del RGPD:
El Artículo 32 requiere «medidas para garantizar la confidencialidad, integridad, disponibilidad y resiliencia continuas». Un registro sin monitorización no proporciona visibilidad continua.

IV. Brecha 4: Sin Política de Aplicación → Remitentes No Autorizados Pasan

El Fallo de Cumplimiento:
La organización publica DMARC en p=none y lo deja así. Los informes DMARC muestran fuentes que fallan, pero no se toma ninguna acción de aplicación. Los actores maliciosos descubren la falta de aplicación y suplantan el dominio a gran escala. Cuando el phishing conduce a una brecha de datos, las autoridades de aplicación evalúan si la organización implementó medidas de bloqueo razonables.

Qué Puede Salir Mal:
Cuando es respetado por el servidor receptor, p=reject les instruye a rechazar mensajes no autenticados durante la entrega SMTP y el mensaje no debería llegar a la bandeja de entrada o carpeta de spam. Sin embargo, la aplicación depende de que el servidor receptor respete la política. Algunos reenviadores, listas de correo y receptores mal configurados no lo hacen. La aplicación de DMARC no garantiza el rechazo en todas partes, pero reduce significativamente las tasas de éxito de suplantación.

Las organizaciones comúnmente permanecen en p=none porque temen bloquear correo legítimo. Ese temor es válido. Evite confiar en el despliegue basado en porcentajes (pct=) como estrategia principal. Los programas actuales conscientes de DMARC deberían escalonar la aplicación por dominio, subdominio, grupo de remitentes y función empresarial.

Prevención:
Use informes agregados de DMARC para identificar todos los remitentes legítimos. Verifique SPF y DKIM para cada uno. Pruebe la aplicación primero en subdominios de bajo riesgo. Mueva los dominios de producción a p=quarantine, luego a p=reject a medida que mejore el cumplimiento de los remitentes. Use Skysnag Protect para rastrear el estado de autenticación de remitentes y escalonar la aplicación de forma segura.

Conexión con el Artículo 5(1)(f) del RGPD:
El Artículo 5(1)(f) requiere «seguridad apropiada» para proteger contra «tratamiento no autorizado o ilícito». Un dominio que no instruye a los receptores a bloquear el uso no autorizado proporciona una protección más débil.

V. Brecha 5: Sin Rotación de DKIM → Compromiso de Clave No Detectado

El Fallo de Cumplimiento:
La organización publicó una clave DKIM hace cinco años y nunca la rotó. Un desarrollador deja la empresa con acceso a la clave privada. Un servidor se desmanteló sin revocación de clave. Una copia de seguridad de configuración que contiene la clave se almacena en un bucket S3 no asegurado. Los actores maliciosos encuentran la clave y firman mensajes maliciosos que pasan DMARC.

Qué Puede Salir Mal:
Las firmas DKIM pueden fallar cuando se rota la clave pero no se actualiza el DNS, cuando el cuerpo del mensaje se modifica en tránsito, o cuando los reenviadores eliminan los encabezados de firma. Que DKIM pase no garantiza que DMARC pase: también se requiere alineación. Sin embargo, una firma DKIM válida de una clave comprometida puede eludir completamente la aplicación de DMARC.

Prevención:
Rote las claves DKIM anualmente. Revoque las claves antiguas inmediatamente cuando se desmantelen servidores o cuando el personal con acceso a claves se vaya. Monitorice la consistencia de firma DKIM a través de informes DMARC. Use Skysnag Protect para rastrear el uso de DKIM entre remitentes y detectar firmas de selectores inesperados.

Conexión con el Artículo 32(1)(d) del RGPD:
El Artículo 32(1)(d) requiere medidas «para garantizar la confidencialidad, integridad, disponibilidad y resiliencia continuas de los sistemas de tratamiento». Una clave estática que nunca se rota aumenta el riesgo de compromiso con el tiempo.

VI. Brecha 6: Sin Visibilidad en la Infraestructura de Fuentes de Email → Compromiso No Detectado

El Fallo de Cumplimiento:
La organización sabe que envía correo electrónico, pero TI no puede listar cada dirección IP, dominio o servicio que envía en su nombre. Cuando los informes DMARC muestran una nueva fuente, nadie sabe si es legítima, fraudulenta o comprometida. Pasan días o semanas antes de que comience la investigación.

Qué Puede Salir Mal:
Los informes agregados de DMARC muestran el remitente del sobre (usado para SPF), el dominio From del encabezado (usado para alineación DMARC) y el dominio de firma DKIM. Si alguno de estos no coincide con los valores esperados, la autenticación puede pasar pero la suplantación sigue siendo posible. Por ejemplo, un servicio legítimo podría pasar SPF pero fallar la alineación DMARC porque el dominio From del encabezado difiere. La investigación es más difícil porque la monitorización muestra resultados de autenticación, pero el dominio no está instruyendo a los receptores a bloquear el uso no autenticado.

Prevención:
Mantenga un inventario completo de la infraestructura de correo electrónico autorizada: direcciones IP, servicios de envío, inclusiones SPF, selectores DKIM y modos de alineación DMARC. Compare los informes DMARC con el inventario diariamente. Use Skysnag Protect para automatizar el descubrimiento de remitentes, identificar nuevas fuentes y correlacionar resultados de autenticación con la infraestructura conocida.

Conexión con el Artículo 30 del RGPD:
El Artículo 30 requiere que las organizaciones «mantengan un registro de las actividades de tratamiento». El correo electrónico es una actividad de tratamiento. Si TI no puede listar los sistemas y servicios que envían correo electrónico, el registro está incompleto.

VII. Brecha 7: Sin Evidencia de Monitorización → Incapacidad de Demostrar Cumplimiento

El Fallo de Cumplimiento:
La organización afirma que monitoriza la seguridad del correo electrónico, pero no tiene registros, ni registros de respuesta a incidentes, ni evidencia de revisión de autenticación, ni documentación de decisiones de aplicación. Cuando ocurre una brecha, las autoridades de aplicación solicitan evidencia de monitorización proactiva. La organización no puede proporcionarla.

Qué Puede Salir Mal:
Las sanciones del RGPD escalan según la intención, negligencia y capacidad de respuesta de remediación. Las organizaciones que demuestran monitorización proactiva, aplicación basada en evidencia y respuesta documentada a incidentes reciben un trato más favorable. Las organizaciones que no pueden demostrar nada de esto enfrentan sanciones más altas.

Prevención:
Registre informes DMARC, decisiones de autenticación, cambios de remitentes y acciones de aplicación. Retenga registros según la política de protección de datos (evite la retención indefinida). Documente decisiones de escalonamiento de aplicación. Use Skysnag Comply para mantener evidencia de controles de autenticación de correo electrónico a través de dominios y remitentes, con pistas de auditoría para revisión de cumplimiento.

Conexión con los Artículos 5(2) y 24 del RGPD:
El Artículo 5(2) requiere que las organizaciones «puedan demostrar el cumplimiento». El Artículo 24 requiere «medidas técnicas y organizativas apropiadas» y la «capacidad de demostrarlas». La monitorización de autenticación de correo electrónico proporciona esa evidencia.

VIII. Lo Que el RGPD Realmente Requiere (y No Requiere)

El RGPD no exige DMARC específicamente. No especifica SPF, DKIM, BIMI ni ningún protocolo particular de autenticación de correo electrónico. Lo que sí requiere:

• Artículo 32: «Medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo».
• Artículo 5(1)(f): El tratamiento debe garantizar «seguridad apropiada» contra «tratamiento no autorizado o ilícito».
• Artículo 24: El responsable del tratamiento «aplicará las medidas técnicas y organizativas apropiadas» y «podrá demostrar que el tratamiento se realiza de conformidad con el presente Reglamento».

Los controles de autenticación de correo electrónico respaldan esos objetivos. Cuando las autoridades de aplicación investigan una brecha donde la suplantación, el acceso de remitentes no autorizados o la exfiltración de datos basada en correo electrónico contribuyeron al daño, evalúan si la organización implementó medidas preventivas razonables. Un dominio sin aplicación de DMARC, sin monitorización de remitentes y sin registro de autenticación presenta evidencia más débil de medidas razonables.

Las organizaciones que pueden demostrar monitorización proactiva, aplicación escalonada, mantenimiento de inventario de remitentes y respuesta documentada a incidentes muestran una postura de cumplimiento más sólida. Use Skysnag Comply para mantener esa evidencia a través de dominios, unidades de negocio y remitentes externos.

IX. Conclusiones Clave

• El RGPD no exige DMARC, pero los controles de autenticación de correo electrónico respaldan los objetivos de seguridad de los Artículos 32, 5(1)(f) y 24.
• Más de 400 millones de euros en multas del RGPD han involucrado brechas donde las deficiencias en la seguridad del correo electrónico contribuyeron al acceso no autorizado o la exfiltración de datos.
• Las siete deficiencias de seguridad de correo electrónico más comunes que aparecen en las decisiones de penalización del RGPD son: (1) ausencia de autenticación de dominio, (2) remitentes de terceros no supervisados, (3) DMARC estático sin recopilación de informes, (4) ausencia de política de aplicación, (5) sin rotación de DKIM, (6) sin visibilidad de la infraestructura de correo electrónico, y (7) sin evidencia de monitoreo.
• Pasar la autenticación no garantiza la colocación en la bandeja de entrada. Fallar la autenticación no siempre significa rechazo. Pero la aplicación proporciona un control medible que los reguladores pueden evaluar.
• Las organizaciones que demuestran monitoreo proactivo, aplicación gradual y respuesta documentada a incidentes reciben un trato más favorable durante las investigaciones de brechas.
• Utilice Skysnag Protect para identificar remitentes legítimos, detectar fuentes no autorizadas e implementar la aplicación de DMARC por subdominio y grupo de remitentes.
• Utilice Skysnag Comply para mantener evidencia de los controles de autenticación de correo electrónico, inventario de remitentes y decisiones de aplicación para revisión de cumplimiento.

Comience el monitoreo de DMARC con Skysnag y obtenga su registro DMARC gratuito: