Microsoft 365 „530 5.7.57 Client not authenticated to send mail“: so behebst du es

Was das bedeutet

Deine Anwendung, dein Drucker oder Mailserver hat sich mit smtp.office365.com verbunden und versucht, eine E-Mail zu senden, ohne sich vorher anzumelden. Dieser Endpunkt nimmt nur E-Mails von authentifizierten Benutzern mit einem Exchange-Online-Postfach an, daher hat er die Nachricht beim Schritt MAIL FROM abgelehnt. Der Fehler sieht meist so aus:

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

Das ist etwas anderes als 535 5.7.139: Bei 5.7.139 hat die App versucht, sich anzumelden, und wurde abgewiesen; bei 5.7.57 hat sie sich gar nicht angemeldet (oder die Anmeldung kam nie zustande).

Warum das passiert

• Die Authentifizierung ist in der App nicht aktiviert: Das Häkchen bei „SMTP-Authentifizierung“ fehlt, der Benutzername ist leer oder das Plugin steht auf „keine Authentifizierung“.
• TLS konnte nicht ausgehandelt werden. Microsoft verlangt TLS, bevor es eine Anmeldung annimmt. Kann das Gerät kein STARTTLS (alte Firmware, nur TLS 1.0), überspringt es die Anmeldung und bekommt dann 5.7.57.
• Falscher Port oder Modus: Port 25 ohne Authentifizierung oder „SSL“ auf Port 587 statt STARTTLS.
• Postfix oder ein anderer Server leitet über Microsoft 365 weiter, ohne dass SASL-Authentifizierung eingerichtet ist.
• Du wolltest ein Relay ohne Anmeldung, hast das Gerät aber auf smtp.office365.com gerichtet. Unauthentifizierter Versand nutzt einen anderen Host (deinen MX-Endpunkt), siehe unten.

So prüfst du es

1. Sieh dir das SMTP-Log der App an. Siehst du MAIL FROM direkt nach EHLO oder STARTTLS ohne eine AUTH-Zeile, hat sich die App nie angemeldet.
2. Prüfe, ob TLS von derselben Maschine aus funktioniert:

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

   Tippe nach dem Zertifikat EHLO test. Du solltest eine Zeile sehen, die mit 250-AUTH beginnt. Schlägt der TLS-Handshake fehl, liegt das Problem bei der TLS-Unterstützung des Geräts.
3. Teste die ganze Kette mit swaks und einer echten Anmeldung (--tls --auth LOGIN). Funktioniert swaks, das Gerät aber nicht, ist die Konfiguration des Geräts schuld.
4. Finde deinen MX-Endpunkt mit dig +short MX yourdomain.com oder mit dem Domain-Scanner. Er sieht aus wie yourdomain-com.mail.protection.outlook.com.

So behebst du es

Microsoft bietet drei Wege, wie Anwendungen und Geräte senden können. Wähle einen und richte ihn vollständig ein.

Option 1: SMTP AUTH (Client Submission)

Am besten, wenn die App sich anmelden kann und an beliebige Empfänger senden muss, intern oder extern.

• Server smtp.office365.com, Port 587, Verschlüsselung STARTTLS.
• Benutzername und Passwort (oder OAuth) eines lizenzierten Postfachs; die From-Adresse muss dieses Postfach sein oder eines, als das es senden darf.
• SMTP AUTH muss für dieses Postfach erlaubt sein; schlägt die Anmeldung dann fehl, sieh dir den oben verlinkten Leitfaden zu 5.7.139 an (er behandelt auch den Zeitplan für das Ende der Standardauthentifizierung).

Leitet Postfix über Microsoft 365 weiter, lauten die üblichen Zeilen in main.cf:

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

mit /etc/postfix/sasl_passwd, das [smtp.office365.com]:587 app@yourdomain.com:password enthält, danach postmap /etc/postfix/sasl_passwd und systemctl reload postfix. Postfix schreibt von sich aus nichts um: Die Absenderadresse muss zum Postfach passen, sonst bekommst du SendAsDenied.

Option 2: Direct Send (ohne Anmeldung, nur interne Empfänger)

Das Gerät sendet ohne Anmeldung auf Port 25 an deinen MX-Endpunkt (yourdomain-com.mail.protection.outlook.com). Das stellt nur an Postfächer in deiner eigenen Organisation zu, und dein SPF-Eintrag sollte die öffentliche IP des Geräts enthalten. Zum Zeitpunkt des Schreibens können Admins Direct Send bei Microsoft auch komplett ablehnen lassen (Set-OrganizationConfig -RejectDirectSendEnabled $true); prüfe also, dass das nicht aktiviert ist, wenn du darauf angewiesen bist.

Option 3: SMTP-Relay mit einem Connector (ohne Anmeldung, beliebige Empfänger)

Lege im Exchange Admin Center einen eingehenden Connector an (Mail flow > Connectors, von „Your organization's email server“ zu Microsoft 365), der deine feste öffentliche IP oder ein TLS-Zertifikat erkennt. Das Gerät sendet dann auf Port 25 an deinen MX-Endpunkt und kann externe Empfänger erreichen. Die From-Adresse muss eine deiner akzeptierten Domains verwenden, sonst riskierst du Sperren mit 5.7.750 unregistered domain.

Prüfe, ob es behoben ist

• Sende vom Gerät einen Test an die einmalige Adresse auf der Startseite von Delivmail (mit Option 1 und 3; Option 2 kann keine externen Adressen erreichen). Der Bericht zeigt die Ergebnisse von SPF, DKIM und DMARC für den gewählten Weg.
• Teste bei Direct Send stattdessen mit einem internen Postfach und sieh dir dessen Header an.
• Sende die fehlgeschlagene Nachricht erneut und bestätige, dass das Log des Geräts 235 Authentication successful (Option 1) oder eine 250-Antwort nach DATA zeigt.