Configurar MTA-STS para Microsoft 365 y Google Workspace

⚡TL;DR

• Microsoft 365 utiliza el pattern MX *.mail.protection.outlook.com en la política MTA-STS; Google Workspace necesita los patterns *.google.com y *.googlemail.com
• El archivo de política mta-sts.txt debe estar alojado en HTTPS en el subdominio mta-sts de tu dominio, con un certificado TLS válido
• Cloudflare Pages o Cloudflare Workers permiten alojar gratuitamente el archivo de política con HTTPS automático
• Despliega siempre en modo testing con TLS-RPT activo antes de pasar a modo enforce

Utilizas Microsoft 365 o Google Workspace para tu correo profesional. Tus servidores MX están correctamente configurados, SPF, DKIM y DMARC están en su sitio. Pero el transporte entre servidores SMTP sigue siendo vulnerable: sin MTA-STS, un atacante puede forzar una conexión en texto plano e interceptar tus mensajes.

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) resuelve este problema imponiendo el cifrado TLS para la recepción de correos. El principio es simple: publicas un registro DNS y un archivo de política que declaran tus servidores MX autorizados y exigen una conexión TLS válida.

Este tutorial te guía paso a paso para desplegar MTA-STS en Microsoft 365, Google Workspace y Cloudflare. Cada sección contiene los patterns MX exactos, los archivos de configuración listos para copiar y los comandos de validación. Si es la primera vez que descubres MTA-STS, consulta primero nuestra guía completa de MTA-STS para entender el funcionamiento del protocolo (ver la sección Guías relacionadas al final del artículo).

Requisitos previos comunes a todos los proveedores

Antes de configurar MTA-STS, verifica estos tres puntos para tu dominio:

1. Certificados TLS válidos en tus MX

Todos tus servidores MX deben disponer de un certificado TLS válido (TLS 1.2 como mínimo). Con Microsoft 365 y Google Workspace, esto ya viene por defecto: Microsoft y Google gestionan los certificados de sus servidores MX.

2. Acceso a tu zona DNS

Debes poder crear un registro TXT en _mta-sts.captaindns.com y un registro CNAME o A para el subdominio mta-sts.captaindns.com.

3. Alojamiento HTTPS para el archivo de política

El archivo mta-sts.txt debe ser accesible en la URL exacta https://mta-sts.captaindns.com/.well-known/mta-sts.txt. Necesitas un alojamiento HTTPS con un certificado válido para el subdominio mta-sts.

MTA-STS para Microsoft 365 / Office 365

El pattern MX de Microsoft 365

Microsoft 365 utiliza servidores MX con el formato captaindns-com.mail.protection.outlook.com. El pattern wildcard correspondiente para tu política MTA-STS es:

*.mail.protection.outlook.com

Este pattern cubre todos los servidores MX de Microsoft 365, incluidas las variaciones regionales y las configuraciones con Exchange Online Protection (EOP).

Para verificar tus MX de Microsoft 365:

dig MX captaindns.com +short
# Resultado esperado: 0 captaindns-com.mail.protection.outlook.com.

Archivo de política para Microsoft 365

Crea el archivo mta-sts.txt con el siguiente contenido:

version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 86400

Directiva	Valor	Explicación
version	STSv1	Versión del protocolo
mode	testing	Supervisión sin bloqueo (fase inicial)
mx	*.mail.protection.outlook.com	Cubre todos los MX de Microsoft 365
max_age	86400	Caché de 24 h (adecuado para testing)

Registro DNS para Microsoft 365

Añade este registro TXT en tu zona DNS:

_mta-sts.captaindns.com. 300 IN TXT "v=STSv1; id=20260207120000"

El campo id debe actualizarse cada vez que modifiques la política. Utiliza una marca de tiempo en formato YYYYMMDDHHMMSS para facilitar el seguimiento.

¿Soporta Microsoft 365 MTA-STS?

Microsoft soporta MTA-STS en emisión: cuando un servidor Microsoft 365 envía un correo, verifica la política MTA-STS del dominio destinatario. Microsoft también soporta MTA-STS en recepción: puedes publicar una política para tu dominio alojado en Microsoft 365, y los servidores emisores la respetarán.

MTA-STS para Google Workspace

Los patterns MX de Google Workspace

Google Workspace utiliza varios servidores MX con nombres variados. Los patterns que debes incluir en tu política MTA-STS son:

*.google.com
*.googlemail.com

Estos dos patterns cubren el conjunto de servidores MX de Google Workspace, incluyendo:

Servidor MX	Prioridad
aspmx.l.google.com	1
alt1.aspmx.l.google.com	5
alt2.aspmx.l.google.com	5
alt3.aspmx.l.google.com	10
alt4.aspmx.l.google.com	10

Archivo de política para Google Workspace

version: STSv1
mode: testing
mx: *.google.com
mx: *.googlemail.com
max_age: 86400

Ten en cuenta que se necesitan dos líneas mx: una para *.google.com y otra para *.googlemail.com. MTA-STS exige que cada pattern se declare en una línea separada.

Registro DNS para Google Workspace

El registro DNS es idéntico en su estructura:

_mta-sts.captaindns.com. 300 IN TXT "v=STSv1; id=20260207120000"

Google Workspace y TLS-RPT

Google es uno de los proveedores más activos en materia de TLS-RPT. Si activas MTA-STS y TLS-RPT, recibirás informes detallados de Google sobre las negociaciones TLS con tu dominio. Estos informes son muy valiosos para identificar problemas antes de pasar a modo enforce.

Alojar MTA-STS en Cloudflare

El archivo de política debe ser accesible en https://mta-sts.captaindns.com/.well-known/mta-sts.txt. Cloudflare ofrece dos opciones gratuitas para el alojamiento.

Opción 1: Cloudflare Pages (recomendado)

Cloudflare Pages es la solución más sencilla. Crea un repositorio con la siguiente estructura:

mi-proyecto-mta-sts/
  .well-known/
    mta-sts.txt

Pasos para el despliegue:

1. Crea un repositorio Git (GitHub o GitLab) con el archivo .well-known/mta-sts.txt
2. Conéctalo a Cloudflare Pages: Dashboard de Cloudflare > Pages > Create a project
3. Configura el build: Framework preset = None, Build command = (vacío), Output directory = /
4. Añade el dominio personalizado: Settings > Custom domains > mta-sts.captaindns.com
5. Configura el DNS: Cloudflare crea automáticamente un registro CNAME

Cloudflare Pages proporciona un certificado TLS automático a través de Let's Encrypt. No se necesita ninguna configuración adicional.

Opción 2: Cloudflare Worker

Para un control más preciso o si no quieres usar un repositorio Git, un Cloudflare Worker puede servir el archivo de política:

export default {
  async fetch(request) {
    const url = new URL(request.url);

    if (url.pathname === '/.well-known/mta-sts.txt') {
      const policy = `version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 86400`;

      return new Response(policy, {
        headers: {
          'Content-Type': 'text/plain; charset=utf-8',
          'Cache-Control': 'public, max-age=3600',
        },
      });
    }

    return new Response('Not Found', { status: 404 });
  },
};

Pasos:

1. Crea un Worker: Dashboard de Cloudflare > Workers & Pages > Create application
2. Pega el código anterior (adapta las líneas mx a tu proveedor)
3. Añade una ruta personalizada: mta-sts.captaindns.com/*
4. Configura el DNS: Añade un registro AAAA mta-sts apuntando a 100:: (proxied)

El plan gratuito de Cloudflare Workers incluye 100 000 solicitudes por día, más que suficiente para MTA-STS.

¿Qué Content-Type usar?

El archivo de política debe servirse con el Content-Type text/plain. La RFC 8461 no especifica un charset obligatorio, pero text/plain; charset=utf-8 es lo recomendado para garantizar la compatibilidad.

Activar TLS-RPT para supervisar el despliegue

TLS-RPT (SMTP TLS Reporting, RFC 8460) es el compañero indispensable de MTA-STS. Te envía informes diarios sobre los éxitos y fallos en la negociación TLS.

Crear el registro TLS-RPT

Añade este registro TXT en tu zona DNS:

_smtp._tls.captaindns.com. 300 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"

Los informes se envían en formato JSON, comprimidos en gzip, a la dirección de correo especificada. También puedes usar una URL HTTPS para recibir los informes mediante webhook:

_smtp._tls.captaindns.com. 300 IN TXT "v=TLSRPTv1; rua=https://tls-reports.captaindns.com/v1/report"

¿Qué contienen los informes TLS-RPT?

Cada informe cubre un periodo de 24 horas e incluye:

Información	Descripción
Dominio de política	Tu dominio (captaindns.com)
Periodo del informe	Fecha de inicio y fin
Organización emisora	Google, Microsoft, etc.
Contador de éxitos	Número de conexiones TLS exitosas
Contador de fallos	Número de conexiones fallidas
Tipo de fallo	starttls-not-supported, certificate-expired, validation-failure, etc.

Interpretar los informes

En modo testing, supervisa los informes durante 2 a 4 semanas. Si la tasa de fallos es nula o cercana a cero, puedes pasar a modo enforce con total confianza.

Los errores más comunes en los informes:

Error	Causa probable	Acción
certificate-expired	Certificado TLS expirado en un MX	Renovar el certificado
certificate-host-mismatch	Nombre de host MX no cubierto por el certificado	Verificar el SAN del certificado
validation-failure	Cadena de certificado incompleta	Instalar los certificados intermedios
sts-policy-fetch-error	Archivo mta-sts.txt inaccesible	Verificar el alojamiento HTTPS
sts-webpki-invalid	Certificado del subdominio mta-sts inválido	Renovar el certificado

De testing a enforce: plan de migración

Fase 1: Despliegue inicial (semana 1)

1. Crea el archivo de política en modo testing con max_age: 86400
2. Alójalo en Cloudflare Pages o Workers
3. Publica el registro DNS _mta-sts
4. Activa TLS-RPT
5. Valida con el verificador MTA-STS de CaptainDNS

Fase 2: Supervisión (semanas 2-4)

1. Analiza los informes TLS-RPT diarios
2. Corrige los errores identificados (certificados, MX no cubiertos)
3. Verifica que la tasa de éxito TLS alcance el 100 %

Fase 3: Paso a enforce

1. Modifica el archivo de política: mode: enforce
2. Aumenta max_age: pasa a 604800 (7 días) y luego a 2592000 (30 días)
3. Actualiza el campo id del registro DNS
4. Continúa supervisando los informes TLS-RPT

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

Retorno de emergencia al modo testing

Si se rechazan correos después de pasar a enforce:

1. Vuelve inmediatamente a mode: testing en el archivo de política
2. Actualiza el campo id del registro DNS
3. Los servidores emisores volverán a descargar la política y dejarán de rechazar

El tiempo de propagación depende del max_age anterior. Por eso se recomienda aumentar max_age de forma progresiva.

Plan de acción recomendado

1. Identifica tu proveedor de correo: Verifica tus registros MX con dig MX captaindns.com +short
2. Crea el archivo de política: Utiliza el generador MTA-STS de CaptainDNS con los patterns MX de tu proveedor
3. Aloja la política: Despliega en Cloudflare Pages (la opción más sencilla y gratuita)
4. Publica los registros DNS: Añade _mta-sts (TXT) y _smtp._tls (TLS-RPT)
5. Valida la configuración: Comprueba con el verificador de sintaxis MTA-STS que la política es correcta
6. Supervisa durante 2-4 semanas: Analiza los informes TLS-RPT antes de pasar a enforce

---

Verifica tu configuración MTA-STS ahora: Utiliza nuestro verificador MTA-STS para analizar tu dominio en segundos.

---

FAQ

¿Cómo configurar MTA-STS para Microsoft 365?

Crea un archivo mta-sts.txt con la directiva mx: *.mail.protection.outlook.com, alójalo en HTTPS en el subdominio mta-sts de tu dominio, y publica un registro DNS TXT en _mta-sts con v=STSv1; id=<marca_de_tiempo>. Empieza en modo testing con un max_age de 86400 segundos (24 horas).

¿Cómo configurar MTA-STS para Google Workspace?

El archivo de política debe contener dos líneas mx: mx: *.google.com y mx: *.googlemail.com. Estos patterns cubren todos los servidores MX de Google Workspace (aspmx.l.google.com y sus alternativas). El resto de la configuración (registro DNS, alojamiento HTTPS) es idéntico a Microsoft 365.

¿Qué pattern MX usar para Office 365 en la política MTA-STS?

El pattern correcto es *.mail.protection.outlook.com. Este wildcard cubre todos los servidores MX de Microsoft 365, incluidas las variantes regionales y Exchange Online Protection. Verifica tus MX con dig MX captaindns.com +short para confirmar que corresponden a este pattern.

¿Cómo alojar el archivo mta-sts.txt en Cloudflare?

Dos opciones: Cloudflare Pages (crea un repositorio Git con el archivo .well-known/mta-sts.txt y añade el dominio personalizado mta-sts.captaindns.com) o Cloudflare Workers (despliega un script que devuelve el contenido de la política con el Content-Type text/plain). Ambas opciones son gratuitas y proporcionan un certificado TLS automático.

¿Hay que configurar TLS-RPT junto con MTA-STS?

Sí, es muy recomendable. TLS-RPT (RFC 8460) te envía informes diarios sobre los éxitos y fallos en la negociación TLS. Publica un registro DNS TXT en _smtp._tls con v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com. Sin TLS-RPT, no tienes visibilidad alguna sobre los problemas de tu despliegue MTA-STS.

¿Funciona MTA-STS con un Cloudflare Worker gratuito?

Sí. El plan gratuito de Cloudflare Workers incluye 100 000 solicitudes por día, más que suficiente para MTA-STS. Los servidores emisores consultan tu política de forma ocasional (en el primer envío y al expirar la caché max_age). Un Worker gratuito cubre fácilmente millones de correos al mes.

¿Microsoft y Google soportan MTA-STS de forma nativa?

Sí, ambos. Google soporta MTA-STS en emisión (verifica las políticas de los dominios destinatarios) y publica informes TLS-RPT. Microsoft 365 soporta MTA-STS en emisión desde 2020 y también envía informes TLS-RPT. Los dos proveedores gestionan los certificados TLS de sus servidores MX de forma automática.

¿Cómo verificar si mi registro MTA-STS es válido?

Utiliza el verificador MTA-STS de CaptainDNS para comprobar tu registro DNS, el archivo de política, el certificado TLS del subdominio mta-sts y la correspondencia entre los patterns MX declarados y tus MX reales. También puedes verificarlo manualmente con dig TXT _mta-sts.captaindns.com y curl https://mta-sts.captaindns.com/.well-known/mta-sts.txt.

Glosario

• MTA-STS: Mail Transfer Agent Strict Transport Security. Estándar RFC 8461 que impone el cifrado TLS para la recepción de correos.
• TLS-RPT: SMTP TLS Reporting (RFC 8460). Mecanismo de informes sobre los éxitos y fallos en la negociación TLS.
• Exchange Online Protection (EOP): Servicio de filtrado de correo de Microsoft 365 que gestiona los servidores MX *.mail.protection.outlook.com.
• Cloudflare Pages: Servicio de alojamiento de sitios estáticos de Cloudflare con HTTPS automático y despliegue mediante Git.
• Cloudflare Workers: Plataforma serverless de Cloudflare que permite ejecutar JavaScript lo más cerca posible de los usuarios.
• max_age: Directiva de la política MTA-STS que indica la duración del almacenamiento en caché en segundos.

Guías de MTA-STS relacionadas

• MTA-STS: la guía completa para proteger el transporte de correo
• ¿MTA-STS no funciona? Guía completa de solución de problemas (próximamente)

Fuentes

• RFC 8461 - SMTP MTA Strict Transport Security (MTA-STS)
• RFC 8460 - SMTP TLS Reporting
• Google Support - Reforzar la seguridad del correo con MTA-STS y TLS-RPT
• Microsoft Learn - SMTP MTA-STS