← RFC Reference

MTA-STS — Seguridad de Transporte Estricto del Agente de Transferencia de Correo

Por qué existe

SMTP fue diseñado en una era cuando el correo electrónico viajaba en texto plano. STARTTLS (RFC 3207) agregó cifrado opcional, pero tiene un defecto fatal: es oportunista. Un servidor de envío pregunta "¿admites TLS?" y un atacante activo en la red puede simplemente eliminar esa respuesta, forzando una degradación a texto plano. El servidor de envío no tiene forma de saber la diferencia entre "este servidor no admite TLS" y "un atacante eliminó la oferta de TLS".

MTA-STS soluciona esto permitiendo que los propietarios de dominios publiquen una política —a través de HTTPS, no DNS— que declara: "Mis servidores de correo siempre admiten TLS con certificados válidos. Si no puedes establecer una conexión segura, rechaza la entrega." Debido a que la política se obtiene a través de HTTPS (que tiene su propia cadena de confianza de certificados), un atacante activo no puede falsificarla ni suprimirla.

Cómo funciona

MTA-STS requiere dos cosas del dominio receptor:

1. Un registro TXT de DNS en _mta-sts.example.com que señale que la política existe e incluya un identificador de versión para invalidación de caché.
2. Un archivo de política servido por HTTPS en https://mta-sts.example.com/.well-known/mta-sts.txt que declare la política real.

Paso 1: Registro de DNS

Publica un registro TXT para anunciar tu política MTA-STS:

El campo id es una cadena opaca. Los servidores de envío almacenan en caché la política y la vuelven a obtener cuando el id cambia. Usa una marca de tiempo o un contador incremental.

Paso 2: Archivo de política

Aloja la política en https://mta-sts.example.com/.well-known/mta-sts.txt. El certificado HTTPS debe ser válido para mta-sts.example.com.

version: STSv1
mode: enforce
mx: mail.example.com
mx: backup.example.com
mx: *.example.net
max_age: 604800

Campos de política

Qué hace el servidor de envío

1. Busca registros MX para el dominio del destinatario.
2. Comprueba si hay una política MTA-STS en caché, u obtiene una si el registro TXT de DNS _mta-sts es nuevo o ha cambiado.
3. Se conecta a un host MX e inicia STARTTLS.
4. Valida el certificado TLS del servidor MX según los patrones mx en la política.
5. Si el modo es enforce y TLS falla o el certificado no coincide: no entregues. Pone el mensaje en cola y reinenta más tarde.

Detalles técnicos clave

¿Por qué HTTPS en lugar de DNSSEC?

La implementación de DNSSEC sigue siendo limitada. HTTPS aprovecha la PKI web ampliamente implementada (infraestructura de autoridades de certificación). Cualquier dominio que pueda obtener un certificado web puede usar MTA-STS — no se requiere DNSSEC. Esta es la diferencia clave entre MTA-STS y DANE (RFC 7672), que requiere DNSSEC.

Confianza en el primer uso (TOFU)

MTA-STS sigue un modelo TOFU. La primera vez que un remitente encuentra tu política, debe confiar en las respuestas de DNS e HTTPS. Después de eso, la política en caché protege contra degradaciones hasta que max_age expire. Un atacante necesitaría comprometer tanto HTTPS como DNS simultáneamente durante la búsqueda inicial — un ataque significativamente más difícil.

Modo de prueba

Comienza con mode: testing. En este modo, los servidores de envío entregan correo incluso si la validación de TLS falla, pero generan reportes TLS-RPT (RFC 8460) para que puedas identificar problemas antes de cambiar a enforce.

Ejemplo de implementación

Una configuración completa de MTA-STS para example.com:

Registros de DNS

Archivo de política

# Servido en https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: mail.example.com
mx: backup.example.com
max_age: 86400

Una vez que los reportes TLS-RPT confirmen que no hay problemas, cambia mode a enforce y aumenta max_age a 604800 o superior.

Errores comunes

• Falta de coincidencia de certificados. El nombre de host MX en tu política debe coincidir con el certificado TLS en ese servidor. Si tu MX es mail.example.com pero el certificado es para *.mailprovider.com, la aplicación causará fallos de entrega.
• Olvidar actualizar el id de DNS. Los remitentes almacenan en caché la política usando el id como clave. Si cambias el archivo de política pero no el id, los remitentes no lo volverán a obtener hasta que expire max_age.
• Certificado HTTPS inválido en mta-sts.example.com. El sitio de alojamiento de la política debe tener un certificado válido y de confianza pública. Los certificados autofirmados o expirados harán que los remitentes ignoren la política.
• Pasar directamente a enforce. Siempre comienza con testing y monitorea los reportes TLS-RPT durante al menos dos semanas. Los servidores MX mal configurados perderán silenciosamente correo en modo enforce.
• max_age corto en modo enforce. Un TTL corto significa que los remitentes obtienen la política con frecuencia, ampliando la ventana TOFU. Usa al menos 604800 segundos (1 semana) en producción.
• Mal uso de comodín MX. mx: * no es válido. Los comodines se aplican solo a la etiqueta DNS más a la izquierda: mx: *.example.com coincide con a.example.com pero no con a.b.example.com.

Impacto en la entregabilidad

MTA-STS no mejora directamente la colocación en la bandeja de entrada — protege el correo de tus destinatarios de la interceptación. Sin embargo, tiene beneficios indirectos de entregabilidad:

• Construye confianza del dominio. Google, Microsoft y Yahoo todos admiten MTA-STS. Publicar una política señala que te tomas la seguridad en serio y ejecutas un dominio bien mantenido.
• Requerido para cumplimiento. Las industrias que manejan datos sensibles (finanzas, sanidad) requieren cada vez más la aplicación de TLS para correo electrónico. MTA-STS es el mecanismo estándar.
• Previene degradaciones silenciosas. Sin MTA-STS, un atacante en la ruta de red puede eliminar STARTTLS e interceptar correo sin que ninguna de las partes lo sepa. Este es un ataque documentado del mundo real.
• Se empareja con TLS-RPT. Los reportes de RFC 8460 te dan visibilidad en los fallos de TLS en todos los remitentes — invaluable para diagnosticar problemas de certificados o configuración antes de que afecten la entrega.

Related RFCs