MTA-STS: ¿Deberías habilitarlo y cómo evitar romper el correo entrante?

Qué hace realmente MTA-STS (y qué no hace)

MTA-STS (Mail Transfer Agent Strict Transport Security) es una forma para que un dominio receptor le diga a los MTAs remitentes: “Cuando entregues correo a mis hosts MX, usa TLS y valida certificados; si no puedes, no desciendas a texto plano”. Es esencialmente HSTS para SMTP—excepto que SMTP es más raro, más antiguo y tiene una larga tradición de entrega “a mejor esfuerzo”.

Mecánicamente, MTA-STS son dos cosas:

1. Un registro TXT en DNS en _mta-sts.<domain> que anuncia el “id” de la política actual.
2. Un archivo de política vía HTTPS en https://mta-sts.<domain>/.well-known/mta-sts.txt que describe los hosts MX aceptables y el modo de aplicación.

Los remitentes que soportan MTA-STS obtienen periódicamente tu política por HTTPS, la cachean y luego la usan para decidir si entregar, aplazar o fallar la entrega cuando TLS no cumple con lo especificado.

De qué te protege

• Ataques de degradación oportunista de TLS donde un atacante en la red elimina STARTTLS y fuerza SMTP en texto plano.
• Algunos escenarios de enrutamiento incorrecto donde la entrega acaba en un host sin un certificado válido para tu dominio.
• Comportamientos tipo “probamos TLS pero aceptamos cualquier cosa” de algunos remitentes; MTA-STS los empuja a validación estricta para tu dominio.

De qué no te protege

• Servidor remitente o receptor comprometido. Si el servidor de correo está controlado por un atacante, MTA-STS es un cinturón en un coche en llamas.
• Envenenamiento de DNS a nivel del propietario del dominio. Si tu DNS está comprometido, puedes publicar políticas que te rompan o te redirijan.
• Integridad del contenido del correo. Eso es territorio de DKIM/DMARC, no del transporte.
• Todos los MITM. MTA-STS depende de HTTPS y la confianza en CA; no es lo mismo que la autenticación anclada en DNSSEC como DANE.

Un matiz operativo: MTA-STS no obliga a tú a hacer algo en el receptor; obliga a los remitentes a rechazar la entrega si tu postura TLS no coincide con lo prometido. Eso significa que las fallas de MTA-STS a menudo se ven como “correo entrante que dejó de llegar aleatoriamente desde ciertos proveedores”, que es una clásica alegría de on-call.

Una cita que vale la pena tatuar en cada solicitud de cambio: “La esperanza no es una estrategia.” — Gene Kranz. No es específica de correo, pero es dolorosamente relevante cuando publicas “enforce” y esperas que todos los casos extremos estén bien.

¿Deberías habilitarlo?

Sí, si puedes cumplir dos requisitos básicos de forma consistente:

• Tus hosts MX soportan STARTTLS de forma fiable con cifrados modernos y sin intermediarios rotos.
• Tus certificados están válidos, no caducados, correctamente encadenados y coinciden con los nombres de host MX que declara tu política.

Si eso suena trivial, bien. Debería serlo. Pero “de forma fiable” es donde están los cadáveres: balanceadores que interceptan TLS, appliances legados, MX de respaldo en terceros que no coinciden con tu lista de nombres, o una ruta DR “temporal” que lleva siendo temporal desde 2019.

Quién se beneficia más

• Dominios que reciben correo sensible: nóminas, legal, salud, finanzas, flujos de autenticación de clientes.
• Organizaciones con cumplimiento estricto que ya requieren TLS en todas partes y necesitan postura exigible de los remitentes.
• Cualquiera cansado del TLS oportunista que es “opcional hasta que no lo es”.

Quién debería retrasar “enforce”

• Dominios con rutas entrantes heterogéneas (múltiples proveedores MX, on‑prem + nube, gateways legados).
• Cualquiera sin automatización de certificados y monitorización.
• Equipos que no pueden responder “¿Qué pasa si nuestro host de política está caído?” sin una reunión.

Mi recomendación con opinión:

• Habilita MTA-STS en mode: testing rápidamente (días), porque es de bajo riesgo y te da señal.
• Mantente en testing hasta tener evidencia: handshakes TLS exitosos desde múltiples redes, rotación de certificados limpia y una situación de MX de respaldo ordenada.
• Pasa a mode: enforce solo después de hacer un simulacro de failover que incluya la ruta del correo. Si nunca has probado el failover de MX en condiciones reales, no tienes failover; tienes un cuento para dormir.

Broma #1: La seguridad del correo es como usar hilo dental: todo el mundo acepta que es bueno, y mucha gente solo lo hace después de que algo duele.

Hechos e historia interesantes (rápido pero útil)

• MTA-STS es un RFC de la IETF de 2018 (RFC 8461). Es relativamente joven comparado con SMTP, por eso los despliegues varían mucho.
• SMTP STARTTLS se estandarizó en 2002 (RFC 3207). Durante años, la mayoría de las entregas fueron “oportunistas”: usa TLS si se ofrece, si no, envía en texto plano.
• MTA-STS se diseñó en parte porque el stripping de STARTTLS es real. No es teórico; atacantes en la red pueden manipular las capacidades anunciadas por el servidor.
• DANE para SMTP existía antes y utiliza DNSSEC para autenticar claves TLS. MTA-STS tomó el camino pragmático: HTTPS + CAs públicas, porque la adopción de DNSSEC en correo sigue siendo irregular.
• La política se obtiene por HTTPS desde un nombre fijo (mta-sts.<domain>). Eso es conveniente y también una dependencia operativa que debes mantener viva.
• Las políticas son cacheadas por los remitentes, lo que significa que tus errores pueden persistir y tus correcciones tardar en propagarse. “Lo arreglamos” no es lo mismo que “los remitentes han vaciado la política cacheada”.
• El registro DNS contiene un “id” que incrementas para señalar cambios. Esto es efectivamente un bust de caché para los remitentes.
• TLS-RPT existe como complemento: un mecanismo de reporte donde los remitentes pueden informarte de fallos TLS. Es lo más cercano a observabilidad que obtienes desde afuera.

Cómo se rompe el correo entrante con MTA-STS

MTA-STS no suele romper el correo inmediatamente cuando lo publicas. La parte desagradable es la falla retardada:

• Los remitentes obtienen tu política según su propio horario.
• La cachean por un tiempo.
• Solo la aplican cuando entregan a ti.

Así que puedes publicar “enforce” hoy y descubrir el daño mañana cuando un remitente importante actualice la política y de repente se niegue a entregar a tu MX “de respaldo” que en realidad es un appliance de spam de terceros con un certificado que caducó en mayo.

Mapa de modos de fallo (los sospechosos habituales)

• Desajuste en la lista MX: tu política lista mx1.example.com y mx2.example.com, pero tu DNS también anuncia mx-backup.vendor.net. Algunos remitentes pueden intentarlo; la política dice “no” y la entrega falla bajo enforce.
• Fallo en el handshake TLS: cifrados no soportados, incompatibilidad de versión TLS, comportamiento SNI roto o STARTTLS anunciado pero no funcionando de forma fiable.
• Problemas de certificado: certificado caducado, nombre equivocado, cadena intermedia faltante o una clave RSA demasiado pequeña para clientes modernos.
• Balanceador con comportamiento incorrecto: offload TLS que no pasa SNI correctamente o presenta un certificado por defecto a algunos remitentes.
• Host de política no disponible: mta-sts.example.com está caído o bloqueado. Algunos remitentes mantendrán la política cacheada; otros tratarán las fallas de fetch de forma diferente. No quieres que esto sea una dependencia sorpresa.
• Ruta “DR” inesperada: haces failover del correo entrante durante un incidente, pero el host MX de DR no está en la política o su certificado no valida. Bajo enforce, el failover se convierte en una caída autoinfligida.

El tema: MTA-STS te obliga a alinear lo que dices (política) con lo que haces (MX + realidad TLS). El trabajo técnico es manejable. El trabajo organizativo—inventariar todas las rutas entrantes—es donde ganas tu sueldo.

Guía rápida de diagnóstico

Cuando alguien dice “no estamos recibiendo correos”, puedes quemar horas debatiendo DMARC, filtrado de spam y errores de usuario. Las interrupciones por MTA-STS tienen un olor distinto: remitentes específicos fallando, errores TLS en sus logs y un cambio reciente en política/certificado/DNS.

Primero: confirma si MTA-STS está en juego

1. Comprueba que existe el registro TXT _mta-sts del dominio y cuál es el id.
2. Obtén el archivo de política y confirma el mode y los patrones MX.
3. Busca un reciente incremento del id de la política o cambio de certificado.

Segundo: valida MX + TLS desde fuera

1. Resuelve los registros MX y lista todos los hosts. Compáralos con las líneas mx: de la política.
2. Prueba STARTTLS y la validación de certificados contra cada host MX en el puerto 25.
3. Confirma la cadena de certificados y que el nombre de host coincide con lo que el remitente validará.

Tercero: correlaciona con fallos reales de entrega

1. Revisa tus logs SMTP para intentos de conexión, negociación STARTTLS y fallos.
2. Busca códigos de alerta TLS, fallos de handshake o “no hay cifrado compartido”.
3. Si publicas TLS-RPT, inspecciona los informes en busca de patrones: MX específico, versión TLS específica, remitente concreto.

Si haces esas tres rondas, normalmente aterrizarás en uno de: “política demasiado estricta para la realidad”, “certificado roto” o “MX cambiado sin actualizar la política”. Entonces la solución es sencilla.

Tareas prácticas: comandos, salidas, decisiones (12+)

Estas son las comprobaciones que realmente ejecuto cuando estoy a cargo de la entrega entrante. Cada tarea incluye el comando, un ejemplo de lo que podrías ver, qué significa y qué decisión tomar.

Task 1: Check if MTA-STS is published in DNS

cr0x@server:~$ dig +short TXT _mta-sts.example.com
"v=STSv1; id=20260103T1200Z"

Qué significa: MTA-STS está habilitado para example.com, y los remitentes cachearán la política identificada por id.

Decisión: Si el correo falla y cambiaste recientemente MX/TLS, considera si el archivo de política coincide con la realidad. Si necesitas publicar una política actualizada, incrementarás el id tras actualizar el archivo.

Task 2: Resolve MX records and inventory all inbound targets

cr0x@server:~$ dig +short MX example.com
10 mx1.example.com.
20 mx2.example.com.
50 mx-backup.vendor.net.

Qué significa: Hay tres destinos de entrega, incluyendo un respaldo de un proveedor.

Decisión: Asegura que la política incluya patrones que coincidan con todos los nombres MX que anuncies, o elimina el MX que no puedas poner en conformidad. Bajo enforce, los hosts MX “olvidados” se convierten en caídas.

Task 3: Fetch the MTA-STS policy file over HTTPS

cr0x@server:~$ curl -fsS https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

Qué significa: El modo enforce está activo; solo mx1 y mx2 están permitidos.

Decisión: Si aún publicas mx-backup.vendor.net en DNS, o lo añades a la política (si puede validar) o lo eliminas del MX para evitar que los remitentes lo intenten y fallen.

Task 4: Verify the policy host certificate and chain

cr0x@server:~$ echo | openssl s_client -connect mta-sts.example.com:443 -servername mta-sts.example.com -showcerts 2>/dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN = mta-sts.example.com
issuer=C = US, O = Example CA, CN = Example Issuing CA 01
notBefore=Dec  1 00:00:00 2025 GMT
notAfter=Mar  1 23:59:59 2026 GMT

Qué significa: El endpoint HTTPS presenta un certificado para el nombre correcto y no está caducado.

Decisión: Si las fechas son incorrectas o hay desajuste CN/SAN, arregla HTTPS primero. Los remitentes no pueden obtener la política de forma fiable si esto falla, y algunos seguirán aplicando la política cacheada de todos modos.

Task 5: Confirm that the policy file is served with HTTP 200 and sane headers

cr0x@server:~$ curl -sSI https://mta-sts.example.com/.well-known/mta-sts.txt | sed -n '1,8p'
HTTP/2 200
content-type: text/plain
cache-control: max-age=300
content-length: 104
date: Fri, 03 Jan 2026 12:15:11 GMT

Qué significa: Es accesible y devuelve texto plano. Un cacheo corto está bien; los remitentes siguen cacheando según max_age en la política.

Decisión: Si ves redirecciones a otro host, desafíos de autenticación o códigos distintos de 200, arréglalo. Mantenlo aburrido: archivo de texto estático, ruta estable, acceso público.

Task 6: Validate STARTTLS and certificate verification to each MX

cr0x@server:~$ echo | openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com -verify_return_error 2>/dev/null | egrep -i "Verify return code|subject=|issuer="
subject=CN = mx1.example.com
issuer=C = US, O = Example CA, CN = Example Issuing CA 01
Verify return code: 0 (ok)

Qué significa: TLS se negocia y el certificado valida para mx1.

Decisión: Repite para cada MX. Si algún MX falla la validación, o arreglas ese MX o asegúrate de que no esté anunciado/permitido cuando esté activado enforce.

Task 7: Check SMTP banner and STARTTLS support

cr0x@server:~$ printf 'EHLO test.example\r\nQUIT\r\n' | nc -w 5 mx2.example.com 25
220 mx2.example.com ESMTP Postfix
250-mx2.example.com
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250-8BITMIME
250-ENHANCEDSTATUSCODES
250 CHUNKING

Qué significa: El servidor anuncia STARTTLS. Bien.

Decisión: Si STARTTLS no se anuncia de forma consistente (intermitente), tienes un problema de balanceador o variación en los backends. MTA-STS amplificará eso en fallos de entrega graves.

Task 8: Detect “default certificate” problems behind a load balancer (SNI)

cr0x@server:~$ echo | openssl s_client -starttls smtp -connect mx1.example.com:25 2>/dev/null | openssl x509 -noout -subject
subject=CN = lb-default.example.net

Qué significa: Sin SNI, el servidor presenta un certificado por defecto que no coincide con mx1.example.com.

Decisión: Muchos MTAs no envían SNI en SMTP STARTTLS. No te fíes de ello. Arregla el frontend para presentar el certificado correcto por defecto en esa IP:puerto, o dedica IPs escuchando por hostname.

Task 9: Confirm TLS versions and ciphers (spot legacy breakage)

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.example.com:25 -tls1_2 -brief /dev/null | egrep -i "Protocol|Ciphersuite|Verification"
Protocol version: TLSv1.2
Ciphersuite: ECDHE-RSA-AES256-GCM-SHA384
Verification: OK

Qué significa: TLS 1.2 funciona y verifica.

Decisión: Si solo funciona TLS 1.0, los remitentes modernos pueden negarse incluso sin MTA-STS. Con MTA-STS en enforce, exiges validación estricta, así que actualiza tu pila TLS al siglo actual.

Task 10: Check Postfix TLS settings (receiver side)

cr0x@server:~$ postconf -n | egrep "smtpd_tls|smtpd_tls_security_level|smtpd_tls_cert_file|smtpd_tls_key_file"
smtpd_tls_security_level = may
smtpd_tls_cert_file = /etc/letsencrypt/live/mx1.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mx1.example.com/privkey.pem
smtpd_tls_loglevel = 1

Qué significa: El servidor ofrece TLS (“may”) y puedes ver qué certificado usa.

Decisión: Asegura que las rutas de certificado coincidan con el nombre de host que anuncias. Si tienes múltiples nombres MX en un mismo servidor, no puedes presentar diferentes certificados sin un diseño cuidadoso de listeners/IP.

Task 11: Spot TLS failures in mail logs quickly

cr0x@server:~$ sudo grep -E "TLS|SSL|handshake|STARTTLS" /var/log/mail.log | tail -n 8
Jan  3 12:07:51 mx1 postfix/smtpd[18291]: warning: TLS library problem: error:0A000152:SSL routines::unsafe legacy renegotiation disabled
Jan  3 12:08:02 mx1 postfix/smtpd[18302]: warning: TLS library problem: error:0A0000C1:SSL routines::no shared cipher
Jan  3 12:08:15 mx1 postfix/smtpd[18310]: Anonymous TLS connection established from mail-oi1-f172.google.com[209.85.167.172]: TLSv1.3 with cipher TLS_AES_128_GCM_SHA256

Qué significa: Estás viendo problemas de cipher/handshake con algunos clientes, pero éxito con otros. Eso apunta a variación de compatibilidad.

Decisión: Decide si ampliar el soporte de cifrados (con cuidado) o aceptar que algunos remitentes legados fallarán bajo enforce. Si esos remitentes importan, necesitas un plan de compatibilidad.

Task 12: Confirm policy id and caching behavior (did you bump id?)

cr0x@server:~$ dig +short TXT _mta-sts.example.com
"v=STSv1; id=20260103T1200Z"

Qué significa: Si cambiaste el archivo de política pero no el id, muchos remitentes seguirán usando la política cacheada hasta que expire.

Decisión: Al cambiar mode o líneas mx, incrementa el id. Trátalo como una versión de configuración.

Task 13: Verify TLS-RPT is published (observability from the outside)

cr0x@server:~$ dig +short TXT _smtp._tls.example.com
"v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Qué significa: Los remitentes que soportan el reporte TLS pueden enviarte informes agregados de fallos.

Decisión: Si vas a aplicar enforce, publica TLS-RPT y asegúrate de que ese buzón esté monitorizado. Si no, vuelas IFR con los instrumentos apagados.

Task 14: Check the certificate actually contains the MX hostname in SAN

cr0x@server:~$ echo | openssl s_client -starttls smtp -connect mx2.example.com:25 -servername mx2.example.com 2>/dev/null | openssl x509 -noout -text | sed -n '/Subject Alternative Name/,+1p'
            X509v3 Subject Alternative Name:
                DNS:mx2.example.com, DNS:mx2.internal.example.com

Qué significa: El certificado cubre el nombre MX público. Bien.

Decisión: Si SAN no incluye el nombre MX público, arregla la emisión del certificado. Solo CN no es suficiente para muchos validadores modernos.

Task 15: Confirm the vendor backup MX can do validated TLS (or remove it)

cr0x@server:~$ echo | openssl s_client -starttls smtp -connect mx-backup.vendor.net:25 -verify_return_error 2>/dev/null | egrep -i "subject=|Verify return code"
subject=CN = mx-backup.vendor.net
Verify return code: 0 (ok)

Qué significa: El MX del proveedor soporta TLS validado para su propio nombre. Eso es necesario pero no suficiente.

Decisión: Debes decidir si incluir mx-backup.vendor.net en tu política MTA-STS. Si lo mantienes en DNS pero lo excluyes de la política mientras estás en enforce, algunas entregas fallarán cuando los remitentes intenten el MX de menor prioridad.

Tres mini-historias corporativas desde las trincheras

1) El incidente causado por una suposición equivocada: “Por supuesto que nuestro MX de respaldo está bien”

Una empresa mediana tenía una configuración de correo limpia: dos hosts MX en activo-activo, certificados automáticos y un MX “de respaldo” apuntando a un gateway de higiene de terceros con un número de prioridad mayor. Ese respaldo estaba pensado para encolar correo si el sitio primario caía.

Implementaron MTA-STS en mode: enforce tras una revisión de seguridad. La política listaba solo sus dos MX principales. La suposición fue simple: “Los remitentes intentarán primero el MX primario; el respaldo es solo una red de seguridad”.

Entonces una ventana de mantenimiento introdujo un problema de enrutamiento de corta duración hacia un rango de IPs del MX primario desde la región de un remitente importante. No fue una caída total, solo una falla parcial de ruta. El remitente hizo lo que SMTP está diseñado para hacer: intentó registros MX alternativos. La siguiente elección fue el gateway de higiene del proveedor.

Bajo MTA-STS enforce, ese hostname del proveedor no estaba permitido. El remitente se negó a entregar en vez de “degradar” a un MX no autorizado. Desde la perspectiva de la empresa, el correo entrante falló solo desde ciertos remitentes, para ciertos destinatarios, durante una ventana que no se correlacionó con su propia monitorización.

La solución no fue heroica. O eliminaron el MX del proveedor del DNS, o lo incluyeron en la política y verificaron su postura TLS. La lección fue dolorosa: el comportamiento de failover de SMTP no es una característica teórica; es lo que pasa cuando internet se indispone.

2) La optimización que se volvió en contra: “Pongamos todo detrás de una IP”

Un equipo de correo empresarial decidió simplificar su borde: un VIP anycast en frente de múltiples nombres MX, una flota de balanceadores, un único conjunto de certificados, menos reglas de firewall. En el papel era ordenado. En los diagramas, era bello.

En la realidad, STARTTLS de SMTP no se comporta como el tráfico HTTPS moderno. Algunos MTAs remitentes no envían SNI. Otros se comportan de forma inconsistente según la versión. El balanceador confiaba en SNI para elegir el certificado correcto por nombre de host. Cuando faltaba SNI, servía un certificado por defecto que no coincidía con el nombre MX.

Antes de MTA-STS, esto causaba “algunas sesiones TLS fallan, luego la entrega cae a texto plano”. Feo, pero el correo llegaba. Tras MTA-STS enforce, esas mismas sesiones se convirtieron en fallos duros porque el remitente debía validar certificados. La optimización no solo falló; falló en voz alta y de forma selectiva.

Rectificaron el diseño: IPs de escucha dedicadas por nombre MX público, cada una presentando un certificado que coincide sin depender de SNI. Costó algunas IPs más y un poco más de configuración. Les compró entrega fiable.

Broma #2: El balanceador prometió “panel único”, y entregó “punto único de tristeza”.

3) La práctica aburrida pero correcta que salvó el día: “Trata la política como configuración con pipeline de despliegue”

Una empresa de servicios financieros habilitó MTA-STS en modo testing pronto y lo mantuvo allí más tiempo del que quería el equipo de seguridad. El equipo de correo insistió en procesos aburridos: un repo git para el archivo de política, revisión por pares y un pequeño trabajo de CI que validaba sintaxis y comparaba las entradas MX de la política contra el DNS en vivo.

También automatizaron cheques de caducidad de certificados para cada nombre MX y para el host de la política. No “alguien recibe un correo 30 días antes”; monitorización real conectada a paginación en horario laboral con runbooks claros.

Cuando una migración de centro de datos requirió cambiar nombres MX, lo hicieron por etapas: publica nuevos MX junto a los antiguos, actualiza la política MTA-STS para incluir ambos, incrementa el id, espera las ventanas de cacheo y luego quita las entradas antiguas. Lento, deliberado y ligeramente molesto.

Durante la migración, un proveedor intentó “ayudar” insertando un relay MX temporal. El chequeo de CI marcó que el nuevo MX no estaba en la política y rompería enforce más tarde. El cambio se atrapó antes de llegar al DNS de producción.

No pasó nada dramático. Ese es el punto. En operaciones, el mayor cumplido es “fue sin incidentes”, seguido de cerca por “nadie se enteró”.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: Gmail/Microsoft aplaza la entrega con errores relacionados con TLS

Causa raíz: Tu MX ofrece STARTTLS pero presenta un certificado inválido (hostname equivocado, caducado, intermedia faltante) o falla la negociación de forma intermitente.

Solución: Valida con openssl s_client -starttls smtp contra cada MX. Asegura que el certificado presentado coincida con el nombre MX y que la cadena esté completa. Corrige el comportamiento del certificado por defecto del balanceador.

2) Síntoma: Solo algunos remitentes fallan; otros entregan bien

Causa raíz: Cacheo de políticas y heterogeneidad de remitentes. Algunos remitentes obtuvieron tu política y la aplican; otros no aún, o tratan las fallas de forma distinta. Alternativamente, solo algunos remitentes llegan al MX/IP problemático por enrutamiento.

Solución: Identifica qué remitentes fallan y reproduce desde redes externas. Comprueba TLS-RPT si está disponible. Verifica cada endpoint MX, no solo el que sueles ver en logs.

3) Síntoma: El correo falla durante failover/mantenimiento pero funciona normalmente

Causa raíz: Tu MX de DR/respaldo no está incluido en la política o no puede pasar la validación TLS estricta.

Solución: Incluye el MX de DR en la política y mantén su postura TLS conforme, o no lo anuncies en MX. Prueba el failover bajo enforce antes de necesitarlo.

4) Síntoma: Actualizaste el archivo de política pero los remitentes siguen comportándose como si fuera el antiguo

Causa raíz: Olvidaste incrementar el id en el TXT DNS, así que los remitentes continúan usando la política cacheada.

Solución: Actualiza el archivo de política y luego incrementa el id en DNS. Planifica para retrasos de cacheo según max_age y comportamiento de remitentes.

5) Síntoma: El fetch de la política falla (404/redirect/auth) y la aplicación se vuelve impredecible

Causa raíz: Tu host mta-sts está detrás de reglas WAF, redirige HTTP→HTTPS incorrectamente, requiere autenticación, bloquea ciertos user agents o tiene disponibilidad intermitente.

Solución: Sirve la política como un archivo estático simple por HTTPS con un certificado válido. Evita autenticación, evita geo‑bloqueos, evita ingenierías innecesarias.

6) Síntoma: Algunos MTAs se quejan de “no shared cipher” o alertas de versión TLS

Causa raíz: Config TLS excesivamente estricta en tu MX, o pila TLS antigua en el remitente. Bajo enforce, algunos remitentes fallarán en vez de degradar.

Solución: Decide mínimos apropiados para el negocio. Soporta TLS 1.2 ampliamente. Mantén cifrados modernos pero no absurdamente restrictivos. Monitoriza quién falla y si importan.

7) Síntoma: Todo parece correcto, pero el correo entrante aún falla para un subconjunto de destinatarios

Causa raíz: Los registros MX difieren por región debido a DNS de horizonte dividido, direccionamiento DNS de CDN o caches de resolvers obsoletos devolviendo MX antiguos. Tu política puede no cubrir todas las variantes.

Solución: Consulta resolvers públicos desde múltiples regiones (o a través de tu monitorización). Asegura que la política cubra todos los nombres MX públicos que podrían ser devueltos.

Listas de verificación / plan paso a paso (despliegue seguro)

Step 0: Inventory the real inbound mail path

• Lista todos los registros MX (incluyendo “respaldo” y gateways de proveedores).
• Lista cualquier proxy/load balancer SMTP entrante y cómo se presentan los certificados.
• Lista escenarios de DR/failover y qué MX cambia durante un incidente.

Step 1: Make TLS boring (before you publish enforce)

• Automatiza emisión/renovación de certificados para cada nombre MX público.
• Asegura que se sirva la cadena completa (usa fullchain.pem donde corresponda).
• Confirma que STARTTLS se ofrece de forma consistente y funciona en todos los backends.
• Evita depender de SNI en SMTP para seleccionar certificados. Prefiere listeners dedicados IP:puerto por hostname si es necesario.

Step 2: Stand up the policy host correctly

• Proporciona mta-sts.<domain> en DNS con hosting estable.
• Sirve /.well-known/mta-sts.txt como archivo estático de texto plano por HTTPS.
• Usa un certificado válido y no bloquees el acceso con reglas WAF que traten al mundo como hostil (los remitentes son el mundo).

Step 3: Publish MTA-STS in testing mode

Comienza con:

• mode: testing
• Patrones MX que coincidan con todos tus hosts MX entrantes reales
• max_age ajustado a algo moderado (una semana es común; más corto durante iteración temprana puede ser razonable)

Luego publica el registro TXT con un id claro.

Step 4: Add TLS-RPT and actually read it

• Publica _smtp._tls TXT apuntando los informes a una dirección monitorizada.
• Configura una regla de buzón o pipeline de ingestión para que los informes no se pudran.
• Busca: qué MX falla, por qué (certificado vs handshake vs DNS) y si es consistente.

Step 5: Do a failover drill while still in testing

• Simula pérdida del MX primario (o cambio de ruta) y observa qué MX eligen los remitentes a continuación.
• Confirma que la ruta alternativa está permitida por la política y valida TLS.
• Arregla la deriva ahora, no durante una caída.

Step 6: Move to enforce with a change window and rollback plan

• Actualiza el archivo de política a mode: enforce.
• Incrementa el id en DNS.
• Monitoriza logs y TLS-RPT durante al menos una ventana de cacheo.
• Plan de rollback: vuelve a mode: testing y sube el id otra vez si ves fallos de entrega materiales.

Step 7: Keep it alive (the part everyone forgets)

• Monitoriza caducidad de certificados para: cada MX + el host mta-sts.
• Monitoriza disponibilidad HTTPS del archivo de política.
• Trata los cambios de MX como un cambio acoplado: DNS + política + certificados, enviados juntos.

Preguntas frecuentes

1) ¿MTA-STS detendrá el spam?

No. MTA-STS es seguridad del transporte. Ayuda a prevenir degradación de TLS y fuerza la validación de certificados. El control de spam es principalmente SPF/DKIM/DMARC más filtrado.

2) ¿Es MTA-STS redundante si ya usamos STARTTLS?

STARTTLS por sí solo suele ser oportunista: si TLS falla, muchos remitentes vuelven a texto plano. MTA-STS les dice a los remitentes compatibles que no degraden para tu dominio.

3) ¿Deberíamos ir directamente a enforce?

No, a menos que hayas validado cada endpoint MX, incluyendo rutas DR y de proveedores, y tengas automatización de certificados y monitorización. El modo testing es un seguro barato.

4) ¿Qué hace realmente el id de la política?

Es una señal de versión. Los remitentes cachean la política; cuando cambia el id, saben que deben recuperar una nueva. Si cambias la política sin cambiar el id, muchos remitentes no notarán rápidamente.

5) ¿Podemos listar direcciones IP en MTA-STS en lugar de hostnames?

No. Las políticas MTA-STS hacen match con nombres MX (con patrones exactos o comodines). Esa es una razón por la que el comportamiento del balanceador y los certificados importan tanto.

6) ¿Y si nuestros hostnames MX son gestionados por un proveedor y cambian?

Entonces necesitas un contrato operativo: hostnames estables, o un proceso para actualizar la política e incrementar el id de forma fiable. Si el proveedor no puede garantizar estabilidad, el modo enforce se convertirá en un generador recurrente de incidentes.

7) ¿MTA-STS requiere DNSSEC?

No. Esa es una diferencia clave con DANE. MTA-STS confía en HTTPS y en el ecosistema de CAs públicas para la autenticidad de la política.

8) Si nuestro host de política cae, ¿para de llegar el correo?

Normalmente no de inmediato, porque los remitentes cachean políticas. Pero crea ambigüedad y fallos retardados. Mantén mta-sts.<domain> altamente disponible; es un servicio pequeño con un radio de impacto desproporcionado.

9) ¿Qué max_age deberíamos usar?

Valores comunes están en el orden de días a semanas. Ages más cortos reducen cuánto duran los errores, pero aumentan la frecuencia de fetch. Escoge algo que puedas soportar operativamente, y recuerda que el cacheo varía según el remitente.

10) ¿Cómo hacemos rollback si enforce rompe el correo entrante?

Actualiza la política a mode: testing (o afloja temporalmente los patrones MX), luego incrementa el id en DNS. Espera que algunos remitentes sigan aplicando la política cacheada hasta que la refresquen.

Conclusión: próximos pasos que puedes enviar esta semana

MTA-STS merece la pena porque TLS oportunista no es un límite de seguridad; es una sugerencia educada. Pero el modo enforce es una promesa, y la internet te hará cumplirla.

Pasos prácticos:

1. Inventaria todos los objetivos MX y compáralos con la realidad (incluyendo proveedores y rutas DR).
2. Levanta el host de política como un archivo HTTPS estático con certificado válido y disponibilidad aburrida.
3. Publica MTA-STS en modo testing con patrones MX correctos y un max_age sensato.
4. Valida STARTTLS + verificación de certificados hacia cada MX desde fuera de tu red.
5. Publica TLS-RPT y dirige los informes a algo monitorizado.
6. Haz un simulacro de failover mientras aún estás en testing. Arregla lo que falle. Luego pasa a enforce con un plan de rollback.

Si haces esto como un cambio de producción—config versionada, endpoints monitorizados, failover ensayado—MTA-STS se convierte en una de las raras mejoras de seguridad de correo que no te castigará después. Si lo haces como una casilla por marcar, eventualmente te despertará a las 2 a.m. y exigirá un sacrificio.