Publique MTA-STS y TLS-RPT primero en modo testing

SPF, DKIM y DMARC impiden que otros falsifiquen su nombre (puede comprobar su registro DMARC), pero ninguno evita que un servidor remitente le entregue el correo en texto plano. MTA-STS le permite publicar una política que indica que sus servidores de correo admiten TLS autenticado, y TLS-RPT le avisa cuando los remitentes no han podido conseguirlo. Puede desplegar ambos con dos registros DNS y un archivo de texto, y puede empezar en un modo pensado para un despliegue gradual.

Lo que STARTTLS deja abierto

El cifrado del correo entre servidores utiliza la extensión STARTTLS y es oportunista. RFC 8461 describe el punto débil: un atacante capaz de eliminar la respuesta "250 STARTTLS" de la sesión SMTP, o de redirigirla sobrescribiendo el registro MX resuelto, puede forzar un downgrade o interceptar la sesión.

DANE es la otra solución, definida en RFC 7672, pero exige DNSSEC. MTA-STS se apoya en cambio en las autoridades de certificación y no necesita DNSSEC, "a costa de arriesgarse a downgrades maliciosos" en palabras del propio RFC. Si ya utiliza DANE, ambos no entran en conflicto: los remitentes que implementan MTA-STS no deben permitir que este anule una validación DANE fallida.

La guía del NCSC sobre seguridad del correo electrónico indica que su servicio debe ser capaz de enviar y recibir correo mediante TLS, y que debe proteger todos sus dominios, incluidos los alojados en proveedores cloud como Google G Suite y Microsoft O365.

Primer paso: la política, en modo testing

MTA-STS tiene dos partes. Un registro TXT en _mta-sts.example.com anuncia que existe una política y cuál es su versión:

_mta-sts.example.com. IN TXT "v=STSv1; id=20250101000000Z;"

El id consta de letras y dígitos, hasta 32 caracteres, y debe identificar de forma única esta versión de la política. No hay ningún orden implícito, así que usar una marca de tiempo es una costumbre y no un requisito. Publique exactamente un registro de este tipo: los remitentes descartan los registros que no empiezan por v=STSv1;, y si después el número de registros no es uno, asumen que usted no tiene política.

La política en sí se obtiene por HTTPS desde una dirección fija, que se construye anteponiendo mta-sts a su dominio:

https://mta-sts.example.com/.well-known/mta-sts.txt

Sírvala como text/plain, porque los remitentes deben comprobar el tipo de medio. El archivo tiene este aspecto:

version: STSv1
mode: testing
mx: mail.example.com
mx: *.example.net
max_age: 604800

Cada línea mx: es una entrada independiente, ya sea un nombre de host completo o un sufijo con comodín como *.example.net. Incluya todos los hosts de sus registros MX en producción, también los de un proveedor cloud.

Los tres modos son enforce, testing y none. El RFC describe testing como un modo opcional que permite despliegues graduales para detectar fallos de la política, y por eso conviene empezar por él.

El max_age se expresa en segundos, hasta 31557600, y 604800 (una semana) es el ejemplo del propio RFC. El RFC espera que los valores en producción estén normalmente en el rango de semanas o más. Mi consejo: mantenga una semana o menos durante las pruebas, para que una política corregida llegue rápido a los remitentes, y auméntelo cuando enforce lleve un tiempo estable.

Segundo paso: active TLS-RPT

La detección solo funciona si los remitentes le cuentan lo que han visto. Publique un registro TXT en _smtp._tls.example.com:

_smtp._tls.example.com. IN TXT "v=TLSRPTv1;rua=mailto:tlsrpt@example.com"

El rua también puede ser un URI https, en cuyo caso los remitentes envían el informe mediante POST, y se admite una lista separada por comas. Igual que con el registro de MTA-STS, exactamente un registro TXT debe empezar por v=TLSRPTv1;; de lo contrario, los remitentes asumen que usted no lo implementa.

Si opta por mailto, utilice un buzón dedicado. Los remitentes entregan estos informes incluso cuando TLS falla, por lo que un informe puede llegar sin cifrar. Los informes enviados por correo deben llevar una firma DKIM válida del dominio que informa, y el RFC dice que los destinatarios deben ignorar los que no la tengan. Descarte los informes sin firma en lugar de actuar en consecuencia.

Compruebe lo que ven los remitentes

Consulte ambos registros y descargue el archivo de política desde fuera de su red:

dig TXT _mta-sts.example.com
dig TXT _smtp._tls.example.com
curl -si https://mta-sts.example.com/.well-known/mta-sts.txt

La salida de dig debe mostrar un registro en cada caso, con el prefijo v= al principio. La salida de curl debe mostrar un 200, Content-Type: text/plain y el cuerpo de la política, así que verifique que mode y cada línea mx: son los que pretendía. Corrija cualquier error de certificado que informe curl antes de publicar el registro TXT.

Cómo leer los informes

Los informes son archivos JSON que cubren un intervalo de tiempo, con un resumen de entregas con los recuentos de éxitos y fallos. El RFC agrupa los fallos en fallos de negociación, de política, generales y transitorios. Los informes pueden llegar comprimidos (el RFC define application/tlsrpt+gzip), así que descomprima uno primero:

gzip -dc report.json.gz | jq .

Los nombres de los campos están definidos en la sección 4.4 de RFC 8460. Lea primero los recuentos del resumen y después las entradas de fallos.

Un informe con muchos éxitos y ningún fallo es lo que desea ver. El RFC señala que un informe puede actuar como latido que demuestra que TLS se negocia como se espera, y una serie constante de informes limpios es su prueba para avanzar. Los fallos que mencionan alguno de sus propios hosts MX apuntan a un certificado o a un patrón mx que debe corregir. Un remitente con una pila defectuosa es problema suyo, no de usted.

Un aumento de fallos de STARTTLS que no pueda relacionar con ningún cambio debe trasladarse a quien gestione los incidentes, o a nuestro equipo de respuesta a incidentes si no cuenta con nadie.

Paso a enforce

Espere a que los informes salgan limpios con sus patrones normales de correo, incluidos remitentes poco frecuentes como los sistemas de facturación mensual. Después cambie mode: testing por mode: enforce y cambie el id en el registro TXT, porque los remitentes lo comparan con su copia en caché para saber que algo ha cambiado.

Los remitentes pueden mantener una política en caché hasta max_age desde la última descarga, de modo que un error puede persistir. Eliminar el registro TXT tampoco borra una política en caché, como señala el RFC. RFC 8461, sección 8.3, trata la retirada de la política, y conviene que la lea antes de necesitarla.

Por dónde empezar

1. Haga una lista de sus hosts MX en producción, incluidos los de cualquier proveedor cloud, y confirme que cada uno presenta un certificado válido que coincide con su nombre.
2. Configure el host mta-sts con HTTPS y sirva el archivo de política como text/plain con mode: testing.
3. Publique el único registro TXT _mta-sts con un id nuevo y ejecute después las comprobaciones con dig y curl indicadas arriba.
4. Publique el registro TXT _smtp._tls apuntando a un buzón dedicado o a un endpoint HTTPS, y revise su configuración global con nuestro verificador de seguridad del correo.
5. Revise los informes durante al menos un ciclo de negocio completo, incluidos los procesos de fin de mes (para la mayoría de las organizaciones, un mes). Corrija todos los fallos que le correspondan, cambie después a enforce y modifique el id.