RFC 4954: Extensión SMTP AUTH

Standards Track Email Authentication Published March 2026

ELI5: Imagina una oficina de correos donde cualquiera puede entrar y dejar correo afirmando ser alguien más. Un caos, ¿verdad? SMTP AUTH es la verificación de identidad en el mostrador. Antes de entregar tu correo, demuestras quién eres — nombre de usuario, contraseña, todo. Solo después de que el empleado verifica tu identidad puedes enviar tu mensaje. Sin AUTH, SMTP es una puerta abierta para el abuso.

Por qué existe

El SMTP original (RFC 5321) no tenía concepto de autenticación del remitente. Cualquier cliente podía conectarse a cualquier servidor y enviar correo como cualquiera. Este diseño funcionaba en el internet primitivo donde todos los participantes eran de confianza, pero se convirtió en la base del problema del spam.

RFC 4954 define la extensión AUTH para SMTP, proporcionando una forma estandarizada para que los clientes se autentiquen con un servidor de correo antes de enviar mensajes. Utiliza el marco SASL (Simple Authentication and Security Layer), permitiendo que múltiples mecanismos de autenticación se conecten sin cambiar el protocolo SMTP en sí.

Este RFC obsoletó RFC 2554 (1999), solucionando problemas de seguridad y aclarando la interacción entre AUTH y otras extensiones SMTP como STARTTLS.

Cómo funciona

La negociación AUTH

El cliente se conecta e emite EHLO.
El servidor anuncia 250-AUTH seguido de una lista de mecanismos SASL soportados.
El cliente elige un mecanismo y envía AUTH <mechanism>, opcionalmente con una respuesta inicial.
El servidor y el cliente intercambian una o más rondas de desafío/respuesta (dependiendo del mecanismo).
El servidor responde con 235 (autenticación exitosa) o 535 (autenticación fallida).

Transcripción SMTP: AUTH PLAIN

El mecanismo PLAIN envía credenciales en una única cadena codificada en Base64 que contiene la identidad de autorización, la identidad de autenticación y la contraseña:

# Conectar y descubrir capacidades S: 220 smtp.mailertogo.com ESMTP C: EHLO app.example.com S: 250-smtp.mailertogo.com S: 250-STARTTLS S: 250-AUTH PLAIN LOGIN XOAUTH2 S: 250-SIZE 26214400 S: 250 ENHANCEDSTATUSCODES # Actualizar a TLS primero (siempre antes de AUTH) C: STARTTLS S: 220 2.0.0 Ready to start TLS # ... Handshake TLS ... se requiere re-EHLO C: EHLO app.example.com S: 250-smtp.mailertogo.com S: 250-AUTH PLAIN LOGIN XOAUTH2 S: 250 ENHANCEDSTATUSCODES # Autenticarse con AUTH PLAIN # Base64 de "\0alice@example.com\0secretpassword" C: AUTH PLAIN AGFsaWNlQGV4YW1wbGUuY29tAHNlY3JldHBhc3N3b3Jk S: 235 2.7.0 Authentication successful # Ahora autorizado para enviar mensajes C: MAIL FROM:<alice@example.com> S: 250 2.1.0 OK

Transcripción SMTP: AUTH LOGIN

El mecanismo LOGIN utiliza un desafío/respuesta separado para el nombre de usuario y la contraseña:

C: AUTH LOGIN S: 334 VXNlcm5hbWU6 ← Base64 de "Username:" C: YWxpY2VAZXhhbXBsZS5jb20= ← Base64 de "alice@example.com" S: 334 UGFzc3dvcmQ6 ← Base64 de "Password:" C: c2VjcmV0cGFzc3dvcmQ= ← Base64 de "secretpassword" S: 235 2.7.0 Authentication successful

Transcripción SMTP: AUTH fallida

C: AUTH PLAIN AGJhZEBleGFtcGxlLmNvbQB3cm9uZw== S: 535 5.7.8 Authentication credentials invalid # El cliente NO DEBE intentar enviar correo después de un 535

Detalles técnicos clave

Mecanismos SASL

RFC 4954 no define directamente mecanismos de autenticación. Proporciona el marco; los mecanismos provienen del registro SASL. Los más usados en SMTP:

Mecanismo	Cómo funciona	Notas de seguridad
`PLAIN`	Cadena única Base64: `\0authzid\0password`	Simple, ampliamente soportado. Solo debe usarse sobre TLS.
`LOGIN`	Desafío/respuesta de dos pasos para nombre de usuario y contraseña	No estándar pero ubicuo. Solo debe usarse sobre TLS.
`XOAUTH2`	Token portador OAuth 2.0 en una cadena formateada	Sin transmisión de contraseña. Basado en token, usado por Gmail y Microsoft 365.
`SCRAM-SHA-256`	Desafío/respuesta salado con vinculación de canal	Contraseña nunca enviada, ni siquiera hasheada. Autenticación mutua. Mejor seguridad pero adopción limitada en SMTP.
`CRAM-MD5`	Desafío/respuesta con HMAC MD5	Obsoleto. MD5 se considera débil. Evita enviar la contraseña pero no protege contra ataques de repetición.

El formato de credencial AUTH PLAIN

El mecanismo PLAIN codifica tres campos separados por bytes nulos (\0), luego codifica en Base64 el resultado:

# Formato: [authzid] \0 authcid \0 password # authzid = identidad de autorización (usualmente vacía o igual a authcid) # authcid = identidad de autenticación (el nombre de usuario) # password = la contraseña en texto plano # Ejemplo: authzid vacía, authcid "alice@example.com", contraseña "s3cret" \0alice@example.com\0s3cret # Codificado en Base64: AGFsaWNlQGV4YW1wbGUuY29tAHMzY3JldA==

La optimización de respuesta inicial

RFC 4954 permite al cliente enviar la respuesta SASL inicial en la misma línea que el comando AUTH (como se muestra en el ejemplo PLAIN anterior). Esto ahorra un viaje redondo comparado con el enfoque antiguo de dos pasos donde el servidor primero envía un desafío vacío. Para mecanismos como PLAIN donde el cliente habla primero, esta optimización es estándar.

Interacción con STARTTLS

RFC 4954 recomienda fuertemente que los servidores no anuncien AUTH hasta después de que TLS se establezca. Esto evita que los clientes envíen accidentalmente credenciales en texto plano. El flujo típico es:

Conectar → EHLO → servidor anuncia STARTTLS pero no AUTH
STARTTLS → Handshake TLS
EHLO nuevamente → servidor ahora anuncia AUTH (STARTTLS ya no está listado)
AUTH → enviar mensajes

Códigos de respuesta

Código	Significado
`235`	Autenticación exitosa
`334`	Desafío del servidor (continuación del intercambio SASL)
`432`	Se requiere transición de contraseña (servidor requiere cambio de contraseña)
`454`	Fallo de autenticación temporal (intenta más tarde)
`500`	Comando AUTH no reconocido (servidor no soporta AUTH)
`534`	Mecanismo de autenticación demasiado débil (servidor requiere mecanismo más fuerte)
`535`	Credenciales de autenticación inválidas

AUTH e identidad MAIL FROM

Después de autenticación exitosa, el servidor asocia la conexión con la identidad autenticada. El MSA puede entonces reforzar que las direcciones MAIL FROM y el encabezado From: coincidan (o estén autorizadas para) el usuario autenticado. Esto evita que usuarios autenticados falsifiquen direcciones de remitente arbitrarias.

Errores comunes

Enviar AUTH antes de STARTTLS. Si el servidor anuncia AUTH en una conexión en texto plano (algunos servidores mal configurados lo hacen), tus credenciales aún viajan sin protección. Siempre establece TLS antes de autenticar. Con TLS implícito en puerto 465, esto es automático.
Confundir codificación Base64 con encriptación. Base64 es una codificación, no encriptación. AUTH PLAIN envía credenciales en un formato trivialmente decodificable. La protección viene de la capa TLS, no de Base64.
No manejar errores 535. Un AUTH fallido significa que el servidor rechazó tus credenciales. Reintentar las mismas credenciales en un bucle te llevará a limitación de velocidad o bloqueo de IP. Verifica las credenciales y falla adecuadamente.
Hardcodear AUTH LOGIN cuando PLAIN está disponible. LOGIN es un mecanismo no estándar con implementaciones inconsistentes. Si el servidor soporta PLAIN, préfierelo. Si soporta XOAUTH2 o SCRAM, prefiere esos.
No reintentar EHLO después de STARTTLS. La lista de capacidades cambia después de que TLS se establece. AUTH solo puede aparecer en la respuesta EHLO posterior a TLS. Saltar el segundo EHLO significa que tu cliente nunca descubre soporte AUTH.
Ignorar la optimización de respuesta inicial. Enviar AUTH PLAIN sin las credenciales en línea fuerza un viaje redondo innecesario adicional. La mayoría de servidores modernos soportan la respuesta inicial.
Usar CRAM-MD5 por "seguridad". CRAM-MD5 evita enviar la contraseña en texto plano, pero usa MD5 (roto), no protege contra ataques de repetición, y requiere que el servidor almacene la contraseña en forma recuperable. PLAIN sobre TLS es estrictamente superior.

Impacto en capacidad de entrega

Requerido para envío de mensajes. Cada servicio de correo moderno requiere SMTP AUTH para envío (RFC 6409). Sin autenticación, el servidor rechazará tus mensajes con una respuesta 530 (autenticación requerida).
Habilita vinculación de identidad de remitente. La autenticación vincula cada mensaje a una cuenta conocida. Esto permite al servicio de correo reforzar políticas de envío, aplicar firmas DKIM, y rastrear reputación por remitente autenticado.
Previene abuso de relé abierto. Al requerir autenticación antes de aceptar mensajes para entrega, los servidores evitan ser explotados como relés abiertos — lo que rápidamente resultaría en lista negra de IP y fallo de entrega para todos los usuarios en el servidor.
OAuth2 para integraciones modernas. Servicios como Gmail y Microsoft 365 están deprecando AUTH basado en contraseña en favor de XOAUTH2. Migrar a autenticación basada en token evita interrupciones de servicio cuando la autenticación básica se deshabilita.
Limitación de velocidad y prevención de abuso. Las sesiones autenticadas permiten limitación de velocidad por usuario. Si una cuenta se ve comprometida, el servicio puede acelerar o deshabilitar esa cuenta sin afectar otros remitentes en la misma infraestructura.