MTA-STS y TLS-RPT: cómo proteger los dominios que reciben respuestas de outbound

SMTP suele negociar TLS de forma oportunista. RFC 8461 explica que un atacante activo podría intentar eliminar la señal STARTTLS o redirigir la conexión hacia otro MX. MTA-STS permite que el dueño del dominio receptor publique qué servidores aceptan su correo y exija TLS con un certificado válido a los remitentes que soportan el estándar.

TLS-RPT, definido en RFC 8460, añade visibilidad. El dominio publica dónde recibir reportes agregados sobre sesiones correctas y fallas como certificado vencido, MX que no coincide o STARTTLS ausente. No es otro DMARC: DMARC observa autenticación y alineación del dominio visible; TLS-RPT observa seguridad de transporte entre servidores.

Para outbound, el ángulo correcto es correo entrante. Si una campaña envía desde ventas@example.com y el prospecto responde a esa dirección, su servidor intenta entregar el mensaje a los MX de example.com. MTA-STS puede proteger ese trayecto cuando el servidor remitente lo implementa. No modifica cómo salió el cold email ni garantiza que llegue a inbox.

Lista cada dominio que recibe respuestas, no solo la marca principal. Incluye dominios secundarios de prospección, subdominios usados en direcciones Reply-To, alias, grupos, proveedores de help desk, gateways antispam y rutas de respaldo. Para cada uno registra MX observado, proveedor esperado, prioridad, certificado presentado, soporte STARTTLS, owner y último test de recepción.

Confirma el destino real. Si los MX apuntan directamente a Google Workspace o Microsoft 365, la política debe incluir los hosts que el proveedor indica. Si apuntan a un gateway o servicio intermedio, ese sistema es el receptor visible para MTA-STS. Microsoft advierte que, cuando existe un intermediario, el dominio debe verificar sus requisitos con ese proveedor en lugar de copiar los MX de Exchange Online.

Prueba todos los MX, incluidos backups de menor prioridad. Un servidor secundario puede permanecer oculto mientras el primario funciona y fallar justo durante un incidente. El inventario necesita una respuesta end to end: mensaje externo recibido, respuesta visible en mailbox y sincronización correcta hacia sender o CRM.

Para example.com, la ubicación fija es https://mta-sts.example.com/.well-known/mta-sts.txt. El host debe presentar un certificado X.509 vigente y válido para mta-sts.example.com. RFC 8461 exige respuesta HTTP 200; los remitentes no deben seguir redirects 3xx. Sirve el archivo como text/plain y evita depender de autenticación, cookies o una aplicación que reescriba la ruta.

Una política inicial puede contener: version: STSv1; mode: testing; mx: mx1.example.com; mx: mx2.example.com; max_age: 86400. En el archivo real cada par va en su propia línea; RFC 8461 acepta finales LF o CRLF. Cada MX permitido necesita su propia línea. Un wildcard solo puede ocupar la etiqueta izquierda completa, como *.example.net; no coincide con example.net ni con foo.bar.example.net.

El max_age expresa cuántos segundos puede conservarse la política. RFC 8461 permite hasta 31,557,600 y espera normalmente periodos de semanas o más para políticas estables. Un valor corto durante pruebas puede acelerar correcciones, pero no elimina cachés existentes ni reemplaza una ventana de cambio. Elige el valor según capacidad de operación y rollback.

En DNS crea _mta-sts.example.com con el valor TXT v=STSv1; id=2026091901;. El id no es una versión semántica ni un secreto: señala a los remitentes que existe una política nueva y deben volver a consultarla. Puede ser una fecha, timestamp o identificador interno mientras cambie con cada versión.

Actualiza primero el cuerpo HTTPS y después el TXT. RFC 8461 recomienda ese orden para evitar que un remitente vea el id nuevo y vuelva a descargar todavía el archivo anterior. Considera el TTL del DNS y el max_age de políticas ya almacenadas; durante una transición, la versión anterior debe seguir permitiendo entrega mientras existan cachés.

No publiques un TXT correcto apuntando a un host sin certificado o a una ruta que redirige. Si un remitente encuentra el TXT pero no puede obtener una política y no conserva una válida en caché, el estándar le permite continuar como si no hubiera MTA-STS. La configuración puede parecer presente en DNS y, al mismo tiempo, no ofrecer protección efectiva.

Publica otro TXT en _smtp._tls.example.com con v=TLSRPTv1; rua=mailto:tls-reports@example.com. RFC 8460 también permite un endpoint HTTPS. Usa un buzón o procesador preparado para reportes JSON y archivos comprimidos; abrir adjuntos manualmente cada mañana no escala y vuelve fácil perder una tendencia.

Los reportes agregan periodos, política aplicada, MX, conteos de sesiones correctas y fallidas, y detalles por tipo. Un mismo intento puede contribuir a más de un tipo de falla, por lo que no siempre debes sumar categorías como si fueran eventos exclusivos. Conserva report_id, organización que reporta, rango, host receptor y motivo antes de construir porcentajes.

No todos los remitentes soportan TLS-RPT ni todos enviarán volumen suficiente. Google advierte que pueden llegar pocos reportes mientras la adopción varía. La ausencia de reportes no prueba que todo esté bien; combínalos con pruebas sintéticas, logs del proveedor, certificados, DNS y mensajes reales.

En testing, un remitente compatible puede informar fallas sin bloquear la entrega por el error de política. Ese modo sirve para descubrir certificados vencidos, hosts ausentes en la lista mx, servidores sin STARTTLS, errores de DNS y endpoints HTTPS inaccesibles antes de convertirlos en mensajes diferidos.

Mantén testing durante todos los ciclos relevantes para la operación: respuestas de campañas, correo humano, facturación, help desk, formularios y proveedores que envían de manera mensual o estacional. No existe un número universal de días. El criterio de salida es poder explicar las fallas y haber probado cada ruta autorizada, no esperar a que transcurra una cifra cómoda.

Define gates: todos los MX productivos incluidos; certificados válidos; endpoint con 200 y text/plain; TXT visible; reportes procesados; backups probados; y respuesta real recibida por cada dominio activo. Documenta qué fallas corresponden a remitentes que no soportan el estándar y cuáles muestran una configuración propia que sí debes corregir.

En enforce, un remitente compatible no debe entregar a un host que no coincide con la política, no ofrece STARTTLS o presenta un certificado inválido. Normalmente tratará la falla como temporal y volverá a intentar, pero la consecuencia para ventas es concreta: una respuesta puede demorarse o no llegar si la política está equivocada.

Antes del cambio, congela modificaciones de MX, valida certificados y reduce lanzamientos que dificulten distinguir un incidente técnico de variación comercial. Publica mode: enforce en el archivo HTTPS, revisa su contenido desde una red externa y después cambia el id del TXT. Observa reportes, colas, bounces y recepción en todos los dominios.

No uses enforce como prueba. El modo existe para expresar un compromiso real sobre los MX. Si todavía desconoces un gateway, backup o proveedor, conserva testing y corrige el inventario. Endurecer una política incompleta no demuestra madurez; convierte una duda de configuración en un problema de entrega.

Prepara antes del cambio el archivo anterior, el nuevo, TTL, max_age, responsable de DNS, responsable del hosting y contacto del proveedor. Si aparece una falla, corrige el certificado o la lista mx cuando sea posible. Si necesitas pausar enforcement, publica mode: testing o mode: none según el objetivo y cambia el id para solicitar una actualización.

La recuperación no es instantánea. Algunos remitentes conservarán una política válida hasta su max_age y los resolvers pueden conservar el TXT hasta el TTL. RFC 8461 propone, para retirar MTA-STS, publicar mode: none con max_age corto, anunciar un id nuevo y esperar a que expiren políticas previas antes de borrar TXT y endpoint. Eliminar los registros de golpe no invalida lo que ya está en caché.

Después del incidente identifica dominios y campañas que pudieron perder respuestas. Revisa inboxes, registros IMAP o API, colas y conversaciones abiertas; no concluyas que una persona ignoró el email cuando el trayecto de retorno estaba fallando. Actualiza el inventario y añade una prueba que reproduzca la causa antes de volver a enforce.

Google Workspace publica una secuencia de configuración: revisar el dominio, crear la política, alojarla, publicar DNS y activar reportes. Su documentación recomienda comenzar en testing para recibir información antes de exigir cifrado y autenticación. El dominio sigue siendo responsable del host mta-sts y de que la política describa sus MX reales.

Microsoft indica que Exchange Online aplica de forma permanente validación MTA-STS al correo saliente hacia dominios protegidos. Para proteger correo entrante del dominio del cliente, el administrador publica su propia política; Exchange Online no hospeda el archivo por el cliente. Microsoft documenta ejemplos con Azure, pero el estándar no exige ese proveedor de hosting.

En ambos casos, no copies una política genérica. Los MX pueden cambiar por tenant, región, gateway, adquisición o arquitectura híbrida. Usa la documentación actual de tu proveedor y lo observado en DNS. Si existen varios proveedores receptores, cada patrón autorizado debe aparecer y cada certificado debe validar para su hostname.

Sigue sesiones exitosas y fallidas por dominio, organización reportante, MX y tipo de resultado. Alerta por certificate-expired, certificate-host-mismatch, starttls-not-supported, validación fallida, host no cubierto y error de consulta de política. Relaciona el inicio de la anomalía con cambios de DNS, certificados, gateway o proveedor.

Añade métricas de negocio: último test inbound exitoso, última respuesta recibida por inbox, latencia hasta sender o CRM y conversaciones afectadas durante incidentes. TLS-RPT puede decir que hubo una falla de transporte; no sabe si era la respuesta de la cuenta más importante del trimestre. El puente entre seguridad y operación necesita IDs, tiempo y ownership.

No conviertas success count en KPI de inbox placement. Una sesión TLS correcta protege el canal entre MTAs, no evalúa reputación, contenido, lista o carpeta final. Mantén por separado autenticación SPF/DKIM/DMARC, rebotes, quejas, pruebas de bandeja y resultados comerciales.

El primer error es describirlos como controles del correo saliente. La política la publica el dominio receptor y la aplican remitentes compatibles al entregar hacia él. El segundo es confundir TLS-RPT con DMARC rua. Son registros, esquemas y problemas distintos; usa endpoints y procesadores capaces de identificar cada formato.

También fallan configuraciones con redirects, certificado incorrecto en mta-sts, archivo servido como página HTML, mx incompleto, wildcard demasiado amplio, id sin actualizar o enforce activado antes de probar backups. Otra trampa es proteger example.com y asumir que la política baja a reply.example.com: RFC 8461 indica que un subdominio receptor necesita su propia política.

Por último, MTA-STS no cubre remitentes que no lo soportan y su descubrimiento inicial por DNS todavía tiene límites frente a ciertos ataques. Es una mejora de seguridad con alcance definido, no cifrado universal ni sustituto de DANE, DNSSEC, autenticación o monitoreo.

Los equipos suelen invertir casi toda la atención en el trayecto de salida: warmup, SPF, DKIM, DMARC, listas y copy. Sin embargo, el resultado comercial vuelve por los MX. Un dominio capaz de enviar pero incapaz de recibir con seguridad y observabilidad es media infraestructura, aunque el dashboard muestre miles de mensajes procesados.

MTA-STS y TLS-RPT añaden una capa específica: transporte autenticado hacia los servidores receptores y evidencia agregada de fallas. Deben desplegarse después de entender MX, certificados y proveedores, primero en testing y con rollback. Copiar tres registros en DNS sin mirar la ruta completa solo vuelve más elegante el incidente.

picos.Ai puede inventariar dominios de outreach, validar MX y certificados, alojar o revisar políticas, procesar reportes y probar replies hasta el CRM. Si tus dominios reciben oportunidades pero nadie monitorea la seguridad del trayecto entrante, usa el enlace Hablemos al final de esta página. Empezamos por testing y evidencia, no por enforce.