Llegar a DMARC p=reject es la meta que la mayoría de las guías plantean como “tener el correo seguro”. Y sí — cerrar el spoofing del From: es un paso importante. Pero hay una superficie que DMARC no cubre: el transporte del mensaje mientras viaja entre servidores.
DMARC protege quién dice que manda el correo. MTA-STS protege cómo viaja ese correo hasta llegar a tu buzón. Son capas distintas del mismo problema.
La pila completa de seguridad del correo
Antes de entrar al detalle, un mapa rápido de lo que cubre cada control:
| Control | Qué protege | Sin él |
|---|---|---|
| SPF | Qué servidores pueden enviar a nombre de tu dominio | Cualquier servidor puede mandar como @tu-dominio.cl |
| DKIM | Integridad y autenticidad del mensaje (firma criptográfica) | El mensaje puede modificarse en tránsito sin detección |
| DMARC | Alineación entre el From: visible y SPF/DKIM; política para fallos |
Spoofing del From: visible pasa sin acción definida |
| MTA-STS | TLS obligatorio en la entrega SMTP hacia tus servidores | El transporte puede degradarse a texto plano en un ataque MITM |
| TLS-RPT | Visibilidad sobre fallos TLS en tránsito hacia tus servidores | Los fallos (incluyendo ataques activos) son invisibles |
| DNSSEC | Integridad de los registros DNS del dominio | Envenenamiento de caché puede redirigir al servidor equivocado |
El post anterior sobre DMARC cubre las primeras tres columnas en detalle. Acá nos enfocamos en MTA-STS y TLS-RPT — los dos controles que aparecen como hallazgo en la mayoría de los scans del FreeScan y que casi ninguna organización tiene configurados.
El problema: STARTTLS no es obligatorio
SMTP existe hace décadas, mucho antes de que TLS fuera obligatorio en cualquier cosa. Para agregar cifrado sin romper los servidores viejos, se inventó STARTTLS: una extensión que le dice al servidor receptor “¿soportas TLS? Si sí, actualicemos la conexión”.
El problema de fondo: STARTTLS es oportunista, no obligatorio. El servidor que envía el correo pregunta, pero si el receptor dice “no lo soporto” — o si alguien en el medio intercepta la negociación y responde “no” en nombre del receptor — la entrega se hace igual, en texto plano.
Ese ataque se llama STARTTLS downgrade. No requiere romper criptografía: sólo interceptar el banner de la negociación y responder que TLS no está disponible. El servidor emisor, cumpliendo con el protocolo, entrega en claro.
Desde una red controlada (un ISP comprometido, un operador que hace inspección de tráfico, un router corporativo con MITM activo), este ataque es trivial y completamente silencioso para ambas partes — el que envía y el que recibe.
MTA-STS: hacer TLS obligatorio en la entrega hacia tu dominio
MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) es el mecanismo que convierte TLS de oportunista a obligatorio para los servidores que entregan correo hacia ti.
El mecanismo funciona así:
- Tu dominio publica un registro DNS que señala que tiene una política MTA-STS.
- Esa política vive en un archivo accesible vía HTTPS (no DNS), lo que la ancla en TLS: si el DNS del dominio está envenenado, el servidor emisor falla porque no puede verificar la política por HTTPS.
- Cuando un servidor externo va a entregarte correo, consulta esa política antes de conectarse.
- Si la política dice
enforcey la conexión TLS no puede establecerse correctamente, el servidor emisor rechaza la entrega en lugar de bajar a texto plano.
Componente 1: el registro DNS
Un TXT record en _mta-sts.<tu-dominio>:
_mta-sts.organizacion-ejemplo.cl. IN TXT "v=STSv1; id=20260515T120000"
El campo id= es un identificador de versión que el servidor emisor usa para saber si su política en caché sigue siendo vigente. Cámbialo cada vez que actualices el archivo de política — un timestamp en formato YYYYMMDDTHHmmss funciona bien. Si el id no cambió, el servidor usa su caché; si cambió, re-descarga el archivo.
Componente 2: el archivo de política
El archivo vive en https://mta-sts.<tu-dominio>/.well-known/mta-sts.txt — sí, un subdominio mta-sts con un certificado TLS válido. Ese HTTPS es la parte que ancla el mecanismo: un atacante que envenene el DNS no puede redirigir la descarga del archivo si no tiene un cert válido para mta-sts.organizacion-ejemplo.cl.
Contenido del archivo:
version: STSv1
mode: enforce
mx: mail.organizacion-ejemplo.cl
mx: *.organizacion-ejemplo.cl
max_age: 604800
Parámetros:
version: STSv1— obligatorio, primer campo.mode:— el campo más importante. Tres valores:testing— los fallos se reportan (si hay TLS-RPT) pero no bloquean la entrega. Equivale alp=nonede DMARC: visibilidad sin protección.enforce— un fallo TLS bloquea la entrega. La entrega en texto plano queda prohibida.none— desactiva la política. Útil para retirarla gradualmente.mx:— patrón de los MX records autorizados. El servidor emisor verifica que el cert TLS del servidor receptor cubra alguno de estos patrones. Uno o más valores, uno por línea.max_age:— segundos que el servidor emisor puede cachear la política. 604800 = 7 días. Máximo recomendado: 31557600 (1 año) en producción estable.
El subdominio mta-sts
El servidor que sirve el archivo HTTPS necesita:
- Un A/AAAA record para
mta-sts.organizacion-ejemplo.cl. - Un certificado TLS válido (no self-signed) que cubra ese hostname.
La mayoría de organizaciones con Cloudflare lo configuran como un Worker o una Page Function; las que tienen control del servidor simplemente sirven el archivo estático desde el mismo servidor web con un virtual host dedicado.
Un archivo de política en testing primero, enforce después de 1-2 semanas sin incidentes reportados en los logs de TLS-RPT.
TLS-RPT: visibilidad sobre fallos en tránsito
TLS-RPT (RFC 8460) es el mecanismo de reporte que acompaña a MTA-STS. Cuando un servidor externo intenta entregarte correo y falla el TLS (por política MTA-STS, por cert inválido, por cualquier fallo de handshake), te manda un reporte JSON diario con el detalle de qué pasó.
Sin TLS-RPT, un ataque STARTTLS downgrade activo es invisible. Con TLS-RPT, los intentos de downgrade aparecen en los reportes como starttls-not-supported o validation-failure — señal de que alguien en el camino está interfiriendo.
El registro DNS
Un TXT record en _smtp._tls.<tu-dominio>:
_smtp._tls.organizacion-ejemplo.cl. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"
El campo rua= apunta a donde quieres recibir los reportes. Puede ser un email, un endpoint HTTPS, o ambos separados por coma:
v=TLSRPTv1; rua=mailto:[email protected],https://report.organizacion-ejemplo.cl/tls-rpt
En la práctica, para la mayoría de organizaciones, un buzón dedicado alcanza. Los reportes llegan como JSON comprimido en gzip — menos legibles que un XML de DMARC, pero con información más accionable: cada falla incluye el tipo de error (certificate-expired, validation-failure, starttls-not-supported), la cantidad de mensajes afectados, y el MX servidor donde ocurrió.
El orden de configuración recomendado
-
Configura TLS-RPT primero — sólo el registro DNS, sin archivo de política. Así empiezas a recibir reportes sobre el estado actual del TLS hacia tus MX antes de tocar nada.
-
Despliega MTA-STS en modo
testing— registro DNS + subdominio + archivo conmode: testing. Esto hace que los servidores que soportan MTA-STS te reporten fallos, pero sigan entregando aunque falle TLS. Equivale ap=noneen DMARC. -
Revisa TLS-RPT durante 1-2 semanas — ¿Hay fallos? ¿Son de cert mal configurado en uno de tus MX? ¿Son fallos transient de handshake? ¿O son
starttls-not-supportedque podrían indicar interferencia activa? -
Cambia a
mode: enforce— cuando los reportes muestren que el TLS funciona limpio y sin fallos inesperados. Actualiza elid=en el registro DNS para forzar la re-descarga del archivo.
DNSSEC: la capa que ancla el DNS
MTA-STS ya mitiga el riesgo de DNS poisoning para la política, porque el archivo de política lo descarga por HTTPS con cert verificado. Pero la cadena todavía empieza con un lookup DNS: si el registro _mta-sts en sí está envenenado para apuntar a otro servidor o simplemente devuelve NXDOMAIN, los servidores emisores no encuentran la política y pueden caer al comportamiento por defecto (STARTTLS oportunista).
DNSSEC firma criptográficamente los registros DNS del dominio, haciendo que cualquier respuesta manipulada sea detectable. No es el control más urgente — MTA-STS en enforce ya da protección sólida — pero cierra la cadena completa.
Para dominios .cl, DNSSEC está soportado por NIC.cl. La configuración varía según el registrar y el DNS autoritativo que uses.
Verificación rápida con dig
# Registro MTA-STS
dig +short TXT _mta-sts.organizacion-ejemplo.cl
# Esperado: "v=STSv1; id=..."
# Política en modo enforce
curl -s https://mta-sts.organizacion-ejemplo.cl/.well-known/mta-sts.txt
# Esperado: version: STSv1 / mode: enforce / mx: ...
# TLS-RPT
dig +short TXT _smtp._tls.organizacion-ejemplo.cl
# Esperado: "v=TLSRPTv1; rua=mailto:..."
# DNSSEC (buscar flags AD en la respuesta)
dig +dnssec TXT organizacion-ejemplo.cl | grep flags
# Esperado: flags: qr rd ra ad
El flag ad (Authenticated Data) en la respuesta de dig confirma que el resolver validó DNSSEC para ese nombre.
Cómo lo detecta el FreeScan
El Asentic FreeScan verifica los tres controles sobre cualquier dominio que escanees:
EMAIL-MTA-STS-MISSING— Baja. El dominio no tiene registro_mta-stso el archivo de política no es accesible. Sin MTA-STS el transporte SMTP hacia tus MX puede degradarse a texto plano sin que nadie lo note.EMAIL-TLS-RPT-MISSING— Info. No hay registro_smtp._tls. Los fallos de TLS en tránsito son invisibles; ni tú ni el servidor emisor tienen forma de saber que el cifrado falló.EMAIL-DNSSEC-MISSING— Baja. El dominio no publica registros DNSSEC. La cadena de confianza del DNS queda sin firma criptográfica; posible vector de envenenamiento de caché.
En los scans actuales, EMAIL-MTA-STS-MISSING y EMAIL-TLS-RPT-MISSING aparecen en más del 90% de los dominios analizados — incluyendo dominios con DMARC en p=reject correcto, lo que confirma que la implementación de email security se suele quedar incompleta en esa última capa.
Cierre
DMARC cierra el spoofing del From:. MTA-STS cierra el downgrade del transporte. TLS-RPT te da la visibilidad para saber cuándo algo falla en el camino.
Los tres controles juntos arman la pila completa. Sin MTA-STS, un atacante en el camino puede leer (o modificar) el correo que va hacia tu dominio, en silencio, aunque tengas DMARC en p=reject y todos los certificados en orden. Con MTA-STS en enforce y TLS-RPT activo, ese ataque produce un fallo visible y deja de ser silencioso.
La configuración completa toma menos de una hora: dos registros DNS, un subdominio con un archivo de texto, y un buzón donde recibir los reportes. El ratio esfuerzo/seguridad es de los mejores en toda la pila.