Alojamiento MTA-STS Gratuito

Por qué MTA-STS es esencial

SMTP fue diseñado en 1982 sin cifrado. STARTTLS se añadió posteriormente para cifrar el correo en tránsito, pero tiene un fallo crítico: es oportunista. Un servidor remitente anuncia soporte STARTTLS y el servidor receptor puede aceptarlo o ignorarlo. Nada obliga a que la conexión permanezca cifrada.

Esto crea una ventana para los ataques de downgrade SMTP. Un atacante posicionado entre dos servidores de correo (mediante secuestro BGP, suplantación DNS o interceptación a nivel de red) elimina el comando STARTTLS del handshake SMTP. El servidor remitente no ve opción de cifrado y recurre al texto plano. El email viaja sin cifrar, legible por cualquiera en la ruta.

MTA-STS (RFC 8461) cierra esta brecha. Publica una política que indica a los servidores remitentes: "este dominio requiere TLS. Si el cifrado falla, no recurras al texto plano." El servidor remitente debe establecer una conexión TLS válida o poner el mensaje en cola para reintento.

La barrera de despliegue: MTA-STS requiere alojar un archivo de política en https://mta-sts.captaindns.com/.well-known/mta-sts.txt a través de HTTPS con un certificado válido. Para muchas organizaciones, configurar y mantener un servidor web dedicado para un único archivo de texto resulta desproporcionado. CaptainDNS elimina esta barrera por completo.

Qué sucede sin MTA-STS

Sin MTA-STS, el transporte de tu correo depende únicamente de TLS oportunista. Esto es lo que implica en la práctica:

• Interceptación en texto plano: cualquier atacante a nivel de red puede leer tus emails eliminando STARTTLS. Esto no es teórico. Se han documentado programas de vigilancia estatales e interceptación a nivel de ISP.
• Sin verificación por parte del remitente: sin una política publicada, los servidores remitentes no tienen forma de saber que tu dominio requiere TLS. Degradarán silenciosamente si algo falla.
• Exposición regulatoria: normativas como RGPD, HIPAA y PCI-DSS exigen el cifrado de datos sensibles en tránsito. El TLS oportunista por sí solo no cumple este estándar porque puede ser eludido.
• Fallos invisibles: sin TLS-RPT (el protocolo de informes complementario), nunca sabrás que los emails hacia tu dominio se entregaron sin cifrar. El problema es silencioso.

En 2014, investigadores documentaron la supresión a gran escala de STARTTLS por parte de intermediarios de red en varios países. El Transparency Report de Google confirmó posteriormente que una parte significativa de los emails entrantes llega aún sin cifrar. MTA-STS es el protocolo diseñado para poner fin a esta situación.

MTA-STS combinado con TLS-RPT te ofrece tanto cumplimiento como visibilidad.

Cómo funciona MTA-STS internamente

MTA-STS utiliza dos componentes que trabajan juntos:

1. Un registro DNS TXT en _mta-sts.captaindns.com

Este registro anuncia tu política MTA-STS y contiene un ID de política único. Cuando el ID cambia, los servidores remitentes saben que deben obtener una copia actualizada de la política.

Ejemplo: v=STSv1; id=20260308120000

2. Un archivo de política alojado en HTTPS en https://mta-sts.captaindns.com/.well-known/mta-sts.txt

Este archivo define tres cosas:

• mode: testing (solo informes) o enforce (rechazar si TLS falla)
• mx: los patrones de servidor de correo que deben coincidir con tus registros MX
• max_age: cuánto tiempo deben los servidores remitentes almacenar la política en caché (en segundos)

Ejemplo:

version: STSv1
mode: enforce
mx: *.mail.protection.outlook.com
max_age: 604800

Cuando un servidor remitente quiere entregar correo a tu dominio, comprueba el registro TXT _mta-sts. Si está presente, obtiene el archivo de política a través de HTTPS, valida el certificado TLS de tus servidores MX contra los patrones de la política y continúa solo si todo coincide.

Trust on first use (TOFU): MTA-STS depende de que la primera obtención exitosa de la política sea legítima. Después, la política en caché protege contra futuros ataques durante la duración de max_age. Por eso se recomienda un max_age largo (7+ días) en modo enforce.

Cómo funciona

1. Crea tu política

Inicia sesión y crea una nueva política. Define tu dominio, el modo (testing o enforce), los patrones MX y la duración de caché (max_age).

2. Verifica la propiedad del dominio

Agrega el registro TXT de verificación a tu DNS. Lo detectamos automáticamente en segundos.

3. Agrega los registros DNS de despliegue

Dos registros DNS:

• CNAME: Apunta mta-sts.captaindns.com a nuestro servidor de políticas
• TXT: Anuncia tu política MTA-STS en _mta-sts.captaindns.com

Tu política MTA-STS está activa.

Compatible con los principales proveedores de correo

MTA-STS funciona con cualquier proveedor de correo que utilice registros MX estándar. Los patrones MX de tu política deben coincidir con los servidores de correo de tu proveedor:

Al crear tu política en CaptainDNS, introduce los patrones MX que coincidan con tu proveedor. El panel de control los valida contra tus registros MX en vivo para evitar discrepancias.

Alojado vs. autoalojado: ¿qué opción elegir?

Elige alojado si quieres MTA-STS desplegado en minutos con cero infraestructura. Elige autoalojado si necesitas control total sobre el endpoint de la política u operas en un entorno aislado.

De testing a enforce: una estrategia progresiva

Desplegar MTA-STS en modo enforce de inmediato es arriesgado. Si tus patrones MX son incorrectos o un certificado TLS caduca, los emails legítimos serán rechazados. El enfoque recomendado es progresivo:

Fase 1: Desplegar en modo testing (1 a 2 semanas)

Establece mode: testing en tu política. Los servidores remitentes intentarán TLS e informarán de los fallos mediante TLS-RPT, pero seguirán entregando los emails aunque TLS falle. Esto te da visibilidad sin riesgo.

Fase 2: Analizar los informes TLS-RPT

Revisa los informes para identificar problemas: discrepancias de certificados, patrones MX que no cubren todos los servidores de correo o remitentes de terceros con TLS defectuoso. Corrige cada problema antes de avanzar.

Fase 3: Cambiar a modo enforce

Cuando los informes muestren cero fallos durante al menos una semana, cambia el modo a enforce y aumenta max_age a 604800 (7 días) o más. En CaptainDNS, esto se hace con un solo clic en el panel de control. El ID de política rota automáticamente.

Reversión de emergencia: si el modo enforce bloquea correo legítimo, vuelve a testing de inmediato. Los servidores remitentes obtendrán la política actualizada y dejarán de rechazar en minutos (o como máximo dentro de la ventana del antiguo max_age).

MTA-STS y DANE: dos enfoques complementarios

Existen dos protocolos para forzar el cifrado del transporte de correo: MTA-STS y DANE (DNS-based Authentication of Named Entities). Resuelven el mismo problema de formas diferentes.

Si tu dominio no usa DNSSEC, MTA-STS es tu única opción para cifrado de transporte forzado.

Si tu dominio usa DNSSEC, desplegar ambos protocolos ofrece la protección más sólida: DANE elimina TOFU para los remitentes compatibles con DNSSEC, mientras que MTA-STS cubre a los remitentes que no soportan DANE.

Buenas prácticas de despliegue MTA-STS

1. Empieza en modo testing: identifica problemas de conectividad TLS antes de cambiar a enforce.
2. Configura TLS-RPT: recibe informes sobre fallos de entrega TLS. Usa nuestro Generador TLS-RPT.
3. Valida tus registros MX: asegúrate de que los patrones MX en tu política coincidan con tus servidores de correo reales. Las discrepancias causan fallos de entrega en modo enforce.
4. Monitoriza antes de forzar: analiza los informes TLS-RPT durante al menos una semana con cero fallos antes de cambiar a enforce.
5. Usa un max_age largo en modo enforce: 604800 segundos (7 días) o más. Esto asegura que los servidores remitentes almacenen tu política en caché el tiempo suficiente para resistir ataques de downgrade.
6. Cambia a enforce: una vez que los informes TLS-RPT confirmen que todo funciona, activa el modo enforce para protección completa.

Herramientas complementarias

Guías y recursos

• MTA-STS: la guía completa para proteger el transporte de tus emails - Todo lo que necesitas saber sobre la configuración y el despliegue de MTA-STS.
• De testing a enforce: estrategia de despliegue progresivo de MTA-STS - Buenas prácticas para un despliegue gradual de MTA-STS.
• Configurar MTA-STS para Microsoft 365 y Google Workspace - Configuración paso a paso para las dos plataformas de correo más populares.
• ¿MTA-STS no funciona? Guía completa de resolución de problemas - Diagnostica y corrige los errores de configuración MTA-STS más comunes.
• MTA-STS vs DANE: ¿qué protocolo elegir para asegurar el transporte de correo? - Comparación detallada para elegir el protocolo adecuado.