Las plataformas digitales están bajo más presión que nunca para demostrar que sus servicios son seguros, responsables y resistentes al abuso.

La Ley de Servicios Digitales de la Unión Europea ha acelerado ese cambio al elevar las expectativas en torno a la gobernanza de las plataformas, la protección del usuario, la transparencia, la gestión de riesgos y la responsabilidad en todo el ecosistema digital. La Comisión Europea describe la DSA como un marco diseñado para hacer que el entorno en línea sea más seguro y confiable. (Estrategia Digital)

La mayor parte de la discusión en torno a la DSA se centra en la moderación de contenido, el contenido ilegal, la trazabilidad de comerciantes, la transparencia publicitaria, el riesgo sistémico y la responsabilidad de las plataformas.

Pero hay otra capa que a menudo recibe menos atención:

Cómo se comunican las plataformas con usuarios, clientes, comerciantes, socios y equipos internos.

El correo electrónico sigue siendo uno de los canales de confianza más importantes en la economía digital. Las plataformas lo utilizan para verificar cuentas, restablecer contraseñas, notificar a los usuarios, apoyar a los vendedores, comunicar decisiones de políticas, enviar alertas de seguridad y gestionar flujos de trabajo operativos.

Si esos correos electrónicos pueden ser suplantados, falsificados o abusados, la confianza en la plataforma se debilita.

Ahí es donde la autenticación de correo electrónico se vuelve estratégicamente importante.

DMARC, SPF, DKIM, MTA-STS y TLS-RPT no hacen que una organización sea «conforme con la DSA» por sí mismos. La DSA no exige estos protocolos por nombre.

Pero para las plataformas que operan en Europa, la autenticación de correo electrónico respalda los objetivos más amplios de confianza, seguridad, lucha contra el abuso y gobernanza que la regulación digital moderna espera que las organizaciones gestionen.

El problema ya no es solo la capacidad de entrega.

Es si la organización puede demostrar que su capa de comunicación está controlada, monitoreada y protegida contra el abuso de dominio.

I. La DSA eleva el estándar de confianza digital

La DSA es parte de un movimiento regulatorio más amplio en Europa: se espera que los servicios digitales operen con mayor responsabilidad.

Esa responsabilidad no se detiene en la interfaz de la plataforma.

Se extiende a los sistemas que las plataformas usan para comunicarse con usuarios y partes interesadas.

Una plataforma puede tener políticas de moderación sólidas, términos de servicio claros y procedimientos de escalamiento documentados. Pero si los atacantes pueden enviar alertas de cuenta falsas, avisos de cumplimiento falsos, comunicaciones de vendedor falsas o correos electrónicos de soporte falsos utilizando el dominio de la plataforma, el modelo de confianza está incompleto.

Para los usuarios, el correo electrónico a menudo se siente como la plataforma.

Un correo electrónico de restablecimiento de contraseña, una solicitud de verificación de vendedor, un aviso de violación de políticas o una alerta de seguridad pueden provocar una acción inmediata. Si ese mensaje es fraudulento, el usuario puede no distinguir entre abuso de la plataforma y fallo de la plataforma.

Por eso la autenticación de correo electrónico pertenece a la conversación de confianza en la era DSA.

No como una casilla legal limitada.

Como un control práctico para proteger la credibilidad de la comunicación de la plataforma.

II. Qué protege realmente la autenticación de correo electrónico

La autenticación de correo electrónico ayuda a los servidores de correo receptores a determinar si un mensaje que dice provenir de un dominio está autorizado.

Los protocolos básicos funcionan juntos:

• SPF identifica qué servidores están autorizados para enviar correo electrónico para un dominio.
• DKIM agrega una firma criptográfica para verificar que un mensaje fue autorizado por el dominio firmante y no fue alterado en tránsito.
• DMARC conecta la autenticación con el dominio From visible que ven los usuarios.
• MTA-STS ayuda a aplicar el transporte de correo cifrado entre servidores de correo compatibles.
• TLS-RPT proporciona informes sobre problemas de entrega TLS.

Para los operadores de plataformas, el control más importante es la alineación DMARC.

Un mensaje pasa DMARC solo cuando al menos una de las siguientes es verdadera:

• SPF pasa y el dominio autenticado por SPF se alinea con el dominio From visible.
• DKIM pasa y el dominio firmante DKIM se alinea con el dominio From visible.

Esto es importante porque los usuarios no ven los encabezados de autenticación. Ven el dominio From visible.

DMARC ayuda a proteger esa identidad visible.

Cuando DMARC se aplica en cuarentena o rechazo, el propietario del dominio le dice a los sistemas receptores cómo manejar mensajes que fallan la autenticación y alineación. Eso ayuda a reducir la suplantación de dominio exacto, donde los atacantes intentan enviar correo electrónico que parece provenir directamente del dominio real de la plataforma.

III. Qué no resuelve la autenticación de correo electrónico

La autenticación de correo electrónico es poderosa, pero no es un programa completo contra el abuso.

DMARC no detiene todos los ataques de phishing. No previene el registro de dominios similares. No detiene la suplantación de nombre para mostrar. No garantiza la ubicación en la bandeja de entrada. No reemplaza la detección de fraude, la educación del usuario, la moderación de contenido, los controles de acceso o la respuesta a incidentes.

Esta distinción es importante.

La autenticación de correo electrónico protege la identidad del dominio propio de la plataforma.

No elimina todas las formas de suplantación.

Un programa de confianza maduro necesita ambos:

• DMARC, SPF y DKIM para proteger el dominio real.
• Monitoreo de marca, detección de abuso y flujos de trabajo de eliminación para abordar dominios similares e infraestructura de suplantación.

Para las plataformas relevantes para la DSA, esta distinción hace que el programa sea más creíble. Muestra que la autenticación de correo electrónico se entiende como una parte de una arquitectura más amplia de confianza y seguridad.

IV. Por qué las plataformas deberían preocuparse

Las plataformas envían correos electrónicos en los que los usuarios confían.

Los ejemplos incluyen:

• Correos electrónicos de verificación de cuenta
• Correos electrónicos de restablecimiento de contraseña
• Alertas de inicio de sesión
• Mensajes de incorporación de vendedores o comerciantes
• Avisos de violación de políticas
• Alertas de seguridad
• Actualizaciones de casos de soporte
• Notificaciones de pago y facturación
• Correos electrónicos de operación de mercado
• Avisos regulatorios o legales

Si los atacantes pueden suplantar estas comunicaciones, el impacto puede ser grave.

Un aviso de política falso puede engañar a un vendedor para que envíe credenciales. Una alerta de seguridad falsa puede empujar a un usuario a un portal de phishing. Un mensaje de soporte falso puede redirigir a un cliente hacia el fraude. Una notificación de pago falsa puede dañar la confianza en la plataforma.

Desde una perspectiva de confianza, la plataforma tiene la responsabilidad de reducir la posibilidad de que su propio dominio pueda ser abusado de esta manera.

DMARC respalda esa responsabilidad al ayudar a las plataformas a responder preguntas importantes:

• ¿Qué sistemas están autorizados para enviar correo electrónico para nuestros dominios?
• ¿Qué plataformas de terceros envían en nuestro nombre?
• ¿Están correctamente autenticados los correos electrónicos dirigidos al usuario?
• ¿Están alineados los mensajes de seguridad y soporte?
• ¿Están intentando fuentes desconocidas usar nuestro dominio?
• ¿Están expuestos los dominios regionales, de campaña o heredados?
• ¿Estamos monitoreando los fallos de autenticación a lo largo del tiempo?

Estas son preguntas operativas, pero tienen valor de gobernanza.

Muestran si la organización está gestionando activamente la integridad de su capa de comunicación.

V. El riesgo oculto: protección parcial

Muchas organizaciones protegen primero su dominio principal.

Eso es un buen comienzo, pero no es suficiente.

Las plataformas a menudo operan muchos dominios y subdominios:

• Dominios corporativos principales
• Dominios de productos
• Dominios de soporte
• Dominios de mercado
• Dominios de incorporación de vendedores
• Dominios regionales
• Dominios de campaña
• Dominios de desarrolladores o API
• Dominios heredados

Los atacantes no necesitan suplantar el dominio mejor protegido. Buscan el dominio creíble más débil.

Una plataforma puede aplicar DMARC en su dominio principal pero dejar un dominio regional o de campaña en modo de monitoreo. Ese dominio aún puede ser abusado en campañas de phishing que parecen creíbles para los usuarios.

Esto crea un problema de gobernanza.

Si la organización ha identificado la suplantación de dominio como un riesgo, la implementación parcial se vuelve más difícil de defender con el tiempo.

Un programa maduro debe cubrir la cartera completa de dominios, no solo el dominio más visible.

VI. Los remitentes de terceros crean la mayor complejidad

Las plataformas modernas rara vez envían todo el correo electrónico desde un solo lugar.

Dependen de múltiples servicios:

• Plataformas CRM
• Sistemas de automatización de marketing
• Herramientas de soporte al cliente
• Proveedores de identidad
• Plataformas de facturación
• Sistemas de notificación de mercado
• Proveedores de correo electrónico transaccional
• Herramientas de comunicación interna y de RRHH

Cada remitente debe estar autorizado, autenticado y alineado.

Aquí es donde muchos programas de autenticación de correo electrónico fallan.

Un proveedor puede estar incluido en SPF pero fallar la alineación DMARC. Otra plataforma puede firmar con DKIM, pero bajo su propio dominio en lugar del dominio de la plataforma. Un equipo de negocios puede lanzar una campaña desde un remitente no aprobado. Un sistema heredado puede continuar enviando correo sin autenticación adecuada.

Estas brechas crean problemas tanto de seguridad como de gobernanza.

Para las plataformas que operan bajo expectativas regulatorias más estrictas, la gestión de remitentes de terceros no debe ser informal. Debe ser parte de la incorporación de proveedores, la gestión de cambios y la revisión de seguridad.

VII. Un programa práctico de autenticación de correo electrónico alineado con la DSA

El enfoque correcto no es tratar a DMARC como un proyecto rápido de DNS.

El enfoque correcto es tratar la autenticación de correo electrónico como un programa de confianza controlado.

VIII. 1. Construir un inventario completo de dominios

Comience identificando cada dominio y subdominio utilizado para la comunicación de la plataforma.

Incluya:

• Dominios dirigidos al usuario
• Dominios de soporte
• Dominios de mercado o comerciantes
• Dominios regionales
• Dominios de campaña
• Dominios de correo electrónico transaccional
• Dominios heredados
• Dominios de comunicación interna

Para cada dominio, documente si envía correo electrónico, quién lo posee, qué sistemas lo usan y qué política de autenticación está actualmente en su lugar.

IX. 2. Identificar cada remitente legítimo

Cree un inventario de remitentes.

Para cada fuente de envío, documente:

• Nombre de la plataforma o proveedor
• Propietario del negocio
• Tipo de mensaje
• Dominio de envío
• Autorización SPF
• Estado de firma DKIM
• Estado de alineación DMARC
• Volumen
• Criticidad
• Estado de aprobación
• Fecha de revisión

Este inventario se convierte en la base para las operaciones de seguridad, la gestión de proveedores y la evidencia de cumplimiento.

X. 3. Alinear SPF y DKIM

DMARC depende de SPF y DKIM.

Antes de la aplicación, los remitentes legítimos deben pasar SPF o DKIM alineado.

Los registros SPF deben incluir solo remitentes autorizados y deben permanecer dentro de los límites de búsqueda de DNS. DKIM debe estar habilitado para todas las comunicaciones principales dirigidas al usuario y sensibles a la seguridad.

Cuando sea posible, los remitentes de terceros deben firmar con DKIM alineado al dominio de la plataforma. Esto suele ser más confiable que SPF en escenarios complejos de enrutamiento y reenvío.

XI. 4. Iniciar el monitoreo DMARC

Antes de avanzar hacia la aplicación, las plataformas necesitan visibilidad.

Esa visibilidad comienza con el monitoreo DMARC.

La ruta recomendada es generar un registro de monitoreo DMARC gratuito a través de Skysnag. Esto le da a la organización un destino de informes administrado y permite a los equipos de seguridad comenzar a recopilar datos de autenticación sin construir manualmente un registro estático que puede nunca ser revisado.

Comience aquí:

«`text id=»skysnag-signup»
https://app.skysnag.com/en/register/

Una vez que se agrega el dominio, Skysnag proporciona el registro DMARC para publicar en DNS.

Un registro de monitoreo DMARC estático tradicional puede verse así:

dns id=»dmarc-static-example»
v=DMARC1; p=none; rua=mailto:[email protected]

Ese enfoque puede funcionar, pero solo si alguien está recibiendo, analizando, evaluando y actuando activamente sobre los informes.

Un registro estático sin monitoreo crea una falsa sensación de progreso.

En esta etapa, el objetivo no es la aplicación. El objetivo es la visibilidad.

Monitorear:

- Remitentes legítimos que pasan DMARC

- Remitentes legítimos que fallan DMARC

- Fuentes desconocidas

- Flujos de correo de alto volumen

- Comportamiento de subdominios

- Diferencias regionales

- Intentos de suplantación

- Problemas de alineación de terceros

Evite habilitar informes de fallo forenses por defecto. Pueden contener información sensible y solo deben usarse después de una revisión de privacidad, legal y de seguridad.

## 5. Avanzar hacia la aplicación

Una vez que los remitentes legítimos estén alineados, avance hacia la aplicación.

Una ruta práctica es:

1. Use el modo de monitoreo para descubrimiento.

2. Mueva dominios o subdominios seleccionados a cuarentena.

3. Remedie los fallos de remitentes legítimos.

4. Mueva dominios maduros a rechazo.

5. Continúe monitoreando después de la aplicación.

Antes de pasar a rechazo, confirme:

- Los remitentes críticos pasan DMARC.

- Las plataformas de terceros están alineadas.

- Los propietarios del negocio han revisado el impacto.

- Los equipos de soporte están preparados.

- Existen procedimientos de reversión.

- Las excepciones están documentadas.

La aplicación de DMARC debe basarse en evidencia, no en suposiciones.

## 6. Agregar MTA-STS y TLS-RPT donde sea apropiado

DMARC protege la autenticación del remitente. No aplica transporte cifrado entre servidores de correo.

MTA-STS y TLS-RPT respaldan la capa de transporte.

MTA-STS permite que un dominio publique una política que requiere que los servidores de correo compatibles usen TLS al entregar correo a ese dominio. TLS-RPT proporciona informes sobre problemas de entrega TLS.

Para plataformas que envían comunicaciones de cuenta, soporte, mercado o seguridad, estos controles pueden fortalecer la cadena general de confianza del correo electrónico.

Ejemplo de política MTA-STS:

text id=»mta-sts-example»
version: STSv1
mode: enforce
mx: mail.example.com
max_age: 86400

Ejemplo de registro TLS-RPT:

dns id=»tls-rpt-example»
_smtp._tls.example.com. IN TXT «v=TLSRPTv1; rua=mailto:[email protected]»
«`

XII. La gobernanza importa más que el registro DNS

Un programa sólido de autenticación de correo electrónico necesita propiedad.

Sin gobernanza, la postura de autenticación se desvía.

Se agregan nuevos proveedores. Se lanzan campañas. Los equipos regionales crean dominios. Los registros DNS cambian. Las claves DKIM rotan. Los sistemas heredados permanecen activos.

Los elementos de gobernanza recomendados incluyen:

• Patrocinador ejecutivo
• Propietario de seguridad
• Propietario de DNS
• Parte interesada de cumplimiento
• Propietario del negocio para cada remitente
• Proceso de incorporación de proveedores
• Flujo de trabajo de gestión de cambios
• Proceso de excepciones
• Cadencia de revisión regular
• Procedimiento de respuesta a incidentes

Aquí es donde el programa se vuelve defendible.

No porque existe un registro DMARC, sino porque la organización puede demostrar que la autenticación de correo electrónico es propiedad, monitoreada y mantenida.

XIII. Evidencia que las plataformas deben mantener

Para organizaciones relevantes para la DSA, la evidencia importa.

Mantenga documentación de:

• Inventario de dominios
• Inventario de remitentes
• Registros SPF, DKIM, DMARC, MTA-STS y TLS-RPT
• Historial de políticas DMARC
• Análisis de informes de autenticación
• Remediación de remitentes
• Aprobaciones de terceros
• Decisiones de excepciones
• Procedimientos de reversión
• Cadencia de monitoreo
• Acciones de respuesta a incidentes
• Controles de seguridad de transporte

Esta evidencia ayuda a demostrar que la comunicación de la plataforma se gestiona activamente como parte del programa más amplio de confianza y lucha contra el abuso de la organización.

XIV. Lista de verificación de implementación

Use esta lista de verificación como punto de partida práctico.

• [ ] Inventariar todos los dominios y subdominios utilizados para la comunicación de la plataforma.
• [ ] Identificar todas las fuentes de envío internas y de terceros.
• [ ] Mapear cada remitente a un propietario del negocio.
• [ ] Confirmar que los registros SPF incluyen solo remitentes autorizados.
• [ ] Revisar los límites de búsqueda SPF.
• [ ] Habilitar DKIM para plataformas de envío críticas.
• [ ] Confirmar la alineación de SPF o DKIM con el dominio From visible.
• [ ] Iniciar el monitoreo DMARC a través de Skysnag y publicar el registro de monitoreo generado.
• [ ] Si usa un registro DMARC estático tradicional, confirme que los informes se recopilan y revisan activamente.
• [ ] Analizar los informes DMARC antes de la aplicación.
• [ ] Remediar remitentes legítimos que fallan la autenticación.
• [ ] Mover dominios maduros hacia cuarentena o rechazo.
• [ ] Evitar informes forenses predeterminados a menos que sean aprobados por equipos de privacidad y legales.
• [ ] Revisar dominios de soporte, mercado, vendedor, seguridad y notificación de usuario.
• [ ] Establecer requisitos de incorporación de remitentes de terceros.
• [ ] Implementar MTA-STS y TLS-RPT donde sea apropiado.
• [ ] Definir propiedad y rutas de escalamiento.
• [ ] Mantener documentación para la preparación de gobernanza y auditoría.
• [ ] Revisar la postura de autenticación regularmente.

XV. Cómo ayuda Skysnag Comply

Skysnag Comply ayuda a las organizaciones a gestionar la capa de evidencia y monitoreo detrás de la autenticación de correo electrónico.

Para plataformas dirigidas a la UE, Skysnag Comply respalda:

• Visibilidad del inventario de dominios
• Monitoreo DMARC
• Visibilidad de alineación SPF y DKIM
• Detección de remitentes no autorizados
• Revisión de remitentes de terceros
• Seguimiento de preparación para la aplicación
• Informes orientados al cumplimiento
• Recopilación de evidencia para revisiones de gobernanza
• Visibilidad continua de fallos de autenticación

Skysnag Comply no convierte la DSA en un mandato DMARC.

Ayuda a las organizaciones a demostrar que la autenticación de correo electrónico se monitorea, gobierna y mantiene como parte de un programa más amplio de confianza y lucha contra el abuso.

XVI. Conclusiones Clave

La Ley de Servicios Digitales no exige DMARC, SPF, DKIM, MTA-STS o TLS-RPT por nombre.

Pero las plataformas que operan en Europa no deben ignorar el papel de la comunicación por correo electrónico confiable en la seguridad del usuario, la integridad de la plataforma, las operaciones del mercado, los flujos de trabajo de soporte y la respuesta a incidentes.

DMARC ayuda a reducir la suplantación de dominio exacto. SPF y DKIM proporcionan señales de autenticación. MTA-STS y TLS-RPT brindan visibilidad de la seguridad del transporte.

En conjunto, estos controles ayudan a las organizaciones a mantener una postura de confianza en el correo electrónico más defendible.

Para las plataformas relevantes bajo la DSA, la pregunta no es solo:

«¿La DSA requiere explícitamente DMARC?»

La pregunta más sólida es:

«¿Podemos demostrar que las comunicaciones de la plataforma están autenticadas, monitoreadas, gobernadas y protegidas contra el abuso de dominio?»

Ahí es donde la autenticación de correo electrónico se vuelve estratégicamente importante.

Comienza el monitoreo DMARC con Skysnag y obtén tu registro DMARC gratuito: