¿MTA-STS no funciona? Guía completa de resolución de problemas

Q: ¿Por qué no se recupera mi política MTA-STS?

El archivo mta-sts.txt debe ser accesible en la URL exacta https://mta-sts.captaindns.com/.well-known/mta-sts.txt . Verifica que el subdominio mta-sts resuelve correctamente (CNAME o registro A), que el certificado TLS es válido y que el servidor responde con un código 200 y el Content-Type text/plain . Las redirecciones HTTP hacia HTTPS no son aceptadas por todos los clientes.

Q: ¿Qué significa el error 'MX no cubierto por la política'?

Tu servidor MX real no corresponde a ningún pattern mx: en el archivo de política. Por ejemplo, si tu MX es captaindns-com.mail.protection.outlook.com pero la política contiene mx: mail.protection.outlook.com (sin wildcard), el servidor remitente considera que el MX no está autorizado. Añade el wildcard: mx: *.mail.protection.outlook.com .

Q: ¿Por qué el modo enforce bloquea correos?

En modo enforce , los servidores remitentes rechazan el envío si la política MTA-STS no puede cumplirse (certificado inválido, MX no cubierto, política inaccesible). Vuelve inmediatamente al modo testing , actualiza el campo id del registro DNS y analiza los informes TLS-RPT para identificar la causa exacta antes de volver a enforce.

Por CaptainDNS
Publicado el 9 de febrero de 2026

Resolución de problemas MTA-STS: diagnóstico y corrección de errores comunes

TL;DR

Verifica primero los tres fundamentos: registro DNS _mta-sts, archivo de política accesible en HTTPS y certificado TLS válido en el subdominio mta-sts
El error sts-policy-fetch-error significa que el archivo mta-sts.txt es inaccesible — verifica el alojamiento, el DNS y el certificado del subdominio
Los informes TLS-RPT identifican con precisión el tipo de fallo (certificate-expired, validation-failure, sts-webpki-invalid) para orientar el diagnóstico
En caso de emergencia con el modo enforce, vuelve inmediatamente a testing y actualiza el campo id del registro DNS

Has desplegado MTA-STS en tu dominio siguiendo todos los pasos: registro DNS publicado, archivo de política alojado, TLS-RPT activado. Sin embargo, los informes señalan fallos, el verificador muestra errores o, peor aún, se rechazan correos en modo enforce.

MTA-STS implica varios componentes que deben funcionar juntos: un registro DNS TXT, un archivo de política servido en HTTPS en un subdominio específico, certificados TLS válidos y patterns MX que correspondan exactamente a tus servidores. Un solo eslabón defectuoso basta para romper la cadena.

Esta guía de resolución de problemas cubre los errores más frecuentes, sus causas y los comandos para diagnosticarlos. Tanto si usas Microsoft 365, Google Workspace o Cloudflare para el alojamiento, encontrarás la solución a tu problema. Si aún no has desplegado MTA-STS, consulta primero nuestra guía completa MTA-STS.

Diagnóstico rápido: verificar tu configuración MTA-STS

Antes de buscar un problema específico, verifica estos tres fundamentos en orden. La mayoría de los problemas MTA-STS provienen de uno de estos tres puntos.

Paso 1: Verificar el registro DNS _mta-sts

El registro TXT en _mta-sts.captaindns.com debe existir y contener un valor válido:

dig TXT _mta-sts.captaindns.com +short
# Resultado esperado: "v=STSv1; id=20260208120000"

Problemas comunes:

Sin resultado → el registro no existe o aún no se ha propagado
v=STS1 en lugar de v=STSv1 → error tipográfico en la versión
Ausencia del campo id → campo obligatorio faltante

Paso 2: Verificar el archivo de política

El archivo debe ser accesible en la URL exacta https://mta-sts.captaindns.com/.well-known/mta-sts.txt:

curl -v https://mta-sts.captaindns.com/.well-known/mta-sts.txt

Verificaciones:

Código HTTP 200 (no 301, 302, 403 ni 404)
Content-Type text/plain (no text/html)
Contenido válido con version: STSv1, mode:, mx: y max_age:
Sin redirección HTTP → HTTPS (el servidor debe responder directamente en HTTPS)

Paso 3: Verificar el certificado TLS

El subdominio mta-sts.captaindns.com debe tener un certificado TLS válido:

openssl s_client -connect mta-sts.captaindns.com:443 -servername mta-sts.captaindns.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject

Verificaciones:

El certificado no ha expirado (notAfter en el futuro)
El certificado cubre mta-sts.captaindns.com (en el CN o SAN)
La cadena de certificados está completa (sin error unable to verify)

Checklist de diagnóstico MTA-STS: registro DNS, archivo de política y certificado TLS

Errores comunes y soluciones

Error "Policy not found" (sts-policy-fetch-error)

Es el error más frecuente en los informes TLS-RPT. Significa que el servidor remitente no pudo recuperar tu archivo de política.

Causa	Comando de diagnóstico	Solución
Archivo ausente	`curl -I https://mta-sts.captaindns.com/.well-known/mta-sts.txt`	Crear y alojar el archivo
DNS mal configurado	`dig A mta-sts.captaindns.com +short`	Verificar el CNAME o registro A
Redirección HTTP	`curl -v http://mta-sts.captaindns.com/.well-known/mta-sts.txt`	Configurar HTTPS directamente
Certificado inválido	`curl -vI https://mta-sts.captaindns.com/`	Renovar o corregir el certificado
Cloudflare en pausa	Verificar el dashboard de Cloudflare	Reactivar el proxy o el Worker

Error "Certificate mismatch" (certificate-host-mismatch)

El certificado TLS de un servidor MX no corresponde al nombre de host MX. No es el certificado del subdominio mta-sts, sino el del propio servidor MX.

# Verificar el certificado de un servidor MX
openssl s_client -connect captaindns-com.mail.protection.outlook.com:25 -starttls smtp -servername captaindns-com.mail.protection.outlook.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

Con Microsoft 365 o Google Workspace: este problema no debería producirse, ya que Microsoft y Google gestionan los certificados de sus MX. Si lo ves, verifica que tus patterns MX en la política correspondan a tus MX reales.

Error "MX not covered by policy"

El servidor MX de tu dominio no corresponde a ningún pattern mx: en el archivo de política. A menudo se trata de un error de wildcard.

# Listar tus MX
dig MX captaindns.com +short

# Comparar con la política
curl -s https://mta-sts.captaindns.com/.well-known/mta-sts.txt | grep "^mx:"

Causas comunes:

Situación	Pattern incorrecto	Pattern correcto
Microsoft 365	`mx: mail.protection.outlook.com`	`mx: *.mail.protection.outlook.com`
Google Workspace	`mx: *.google.com` (solo)	`mx: .google.com` + `mx: .googlemail.com`
MX personalizado	Pattern wildcard demasiado restrictivo	Verificar cada MX individualmente

Error "Certificate expired" (certificate-expired)

Un certificado TLS ha expirado en uno de tus servidores MX o en el subdominio mta-sts.

# Verificar la fecha de expiración del certificado mta-sts
echo | openssl s_client -connect mta-sts.captaindns.com:443 -servername mta-sts.captaindns.com 2>/dev/null | openssl x509 -noout -enddate

Si es el subdominio mta-sts: renueva el certificado a través de tu proveedor de alojamiento (Cloudflare lo hace automáticamente). Si es un servidor MX: con Microsoft 365 o Google Workspace, la renovación es automática. Para un MX autohospedado, renueva el certificado a través de Let's Encrypt o tu autoridad de certificación.

Error "Validation failure" (validation-failure)

La cadena de certificados está incompleta: falta el certificado raíz o un certificado intermedio.

# Probar la cadena completa
openssl s_client -connect mta-sts.captaindns.com:443 -servername mta-sts.captaindns.com </dev/null 2>&1 | grep "Verify return code"
# Resultado esperado: Verify return code: 0 (ok)

Si el código de retorno no es 0, instala los certificados intermedios faltantes en tu servidor.

Problemas específicos por proveedor

Microsoft 365

Problema	Causa	Solución
MX no cubierto	Pattern sin wildcard	Usar `mx: *.mail.protection.outlook.com`
Informes TLS-RPT vacíos	M365 envía los informes con retraso	Esperar 48-72h tras la activación
Certificado MX con error	Raro (gestionado por Microsoft)	Contactar con el soporte de Microsoft

Google Workspace

Problema	Causa	Solución
MX parcialmente cubiertos	Un solo pattern `mx:`	Añadir `mx: .google.com` Y `mx: .googlemail.com`
Informes TLS-RPT incompletos	Google agrega en 24h	Esperar el informe completo del día siguiente
Cambio de MX en Google	Migración hacia nuevos MX	Verificar los MX actuales con `dig MX`

Cloudflare Pages / Workers

Problema	Causa	Solución
404 en mta-sts.txt	Ruta incorrecta en el repositorio	El archivo debe estar en `.well-known/mta-sts.txt`
Certificado TLS ausente	Dominio personalizado no configurado	Añadir `mta-sts.captaindns.com` en Custom Domains
Worker no responde	Ruta mal configurada	Verificar que la ruta `mta-sts.captaindns.com/*` esté activa
Content-Type incorrecto	Worker devuelve `text/html`	Forzar `Content-Type: text/plain` en la Response
DNS no resuelto	CNAME faltante	Añadir el CNAME hacia el proyecto Pages o el AAAA `100::` para Workers

Leer e interpretar los informes TLS-RPT

Los informes TLS-RPT enviados por los proveedores de correo contienen los detalles de los fallos TLS. Aquí te explicamos cómo leerlos.

Estructura de un informe TLS-RPT

Un informe JSON típico contiene:

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-02-08T00:00:00Z",
    "end-datetime": "2026-02-08T23:59:59Z"
  },
  "policies": [{
    "policy": {
      "policy-type": "sts",
      "policy-domain": "captaindns.com"
    },
    "summary": {
      "total-successful-session-count": 150,
      "total-failure-session-count": 2
    },
    "failure-details": [{
      "result-type": "certificate-host-mismatch",
      "sending-mta-ip": "209.85.220.41",
      "receiving-mx-hostname": "captaindns-com.mail.protection.outlook.com",
      "failed-session-count": 2
    }]
  }]
}

Tabla de correspondencia de errores TLS-RPT

Código TLS-RPT	Significado	Gravedad	Acción
`starttls-not-supported`	El MX no soporta STARTTLS	Crítica	Activar TLS en el servidor MX
`certificate-host-mismatch`	El certificado no corresponde al MX	Alta	Verificar el SAN del certificado
`certificate-expired`	Certificado expirado	Alta	Renovar inmediatamente
`certificate-not-trusted`	Certificado autofirmado o CA desconocida	Alta	Usar un certificado de una CA reconocida
`validation-failure`	Cadena de certificados incompleta	Alta	Instalar los certificados intermedios
`sts-policy-fetch-error`	Archivo mta-sts.txt inaccesible	Alta	Verificar el alojamiento
`sts-policy-invalid`	Contenido de la política inválido	Alta	Corregir la sintaxis
`sts-webpki-invalid`	Certificado del subdominio mta-sts inválido	Alta	Renovar el certificado

Flujo de diagnóstico de errores TLS-RPT: del error a la solución

El modo enforce bloquea correos: ¿qué hacer?

Si has pasado a modo enforce y se rechazan correos legítimos, actúa inmediatamente:

1. Vuelta de emergencia al modo testing

Modifica el archivo de política:

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

2. Actualizar el registro DNS

Cambia el campo id para forzar a los servidores remitentes a volver a descargar la política:

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

3. Tiempo de propagación

Los servidores remitentes almacenan en caché tu política durante el max_age anterior. Si tenías max_age: 2592000 (30 días), algunos servidores podrían no volver a descargar la política durante 30 días. Por eso se recomienda aumentar max_age progresivamente:

Fase	max_age	Duración	Uso
Testing inicial	`86400`	24 horas	Permite una vuelta rápida
Testing avanzado	`604800`	7 días	Tras 2 semanas sin errores
Enforce prudente	`604800`	7 días	Primeras semanas en enforce
Enforce estable	`2592000`	30 días	Tras 1 mes en enforce sin problemas

Comandos de diagnóstico esenciales

Aquí tienes los comandos que debes tener a mano para diagnosticar cualquier problema MTA-STS:

# 1. Verificar el registro DNS MTA-STS
dig TXT _mta-sts.captaindns.com +short

# 2. Verificar el registro TLS-RPT
dig TXT _smtp._tls.captaindns.com +short

# 3. Recuperar el archivo de política
curl -s https://mta-sts.captaindns.com/.well-known/mta-sts.txt

# 4. Verificar las cabeceras HTTP del archivo de política
curl -I https://mta-sts.captaindns.com/.well-known/mta-sts.txt

# 5. Listar los servidores MX
dig MX captaindns.com +short

# 6. Verificar el certificado del subdominio mta-sts
echo | openssl s_client -connect mta-sts.captaindns.com:443 -servername mta-sts.captaindns.com 2>/dev/null | openssl x509 -noout -dates -subject

# 7. Probar la conexión STARTTLS en un MX
openssl s_client -connect captaindns-com.mail.protection.outlook.com:25 -starttls smtp -servername captaindns-com.mail.protection.outlook.com </dev/null 2>/dev/null | openssl x509 -noout -dates

Plan de acción recomendado

Identifica el problema: Usa el verificador MTA-STS de CaptainDNS para un diagnóstico automático completo
Verifica los tres fundamentos: Registro DNS, archivo de política, certificado TLS (en ese orden)
Consulta los informes TLS-RPT: El campo result-type te indica exactamente qué está fallando
Corrige el problema identificado: Sigue las soluciones de la sección correspondiente de esta guía
Valida la corrección: Usa el validador de sintaxis MTA-STS para confirmar que la política es correcta
Monitoriza durante 48h: Verifica que los informes TLS-RPT ya no señalen el error

Verifica tu configuración MTA-STS ahora: Usa nuestro verificador MTA-STS para diagnosticar tu dominio en cuestión de segundos.

FAQ

¿Por qué no se recupera mi política MTA-STS?

El archivo mta-sts.txt debe ser accesible en la URL exacta https://mta-sts.captaindns.com/.well-known/mta-sts.txt. Verifica que el subdominio mta-sts resuelve correctamente (CNAME o registro A), que el certificado TLS es válido y que el servidor responde con un código 200 y el Content-Type text/plain. Las redirecciones HTTP hacia HTTPS no son aceptadas por todos los clientes.

¿Qué significa el error 'MX no cubierto por la política'?

Tu servidor MX real no corresponde a ningún pattern mx: en el archivo de política. Por ejemplo, si tu MX es captaindns-com.mail.protection.outlook.com pero la política contiene mx: mail.protection.outlook.com (sin wildcard), el servidor remitente considera que el MX no está autorizado. Añade el wildcard: mx: *.mail.protection.outlook.com.

¿Cómo corregir un error de certificado TLS en MTA-STS?

Identifica primero qué certificado está causando el problema. Si es el certificado del subdominio mta-sts: renuévalo a través de tu proveedor de alojamiento (Cloudflare lo renueva automáticamente). Si es el certificado de un servidor MX: con Microsoft 365 o Google Workspace, se gestiona automáticamente. Para un MX autohospedado, verifica la cadena de certificados completa y la fecha de expiración.

¿Por qué el modo enforce bloquea correos?

En modo enforce, los servidores remitentes rechazan el envío si la política MTA-STS no puede cumplirse (certificado inválido, MX no cubierto, política inaccesible). Vuelve inmediatamente al modo testing, actualiza el campo id del registro DNS y analiza los informes TLS-RPT para identificar la causa exacta antes de volver a enforce.

¿Cómo volver al modo testing de emergencia?

Modifica el archivo mta-sts.txt reemplazando mode: enforce por mode: testing. Después actualiza el campo id del registro DNS TXT _mta-sts con una nueva marca de tiempo. Los servidores remitentes volverán a descargar la política y dejarán de rechazar correos. El plazo depende del max_age anterior.

¿Cómo leer un informe TLS-RPT?

Los informes TLS-RPT son archivos JSON enviados diariamente a la dirección especificada en tu registro _smtp._tls. El campo result-type indica el tipo de error (certificate-expired, sts-policy-fetch-error, etc.), receiving-mx-hostname identifica el servidor MX afectado y failed-session-count indica el número de fallos.

¿MTA-STS no funciona con Cloudflare Workers: qué verificar?

Verifica que la ruta mta-sts.captaindns.com/* está configurada en el Worker, que el DNS contiene un registro AAAA mta-sts apuntando a 100:: (proxied) y que el Worker devuelve el Content-Type text/plain; charset=utf-8. Prueba con curl -I https://mta-sts.captaindns.com/.well-known/mta-sts.txt para confirmar el código 200 y las cabeceras.

¿Cuánto tiempo hay que esperar para que las correcciones surtan efecto?

Los servidores remitentes almacenan en caché tu política durante el max_age. Si tenías max_age: 86400 (24h), la corrección será efectiva en un máximo de 24h. Si tenías max_age: 2592000 (30 días), algunos servidores podrían no ver la corrección durante 30 días. Por eso se recomienda mantener un max_age corto en fase de pruebas.

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 informe diario sobre los éxitos y fallos de negociación TLS.
sts-policy-fetch-error: Código de error TLS-RPT que indica que el archivo de política mta-sts.txt no pudo ser recuperado por el servidor remitente.
max_age: Directiva de la política MTA-STS que indica la duración del almacenamiento en caché en segundos. Determina el plazo de propagación de las modificaciones.
STARTTLS: Extensión SMTP que permite cifrar la conexión entre servidores de correo. MTA-STS impone su uso con un certificado válido.