MTA-STS permite que un dominio receptor publique expectativas para la entrega TLS autenticada. Dirige la conexión SMTP al servicio receptor. No autentica la dirección De del autor del mensaje ni cifra el mensaje desde el dispositivo de una persona a otra.
Una implementación funcional conecta tres cosas: las rutas MX entrantes reales del dominio, la política HTTPS y el registro DNS que señala esa política. Los informes TLS proporcionan una ruta de retroalimentación independiente.
Establecer el límite de recepción real
Referencias: RFC 8461 §3.4, RFC 8461 §4.
Enumere los hosts MX que aceptan correo para el dominio, incluidos los servicios de respaldo y una puerta de enlace de seguridad ascendente. Verifique el comportamiento TLS y del certificado en el límite de recepción público real, no solo en un servidor de buzón de correo interno.
Registre quién es el propietario de la ruta MX , el alojamiento de políticas, la renovación de certificados y el destino de informes. Un servicio de buzón de correo alojado no necesariamente aloja la política MTA-STS del cliente ni opera todas las puertas de enlace que se encuentran frente a ella.
Evalúe los subdominios por separado. MTA-STS no utiliza herencia de políticas principales estilo DMARC. Un subdominio receptor necesita la configuración aplicable a ese dominio.
Cree una política para los hosts reales
Referencias: RFC 8461 §3.2, RFC 8461 §3.3.
Entregue la política desde la ubicación HTTPS requerida para el dominio receptor. Por example.com , la ubicación es https://mta-sts.example.com/.well-known/mta-sts.txt. El servicio HTTPS necesita un certificado válido para su nombre de host de política.
La política identifica su versión, modo, patrones MX permitidos y duración máxima de la caché. Comience con una implementación de pruebas apropiada para el alcance e inspeccione los resultados antes de aplicarlas. Elija el período de observación entre el tráfico real y las dependencias en lugar de tratar una duración de muestra como prueba universal.
Una política ilustrativa para un dominio MX único ficticio es:
versión: modo STSv1: prueba mx: mx1.example.net max_age: 86400Este ejemplo supone que mx1.example.net es el host receptor real del dominio y tiene soporte SMTP TLS adecuado. No es una póliza ya preparada para otro proveedor. Haga coincidir los hosts permitidos con precisión e incluya todas las rutas de recepción legítimas.
Publicar descubrimientos e informes por separado
Referencias: RFC 8461 §3.1, RFC 8461 §8.1, RFC 8460 §3.
En _mta-sts.example.com , un valor TXT ilustrativo es v=STSv1; id=2026110701. El identificador indica una revisión de la política. Publicar y verificar la política antes de anunciar su nueva revisión en DNS .
TLS-RPT utiliza su propio registro en _smtp._tls.example.com . Una solicitud ilustrativa es v=TLSRPTv1; rua=mailto:tls-reports@example.com, suponiendo que esa dirección exista y su ruta de recopilación funcione.
No asumas un DMARC rua destino recibe automáticamente informes TLS , o que las pruebas MTA-STS por sí solas crean una solicitud de informes funcional. Verifique cada registro con el nombre correcto y cada destino mediante su propio proceso de recolección.
Probar la cadena implementada
Referencias: RFC 8461 §4, RFC 8461 §6.
Obtenga la política externamente y confirme que el punto final HTTPS requerido proporcione el cuerpo de texto sin formato deseado con HTTP 200. No siga las redirecciones HTTP: una redirección no es una búsqueda de política válida según RFC 8461 §3.3. Verifique DNS de descubrimiento y compare todas las rutas MX anunciadas con los patrones permitidos.
Pruebe SMTP TLS y la validación de certificados en cada ruta de recepción. Un certificado web que funcione en mta-sts.example.com no establece que el servidor MX presente un certificado SMTP válido.
Revise los informes TLS disponibles y la evidencia de entrega controlada. Los servicios de envío difieren en cuanto a participación, por lo que el silencio no garantiza el éxito universal. Mantenga el reportero, el intervalo y MX afectado con cada observación.
En un caso sintético, una política permite solo la puerta de enlace principal, mientras que DNS también anuncia un MX de respaldo. La copia de seguridad acepta correo en pruebas ordinarias pero no coincide con la política. Reparar la política o el diseño de enrutamiento antes de su aplicación; No descarte la copia de seguridad porque su volumen diario es pequeño.
Planificar la aplicación y la recuperación en torno a las cachés
Referencias: RFC 8461 §5, RFC 8461 §8.3.
El modo Enforce puede evitar que los remitentes compatibles entreguen a través de una conexión no compatible. Los remitentes que no respaldan están fuera de esa garantía. Registre la dependencia y la respuesta operativa aceptable antes de cambiar de modo.
Las cachés del remitente pueden conservar políticas anteriores válidas para su max_age. Eliminar DNS de descubrimiento o eliminar el punto final HTTPS no es una reversión global inmediata. Para el retiro, publique un modo válido: ninguna política con una vida útil corta y luego actualice la identificación de descubrimiento. Mantenga ambos puntos finales disponibles hasta que hayan caducado todas las políticas anteriores, incluidas las revisiones anteriores con una vida útil más larga. Cuente cada vida útil desde la última vez que se publicó esa revisión, no solo desde la siguiente edición.
Para una migración de puerta de enlace, haga que la política sea compatible con la transición planificada, verifique la nueva ruta y permita versiones almacenadas en caché. Mantenga el punto final de la política disponible mientras los remitentes relevantes aún puedan confiar en él.
La transferencia debe incluir la configuración MX , el historial de políticas, la propiedad del certificado y el manejo de informes. MTA-STS sigue siendo útil cuando esas piezas móviles se mantienen juntas.