DMARC valida que el email recibido sea auténtico. No garantiza que viajó cifrado en tránsito. STARTTLS opportunistic es el default del 60% de los servidores SMTP B2B en producción: si el cifrado falla, degrada a plaintext sin alertar. Un MITM con visibilidad en la red puede inducir downgrade y leer el contenido. MTA-STS cierra ese vector publicando policy en HTTPS que obliga TLS verificado o rebota. DANE lo refuerza con DNSSEC. TLS-RPT da visibilidad de fallos. Doce dominios con MTA-STS enforce live operando.
STARTTLS es el comando que un servidor SMTP usa para negociar cifrado TLS durante una sesión iniciada en plaintext. El problema operacional es el comportamiento default: si la negociación falla por cualquier razón (certificado expirado, MITM stripping del comando, cipher mismatch), la mayoría de los MTAs degradan a plaintext sin alertar al operador. Esto es el opportunistic encryption: cifrado cuando se puede, plaintext cuando no. Para DMARC compliance no importa, el email igual se autentica. Para confidencialidad de contenido importa mucho.
El escenario de ataque es real y documentado: un atacante con position en la red entre los dos MTAs (ISP comprometido, BGP hijacking, MITM en datacenter) intercepta la conexión SMTP, strippea el comando STARTTLS de la respuesta del receiver, y fuerza la sesión a continuar en plaintext. El sender no tiene forma de saber que la negociación TLS fue saboteada porque no hay policy que le diga que TLS era obligatorio.
Vista comparada de qué pasa con y sin MTA-STS publicada cuando un atacante en la red intermedia intenta stripear el cifrado.
El receiver acepta STARTTLS pero también plaintext. El atacante con MITM strippea el comando y el sender continúa en clear.
El sender consulta la policy MTA-STS antes de enviar. Si no negocia TLS válido, no entrega.
El cierre del vector no es teórico. Mailgun publicó en 2019 análisis de tráfico mostrando que cerca del 1.2% de sesiones SMTP outbound habrían sido cifradas si el peer hubiera respetado STARTTLS y terminaron en plaintext. Google reportó en su Transparency Report que el porcentaje de email recibido cifrado pasó de 33% en 2014 a 92% en 2024, pero queda un 8% en clear, mayoritariamente con dominios que no implementan MTA-STS. Para una operación enviando 5M mensajes/mes ese 8% son 400.000 mensajes mensuales potencialmente vulnerables.
No son competencia entre sí. MTA-STS publica policy de cifrado obligatorio, DANE vincula el certificado al DNS firmado con DNSSEC, TLS-RPT entrega reporting de fallos. Operacionalmente los tres se implementan en orden ascendente de complejidad.
RFC 8461 (2018) · IETF
Publica policy en HTTPS sobre well-known URI con modo testing o enforce. Los senders MTA-STS-aware consultan la policy antes de entregar.
RFC 7672 + 6698 (2015) · IETF
Publica hash del certificado TLS del MX directamente en DNS firmado con DNSSEC. Defense-in-depth sobre MTA-STS, criptográficamente más fuerte.
RFC 8460 (2018) · IETF
Endpoint receptor de reports JSON agregados con fallos TLS detectados por senders externos. Visibilidad operacional sobre MTA-STS y DANE.
Plan operacional típico: fase 1 MTA-STS + TLS-RPT (cierra el vector principal con menor overhead y entrega visibilidad), fase 2 DANE-TLSA opcional cuando compliance lo exige o cuando la criticidad del email transaccional justifica defense-in-depth. Para 95% de operaciones B2B Latinoamérica MTA-STS estándar es suficiente. Para banca, healthcare con HIPAA, gobierno con clasificación, vale la pena el overhead DNSSEC.
Activar MTA-STS en mode enforce sin pasar por testing es una receta para romper email legítimo. El mode testing existe específicamente para observar 30 días el comportamiento de senders externos contra tu policy, recolectar reports TLS-RPT, identificar dominios con TLS roto que envían legítimamente, y resolver esos casos antes de bloquear.
Policy publicada, senders MTA-STS-aware la consultan, pero los fallos TLS no rebotan el mensaje. Solo se reportan vía TLS-RPT.
Policy en enforce. Senders MTA-STS-aware rebotan los mensajes que no pueden negociar TLS válido contra tu MX.
El mode enforce no es punto de no retorno: si después del go-live aparece un partner crítico con TLS roto que envía a tu dominio (común en healthcare con sistemas legacy, en banca con peers regionales), se puede degradar temporalmente a testing mientras se coordina la fix con el partner. La degradación se propaga al cache de senders en horas según el TTL del DNS y el max_age de la policy. EMP gestiona este escenario dentro del soporte managed sin costo adicional.
Estos son los registros DNS y el archivo HTTPS que publica EMP al cerrar el deployment. La separación TXT con versión del archivo HTTPS con la policy completa permite rotación atómica sin downtime: nuevo archivo, bump del id en TXT, propagación rápida.
; --- MTA-STS · TXT pointer con version id --- _mta-sts.tudominio.com. 3600 IN TXT "v=STSv1; id=20260512143000Z" ; --- TLS-RPT · endpoint para reports agregados --- _smtp._tls.tudominio.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:[email protected], https://tlsrpt-collect.emailmarketingpanama.com/v1/<client_id>" ; --- DANE-TLSA · solo si DNSSEC habilitado --- _25._tcp.mx1.tudominio.com. 3600 IN TLSA 3 1 1 e3b0c44298fc1c149afbf4c8996fb924 27ae41e4649b934ca495991b7852b855
# Archivo servido en: # https://mta-sts.tudominio.com/.well-known/mta-sts.txt version: STSv1 mode: enforce mx: mx1.tudominio.com mx: mx2.tudominio.com mx: *.fallback.tudominio.com max_age: 604800 # 7 días cache para senders
Notas operacionales sobre los registros. El id en el TXT debe ser único por cada cambio de policy: formato típico timestamp ISO 8601 sin separadores. Cuando se modifica la policy, se sube el archivo nuevo a HTTPS, se bump del id en TXT, y los senders refrescan el cache al detectar el cambio en el TXT. El max_age de 604.800 segundos (7 días) es el balance recomendado: lo suficientemente alto para que un outage HTTPS corto no rompa entregas, lo suficientemente bajo para que cambios de policy se propaguen razonablemente rápido.
Dashboard que parsea los reports JSON agregados de los senders MTA-STS-aware y los presenta por dominio sender, mailbox provider, tipo de fallo, evolución temporal. Es la herramienta operacional principal post-go-live.
tudominio.com · 12 reports recibidos · 4 senders únicos
| Sender domain | MX | Sessions | Fail type | Status |
|---|---|---|---|---|
| google.com | mx1.tudominio.com | 1,524 | — | OK |
| outlook.com | mx1.tudominio.com | 892 | — | OK |
| yahoo.com | mx2.tudominio.com | 431 | — | OK |
| partner-legacy.com | mx1.tudominio.com | 3 | certificate-not-trusted | Investigate |
El dashboard EMP entrega view filtrable por: rango temporal (24h, 7d, 30d, custom), sender domain (búsqueda), tipo de fallo (certificate-expired, certificate-not-trusted, sts-policy-fetch-error, etc.), MX hostname involucrado. La integración SIEM (Splunk, Datadog, Elastic) está disponible en el tier Enterprise para correlacionar fallos TLS con otros eventos de security operations.
Validación que DMARC está en enforcement, que los MX tienen certificados TLS válidos, que el HTTPS hosting está disponible.
Policy publicada en HTTPS bajo well-known URI, TXT records publicados, TLS-RPT endpoint activo recibiendo reports.
TLS-RPT dashboard activo. Identificación de senders legítimos con TLS roto. Coordinación con partners afectados antes de enforce.
Bump del archivo HTTPS de testing a enforce. Bump del id en TXT record. Monitoreo continuo, alertas configuradas.
El precio incluye setup técnico completo, hosting HTTPS de la policy bajo CDN propia, TLS-RPT collection endpoint, dashboard y soporte post-deployment. Renovación anual de certificados o DNSSEC keys se gestiona dentro del soporte managed.
Mode testing · 30 días observación · TLS-RPT setup.
Mode enforce + monitoreo continuo · 90 días support.
DNSSEC chain + DANE-TLSA + MTA-STS · compliance estricto.
Multi-domain hasta 10 dominios · SIEM integration.
"¿Por qué necesito MTA-STS si ya tengo DMARC en enforcement?"
DMARC valida que el email recibido sea auténtico (autenticación del sender), pero no garantiza que el email haya viajado cifrado en tránsito SMTP. STARTTLS opportunistic es el default del 60% de los servidores SMTP en producción: si el cifrado falla, el servidor degrada a plaintext sin alertar. MTA-STS cierra ese vector publicando policy via HTTPS que obliga al sender a usar TLS verificado o rebotar el mensaje. Sin MTA-STS, un atacante con MITM en la red entre los dos MTAs puede inducir downgrade a plaintext y leer el contenido. Operativamente: DMARC protege contra spoofing, MTA-STS protege contra interception en tránsito. Son complementarios, no excluyentes.
"¿Qué pasa si activo enforce y un destinatario no tiene TLS configurado correctamente?"
El mensaje no se entrega. Ese es exactamente el comportamiento esperado del modo enforce: prefiere fallar a leak en plaintext. Esta es la razón por la que el deployment se hace en dos fases. Fase 1 (mode testing, 30 días mínimo): la policy se publica con mode=testing, los senders que la consultan emiten TLS-RPT reports de los fallos pero entregan el mensaje igual. Fase 2 (mode enforce): después de 30 días de TLS-RPT limpio sin fallos, se promueve a mode=enforce. Esto evita que el cliente descubra problemas en producción. Si después de enforce aparece un dominio destinatario problemático conocido (legacy systems, healthcare partners con TLS roto), se puede crear una excepción específica en la policy o degradar temporal a testing durante la coordinación con el partner.
"DANE requiere DNSSEC. ¿Vale la pena la complejidad?"
Depende del riesgo. DNSSEC firma criptográficamente la zona DNS para que los resolvers validen que las respuestas no fueron tampered en tránsito. Sin DNSSEC, MTA-STS depende de HTTPS para servir la policy, que tiene su propio modelo de seguridad robusto pero distinto. Con DANE el certificado TLS está vinculado directamente al DNS firmado, eliminando dependencia de CAs externas. Operacionalmente: DNSSEC agrega complejidad de rotación de claves (KSK rollover anual, ZSK más frecuente) y un punto adicional de fallo si la firma expira. Recomendación EMP: si tu compliance regulatorio (PCI-DSS Level 1, HIPAA con BAA, GDPR Art. 32 con DPA exigente) menciona DNSSEC o DANE explícitamente, vale la pena. Si no, MTA-STS estándar cubre 95% del riesgo con 30% del overhead operacional.
"¿MTA-STS protege todo el email saliente o solo el que llega a mi dominio?"
MTA-STS publicado por mi dominio protege únicamente el email entrante hacia mi dominio. Es decir, los senders externos que envían a tu-dominio.com consultan tu policy y respetan el enforce. No protege el email saliente desde tu dominio: para eso necesitás que los dominios destino (gmail.com, outlook.com, dominio-de-tu-cliente.com) tengan MTA-STS publicada y vos respetes la policy de ellos. Gmail, Outlook, Yahoo, Apple, Fastmail tienen MTA-STS publicada en modo enforce desde 2019-2021. Para que tu MTA outbound respete las policies remotas necesita ser MTA-STS-aware. PowerMTA y KumoMTA lo soportan nativamente; Postfix y Exim requieren plugins externos.
"¿Qué pasa si el HTTPS donde está hosteada mi policy se cae?"
Los senders MTA cachean la policy por la duración declarada en el campo max_age (típicamente 1-2 semanas). Si el HTTPS cae durante un período corto los senders usan el cache. Si el HTTPS cae durante un período mayor que el cache, los senders verán failure to fetch policy y emitirán TLS-RPT con sts-policy-fetch-error pero continuarán entregando con la política previa cacheada hasta que expire. Recomendación: alta disponibilidad del HTTPS (CDN multi-región, healthchecks) y monitoreo del endpoint con alerta proactiva. El TLS-RPT dashboard EMP detecta fetch errors y notifica antes de que el cache expire.
"¿El TLS-RPT puede revelar información sensible de mi operación?"
Los reports contienen información operacional, no contenido de mensajes. Específicamente: identidad del sender domain (ej. google.com, outlook.com), número de sessions exitosas y fallidas, tipo de fallo TLS, MX hostname tuyo involucrado, contadores agregados. No contienen: direcciones email específicas de remitentes o destinatarios, contenido o subject de mensajes, message-IDs específicos, IPs individuales de senders. Privacidad: los reports son agregados sobre ventanas de 24 horas, no por mensaje. Aun así EMP firma DPA específico para el procesamiento de TLS-RPT data porque técnicamente contiene metadata operacional del email del cliente.
Dos approaches diferentes al mismo problema.
.well-known/mta-sts.txt) y referencia el dominio policy via TXT record con versión. Funciona sobre cualquier DNS, no requiere DNSSEC, deployment rápido.En la práctica: 95% de los dominios B2B implementan solo MTA-STS por simplicidad. Operaciones reguladas con compliance estricto (banca, healthcare, government) implementan ambos en defense-in-depth.
Plazo varía por tier:
Los plazos incluyen testing TLS contra el top 50 de dominios destino habituales de tu base receptora antes de cualquier enforce.
Reports JSON agregados de 24 horas enviados por los senders MTA al endpoint que publicás en el registro DNS _smtp._tls. Contienen:
EMP entrega dashboard que parsea estos reports y los presenta por dominio destino, mailbox provider, tipo de fallo, evolución temporal. Volumen típico: 10-50 reports diarios para una operación B2B media.
Lista de senders que respetan MTA-STS publicada (envían a tu dominio respetando enforce):
Cobertura efectiva: alrededor del 80% del email B2C global y 60% del email B2B (Microsoft 365 cubre la mayoría del B2B corporate). Senders que no respetan MTA-STS: mayoritariamente operadores legacy regionales, on-premise Exchange viejo, sistemas custom de banca/government que no han actualizado.
Para que tu MTA outbound respete las policies MTA-STS publicadas por dominios destino:
smtp_tls_policy_maps + plugin externo (Mailfence postfix-mta-sts-resolver)Para Postfix y Exim el plugin externo es required pero estable. EMP incluye configuración del plugin en el scope del servicio si el cliente usa Postfix/Exim en producción.
No, si se hace correctamente. La rotación DNSSEC tiene dos tipos de keys:
Durante la transición ambas keys firman la zona simultáneamente. Los resolvers validan con cualquiera de las dos. La rotación de DKIM keys puede coordinarse con la rotación ZSK para minimizar overhead operacional. EMP gestiona ambas rotaciones automáticamente en el tier DANE + DNSSEC.
Sí, con caveats. Los forwarders (redirección automática a otra dirección) funcionan correctamente con MTA-STS siempre que el dominio de destino de la redirección también tenga TLS válido. Si el forwarder reenvía a un dominio con TLS roto, la policy MTA-STS del dominio destino final (no el del forwarder intermedio) determina si el mensaje se entrega.
Caso problemático: forwarders que routen via Microsoft Exchange Online Protection (EOP) o filtros externos pueden tener TLS internal misconfigured. Esos casos aparecen en TLS-RPT como certificate-not-trusted del MX intermedio y se resuelven coordinando con el operador del forwarder. EMP gestiona estos casos en el soporte post-deployment.
Marcos regulatorios que mencionan explícitamente cifrado en tránsito SMTP:
Para auditorías formales EMP entrega documentación del setup con certificate chain, policy versioning, TLS-RPT historical reports y diagramas técnicos.
Validamos el estado actual de tu STARTTLS, certificados TLS de los MX, soporte MTA-STS publicada en el dominio, presencia de TLS-RPT. Si ya tenés MTA-STS en testing te ayudamos a interpretar los reports y planear el go-live a enforce. Si todavía no implementaste, evaluamos pre-requisitos (DMARC enforcement, HTTPS hosting, DNSSEC capability del registrar) y cotizamos el tier que encaja.