¿Qué es MTA-STS?
MTA-STS (Seguridad de transporte estricta del agente de transferencia de correo) permite que un dominio declare que las conexiones SMTP entrantes deben usar TLS con un certificado válido. Combina un registro DNS TXT en _mta-sts.yourdomain.com con un archivo de política servido a través de HTTPS en mta-sts.yourdomain.com/.well-known/mta-sts.txt. El registro DNS anuncia que existe una política y lleva una identificación que cambia cada vez que se actualiza la política.
Sin MTA-STS, un atacante en la ruta puede eliminar silenciosamente el oportunista TLS de SMTP, lo que obligará a que el correo se entregue en texto sin formato. MTA-STS cierra esa brecha al ordenar a los servidores de envío que rechacen la entrega si no se puede negociar TLS. Se combina naturalmente con TLS-RPT, que le envía informes por correo electrónico cuando un remitente no puede cumplir con la política. El estándar está definido en RFC 8461.
¿Por qué verificar su registro MTA-STS?
1Confirmar que la política es detectable
Si el registro DNS falta o tiene un formato incorrecto, los remitentes nunca buscan su archivo de política; verifique que se resuelva
2Atrapa una identificación que nunca cambia
La identificación debe actualizarse con cada cambio de política o los cachés sirven una política obsoleta: un verificador muestra el valor actual
3Evite degradaciones silenciosas de TLS
Un registro funcional indica a los remitentes que requieran cifrado, protegiendo el correo en tránsito contra la interceptación.
4Validar antes de aplicar el modo
Confirme que el registro y la política estén alineados mientras está en modo de prueba para que al cambiar a aplicar no se rebote el correo legítimo.
Cómo funciona MTA-STS: paso a paso
Usted aloja un archivo de política en https://mta-sts.yourdomain.com/.well-known/mta-sts.txt que describe el modo, los hosts MX y max_age.
Publica un registro TXT en _mta-sts.yourdomain.com que contiene la versión y una identificación única.
Se anuncia un servidor de envío a punto de entregar consultas de correo que registran TXT y ve una política.
Obtiene el archivo de política HTTPS, valida el MX receptor y su certificado TLS.
Si la política está en modo de cumplimiento y TLS no se puede validar, el remitente se niega a realizar la entrega en lugar de recurrir al texto sin formato.
Sintaxis de registro MTA-STS
_mta-sts.example.com. 3600 IN TXT "v=STSv1; id=20240118T120000Z"
# https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mail.example.com
max_age: 604800Desglose de etiquetas DNS
v=STSv1— versión del protocolo, siempre primeroidentificación =- token único, cambios en cada actualización de políticaCampos del archivo de política
Fallos y soluciones comunes de MTA-STS
Archivo de política inalcanzable
El archivo .well-known debe cargarse a través de HTTPS con un certificado válido: corrija el host antes de que los remitentes puedan aplicarlo.
Identificación obsoleta
Olvidar cambiar la identificación después de editar la política hace que los remitentes conserven la anterior; cámbiela en cada actualización
MX no coincide
Si las entradas mx no coinciden con sus registros MX reales, el modo forzar bloquea el correo legítimo: manténgalos sincronizados
Saltar directamente para hacer cumplir
Comience a realizar pruebas con TLS-RPT para detectar problemas antes de que el modo de aplicación pueda rebotar mensajes.
Preguntas Frecuentes
MTA-STS (Seguridad de transporte estricta del agente de transferencia de correo) permite que su dominio indique a los servidores de envío que el correo debe entregarse a través de TLS con un certificado válido. Combina un registro DNS TXT en _mta-sts.yourdomain.com con un archivo de política alojado en HTTPS. Sin él, un atacante puede eliminar el cifrado oportunista de SMTP en la ruta de la red, lo que obligará a su correo a viajar en texto sin formato.
El registro TXT en _mta-sts.yourdomain.com contiene dos cosas: la versión (v=STSv1) y una identificación, un token único que debe cambiar cada vez que actualiza el archivo de política. El registro no contiene la póliza en sí; simplemente anuncia que existe una política y señala, a través de una identificación modificada, cuándo los remitentes deben volver a buscarla.
El modo se establece en el archivo de política HTTPS, no en el registro DNS. En el modo de prueba, los remitentes informan fallas de TLS (a través de TLS-RPT) pero aún entregan el correo, lo que le permite encontrar problemas de forma segura. En el modo obligatorio, los remitentes se niegan a realizar la entrega si no se puede validar TLS. La mejor práctica es ejecutar las pruebas con los informes habilitados primero y luego cambiar a aplicar una vez que confirme que todo funciona.
Ambos requieren TLS para el correo entrante, pero anclan la confianza de manera diferente. DANE utiliza registros DNSSEC y TLSA para fijar certificados, por lo que depende de la implementación de DNSSEC. MTA-STS utiliza la PKI web pública y una política alojada en HTTPS, por lo que funciona sin DNSSEC. Muchos dominios adoptan MTA-STS primero porque es más sencillo de implementar en la infraestructura existente.
Los motivos comunes son un registro TXT faltante o con formato incorrecto, una identificación que no se actualizó después de un cambio de política o un archivo de política que no se carga a través de HTTPS con un certificado válido. Este verificador verifica el registro DNS; También confirme que el archivo en /.well-known/mta-sts.txt sea accesible y que sus entradas mx coincidan con sus registros MX reales.