Microsoft 365 "530 5.7.57 Client not authenticated to send mail": come risolvere

Cosa significa

La tua applicazione, la tua stampante o il tuo server di posta si è collegato a smtp.office365.com e ha provato a inviare un'email senza prima effettuare l'accesso. Quell'endpoint accetta posta solo da utenti autenticati con una casella Exchange Online, quindi ha rifiutato il messaggio al passaggio MAIL FROM. L'errore di solito è così:

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

È diverso da 535 5.7.139: con 5.7.139 l'app ha provato ad accedere ed è stata rifiutata; con 5.7.57 non ha effettuato l'accesso affatto (o l'accesso non è mai avvenuto).

Perché succede

• L'autenticazione non è attiva nell'app: la casella "Autenticazione SMTP" non è spuntata, il nome utente è vuoto o il plugin è impostato su "nessuna autenticazione".
• Non è stato possibile negoziare TLS. Microsoft richiede TLS prima di accettare un accesso. Se il dispositivo non supporta STARTTLS (firmware vecchio, solo TLS 1.0), salta l'accesso e riceve 5.7.57.
• Porta o modalità sbagliata: porta 25 senza autenticazione, oppure "SSL" sulla porta 587 invece di STARTTLS.
• Postfix o un altro server che inoltra tramite Microsoft 365 senza autenticazione SASL configurata.
• Volevi un relay senza accesso ma hai puntato il dispositivo su smtp.office365.com. L'invio non autenticato usa un host diverso (il tuo endpoint MX), vedi sotto.

Come verificare

1. Guarda il log SMTP dell'app. Se vedi MAIL FROM subito dopo EHLO o STARTTLS senza alcuna riga AUTH, l'app non ha mai effettuato l'accesso.
2. Verifica che TLS funzioni dalla stessa macchina:

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

   Dopo il certificato, digita EHLO test. Dovresti vedere una riga che inizia con 250-AUTH. Se l'handshake TLS fallisce, il problema è il supporto TLS del dispositivo.
3. Prova l'intera catena con swaks e un accesso reale (--tls --auth LOGIN). Se swaks funziona ma il dispositivo no, è colpa della configurazione del dispositivo.
4. Trova il tuo endpoint MX con dig +short MX yourdomain.com o con lo scanner di dominio. Ha un aspetto come yourdomain-com.mail.protection.outlook.com.

Come risolvere

Microsoft offre tre modi per far inviare applicazioni e dispositivi. Scegline uno e configuralo completamente.

Opzione 1: SMTP AUTH (client submission)

È la soluzione migliore quando l'app può effettuare l'accesso e deve inviare a chiunque, interno o esterno.

• Server smtp.office365.com, porta 587, crittografia STARTTLS.
• Nome utente e password (o OAuth) di una casella con licenza; l'indirizzo From deve essere quella casella o un indirizzo per cui ha il permesso di inviare come.
• SMTP AUTH deve essere consentito per quella casella; se poi l'accesso fallisce, consulta la guida 5.7.139 indicata sopra (tratta anche il calendario del ritiro dell'autenticazione di base).

Per Postfix che inoltra tramite Microsoft 365, le righe abituali di main.cf sono:

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 che contiene [smtp.office365.com]:587 app@yourdomain.com:password, poi postmap /etc/postfix/sasl_passwd e systemctl reload postfix. Postfix non riscrive nulla da solo: l'indirizzo del mittente deve corrispondere alla casella, altrimenti ricevi SendAsDenied.

Opzione 2: direct send (senza accesso, solo destinatari interni)

Il dispositivo invia al tuo endpoint MX (yourdomain-com.mail.protection.outlook.com) sulla porta 25 senza effettuare l'accesso. Consegna solo alle caselle della tua organizzazione, e il tuo record SPF dovrebbe includere l'IP pubblico del dispositivo. Al momento in cui scriviamo, Microsoft permette anche agli amministratori di rifiutare del tutto il direct send (Set-OrganizationConfig -RejectDirectSendEnabled $true), quindi verifica che non sia attivo se ti affidi a questo metodo.

Opzione 3: SMTP relay con un connettore (senza accesso, qualsiasi destinatario)

Crea un connettore in ingresso nell'interfaccia di amministrazione di Exchange (Mail flow > Connectors, da "Your organization's email server" a Microsoft 365) che riconosca il tuo IP pubblico fisso o un certificato TLS. Il dispositivo invia quindi al tuo endpoint MX sulla porta 25 e può raggiungere destinatari esterni. L'indirizzo From deve usare uno dei tuoi accepted domain, altrimenti rischi blocchi 5.7.750 dominio non registrato.

Verifica che sia risolto

• Invia un test dal dispositivo all'indirizzo unico nella home page di Delivmail (con le opzioni 1 e 3; l'opzione 2 non può raggiungere indirizzi esterni). Il report mostra i risultati SPF, DKIM e DMARC per il percorso scelto.
• Con il direct send, prova invece con una casella interna e guardane le intestazioni.
• Invia di nuovo il messaggio fallito e verifica che il log del dispositivo mostri 235 Authentication successful (opzione 1) o una risposta 250 dopo DATA.