Cómo configurar MTA-STS y TLS-RPT: detener la interceptación de correos electrónicos

Miles de millones de correos electrónicos circulan por Internet cada día, y una parte significativa de ellos sigue viajando sin cifrado obligatorio. Esa escala por sí sola convierte al correo electrónico en uno de los objetivos más atractivos para la interceptación, donde los mensajes pueden leerse o alterarse mientras están en tránsito sin que ni el remitente ni el destinatario se den cuenta.

La debilidad radica en cómo se entrega el correo electrónico. SMTP se basa en el cifrado oportunista, lo que permite a los atacantes eliminar o manipular el comando STARTTLS y forzar una conexión para volver al texto sin formato. Estos ataques de degradación de SMTP abren la puerta a la interceptación de tipo «man-in-the-middle», lo que permite a los atacantes supervisar el tráfico, capturar contenido confidencial o redirigir mensajes a través de servidores que controlan.

Contacto con nosotros Reservar una demostración

Índice de contenidos

    1. Agente de Transferencia de Correo-Seguridad de Transporte Estricta (MTA-STS)
    2. Garantizar el cifrado con MTA-STS
    3. La anatomía de un ataque MITM
    4. El archivo de políticas del MTA-STS
    5. Cómo publicar el archivo de políticas MTA-STS
    6. Registro DNS de MTA-STS
    7. Configuración de MTA-STS para su dominio
    8. CRetos de la implementación manual de MTA-STS
    9. Cómo probar y validar la configuración de MTA-STS
    10. Servicios MTA-STS alojados de PowerDMARC
    11. Informes SMTP TLS (TLS-RPT)
    12. Protección del transporte de correo electrónico con MTA-STS
    13. Preguntas frecuentes

El agente de transferencia de correo con seguridad de transporte estricta (MTA-STS) cierra esta brecha al exigir conexiones TLS cifradas entre los servidores de correo emisores y receptores, y al rechazar la entrega cuando no se puede establecer un canal seguro. En lugar de esperar que se utilice el cifrado, MTA-STS lo impone, lo que lo convierte en algo esencial para las organizaciones que desean configurar MTA-STS como parte de su estrategia de seguridad del correo electrónico.

encriptación tls

Agente de Transferencia de Correo-Seguridad de Transporte Estricta (MTA-STS)

MTA-STS, tal y como su nombre indica, es un protocolo que permite el transporte cifrado de mensajes entre dos servidores de correo SMTP. MTA-STS especifica a los servidores de envío que los correos electrónicos solo deben enviarse a través de una conexión cifrada TLS y que no deben entregarse en absoluto en caso de que no se establezca una conexión segura mediante el comando STARTTLS. Al mejorar la seguridad de los correos electrónicos en tránsito, MTA-STS ayuda a mitigar los ataques Man-In-The-Middle (MITM), como los ataques de degradación SMTP y los ataques de suplantación de DNS.

Leer más

Garantizar el cifrado con MTA-STS

El correo electrónico se envía entre servidores mediante SMTP, un protocolo que admite el cifrado, pero que no lo requiere de forma predeterminada. Esto crea una brecha por la que los mensajes pueden seguir transmitiéndose sin protección. MTA-STS cierra esa brecha al convertir el envío cifrado en un requisito en lugar de una opción.

Para comprender cómo funciona el cifrado durante el envío de correos electrónicos, imaginemos un servidor de correo que envía un mensaje a [email protected]. El agente de transferencia de correo (MTA) remitente primero realiza una consulta DNS para recuperar los registros MX de powerdmarc.com, identificando qué servidores de correo son responsables de recibir el mensaje. A continuación, el MTA remitente se conecta a uno de esos servidores y comprueba si admite el cifrado TLS mediante el comando STARTTLS. Si TLS está disponible, el correo electrónico se envía a través de una conexión cifrada. Si no lo está, el servidor remitente no consigue negociar una conexión segura y, sin aplicación, puede recurrir al envío del mensaje en texto sin formato.

MTA-STS cambia este comportamiento de entrega al aplicar requisitos de seguridad estrictos durante la comunicación entre servidores:

MTA-STS indica a los servidores de correo de envío que entreguen los mensajes únicamente a través de una conexión cifrada con TLS. Si no se puede establecer el cifrado, el mensaje no se entrega. Esto elimina el recurso silencioso al texto sin formato que hace posible la interceptación.

El servidor de correo receptor debe presentar un certificado TLS válido, y el nombre de dominio que figura en dicho certificado debe coincidir con el dominio definido en la política MTA-STS. Esto garantiza que el servidor emisor se comunica con el destino correcto y no con un host que se hace pasar por otro.

Las políticas MTA-STS se recuperan a través de HTTPS desde un servidor web seguro. La obtención de la política a través de un canal cifrado y autenticado impide que los atacantes modifiquen o falsifiquen las instrucciones de la política durante la transmisión.

Al aplicar el cifrado y validar tanto los certificados como las instrucciones de política, MTA-STS bloquea los ataques de degradación SMTP que se basan en eliminar o alterar el comando STARTTLS. Los servidores de envío ya no aceptan soluciones de respaldo inseguras cuando debería existir una conexión segura.

servicios alojados de mta sts
alojado MTA STS

MTA-STS se implementa mediante la publicación de un registro DNS que indica a los servidores de correo electrónico emisores que recuperen un archivo de políticas de un subdominio designado. Se accede al archivo de políticas a través de HTTPS, se valida mediante certificados TLS y contiene los nombres de host aprobados de los servidores de correo electrónico del destinatario. El protocolo indica a los servidores SMTP emisores que requieran una conexión cifrada y que verifiquen que el dominio que figura en el certificado TLS coincide con el dominio definido en el archivo de políticas. Si se aplica MTA-STS, en caso de que no se pueda negociar un canal cifrado, el mensaje no se entrega en absoluto.

La anatomía de un ataque MITM

Esencialmente, un ataque MITM tiene lugar cuando un atacante reemplaza o borra el comando STARTTLS para hacer que la conexión segura retroceda a una no segura, sin cifrado TLS. Esto se conoce como un ataque de downgrade. Después de realizar con éxito un ataque de downgrade, el atacante puede acceder y ver el contenido del correo electrónico sin obstáculos.

Un atacante MITM también puede sustituir los registros MX en la respuesta de la consulta DNS por un servidor de correo al que tenga acceso y que controle. En ese caso, el agente de transferencia de correo entrega el correo electrónico al servidor del atacante, lo que le permite acceder al contenido del correo y manipularlo. Posteriormente, el correo electrónico puede ser reenviado al servidor del destinatario previsto, sin ser detectado. Esto se conoce como un ataque de suplantación de DNS.

Ataque de degradación SMTP

Señales de advertencia

Los ataques MITM suelen operar de forma silenciosa, pero ciertos patrones pueden indicar que algo va mal durante la entrega del correo electrónico. Una señal de advertencia común son los fallos o retrasos inesperados en la entrega al comunicarse con dominios específicos, especialmente cuando esos dominios aceptaban previamente los mensajes sin problemas. El aumento repentino de los fallos en la negociación TLS, el retorno a conexiones no cifradas o los errores repetidos de STARTTLS también pueden indicar interferencias durante la transmisión.

Otro indicador es el comportamiento inconsistente del enrutamiento del correo. Los correos electrónicos pueden parecer que pasan por servidores desconocidos, o los registros pueden mostrar conexiones a hosts que no coinciden con los registros MX publicados del destinatario previsto. En casos más avanzados, los mensajes llegan alterados, truncados o reenviados a través de sistemas intermedios sin una explicación clara.

La detección depende en gran medida de la visibilidad. La supervisión de los registros de conexión SMTP ayuda a identificar fallos repetidos de cifrado o discrepancias en los certificados. TLS-RPT añade otra capa al proporcionar informes cuando los servidores no logran establecer conexiones TLS seguras, señalando problemas como intentos de degradación, certificados no válidos o fallos en la aplicación de políticas. 

Todas estas señales ayudan a detectar la actividad MITM que, de otro modo, permanecería oculta durante el flujo normal del correo electrónico.

El archivo de políticas del MTA-STS

El archivo de políticas MTA-STS es básicamente un archivo de texto simple, que tiene el siguiente aspecto:

versión: STSv1
modo: enforce
mx: mx1.powerdmarc.com
mx: mx2.powerdmarc.com
mx: mx3.powerdmarc.com
max_age: 604800

Nota: El campo de la versión debe incluirse al principio del archivo de texto, mientras que los demás campos pueden incorporarse en cualquier orden.

El archivo de políticas utiliza pares clave-valor, con cada valor codificado en una línea separada en el archivo de texto, como se muestra arriba. El tamaño de este archivo puede alcanzar hasta 64 KB. El nombre del archivo de políticas debe ser mta-sts.txt. Los archivos de políticas deben actualizarse cada vez que se añaden o modifican servidores de correo en el dominio.

Nota: Configurar el MTA-STS en modo enforce puede hacer que algunos correos no se entreguen. Por lo tanto, es aconsejable establecer el modo de política en pruebas y optar por un max_age bajo para asegurarse de que todo funciona correctamente antes de cambiar a la política de aplicación. Recomendamos configurar TLS-RPT para su política en modo de prueba también para recibir una notificación en caso de que los correos electrónicos se envíen en texto plano. 

Política MTA-STS

Cómo publicar el archivo de políticas MTA-STS

Para publicar el archivo de política MTA-STS, el servidor web que aloja su archivo debe:

  • Soporta HTTPS/SSL

    El archivo de políticas debe servirse a través de un servidor web habilitado para HTTPS para garantizar que los servidores de correo lo recuperen de forma segura.

  • Utilice un certificado emitido por una autoridad certificadora de confianza.

    El certificado del servidor debe estar firmado y validado por una autoridad de certificación raíz externa para que los MTA emisores puedan autenticar el origen de la política.

  • Aloja el archivo en un subdominio mta-sts dedicado.

    Se debe configurar un servidor web público con el subdominio mta-sts añadido a su dominio, que se utiliza exclusivamente para publicar la política MTA-STS.

  • Coloque el archivo de política en el directorio requerido.

    El archivo de política debe llamarse mta-sts.txt y publicarse dentro del directorio .well-known en el subdominio mta-sts.

  • Asegúrese de que el archivo de políticas sea accesible públicamente en la URL correcta.

    Los MTA emisores deben poder recuperar el archivo desde una ubicación con el formato
    https://mta-sts.yourdomain.com/.well-known/mta-sts.txt sin autenticación ni redireccionamientos.

alojado MTA STS

Registro DNS de MTA-STS

Se publica un registro DNS TXT para MTA-STS en el DNS de su dominio para especificar que su dominio admite el protocolo MTA-STS y para indicar que se actualicen los valores almacenados en caché en los MTA en caso de que se altere la política. El registro DNS MTA-STS se coloca en el subdominio _mta-sts como en: _mta-sts.powerdmarc.com. El registro TXT debe comenzar con v=STSv1, y el valor "id" valor puede contener hasta 32 caracteres alfanuméricos, incluidos de la siguiente manera:

 v=STSv1; id=30271001S00T000;

Nota: El valor del identificador del registro TXT debe actualizarse a un nuevo valor cada vez que se realicen cambios en la política. 

El registro DNS MTA-STS se utiliza para: 

  • Especifique la compatibilidad con MTA-STS para el dominio
  • Indicar al MTA que recupere la política a través de HTTPS en caso de que se modifique la política

Tenga en cuenta que con el registro DNS MTA-STS TXT, los MTA pueden almacenar el archivo de política durante un período de tiempo más largo sin tener que volver a obtener la política a menos que se haya modificado, mientras que sigue realizando una consulta DNS cada vez que se recibe un correo electrónico para el dominio.

Configuración de MTA-STS para su dominio

Para habilitar el MTA-STS para su dominio se requiere:

  • Añada un registro DNS de tipo cname en mta-sts.ejemplo.comdirigido al servidor web habilitado para HTTPS que aloja el archivo de política MTA-STS.

  • Añada un registro DNS de tipo txt o cname en _mta-sts.example.com que especifica la compatibilidad con MTA-STS para su dominio.

  • Configure un servidor web habilitado para HTTPS con un certificado válido para su dominio.

  • Habilite los informes TLS de SMTP para su dominio a fin de detectar problemas en la entrega del correo electrónico debido a fallos en el cifrado TLS.

icono de búsqueda de registros spf powerdmarc

Desafíos de la implementación manual de MTA-STS

La implementación manual de MTA-STS implica más que publicar un único registro DNS. Requiere coordinar la infraestructura web, los certificados, las políticas y el mantenimiento continuo, lo que puede plantear varios retos si no se gestiona con cuidado.

  • Requisito para un servidor web habilitado para HTTPS

    Las políticas MTA-STS deben alojarse en un servidor HTTPS de acceso público con un certificado TLS válido. Esto requiere aprovisionar la infraestructura, configurar TLS correctamente, renovar los certificados a tiempo y garantizar una alta disponibilidad.

    Solución: Las organizaciones con una infraestructura web limitada pueden reducir la complejidad utilizando un servicio MTA-STS alojado que gestione los servidores y los certificados automáticamente.

  • Mantenimiento continuo de los archivos de políticas

    Cualquier cambio en la configuración del servidor de correo requiere actualizar el archivo de políticas MTA-STS. Si el archivo está desactualizado, los correos electrónicos legítimos pueden fallar en su entrega una vez que se habilite la aplicación.

    Solución: La gestión centralizada de políticas o las herramientas automatizadas ayudan a garantizar que las actualizaciones se apliquen de forma inmediata y precisa.

  • Actualizaciones de registros DNS y control de versiones

    El registro MTA-STS TXT debe actualizarse con un nuevo valor de identificación cada vez que cambie la política. Las actualizaciones que falten o sean incorrectas pueden retrasar la actualización de la política y provocar una aplicación inconsistente.

    Solución: La automatización reduce el riesgo de errores humanos y mantiene los registros DNS alineados con los cambios en las políticas.

  • Visibilidad limitada de los fallos en la entrega

    Sin TLS-RPT, es posible que los problemas de entrega relacionados con el cifrado pasen desapercibidos. Incluso con TLS-RPT habilitado, los informes JSON sin procesar pueden ser difíciles de interpretar sin conocimientos especializados.

    Solución: Las plataformas de generación de informes que analizan y visualizan los informes TLS facilitan la detección de fallos y permiten responder rápidamente.

  • Mayores gastos generales operativos y esfuerzo de coordinación.

    La implementación manual requiere coordinación entre los equipos de DNS, correo electrónico y seguridad, lo que aumenta el riesgo de errores de configuración y retrasos.

    Solución: Los equipos deben evaluar si disponen del tiempo y la experiencia necesarios para mantener MTA-STS a largo plazo o si un enfoque gestionado se ajusta mejor a sus prioridades operativas.

Cómo probar y validar la configuración de MTA-STS

Las pruebas son un paso fundamental antes de pasar una política MTA-STS al modo de aplicación. Una vez habilitada la aplicación, se indica a los servidores de envío que rechacen la entrega de correos electrónicos si no se puede establecer una conexión TLS segura. Sin una validación adecuada, los errores de configuración pueden provocar la pérdida involuntaria de mensajes, por lo que es esencial realizar pruebas minuciosas para mantener la fiabilidad de la entrega de correos electrónicos.

  • Comprobaciones de propagación del DNS

    Después de publicar el registro MTA-STS TXT y las entradas DNS relacionadas, confirme que se resuelven correctamente en los resolutores DNS públicos. Una propagación incompleta o retrasada puede hacer que los servidores de envío se basen en políticas obsoletas o almacenadas en caché, lo que da lugar a un comportamiento inconsistente durante la entrega.

  • Accesibilidad del archivo de políticas

    Verifique que se pueda acceder al archivo de políticas MTA-STS a través de HTTPS en la ubicación prevista en el subdominio mta-sts. Se debe poder acceder al archivo sin redireccionamientos, requisitos de autenticación ni errores de certificado. Cualquier interrupción en el acceso puede impedir que los servidores de envío recuperen la política.

  • Verificación de compatibilidad con TLS

    Confirme que todos los hosts MX incluidos en la política admiten TLS y presentan certificados válidos que cumplen con los requisitos de la política. Una negociación TLS satisfactoria garantiza que se puedan establecer conexiones cifradas de forma coherente una vez que se habilite la aplicación.

Servicios MTA-STS alojados de PowerDMARC

PowerDMARC le hace la vida mucho más fácil al encargarse de todo eso por usted, completamente en segundo plano. Una vez que le ayudamos a configurarlo, no tendrá que volver a pensar en ello.

  • Le ayudamos a publicar sus registros cname con unos pocos clics

  • Nos encargamos del mantenimiento del servidor web y del alojamiento de los certificados

  • A través de nuestros servicios MTA-STS alojados, la implantación por su parte se reduce a la simple publicación de unos pocos registros DNS

  • Puede realizar cambios en la política MTA-STS al instante y con facilidad, a través del panel de control de PowerDMARC, sin tener que realizar manualmente los cambios en el DNS

  • Los servicios MTA-STS alojados de PowerDMARC cumplen con la RFC y son compatibles con los últimos estándares TLS

  • Desde la generación de certificados y el archivo de políticas MTA-STS hasta la aplicación de políticas, le ayudamos a eludir las enormes complejidades que conlleva la adopción del protocolo

Informes SMTP TLS (TLS-RPT)

Con el fin de hacer más segura y cifrada la conexión entre dos servidores SMTP que se comunican a través de TLS, se introdujo MTA-STS para aplicar el cifrado y evitar que los correos electrónicos se envíen en texto sin cifrar cuando no se puede establecer una conexión segura. Sin embargo, sigue sin resolverse un problema: cómo notificar a los propietarios de dominios cuando los servidores remotos experimentan problemas de entrega de correo electrónico causados por fallos de TLS. Aquí es donde entra en juego TLS-RPT, que complementa a MTA-STS proporcionando informes de diagnóstico que permiten supervisar y resolver problemas de comunicación del servidor, como certificados TLS caducados, configuraciones incorrectas del servidor de correo o negociaciones TLS fallidas.

Los informes TLS ayudan a detectar y responder a los problemas en la entrega del correo electrónico a través de un mecanismo de información en forma de archivos JSON. Estos archivos JSON pueden ser complicados e indescifrables para una persona no técnica.

PowerDMARC ayuda a simplificar los archivos JSON en forma de documentos sencillos, completos y legibles con gráficos y tablas para su comodidad. Los informes de diagnóstico de su dominio también se muestran en dos formatos en el panel de control de PowerDMARC:por resultado y por fuente de envío.

 

powerdmarc tls rpt

¿Qué hace TLS-RPT?

TLS-RPT está diseñado para informar de los fallos en la entrega de correos electrónicos relacionados con el cifrado TLS entre servidores de correo. Su objetivo principal es proporcionar a los propietarios de dominios visibilidad sobre las situaciones en las que los mensajes no se pueden entregar de forma segura, lo que ayuda a identificar problemas que, de otro modo, permanecerían ocultos durante la comunicación SMTP normal.

A través de estos informes, TLS-RPT ayuda a identificar problemas como fallos en las negociaciones TLS entre los servidores de envío y recepción, certificados TLS caducados o no válidos y errores de configuración en cualquiera de los extremos del intercambio de correo. Esta información permite a los administradores localizar con precisión dónde se produce la interrupción del cifrado y tomar las medidas correctivas oportunas.

Los informes TLS-RPT son generados y enviados por agentes de transferencia de correo compatibles, normalmente a diario, lo que proporciona una visibilidad continua del estado de la entrega segura del correo electrónico.

gráficos json

Cómo habilitarlo

TLS-RPT se habilita publicando un registro DNS TXT en la ubicación _smtp._tls requerida para su dominio. Este registro indica la compatibilidad con los informes TLS y especifica el destino al que deben enviarse los informes de diagnóstico.

El registro TXT define una o varias direcciones de notificación, normalmente direcciones de correo electrónico o puntos finales HTTPS, que los servidores de correo compatibles utilizan para enviar datos TLS-RPT. Una vez creado el registro, la notificación se inicia automáticamente sin necesidad de realizar ningún cambio en el comportamiento del servidor de correo.

TLS-RPT se puede configurar manualmente añadiendo el registro TXT directamente al DNS o a través de plataformas que proporcionan una configuración basada en una interfaz de usuario. El uso de una interfaz gestionada simplifica la implementación, ya que se encarga de la creación y validación de registros, lo que reduce el riesgo de errores de sintaxis o de configuración incorrecta.

Leer más

Protección del transporte de correo electrónico con MTA-STS

El correo electrónico sigue siendo un canal de comunicación fundamental, pero sin un cifrado reforzado, es vulnerable a ataques de degradación y MITM que pueden exponer el contenido de los mensajes o interrumpir su entrega. Proteger el correo electrónico en tránsito es esencial para preservar la confidencialidad y mantener la confianza entre los servidores de correo emisores y receptores.

MTA-STS refuerza el transporte de correo electrónico al exigir el cifrado TLS y rechazar la entrega cuando no se pueden establecer conexiones seguras. Al eliminar la alternativa de la comunicación sin cifrar, ayuda a garantizar que los mensajes se entreguen únicamente a través de canales autenticados y protegidos, lo que mejora la coherencia y la fiabilidad en los intercambios entre servidores.

La adopción satisfactoria de MTA-STS depende de una preparación minuciosa. Las políticas deben configurarse con precisión, la infraestructura de soporte debe validarse y la aplicación debe introducirse gradualmente tras realizar pruebas exhaustivas. Saltarse estos pasos puede dar lugar a fallos de entrega no deseados, especialmente cuando las políticas se pasan demasiado rápido al modo de aplicación.

Antes de habilitar la aplicación, las organizaciones deben revisar su postura actual en materia de seguridad del correo electrónico, confirmar la preparación de TLS en todos los servidores de correo y asegurarse de que los archivos DNS y de políticas se publiquen correctamente. La supervisión continua y la validación periódica siguen siendo importantes a lo largo del tiempo, ya que las configuraciones de los servidores cambian y los certificados caducan, lo que ayuda a garantizar que las políticas MTA-STS sigan protegiendo eficazmente la entrega del correo electrónico.

Preguntas frecuentes

El panel de control de PowerDMARC le permite configurar automáticamente MTA-STS y TLS-RPT para su dominio publicando sólo tres registros CNAME en las DNS de su dominio. Desde el alojamiento de los archivos de políticas y certificados de MTA-STS hasta el mantenimiento del servidor web, nosotros nos encargamos de todo en segundo plano sin que usted tenga que hacer ningún cambio en sus DNS. El despliegue de MTA-STS por su parte con PowerDMARC se reduce a unos pocos clics.

Puede desplegar y gestionar MTA-STS para todos sus dominios desde su cuenta PowerDMARC, a través de un único panel de vidrio. En caso de que alguno de esos dominios esté utilizando servidores de correo de recepción que no soporten STARTTLS, se reflejará en sus informes TLS siempre que tenga TLS-RPT activado para esos dominios.

Siempre es aconsejable establecer el modo de la política MTA-STS en prueba durante las fases iniciales del despliegue, para que pueda supervisar las actividades y obtener visibilidad de su ecosistema de correo electrónico antes de cambiar a una política más agresiva como la de forzar. De este modo, aunque los correos electrónicos no se envíen a través de una conexión cifrada TLS, se enviarán en texto plano. Sin embargo, asegúrese de habilitar TLS-RPT para ser notificado si esto sucede.

TLS-RPT es un amplio mecanismo de información que le permite recibir una notificación en caso de que no se haya podido establecer una conexión segura y no se haya podido entregar el correo electrónico. Esto le ayuda a detectar problemas en la entrega de correos electrónicos o correos electrónicos entregados a través de una conexión no segura para que pueda mitigarlos y resolverlos rápidamente.

Debe tener en cuenta que, aunque el MTA-STS garantiza que los correos electrónicos se transfieran a través de una conexión cifrada TLS, en caso de que no se negocie una conexión segura, el correo electrónico podría no entregarse en absoluto. Sin embargo, esto es necesario ya que garantiza que el correo electrónico no se entregue a través de una vía no cifrada. Para evitar este tipo de problemas, es aconsejable configurar una política MTA-STS en modo de prueba y habilitar inicialmente TLS-RPT para su dominio, antes de proceder al modo de aplicación MTA-STS. 

Puede cambiar fácilmente el modo MTA-STS desde el panel de control de PowerMTA-STS seleccionando el modo de política deseado y guardando los cambios sin necesidad de realizar ningún cambio en sus DNS.

Puede desactivar MTA-STS para su dominio estableciendo el modo de política en ninguno, lo que indica a los MTA que su dominio no es compatible con el protocolo, o eliminando su registro DNS TXT de MTA-STS. 

Los registros MX del archivo de políticas MTA-STS deben incluir las entradas de todos los servidores de correo de recepción utilizados por su dominio.

Programe una demostración hoy mismo
correo electrónico seguro powerdmarc

Prueba de 15 díasAgendar demo