Beim Einrichten von E-Mail-Konten scheitert die Konfiguration selten nur an Benutzername oder Passwort. Häufiger passt die Kombination aus Protokoll, Port, Verschlüsselungsmodus und Authentifizierung nicht zusammen. IMAP und POP3 rufen Nachrichten ab, SMTP versendet sie. Je nach Anbieter erwartet der Server sofortiges TLS, ein nachträgliches Upgrade per STARTTLS oder eine Anmeldung erst nach erfolgreicher Transportverschlüsselung. Wählen Sie im Client „automatisch“, verdeckt das oft die Ursache: Der Port ist erreichbar, aber der TLS-Dialog beginnt falsch, der Server bietet AUTH erst nach STARTTLS an oder eine Richtlinie blockiert die Anmeldung.
Für die Praxis zählt deshalb nicht nur, welche Serveradresse Ihr Anbieter nennt. Entscheidend ist, ob der Client auf dem gewählten Port sofort verschlüsselt starten muss, ob er zuerst einen Klartextdialog eröffnet und dann per STARTTLS hochschaltet oder ob der Dienst moderne Authentifizierung statt klassischem Passwort erwartet. Besonders bei Microsoft 365, Unternehmensservern, Scannern, NAS-Systemen und älteren Mailprogrammen liegen Fehler oft nicht im einzelnen Feld, sondern in der Reihenfolge der Aushandlung.
Prüfen Sie E-Mail-Einstellungen daher immer als Kette: zuerst den richtigen Servernamen, dann Port und TLS-Modus, danach Authentifizierung, Absenderrecht und Zustellbarkeit. Ein funktionierender Posteingang beweist nicht, dass der Postausgang korrekt eingerichtet ist. Ebenso sagt ein erreichbarer SMTP-Port noch nichts darüber aus, ob der Server die Anmeldung akzeptiert oder die versendete Nachricht später SPF, DKIM und DMARC besteht.
E-Mail-Ports richtig konfigurieren: IMAP, POP3 und SMTP im Überblick
Die Portnummer sagt nicht nur „verschlüsselt“ oder „unverschlüsselt“. Entscheidend ist, wie der Client die Verbindung startet. Bei implizitem TLS beginnt der TLS-Handshake sofort nach dem TCP-Verbindungsaufbau. Bei STARTTLS spricht der Server zunächst im jeweiligen Klartextprotokoll, kündigt seine Fähigkeiten an und wechselt erst nach einem Upgrade-Kommando in den verschlüsselten Kanal. Genau deshalb führt „SSL/TLS“ auf einem STARTTLS-Port oft zu Fehlern wie wrong version number, obwohl Servername und Zugangsdaten stimmen.
| Protokoll / Rolle | Port | Im Client wählen | Bewertung | So beginnt die Verbindung | Anmeldung | Beste Verwendung | Typischer Fehler bei falscher Wahl | Was Sie konkret korrigieren |
|---|---|---|---|---|---|---|---|---|
| IMAP | 993 | SSL/TLS | 🟢 beste Wahl | Der Client startet sofort einen TLS-Handshake; erst danach beginnt der IMAP-Dialog. | Benutzername plus Passwort, App-Passwort oder OAuth – je nach Anbieter. | Standard für modernen Postfachabruf mit Ordnern, Gelesen-Status und Synchronisation auf mehreren Geräten. | Handshake-Fehler, wenn der Client auf diesem Port STARTTLS statt SSL/TLS erzwingt. | Port 993 mit „SSL/TLS“ kombinieren und den vom Anbieter genannten IMAP-Hostnamen verwenden. |
| IMAP | 143 | STARTTLS | 🟡 zweite Wahl | Der Server spricht zunächst IMAP im Klartext und wechselt erst nach STARTTLS in TLS. | In der Praxis meist erst nach erfolgreichem TLS-Upgrade erlaubt. | Geeignet, wenn der Anbieter Port 143 ausdrücklich mit STARTTLS nennt oder ein Legacy-System diesen Pfad benötigt. | wrong version number, wenn im Client „SSL/TLS“ statt STARTTLS gewählt wird. | Auf STARTTLS umstellen oder direkt den moderneren Standardpfad 993 mit SSL/TLS verwenden. |
| POP3 | 995 | SSL/TLS | 🟢 beste Wahl | Der TLS-Handshake startet sofort; danach beginnt der POP3-Abruf. | Benutzername plus Passwort, App-Passwort oder OAuth – je nach Anbieter. | Für klassischen sicheren Abruf, wenn keine vollständige Ordnersynchronisation benötigt wird. | Sofortiger Verbindungsabbruch, wenn der Client STARTTLS auf diesem Port versucht. | Port 995 mit „SSL/TLS“ setzen; für mehrere Geräte besser IMAP statt POP3 prüfen. |
| POP3 | 110 | STARTTLS | 🟠 Sonderfall | Der Server beginnt mit POP3 im Klartext; das TLS-Upgrade erfolgt technisch über STLS. | Viele Server erlauben die Anmeldung nur nach dem TLS-Upgrade. | Nur sinnvoll, wenn ein Anbieter oder Altgerät diesen Port ausdrücklich verlangt. | „Server unterstützt sichere Verbindung nicht“ oder Login-Abbruch bei falschem TLS-Modus. | STARTTLS/STLS aktivieren oder auf 995 mit SSL/TLS wechseln. |
| SMTP Submission | 587 | STARTTLS | 🟢 beste Wahl | Der Server begrüßt den Client, der Client sendet EHLO, danach folgt STARTTLS und anschließend erneut EHLO. | SMTP AUTH nach aktivem TLS; je nach Anbieter mit Passwort, App-Passwort oder OAuth. | Standard für normalen Mailversand aus Mailclients, Apps, NAS-Systemen, Scannern und Anwendungen. | 530 Must issue a STARTTLS command first, wenn der Client vor TLS authentifizieren will. | Port 587 mit STARTTLS kombinieren und erst danach SMTP AUTH prüfen. |
| SMTP Submission mit implizitem TLS | 465 | SSL/TLS | 🟡 zweite Wahl | Der Client startet sofort TLS; der SMTP-Dialog beginnt erst im verschlüsselten Kanal. | SMTP AUTH innerhalb der TLS-Verbindung. | Gute Alternative, wenn der Anbieter Port 465 ausdrücklich als submissions/SMTPS dokumentiert. | Timeout oder unexpected EOF, wenn der Client auf diesem Port STARTTLS erzwingen will. | Nur „SSL/TLS“ verwenden; bei Microsoft 365 nicht für SMTP-Clientübermittlung einplanen. |
| SMTP Transport / Relay | 25 | nicht als normaler Mailclient-Port wählen | 🟠 Sonderfall | Der Server spricht SMTP; STARTTLS ist je nach Gegenstelle opportunistisch oder per Policy erzwungen. | Keine normale Client-Anmeldung garantiert; Relay oft über IP, Zertifikat, Connector oder MTA-Regeln. | MTA-Transport, interne Relays, Microsoft-365-Connector, Direct Send oder Server-zu-Server-Kommunikation. | 550 Relaying denied, Providerblockade oder fehlende Client-Auth. | Für normale Mailprogramme Port 587 oder beim Anbieter 465 nutzen; Port 25 nur für klar definierte Relay- oder Serverpfade. |
Warum STARTTLS nach dem TLS-Handshake erneut EHLO braucht
Bei SMTP auf Port 587 startet die Verbindung nicht sofort verschlüsselt. Der Server begrüßt den Client, der Client sendet EHLO, der Server nennt seine Fähigkeiten, erst danach folgt STARTTLS. Nach erfolgreichem TLS-Handshake beginnt die SMTP-Sitzung logisch neu. Ein sauberer Client sendet deshalb erneut EHLO, weil der Server erst im geschützten Kanal Mechanismen wie AUTH PLAIN oder AUTH LOGIN anbieten kann. Einfache Scanner, ältere NAS-Systeme und schlecht gepflegte Anwendungen scheitern genau hier: Der Port ist offen, TLS startet vielleicht sogar, aber die zweite Aushandlung, die geforderte TLS-Version oder die passende Authentifizierung fehlt.
- Implizites TLS: Verwenden Sie „SSL/TLS“ für IMAP
993, POP3995und SMTP465. Der TLS-Handshake beginnt sofort. - STARTTLS: Verwenden Sie STARTTLS für IMAP
143, POP3110und SMTP587. Der Server spricht zuerst das jeweilige Klartextprotokoll. - Unverschlüsselt: Nutzen Sie das nur noch in kontrollierten Sonderfällen. Für Mailabruf und Clientversand ist unverschlüsselte Anmeldung nicht zeitgemäß.
- Port 25: Planen Sie ihn nicht als normalen Client-Ausweichport. Er gehört in den Server-, Relay- oder Connector-Kontext.
Authentifizierung, Zertifikat und Domainprüfung nicht vermischen
Ein erfolgreicher Porttest beweist nur, dass TCP erreichbar ist. Er beweist nicht, dass der TLS-Handshake korrekt läuft, dass der Server die gewählte Authentifizierung akzeptiert oder dass die spätere Nachricht SPF, DKIM und DMARC besteht. Arbeiten Sie deshalb in Ebenen: Verbindung, TLS, Protokolldialog, Authentifizierung, Absenderrecht, Relay-Policy und Zustellbarkeit.
SMTP AUTH und SASL: Anmeldung erst nach dem richtigen Transport bewerten
SMTP AUTH wird nicht blind ausprobiert, sondern über die vom Server angebotenen Fähigkeiten ausgehandelt. Nach EHLO sehen Sie, ob der Server STARTTLS, AUTH, Größenlimits oder Erweiterungen wie SMTPUTF8 nennt. Viele Server erlauben AUTH PLAIN und AUTH LOGIN nur nach aktivem TLS. Meldet der Client dann „Passwort falsch“, kann die eigentliche Ursache eine falsche Reihenfolge, ein deaktiviertes SMTP AUTH oder eine blockierte Basic-Auth-Richtlinie sein.
| Ebene / Mechanismus | Wofür zuständig? | Voraussetzung | Löst nicht | Typisches Fehlerbild | Prüfschritt |
|---|---|---|---|---|---|
AUTH PLAIN / AUTH LOGIN | Benutzername/Passwort gegenüber dem Submission-Server | TLS aktiv, gültiges Konto, SMTP AUTH erlaubt | SPF, DKIM, DMARC oder Send-As-Rechte | 530 Must issue a STARTTLS command first, 535 Authentication unsuccessful | Nach STARTTLS erneut EHLO prüfen und SMTP-AUTH-Status kontrollieren. |
AUTH XOAUTH2 | Tokenbasierte Anmeldung statt klassischem Passwort | Client, App-Registrierung, Scopes und Tenant-Policy passen | Portwahl, TLS-Modus oder Absenderautorisierung | Token abgelaufen, ungültiger Scope, 535 5.7.3 | OAuth-Fähigkeit des Clients und Freigaben des Tenants prüfen. |
| Anonymer SMTP-Zugriff | MTA-Transport, Direct Send oder internes Relay | definierte Quell-IP, Connector, Zertifikat oder internes Netz | normalen Mailclientversand über ein Postfach | 550 Relaying denied, 530 Authentication required | Relay-Regel, Connector und erlaubte Absenderdomänen prüfen. |
| Send-As / From-Address-Validation | Recht, mit einer sichtbaren Absenderadresse zu senden | Authentifiziertes Konto darf diese Adresse verwenden | Login, TLS und DNS-Authentizität | 5.7.60 Client doesn't have permissions to send as this sender | Login-Konto, MAIL FROM, sichtbares From: und Berechtigungen abgleichen. |
| CRAM-MD5 / DIGEST-MD5 | ältere Challenge-Response-Mechanismen | Legacy-Server bietet den Mechanismus noch an | moderne Microsoft-365- oder OAuth-Szenarien | 504 Unrecognized authentication type | Client auf unterstützte Verfahren umstellen oder Relay/API nutzen. |
Zertifikate, Hostname und SNI: Der Name im Client muss passen
Bei TLS prüft der Client nicht nur, ob verschlüsselt wird. Er bewertet auch, ob das Zertifikat zum verwendeten Servernamen passt, ob die Zertifikatskette vollständig ist und ob der Server bei Multi-Tenant-Plattformen per SNI das richtige Zertifikat auswählt. Verwenden Sie deshalb den dokumentierten FQDN des Anbieters und keine IP-Adresse. In modernen Zertifikaten zählt vor allem der Eintrag im SAN-Feld; der CN ist nur noch in Altumgebungen als Rückfall relevant.
- FQDN statt IP: Nutzen Sie den Servernamen, den der Anbieter dokumentiert, etwa
imap.example.tldodersmtp.example.tld. - SNI beachten: Ohne Server Name Indication kann ein Gateway ein Default-Zertifikat ausliefern, das nicht zur Domain passt.
- TLS-Inspection einordnen: Ersetzt eine Firewall Zertifikate, muss der Client der internen CA vertrauen. Sonst ist der Zertifikatsfehler korrekt.
- Nicht mit Passwortfehlern verwechseln: Ein Hostname-Mismatch lässt sich nicht durch neue Zugangsdaten lösen.
SPF, DKIM und DMARC: SMTP-Login ist keine Zustellgarantie
SMTP AUTH beweist gegenüber dem sendenden Server, dass ein Client ein Konto oder Token verwenden darf. SPF, DKIM und DMARC prüfen dagegen auf Empfängerseite, ob die verwendete Domain plausibel autorisiert ist. SPF bewertet die sendende IP im Verhältnis zum Envelope-Absender aus MAIL FROM beziehungsweise zur SMTP-Identität. DKIM bewertet eine kryptografische Signatur und die Domain im d=-Tag. DMARC verlangt, dass die sichtbare From:-Domain zu SPF oder DKIM ausgerichtet ist. Deshalb kann eine Nachricht trotz erfolgreichem SMTP-Login abgelehnt oder als Spam eingestuft werden.
| Prüfung | Bewertet | Häufige Fehlannahme | Praxisfolge |
|---|---|---|---|
| SMTP AUTH | Anmeldung beim sendenden Server | „Wenn der Login klappt, ist die Domain sauber authentifiziert.“ | Login und Zustellbarkeit getrennt prüfen. |
| SPF | sendende IP gegen Envelope-Absender / SMTP-Identität | „SPF prüft direkt die sichtbare From-Adresse.“ | MAIL FROM und sendende Infrastruktur müssen zur Domain passen. |
| DKIM | Signatur und Domain im d=-Tag | „DKIM bleibt bei jeder Weiterleitung und Bearbeitung stabil.“ | Änderungen an signierten Headern oder Inhalten können DKIM brechen. |
| DMARC | Alignment zur sichtbaren From:-Domain | „Ein SPF-Pass reicht immer.“ | SPF oder DKIM müssen zur sichtbaren Absenderdomain ausgerichtet sein. |
| From-Address-Validation | Absenderrecht beim Submission-Server | „Der Client darf jede From-Adresse setzen.“ | Provider blockieren, ersetzen oder verwerfen unzulässige Absenderadressen. |
SMTP-Wege richtig wählen: Client, Scanner, Relay und Microsoft 365
SMTP ist kein einzelner Einrichtungsfall. Ein Mailclient reicht eine Nachricht authentifiziert ein. Ein Mailserver transportiert Nachrichten weiter. Ein Scanner oder ERP-System braucht oft nur einen kontrollierten Versandweg. Vermischen Sie diese Rollen, wirken die Fehlermeldungen widersprüchlich: Port und TLS stimmen, trotzdem lehnt der Server das Relay ab oder verweigert die Absenderadresse.
| Szenario | Passender SMTP-Weg | Port / Ziel | Authentifizierung | TLS-Anforderung | Typisches Risiko | Bessere Wahl, wenn … |
|---|---|---|---|---|---|---|
| normaler Mailclient | Client Submission | 587 + STARTTLS oder 465 + SSL/TLS beim Anbieter | Postfach, App-Passwort oder OAuth | TLS muss vor Authentifizierung aktiv sein | Client nutzt Port 25 oder falschen TLS-Modus. | Sie über ein persönliches oder Funktionspostfach senden. |
| Scanner / Multifunktionsgerät | Submission oder internes Relay | meist 587; beim Relay häufig 25 | Postfach, Relay-IP oder Connector | abhängig vom Ziel; bei Microsoft 365 TLS 1.2/1.3 | alte Firmware unterstützt nur schwache TLS-Versionen oder kein OAuth. | ein internes Relay moderne TLS-/Auth-Anforderungen übernimmt. |
| Webanwendung / CRM / ERP | Submission, API oder Relay | anbieterabhängig | OAuth, SMTP AUTH, API-Key oder Connector | dienstabhängig | Absenderdomain passt nicht zu SPF/DKIM/DMARC oder Send-As-Rechten. | viele transaktionale Mails über einen spezialisierten Versanddienst laufen sollen. |
| internes SMTP-Relay | kontrolliertes Relay im eigenen Netz | meist 25 intern | Quell-IP, Zertifikat, ACL oder internes Netz | intern nach Risiko; extern möglichst erzwungen | Open-Relay-Risiko bei zu breiten Freigaben. | viele Geräte keine moderne Authentifizierung unterstützen. |
| Microsoft 365 Client SMTP Submission | authentifizierter Versand über Cloud-Postfach | smtp.office365.com:587 empfohlen; Port 25 dokumentiert, aber störanfälliger | SMTP AUTH; OAuth ist der sauberere Zielpfad, wenn der Client ihn unterstützt | TLS 1.2 oder TLS 1.3, STARTTLS aktiv | Security Defaults, Authentifizierungsrichtlinien oder Postfachvorgaben blockieren SMTP AUTH. | ein einzelnes lizenziertes Cloud-Postfach kontrolliert senden soll und die Sicherheitsrichtlinie SMTP AUTH zulässt. |
| Microsoft 365 SMTP Relay | Connector mit IP- oder Zertifikatsvertrauen | MX-Endpunkt, Port 25 | Connector statt Postfachlogin | TLS 1.2/1.3 empfohlen; je nach Connector erzwungen | falsche öffentliche IP, nicht passende Domain im Zertifikat oder fehlender Connector. | Geräte ohne OAuth- oder Postfachlogin zuverlässig senden sollen. |
| Microsoft 365 Direct Send | nicht authentifizierter Versand an eigene Organisation | MX-Endpunkt, Port 25 | keine SMTP AUTH | optional beziehungsweise empfangspfadabhängig | kein Versand an externe Empfänger über Microsoft 365. | nur interne Empfänger benachrichtigt werden sollen. |
| Server-zu-Server-Transport | MTA-Transport | 25 | keine Client-Anmeldung | STARTTLS oft opportunistisch; strikte Policies separat über MTA-STS, DANE oder Connector | Verwechslung mit Clientversand führt zu Relay-Ablehnung. | ein echter Mailserver Nachrichten zustellt. |
Microsoft 365: IMAP, POP und SMTP sind heute Sonderpfade
Microsoft 365 sollten Sie nicht wie einen klassischen Mailanbieter behandeln, bei dem IMAP, POP3 und SMTP dauerhaft mit Servername, Port und Passwort funktionieren. Für Outlook und moderne Microsoft-365-Clients ist ein Exchange-Profil mit moderner Authentifizierung der vorgesehene Weg. IMAP, POP3 und SMTP bleiben vor allem für Spezialfälle relevant: ältere Mailclients, Multifunktionsgeräte, Scanner, NAS-Systeme, Fachanwendungen oder selbst entwickelte Integrationen. Genau dort greifen die Sicherheitsgrenzen. Security Defaults blockieren Legacy-Authentifizierung und deaktivieren SMTP AUTH in Exchange Online. Basic Auth ist für POP und IMAP nicht mehr der normale Anmeldeweg; SMTP AUTH mit Benutzername und Passwort ist ein auslaufender Ausnahmefall. Nutzen Sie diese Protokolle deshalb nur, wenn der Authentifizierungsweg bewusst geplant ist: OAuth/XOAUTH2 bei unterstützten Clients, SMTP Relay über Connector, Direct Send nur für interne Empfänger oder ein spezialisierter Versanddienst.
| Zugriffspfad | Endpunkt / Port | Authentifizierung | Voraussetzung | Geeignet für | Typischer Fehler | Praxisfolge |
|---|---|---|---|---|---|---|
| Outlook mit Microsoft 365 | Exchange-Profil über Autodiscover / moderne Microsoft-365-Dienste | Modern Authentication | Mandant, Konto und Client unterstützen moderne Authentifizierung | normale Benutzerpostfächer in Outlook | manuelles POP/IMAP-Profil scheitert trotz richtiger Serverdaten | Outlook nicht künstlich auf IMAP/SMTP reduzieren; Exchange-Profil verwenden. |
| IMAP / POP in Exchange Online | IMAP 993, POP3 995 | OAuth/XOAUTH2 bei unterstützten Clients; Basic Auth nicht als Normalpfad | Protokoll am Postfach erlaubt, Client unterstützt das Auth-Verfahren | Spezialclients und Anwendungen, die bewusst IMAP oder POP benötigen | Login schlägt trotz korrekter Daten fehl | Protokollstatus, OAuth-Fähigkeit und Richtlinien prüfen, bevor Sie Ports ändern. |
| SMTP AUTH mit OAuth | smtp.office365.com:587 bevorzugt, STARTTLS | OAuth/XOAUTH2 mit passendem Token | Client, App-Registrierung, Berechtigungen, Tenant-Policy und Postfachstatus passen | Anwendungen und Clients mit echter OAuth-Unterstützung | Token-, Scope- oder Policyfehler | Das ist eher ein bewusst konfiguriertes App-Szenario als ein einfaches Drucker-Häkchen. |
| SMTP AUTH mit Benutzername/Passwort | smtp.office365.com:587 bevorzugt; 25 dokumentiert | Basic Auth über TLS, nur wenn noch zulässig | Security Defaults aus, SMTP AUTH tenant- und postfachseitig erlaubt, Auth-Policy blockiert es nicht | Legacy-Geräte und Übergangslösungen | 535 5.7.3 Authentication unsuccessful | Nicht als Zukunftspfad planen; Relay, Connector, OAuth oder Versanddienst prüfen. |
| Port-465-Geräte bei Microsoft 365 | 465 | geräteseitig oft SSL/TLS fest verdrahtet | für Microsoft-365-SMTP-Clientübermittlung nicht passend | nur bei anderen Anbietern, die 465 ausdrücklich unterstützen | Verbindungs- oder TLS-Abbruch | Gerät auf 587 + STARTTLS umstellen oder Relay/Alternative nutzen. |
| SMTP Relay über Connector | MX-Endpunkt, Port 25 | statische öffentliche IP oder Zertifikat | Inbound Connector, akzeptierte Domain, passende Absenderadresse | Geräte und Systeme ohne OAuth- oder Postfachlogin | 550 Relaying denied | Connector, IP, Zertifikat und Absenderdomain gemeinsam prüfen. |
| Direct Send | MX-Endpunkt, Port 25 | keine SMTP AUTH | Empfänger liegen in der eigenen Organisation | einfache interne Benachrichtigungen | externe Zustellung funktioniert nicht wie erwartet | Nicht als Ersatz für authentifizierten externen Versand verwenden. |
| Send-As mit abweichendem Absender | Submission oder Relay | Konto plus Absenderrecht | authentifiziertes Konto darf die sichtbare From-Adresse verwenden | Funktionspostfächer, No-Reply-Adressen, Scanner-Absender | 5.7.60 Client doesn't have permissions to send as this sender | Login-Konto, MAIL FROM und sichtbares From: abgleichen. |
| Exchange on-premises | Receive Connector / Client Access, je nach Topologie | Basic, NTLM, Kerberos, Zertifikat, IP-ACL oder Relay-Regel | Zertifikat, Namespace, Load-Balancer, Auth-Mechanismus und Connector passen zusammen | eigene Exchange- oder Hybridumgebungen | Hostname-Mismatch, Auth-Loop, Relay-Verweigerung | Autodiscover-Erfolg beweist nicht, dass IMAP/POP/SMTP korrekt gebunden sind. |
OAuth 2.0 vs. Basic Auth: Token ersetzen nicht TLS und Portlogik
Basic Auth bedeutet bei IMAP, POP3 und SMTP meist Benutzername und Passwort innerhalb eines TLS-geschützten Kanals. OAuth ersetzt diesen Nachweis durch ein Zugriffstoken, nicht aber den Transportweg. Auch ein OAuth-fähiger Client muss den richtigen Port, den richtigen TLS-Modus und das passende Protokoll sprechen. Bei IMAP, POP3 und SMTP erfolgt OAuth technisch über SASL-Mechanismen wie XOAUTH2; ein Web-Login-Fenster allein macht einen alten SMTP-Client nicht automatisch OAuth-fähig.
- Prüfen Sie Legacy-Geräte realistisch: Unterstützt ein Scanner nur
AUTH LOGINund alte TLS-Versionen, ist nicht der Port das Hauptproblem, sondern die gesamte Auth- und TLS-Fähigkeit. - Verwechseln Sie OAuth nicht mit Transportverschlüsselung: Auch mit Token bleibt
587ein STARTTLS-Pfad und465ein Pfad mit implizitem TLS. - Planen Sie Alternativen für Anwendungen: Wenn SMTP AUTH nicht mehr zur Sicherheitsrichtlinie passt, sind ein internes Relay, ein Connector, eine API oder ein spezialisierter Versanddienst oft sauberer als eine unsichere Ausnahme.
Fehlermeldungen gezielt deuten: Port, TLS, Auth, Policy oder Absenderrecht?
Viele Clients reduzieren sehr unterschiedliche Ursachen auf „Anmeldung fehlgeschlagen“. Das ist für die Diagnose zu grob. Gehen Sie von unten nach oben: DNS, TCP-Port, TLS-Handshake, Protokolldialog, Authentifizierung, Absenderrecht, Relay-Policy und erst danach Zustellbarkeit beim Empfänger. So vermeiden Sie Passwortwechsel, obwohl eigentlich ein Zertifikat, eine Richtlinie oder ein falscher SMTP-Weg das Problem auslöst.
| Fehlertext | Ebene | Wahrscheinliche Ursache | Sofort prüfen | Korrektur |
|---|---|---|---|---|
SSL handshake failed / TLS negotiation failed | TLS | falscher TLS-Modus, veraltete TLS-Version, blockierte Chiffre, TLS-Inspection | Port und Modus: 587 STARTTLS, 465 SSL/TLS | TLS-Modus korrigieren, TLS 1.2/1.3 sicherstellen, Proxy/Firewall prüfen. |
wrong version number | TLS-Start | Client startet TLS direkt auf einem Port, der zuerst Klartext spricht | Wurde auf 143, 110 oder 587 „SSL/TLS“ gewählt? | Auf STARTTLS umstellen oder den passenden impliziten TLS-Port verwenden. |
unexpected EOF | TLS / Verbindungsabbruch | Server beendet wegen falschem Dialog oder blockierter TLS-Aushandlung | gezielter Test mit openssl s_client | Port/TLS-Modus korrigieren und Zertifikatspfad prüfen. |
Server does not support secure connections | Capabilities / TLS | Client erwartet falschen TLS-Start oder Server bietet kein Upgrade an | Serverfähigkeiten nach EHLO, IMAP-Capability oder POP3-STLS prüfen | Korrektes Verfahren wählen oder Server-/Anbieterangaben prüfen. |
530 Must issue a STARTTLS command first | Reihenfolge | Client versucht Authentifizierung vor TLS | Ist STARTTLS wirklich aktiviert? | STARTTLS aktivieren; bei SMTP nach STARTTLS erneut EHLO zulassen. |
535 5.7.3 Authentication unsuccessful | Authentifizierung / Policy | SMTP AUTH deaktiviert, Basic Auth blockiert, falscher UPN, MFA/Conditional Access oder Tokenproblem | Postfach-, Tenant- und Authentifizierungsrichtlinien; bei Microsoft 365 zusätzlich Security Defaults | SMTP AUTH gezielt erlauben oder auf OAuth, Relay, Connector oder API wechseln. |
5.7.57 Client not authenticated | Authentifizierung | Server akzeptiert keine anonyme Submission oder Client sendet keine gültige Auth | Wird wirklich der Submission-Endpunkt genutzt? | SMTP AUTH einrichten oder Relay/Connector korrekt konfigurieren. |
5.7.60 Client doesn't have permissions to send as this sender | Absenderrecht | authentifiziertes Konto darf die gesetzte From-Adresse nicht verwenden | Login-Konto, MAIL FROM, sichtbares From:, Send-As-Recht | Send-As-Berechtigung setzen oder From-Adresse an das Login-Konto anpassen. |
550 5.7.1 Relaying denied | Relay-Policy | falscher SMTP-Weg, fehlender Connector, nicht erlaubte Quell-IP oder externe Empfänger über Direct Send | Submission, Relay und Direct Send voneinander trennen | Client Submission mit Auth verwenden oder Relay über IP/Zertifikat sauber einrichten. |
certificate verify failed | Zertifikat | unvollständige Kette, nicht vertrauenswürdige CA, TLS-Inspection | Zertifikatskette und ausstellende CA | Intermediate-Zertifikate korrigieren oder Truststore/TLS-Inspection prüfen. |
hostname does not match certificate | Zertifikat / Name | Client nutzt Alias oder IP, die nicht im Zertifikat enthalten ist | FQDN im Client gegen SAN im Zertifikat | Dokumentierten Hostnamen verwenden und SNI unterstützen. |
Prüfbefehle nach Ebene: Was der Test beweist und was offenbleibt
Ein einzelner Test reicht selten aus. Test-NetConnection zeigt nur die TCP-Erreichbarkeit. Erst ein protokollbewusster TLS-Test zeigt, ob der Server auf diesem Port den erwarteten Dialog liefert. Authentifizierungs-, Absender- und Policyfehler sehen Sie erst danach.
| Ebene | Test | Beweist | Beweist nicht | Nächster Schritt |
|---|---|---|---|---|
| DNS | nslookup -type=mx domain.tldnslookup autodiscover.domain.tld | Der Name löst auf beziehungsweise MX/Autodiscover sind sichtbar. | Der Maildienst muss deshalb noch nicht korrekt erreichbar sein. | Den dokumentierten Hostnamen des Anbieters verwenden. |
| TCP-Port | Test-NetConnection -ComputerName smtp.office365.com -Port 587Test-NetConnection -ComputerName imap.server.tld -Port 993 | Firewall, Route und Zielport sind grundsätzlich erreichbar. | TLS, Zertifikat, STARTTLS und Authentifizierung werden nicht geprüft. | Danach den passenden TLS-Modus testen. |
| SMTP STARTTLS | openssl s_client -starttls smtp -connect smtp.server.tld:587 -servername smtp.server.tld | Der Server spricht SMTP, bietet STARTTLS und liefert ein Zertifikat. | Benutzername, Passwort, OAuth und Send-As-Rechte sind noch ungeprüft. | Nach TLS die angebotenen AUTH-Mechanismen auswerten. |
| IMAP STARTTLS | openssl s_client -starttls imap -connect imap.server.tld:143 -servername imap.server.tld | IMAP auf Port 143 unterstützt ein TLS-Upgrade. | IMAP-Login, Ordnerzugriff und Postfachfreigabe sind noch offen. | Danach Authentifizierung und Postfachstatus prüfen. |
| POP3 STARTTLS/STLS | openssl s_client -starttls pop3 -connect pop.server.tld:110 -servername pop.server.tld | POP3 auf Port 110 unterstützt das TLS-Upgrade. | Ob POP3 für das Postfach erlaubt ist, bleibt offen. | Protokollstatus am Postfach kontrollieren. |
| Implizites TLS bei IMAP | openssl s_client -connect imap.server.tld:993 -servername imap.server.tld | Der Server erwartet sofort TLS und präsentiert ein Zertifikat. | IMAP-Login und Ordnerzugriff sind noch nicht bestätigt. | Zertifikatsname, Kette und anschließend Client-Auth prüfen. |
| Implizites TLS bei POP3 | openssl s_client -connect pop.server.tld:995 -servername pop.server.tld | POP3S ist erreichbar und der TLS-Handshake startet korrekt. | POP3-Freigabe am Postfach ist noch nicht bestätigt. | Postfach-/Tenant-Protokollstatus prüfen. |
| Microsoft 365 Postfachstatus | Get-CASMailbox -Identity user@domain.tld | Format-List PopEnabled,ImapEnabled,SmtpClientAuthenticationDisabled | IMAP, POP und SMTP AUTH sind am Postfach einordenbar. | Tenantweite Policies, Conditional Access, Security Defaults und Tokenfehler sind damit nicht vollständig geklärt. | Zusätzlich Organisationseinstellung, Security Defaults und Authentifizierungsrichtlinien prüfen. |
| Microsoft 365 Tenant-Status | Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled | Die globale SMTP-AUTH-Einstellung ist sichtbar. | Ein Postfachwert kann die globale Einstellung überschreiben; Security Defaults können dennoch blockieren. | Globalen Wert, Postfachwert und Security Defaults gemeinsam bewerten. |
Diagnosereihenfolge ohne unnötige Passwortwechsel
- Zielhost festlegen: Verwenden Sie den dokumentierten FQDN, keine IP-Adresse und keinen geratenen Alias.
- Rolle klären: Prüfen Sie, ob es um Abruf, Submission, Relay, Direct Send oder MTA-Transport geht.
- Port und TLS paaren: SSL/TLS nur auf impliziten TLS-Ports; STARTTLS nur auf Ports mit Klartextbeginn.
- Zertifikat prüfen: Hostname, SAN, Zertifikatskette, SNI und mögliche TLS-Inspection kontrollieren.
- Authentifizierung bewerten: Erst nach erfolgreichem TLS prüfen, ob Passwort, OAuth, SMTP AUTH oder Postfachfreigabe stimmen.
- Absender und Zustellbarkeit trennen: Send-As, SPF, DKIM und DMARC erklären andere Fehler als ein falscher Port oder ein gesperrter Login.
Wenn Sie in dieser Reihenfolge prüfen, wird aus einer unscharfen Meldung wie „Anmeldung fehlgeschlagen“ eine nachvollziehbare Fehlerkette. Ein erreichbarer Port ist nur der Anfang. Erst der passende TLS-Dialog, eine erlaubte Authentifizierung, ein zulässiger Absender und eine sauber eingerichtete Domain machen aus einer erfolgreichen Verbindung einen verlässlichen Mailversand.
Werbung
(**) UVP: Unverbindliche Preisempfehlung
Preise inkl. MwSt., zzgl. Versandkosten