RFC 8689: Opción SMTP Requerir TLS

Standards Track Transport Security Published March 2026

ELI5: El cifrado de correo electrónico normal es como pedirle a un mensajero "por favor, usa el camión blindado si está disponible". Si el camión blindado está ocupado, el mensajero se encoge de hombros y usa una furgoneta normal. REQUIRETLS es un sello en el sobre que dice "camión blindado o no lo entregues en absoluto". El mensaje preferiría rebotar que viajar sin cifrar.

Por qué esto existe

El cifrado de correo de servidor a servidor (vía STARTTLS) es oportunista por defecto. Si el servidor receptor no admite TLS, o si un intermediario elimina la capacidad de STARTTLS, la mayoría de los servidores de envío recurrirán a la entrega en texto plano. El mensaje llega, pero sin cifrado.

Tecnologías como MTA-STS y DANE abordan esto a nivel de dominio — permiten que un dominio receptor declare "todo el correo dirigido a nosotros debe usar TLS." Pero esas son políticas del lado del receptor. El remitente no tenía forma de decir "este mensaje específico requiere TLS en cada salto."

RFC 8689 cubre esa brecha con dos mecanismos complementarios:

La extensión REQUIRETLS SMTP: Una bandera por mensaje en el sobre SMTP que le dice a cada servidor de retransmisión "no entregues este mensaje a menos que el siguiente salto admita TLS con certificados verificados."
El encabezado TLS-Required: Un encabezado de mensaje que señala la misma intención, utilizable cuando el remitente no tiene control directo sobre el sobre SMTP (por ejemplo, al enviar a través de un MSA).

Cómo funciona

La extensión REQUIRETLS SMTP

El remitente anuncia su intención durante la transacción SMTP agregando REQUIRETLS como parámetro al comando MAIL FROM:

# El servidor anuncia soporte de REQUIRETLS en EHLO S: 220 mx.example.com ESMTP C: EHLO sender.example.org S: 250-mx.example.com S: 250-STARTTLS S: 250-REQUIRETLS S: 250 OK # Actualizar a TLS primero C: STARTTLS S: 220 Go ahead # ... protocolo de enlace TLS con verificación de certificado ... C: EHLO sender.example.org S: 250-mx.example.com S: 250-REQUIRETLS S: 250 OK # Enviar con bandera REQUIRETLS C: MAIL FROM:<alice@example.org> REQUIRETLS S: 250 OK C: RCPT TO:<bob@example.com> S: 250 OK

Qué sucede en cada salto

Cuando un servidor de retransmisión procesa un mensaje con la bandera REQUIRETLS, debe aplicar estas reglas antes de reenviar:

TLS es obligatorio. La conexión al siguiente salto debe usar TLS. Si el siguiente servidor no admite STARTTLS, el mensaje no debe entregarse — rebota.
La verificación de certificado es requerida. El certificado TLS del siguiente salto debe ser válido y coincidir con el nombre de host del servidor (vía DANE/TLSA o Web PKI). Los certificados autofirmados o no coincidentes causan un rechazo.
La bandera REQUIRETLS se propaga. La retransmisión debe pasar el parámetro REQUIRETLS al siguiente salto si también admite la extensión. Si el siguiente salto no admite REQUIRETLS, la retransmisión aún puede entregar si puede verificar TLS vía DANE o MTA-STS.

El encabezado TLS-Required

Para los remitentes que envían a través de un MSA y no controlan directamente los parámetros SMTP, el encabezado TLS-Required proporciona la misma señal:

TLS-Required: No ; Espera — ¿"No" significa "no requerir TLS"? ; Correcto. El encabezado tiene dos valores: ; TLS-Required: No → explícitamente desactivar REQUIRETLS ; (usar TLS oportunista normal) ; La ausencia del encabezado significa comportamiento normal. ; La bandera de sobre REQUIRETLS es la señal positiva.

El encabezado TLS-Required: No está específicamente diseñado como mecanismo de exclusión. Le dice al MTA de envío: "incluso si REQUIRETLS normalmente se aplicaría a este mensaje (por ejemplo, debido a una política de dominio), no lo hagas cumplir para este mensaje en particular." Esto es útil para mensajes como reestablecimientos de contraseña o notificaciones donde la entrega es más importante que el cifrado garantizado.

Comportamiento de rechazo

Cuando REQUIRETLS impide la entrega, el servidor de envío genera un informe de no entrega (rechazo). El rechazo en sí mismo también debe enviarse a través de TLS — REQUIRETLS se aplica a mensajes DSN (Delivery Status Notification) también. Si el rechazo no se puede entregar de forma segura, se descarta silenciosamente en lugar de enviarse en texto plano (para evitar filtrar información sobre el mensaje original).

# El siguiente salto no admite TLS — REQUIRETLS impide la entrega C: EHLO relay.example.org S: 250-mx.recipient.com S: 250 OK # No hay STARTTLS anunciado — no se puede entregar con REQUIRETLS # La retransmisión genera un rechazo a alice@example.org: # 550 5.7.30 REQUIRETLS support required but not available

Detalles técnicos clave

Relación con MTA-STS y DANE

Mecanismo	Quién establece la política	Alcance	Método de verificación
MTA-STS	Dominio receptor	Todo correo al dominio	Web PKI (descarga HTTPS)
DANE	Dominio receptor	Todo correo al dominio	DNSSEC + registros TLSA
REQUIRETLS	Servidor/usuario de envío	Por mensaje	DANE o MTA-STS en cada salto

REQUIRETLS es complementario, no competitivo. MTA-STS y DANE protegen el correo de entrada del dominio receptor. REQUIRETLS protege un mensaje saliente específico. Un mensaje con REQUIRETLS se valida usando DANE o MTA-STS en cada salto — si ninguno está disponible para un salto, la entrega falla.

Requisitos de versión de TLS

REQUIRETLS requiere TLS 1.2 o posterior. Las conexiones que utilizan TLS 1.0 o 1.1 no satisfacen el requisito, consistente con RFC 8996 que depreca versiones de TLS más antiguas.

Códigos de estado mejorados

Código	Significado
`5.7.30`	Se requiere soporte de REQUIRETLS pero no está disponible en el siguiente salto
`5.7.31`	REQUIRETLS no se puede honrar (por ejemplo, el certificado del siguiente salto no es válido)

Errores comunes

Asumir que REQUIRETLS está ampliamente implementado. La adopción sigue siendo limitada. La mayoría de los MTA aún no admiten la extensión REQUIRETLS. Usarlo para todo el correo resultará en rechazos a muchos destinatarios.
Confundir REQUIRETLS con STARTTLS. STARTTLS es el mecanismo para actualizar una conexión a TLS. REQUIRETLS es una política que exige que STARTTLS tenga éxito y los certificados se validen. STARTTLS sin REQUIRETLS es oportunista; REQUIRETLS lo hace obligatorio.
Esperar cifrado de extremo a extremo. REQUIRETLS asegura TLS en cada salto, pero el mensaje se descifra y se cifra nuevamente en cada servidor de retransmisión. Es cifrado de salto a salto, no de extremo a extremo. Para cifrado verdadero de extremo a extremo, usa S/MIME o PGP.
No manejar rechazos. REQUIRETLS causará fallos de entrega legítimos cuando el servidor del destinatario no admite TLS o tiene problemas de certificado. Tu aplicación debe manejar estos rechazos y potencialmente reintentar sin REQUIRETLS o notificar al usuario.
Usar TLS-Required: Yes. No hay valor TLS-Required: Yes. El encabezado solo tiene un valor No para exclusión. La señal positiva es el parámetro SMTP REQUIRETLS, no un valor de encabezado.
Olvidar acerca de los rechazos. REQUIRETLS se aplica a los mensajes DSN también. Si el rechazo no se puede entregar a través de TLS, se descarta silenciosamente. El remitente original puede nunca saber que la entrega falló.

Impacto en la capacidad de entrega

Reduce la tasa de entrega. Habilitar REQUIRETLS para todos los mensajes causará fallos de entrega en servidores que no admiten TLS o tienen problemas de certificado. Úsalo selectivamente para mensajes donde la seguridad supera la certeza de entrega.
Protege mensajes de alto valor. Para notificaciones financieras, documentos legales, datos de salud, o cualquier mensaje sujeto a cumplimiento normativo, REQUIRETLS asegura que el mensaje nunca se transmita en texto plano.
Complementa MTA-STS. Si tu dominio publica MTA-STS y los dominios de tus destinatarios también tienen MTA-STS o DANE, REQUIRETLS agrega seguridad por mensaje además de las políticas a nivel de dominio. La combinación proporciona la seguridad de transporte más fuerte disponible en SMTP.
Los mensajes de rechazo también están protegidos. Porque REQUIRETLS se aplica a DSN, la información sensible en mensajes de rechazo (que puede incluir partes del mensaje original) también está protegida de la transmisión en texto plano.