Microsoft 365 « 530 5.7.57 Client not authenticated to send mail » : la solution

Ce que ça veut dire

Votre application, votre imprimante ou votre serveur mail s'est connecté à smtp.office365.com et a tenté d'envoyer un email sans s'authentifier d'abord. Ce serveur n'accepte que les emails d'utilisateurs authentifiés disposant d'une boîte Exchange Online : il a donc refusé le message à l'étape MAIL FROM. L'erreur ressemble généralement à ceci :

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

C'est différent de 535 5.7.139 : avec 5.7.139, l'application a tenté de se connecter et a été refusée ; avec 5.7.57, elle ne s'est pas connectée du tout (ou la connexion n'a jamais eu lieu).

Pourquoi cela arrive

• L'authentification n'est pas activée dans l'application : la case « Authentification SMTP » est décochée, le nom d'utilisateur est vide, ou le plugin est réglé sur « aucune authentification ».
• TLS n'a pas pu être négocié. Microsoft exige TLS avant d'accepter une connexion. Si l'appareil ne sait pas faire STARTTLS (ancien firmware, TLS 1.0 seulement), il saute l'authentification et reçoit ensuite 5.7.57.
• Mauvais port ou mauvais mode : port 25 sans authentification, ou « SSL » sur le port 587 au lieu de STARTTLS.
• Postfix ou un autre serveur relaie via Microsoft 365 sans authentification SASL configurée.
• Vous vouliez un relais sans identifiant mais avez fait pointer l'appareil vers smtp.office365.com. L'envoi sans authentification utilise un autre hôte (votre point de terminaison MX), voir plus bas.

Comment vérifier

1. Regardez le log SMTP de l'application. Si vous voyez MAIL FROM juste après EHLO ou STARTTLS, sans ligne AUTH, l'application ne s'est jamais authentifiée.
2. Vérifiez que TLS fonctionne depuis la même machine :

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

   Après le certificat, tapez EHLO test. Vous devez voir une ligne commençant par 250-AUTH. Si la négociation TLS échoue, c'est la prise en charge de TLS par l'appareil qui pose problème.
3. Testez toute la chaîne avec swaks et un vrai identifiant (--tls --auth LOGIN). Si swaks fonctionne mais pas l'appareil, c'est la configuration de l'appareil qui est en cause.
4. Trouvez votre point de terminaison MX avec dig +short MX yourdomain.com ou sur le scanner de domaine. Il ressemble à yourdomain-com.mail.protection.outlook.com.

Comment corriger

Microsoft propose trois façons d'envoyer pour les applications et les appareils. Choisissez-en une et configurez-la entièrement.

Option 1 : SMTP AUTH (client submission)

Idéal quand l'application peut s'authentifier et doit écrire à n'importe qui, en interne comme en externe.

• Serveur smtp.office365.com, port 587, chiffrement STARTTLS.
• Nom d'utilisateur et mot de passe (ou OAuth) d'une boîte mail disposant d'une licence ; l'adresse From doit être cette boîte ou une adresse au nom de laquelle elle a le droit d'envoyer.
• SMTP AUTH doit être autorisé pour cette boîte ; si la connexion échoue ensuite, voir le guide 5.7.139 cité plus haut (il couvre aussi le calendrier de fin de l'authentification de base).

Pour Postfix en relais via Microsoft 365, les lignes habituelles de main.cf sont :

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

avec un fichier /etc/postfix/sasl_passwd contenant [smtp.office365.com]:587 app@yourdomain.com:password, puis postmap /etc/postfix/sasl_passwd et systemctl reload postfix. Postfix ne réécrit rien tout seul : l'adresse de l'expéditeur doit correspondre à la boîte mail, sinon vous obtenez SendAsDenied.

Option 2 : direct send (sans identifiant, destinataires internes uniquement)

L'appareil envoie vers votre point de terminaison MX (yourdomain-com.mail.protection.outlook.com) sur le port 25 sans s'authentifier. Cela ne livre qu'aux boîtes de votre propre organisation, et votre enregistrement SPF doit inclure l'IP publique de l'appareil. Au moment où nous écrivons ces lignes, Microsoft permet aussi aux administrateurs de refuser entièrement le direct send (Set-OrganizationConfig -RejectDirectSendEnabled $true) : vérifiez que ce n'est pas activé si vous en dépendez.

Option 3 : relais SMTP avec un connecteur (sans identifiant, tous destinataires)

Créez un connecteur entrant dans le centre d'administration Exchange (Mail flow > Connectors, de « Your organization's email server » vers Microsoft 365) qui reconnaît votre IP publique fixe ou un certificat TLS. L'appareil envoie alors vers votre point de terminaison MX sur le port 25 et peut atteindre des destinataires externes. L'adresse From doit utiliser l'un de vos accepted domains, sinon vous risquez des blocages 5.7.750 domaine non enregistré.

Vérifier que c'est corrigé

• Envoyez un test depuis l'appareil à l'adresse unique de la page d'accueil de Delivmail (avec les options 1 et 3 ; l'option 2 ne peut pas atteindre d'adresses externes). Le rapport affiche les résultats SPF, DKIM et DMARC pour le chemin choisi.
• Avec le direct send, testez plutôt avec une boîte interne et regardez ses en-têtes.
• Renvoyez le message qui avait échoué et vérifiez que le log de l'appareil affiche 235 Authentication successful (option 1) ou une réponse 250 après DATA.