Microsoft 365 "530 5.7.57 Client not authenticated to send mail": cómo solucionarlo

Qué significa

Tu aplicación, impresora o servidor de correo se ha conectado a smtp.office365.com y ha intentado enviar un email sin iniciar sesión antes. Ese endpoint solo acepta correo de usuarios autenticados que tengan un buzón de Exchange Online, así que ha rechazado el mensaje en el paso MAIL FROM. El error suele tener este aspecto:

530 5.7.57 Client not authenticated to send mail.
530 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM

Es distinto de 535 5.7.139: con el 5.7.139 la aplicación intentó iniciar sesión y fue rechazada; con el 5.7.57 ni siquiera inició sesión (o el inicio de sesión nunca llegó a producirse).

Por qué ocurre

• La autenticación no está activada en la aplicación: la casilla "autenticación SMTP" está desmarcada, el usuario está vacío o el plugin está configurado como "sin autenticación".
• No se ha podido negociar TLS. Microsoft exige TLS antes de aceptar un inicio de sesión. Si el dispositivo no admite STARTTLS (firmware antiguo, solo TLS 1.0), se salta el inicio de sesión y recibe el 5.7.57.
• Puerto o modo equivocados: puerto 25 sin autenticación, o "SSL" en el puerto 587 en lugar de STARTTLS.
• Postfix u otro servidor que retransmite a través de Microsoft 365 sin la autenticación SASL configurada.
• Querías un relay sin inicio de sesión pero apuntaste el dispositivo a smtp.office365.com. El envío sin autenticación usa otro host (tu endpoint MX), consulta más abajo.

Cómo comprobarlo

1. Mira el log SMTP de la aplicación. Si ves MAIL FROM justo después de EHLO o STARTTLS sin ninguna línea AUTH, la aplicación nunca inició sesión.
2. Comprueba que TLS funciona desde la misma máquina:

   openssl s_client -starttls smtp -connect smtp.office365.com:587 -crlf

   Después del certificado, escribe EHLO test. Deberías ver una línea que empieza por 250-AUTH. Si falla la negociación TLS, el problema es el soporte TLS del dispositivo.
3. Prueba toda la cadena con swaks y un inicio de sesión real (--tls --auth LOGIN). Si swaks funciona pero el dispositivo no, la culpa es de la configuración del dispositivo.
4. Encuentra tu endpoint MX con dig +short MX yourdomain.com o con el escáner de dominios. Tiene la forma yourdomain-com.mail.protection.outlook.com.

Cómo solucionarlo

Microsoft ofrece tres formas de enviar para aplicaciones y dispositivos. Elige una y configúrala por completo.

Opción 1: SMTP AUTH (client submission)

La mejor cuando la aplicación puede iniciar sesión y tiene que enviar a cualquiera, interno o externo.

• Servidor smtp.office365.com, puerto 587, cifrado STARTTLS.
• Usuario y contraseña (u OAuth) de un buzón con licencia; la dirección From debe ser ese buzón o una dirección en cuyo nombre tenga permiso para enviar.
• SMTP AUTH debe estar permitido para ese buzón; si después el inicio de sesión falla, consulta la guía del 5.7.139 enlazada más arriba (también trata el calendario de retirada de la autenticación básica).

Para Postfix retransmitiendo a través de Microsoft 365, las líneas habituales de main.cf son:

relayhost = [smtp.office365.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

con /etc/postfix/sasl_passwd conteniendo [smtp.office365.com]:587 app@yourdomain.com:password, y después postmap /etc/postfix/sasl_passwd y systemctl reload postfix. Postfix no reescribe nada por sí solo: la dirección del remitente debe coincidir con el buzón, o recibirás SendAsDenied.

Opción 2: direct send (sin inicio de sesión, solo destinatarios internos)

El dispositivo envía a tu endpoint MX (yourdomain-com.mail.protection.outlook.com) por el puerto 25 sin iniciar sesión. Solo entrega a buzones de tu propia organización, y tu registro SPF debería incluir la IP pública del dispositivo. En el momento de escribir esto, Microsoft también permite a los administradores rechazar por completo el direct send (Set-OrganizationConfig -RejectDirectSendEnabled $true), así que comprueba que no está activado si dependes de él.

Opción 3: relay SMTP con un conector (sin inicio de sesión, cualquier destinatario)

Crea un conector de entrada en el Exchange admin center (Mail flow > Connectors, de "Your organization's email server" a Microsoft 365) que reconozca tu IP pública fija o un certificado TLS. El dispositivo envía entonces a tu endpoint MX por el puerto 25 y puede llegar a destinatarios externos. La dirección From debe usar uno de tus dominios aceptados; si no, te arriesgas a bloqueos 5.7.750 de dominio no registrado.

Comprueba que está solucionado

• Envía una prueba desde el dispositivo a la dirección única de la página de inicio de Delivmail (con las opciones 1 y 3; la opción 2 no puede llegar a direcciones externas). El informe muestra los resultados de SPF, DKIM y DMARC para la vía que hayas elegido.
• Con direct send, haz la prueba con un buzón interno y mira sus cabeceras.
• Reenvía el mensaje que falló y confirma que el log del dispositivo muestra 235 Authentication successful (opción 1) o una respuesta 250 después de DATA.