Exchange-Ratgeber › Eingang: POP3- und IMAP-Abholung nach Exchange

POP3/IMAP über TLS bei der Mailabholung: Ports 995 und 993, STARTTLS oder implizites TLS und „-ERR Command is not valid in this state“

POP3 und IMAP kennen jeweils zwei Wege, eine Verbindung zu verschlüsseln: implizites TLS auf einem eigenen Port — 995 für POP3, 993 für IMAP —, bei dem die Verbindung verschlüsselt ist, bevor der erste Befehl gesendet wird, und STARTTLS (der POP3-Befehl heißt STLS) auf dem Standardport — 110 für POP3, 143 für IMAP —, bei dem der Client im Klartext verbindet und den Server dann auffordert, auf Verschlüsselung umzuschalten. Beides darf nicht vermischt werden: STLS auf Port 995 scheitert, weil der Server dort TLS bereits voraussetzt, und ein TLS-Handshake auf Port 110 trifft auf einen Server, der auf Klartext wartet.

Aktualisiert am 2026-10-06

Die Port- und Verschlüsselungsangaben auf dieser Seite stammen aus Microsoft Learn, wo sie für Exchange Server 2016, 2019 und Subscription Edition sowie für Exchange Online dokumentiert sind; die Connector-Seite stammt aus der Hilfe und der Knowledge Base zu POPcon. Nichts hier hängt von einem bestimmten Provider ab, außer wo dessen dokumentierte Einstellungen wiedergegeben werden.

Zwei Wege, dasselbe Protokoll zu verschlüsseln

Microsoft beschreibt das Paar für Exchange Server in je einem Satz: Für POP3 gilt Port 995 für immer SSL/TLS-verschlüsselte Verbindungen und Port 110 für unverschlüsselte Verbindungen oder für opportunistisches TLS (STARTTLS), das nach dem anfänglichen Klartext-Handshake zu einer verschlüsselten Verbindung führt; für IMAP4 dasselbe mit 993 und 143 (POP3 und IMAP4 in Exchange Server, sinngemäß wiedergegeben). „Immer SSL/TLS“ nennt diese Seite implizites TLS, „opportunistisches TLS“ ist STARTTLS. Die SMTP-Seite, über die ein Connector oder ein Relay Mail einliefert, hat dieselben zwei Formen — deshalb steht sie mit in der Tabelle.

Protokoll	Standardport	Port mit implizitem TLS (verschlüsselt vor dem ersten Befehl)	Anhebungsbefehl auf dem Standardport	Von Microsoft dokumentiert
POP3	110	995	STLS	Exchange Server: 995 immer verschlüsselt, 110 Klartext oder STARTTLS; Exchange Online: outlook.office365.com 995, SSL/TLS
IMAP	143	993	STARTTLS	Exchange Server: 993 immer verschlüsselt, 143 Klartext oder STARTTLS; Exchange Online: outlook.office365.com 993, SSL/TLS
SMTP-Einlieferung (die sendende Seite eines Mailprogramms oder Relays)	25 / 587	465	STARTTLS	Exchange Online: smtp.office365.com 587, STARTTLS

Die Werte für Exchange Online sind Microsofts Tabelle der Einstellungen in POP3 und IMAP4 in Exchange Online: Verschlüsselungsmethode „SSL/TLS“ für 995 und 993, „STARTTLS“ für 587. Dieselbe Seite hält fest, dass die Sicherheitsstandards POP3 und IMAP4 im Mandanten abschalten und dass das Deaktivieren der Standardauthentifizierung beide Protokolle blockiert — weshalb ein Microsoft-365-Postfach mit OAuth 2.0 abgeholt wird, beschrieben in Ohne Basic Authentication: Microsoft-365-Postfächer mit OAuth2 holen.

Was die gängigen Server erwarten

Postfach bei	POP3	IMAP	Quelle
Microsoft 365 / Exchange Online	outlook.office365.com, 995, SSL/TLS (implizit)	outlook.office365.com, 993, SSL/TLS (implizit); die POPcon-Anleitung verwendet IMAP, 993, OAuth2 Microsoft	Microsoft Learn (oben); Knowledge Base
Gmail / Google Workspace	pop.gmail.com, 995, Servertyp POP3-SSL	imap.gmail.com, 993, OAuth2 Google	Knowledge Base: Gmail per POP3, Gmail mit OAuth2; Ratgeber Gmail mit OAuth2 nach Exchange
Ein weiterer Exchange Server 2016, 2019 oder SE (wenn Sie aus einem Postfach auf einem zweiten Exchange abholen)	995 immer verschlüsselt; 110 Klartext oder mit STARTTLS	993 immer verschlüsselt; 143 Klartext oder mit STARTTLS	Microsoft Learn, POP3 und IMAP4 in Exchange Server
1&1 und andere Provider	Das, was die Einstellungsseite des Providers für Mailprogramme nennt. „SSL/TLS“ oder „SSL“ neben 995/993 bedeutet implizites TLS, „STARTTLS“ neben 110/143 die Anhebung. Die Knowledge Base hält fest, dass etwa 1&1 die Abholung nur noch über eine SSL-verschlüsselte Verbindung zulässt — in POPcon die Umstellung von POP3 auf POP3-SSL.		Knowledge Base

Für einen Connector folgt daraus zweierlei. Erstens entscheidet der Provider die TLS-Frage, nicht der Administrator: Verwenden Sie den Port, den der Provider dokumentiert, und die Verschlüsselungsart, die zu ihm gehört. Zweitens ist für die beiden Anbieter, bei denen heute die meisten Postfächer liegen, die dokumentierte Kombination IMAP auf 993 mit implizitem TLS und OAuth 2.0 — die Wahl zwischen POP3 und IMAP selbst behandelt POP3 oder IMAP für die Abholung von Provider-Postfächern nach Exchange?.

Der klassische Fehler: STLS auf Port 995

Ein Thread auf Microsoft Q&A zeigt den Fehler genau so, wie er entsteht (Unable to connect to POP email, eine Community-Frage, keine Microsoft-Dokumentation). Das Protokoll des Clients liest sich der Reihe nach so: Er öffnet eine TLS-Verbindung zu outlook.office365.com:995; der Server antwortet +OK Microsoft Exchange POP3 server ready; der Client sendet dann STLS; der Server antwortet -ERR Command is not valid in this state.; der Client gibt auf mit „Could not connect to POP3 server outlook.office365.com on port 995“.

Bis zur Zeile STLS war alles richtig. Auf Port 995 findet der TLS-Handshake vor dem ersten POP3-Befehl statt — das meint Microsoft mit „immer SSL/TLS-verschlüsselt“ —, und wenn der Client STLS senden könnte, ist die Sitzung also bereits verschlüsselt. Es gibt nichts mehr anzuheben, und der Server weist den Befehl als unpassend ab; „not valid in this state“ ist die POP3-Formulierung für „nicht jetzt“. Der Server ist nicht defekt, und das Kennwort wurde nie geprüft. Die Korrektur liegt beim Client: implizites TLS für Port 995 (oder 993) wählen — oder, wenn der Client STLS verwenden soll, ihn auf Port 110 (oder 143) richten, wo der Provider STARTTLS anbietet.

Der umgekehrte Fehler sieht anders aus. Ein Client mit implizitem TLS, der sich mit Port 110 verbindet, beginnt mit einem TLS-Handshake; der Server wartet auf POP3 im Klartext und antwortet nicht so, dass der Client es versteht. Es gibt keine lesbare Fehlerzeile — die Anmeldung scheitert oder die Verbindung läuft in die Zeitüberschreitung, bevor eine Mail gelesen ist. Das Symptom „Timeout bei korrektem Kennwort“ zeigt deshalb zuerst auf das Paar aus Port und Verschlüsselung und erst danach auf den Provider.

Die Einstellung im Connector

In POPcon besteht das Paar aus zwei Feldern des Kontos. Der Servertyp trägt den Standardport — POP3 110, POP3-SSL 995, IMAP 143, IMAP-SSL 993 (POP3/IMAP-Einstellungen) —, und das Feld Verschlüsselung kennt vier Werte (Kontodetails):

Wert	Was er tut	Gehört zu
TLS	Transport Layer Security, implizit — verbindet sich auf dem SSL-Port und verschlüsselt vor dem ersten Befehl	POP3-SSL / 995, IMAP-SSL / 993
SSL	Secure Sockets Layer, der Legacy-Vorgänger, ebenfalls auf dem SSL-Port	995 / 993 (Legacy)
STLS	STARTTLS — verbindet sich im Klartext auf dem Standardport und hebt die Verbindung auf eine verschlüsselte an	POP3 / 110, IMAP / 143
SPA	Secure Password Authentication — eine Authentifizierungsoption, keine Transportverschlüsselung	Kein eigenes Port-Paar

Die funktionierenden Kombinationen sind TLS mit 995 oder 993 und STLS mit 110 oder 143. Die Schaltfläche Zugriff testen prüft Serververbindung, Authentifizierung und Postfachzugriff in einem Schritt und ist der schnellste Weg, das Paar zu bestätigen; die Wartezeit auf eine Serverantwort beträgt standardmäßig 180 Sekunden, sodass ein falsches Paar eher als langes Warten erscheint als als sofortiger Fehler. POPcon unterstützt TLS 1.2 und 1.3 und beide Varianten, STARTTLS und implizites TLS, auf POP3 (995) und IMAP (993).

TLS-Versionen

Das Zweite, was an einer verschlüsselten Verbindung falsch sein kann, ist die Protokollversion. Die Versionshistorie von POPcon nennt die Unterstützung von TLS 1.2 mit Version 4.0 (April 2021), die Produktseite TLS 1.2 und 1.3 für die aktuelle Version. Der Knowledge-Base-Artikel zur Wartezeitüberschreitung bei Strato-Konten beschreibt das Symptom des alten Zustands: Die 3.9x-Versionen nutzten eine SSL/TLS-Bibliothek, die seit Jahren nicht mehr weiterentwickelt wurde und TLS 1.2 nicht unterstützte; die Meldung „Wartezeitüberschreitung bei Warten auf Antwort vom Host“ bei Strato führt der Artikel auf die langsame TLS-Entschlüsselung dieser Versionen zurück. Erreicht ein Connector vor Version 4.0 einen Provider auf 995 oder 993 plötzlich nicht mehr, ist die TLS-Version der erste Verdächtige und das Update die Lösung. Zeitüberschreitungen haben allerdings noch eine zweite Ursache, die nichts mit TLS zu tun hat: Hardware-Firewalls, die den Download blockieren (Knowledge Base).

Die SMTP-Seite, der Vollständigkeit halber

Ein Connector holt nur über POP3 oder IMAP ab; an Exchange übergibt er die Mail per SMTP, und ein Relay wie MultiSendcon sendet ausgehende Mail per SMTP an einen Provider. SMTP hat dieselben zwei Formen: STARTTLS auf Port 587 (und 25) und implizites TLS auf Port 465. MultiSendcon unterstützt beides für jede konfigurierte Route; Microsoft dokumentiert smtp.office365.com auf 587 mit STARTTLS, und die Hilfe zum SMTP-Konto (englisch) hält fest, dass SSL bei Port 465 automatisch aktiviert wird. Zwei Knowledge-Base-Artikel sind die SMTP-Zwillinge dieser Seite: „504 5.7.4 Unrecognized authentication type“ erscheint, wenn ein Server explizites TLS verlangt und die SSL-Einstellung des Kontos nicht auf „explicit SSL/TLS“ steht, und „530 5.7.0 Must issue a STARTTLS command first“ ist die SMTP-Seite von Exchange selbst, die TLS verlangt, bevor sie Mail vom Connector annimmt. Die vollständige Liste der Antworten steht in Exchange-SMTP-Fehlercodes erklärt.

Symptome und was sie bedeuten

Symptom	Ursache	Lösung
Protokoll zeigt STLS, gefolgt von -ERR Command is not valid in this state	STLS auf einem Port mit implizitem TLS (995/993) gesendet; die Sitzung war bereits verschlüsselt	Verschlüsselung auf TLS (implizit) für 995/993 stellen oder STLS auf 110/143 verwenden
Anmeldung auf 995 oder 993 scheitert oder läuft in die Zeitüberschreitung, obwohl das Kennwort stimmt; keine lesbare Serverantwort	Klartext- oder STLS-Client auf einem Port mit implizitem TLS, oder implizites TLS auf einem Standardport gewählt	TLS mit 995/993 und STLS mit 110/143 paaren; Zugriff testen ausführen
Verbindung auf 110 oder 143 scheitert mit gewähltem TLS	Der Server erwartet zuerst Klartext	STLS wählen oder auf den SSL-Port mit TLS wechseln
Microsoft-365-Postfach weist ein korrektes Kennwort ab	Standardauthentifizierung für POP und IMAP ist in Exchange Online abgeschaltet; kein TLS-Problem	IMAP, outlook.office365.com, 993, OAuth2 Microsoft — Ratgeber
Google-Workspace-Postfach weist ein korrektes Kennwort ab	Google nimmt von einer Drittanbieter-App keinen Benutzernamen mit Kennwort mehr an	IMAP, imap.gmail.com, 993, OAuth2 Google — Ratgeber
Zeitüberschreitungen auf einem verschlüsselten Port mit einer POPcon-Version 3.9x	Alte TLS-Bibliothek ohne TLS 1.2	Auf die aktuelle Version aktualisieren (Download)
504 5.7.4 Unrecognized authentication type, wenn MultiSendcon an Microsoft 365 sendet	Der Server verlangt explizites TLS, das Konto ist nicht darauf eingestellt	SSL-Option des Kontos auf „explicit SSL/TLS“ stellen (Knowledge Base)
530 5.7.0 Must issue a STARTTLS command first von Exchange bei der Übergabe	Die SMTP-Seite von Exchange verlangt TLS, bevor sie Mail annimmt	Knowledge-Base-Artikel; die Zeile in der Tabelle der SMTP-Fehlercodes

Das Verbindungsprotokoll mit dem Befehlswechsel ist bei POPcon die Datei POPconSrv.log im Programmverzeichnis. Wie die abgeholte Mail dann Exchange erreicht — Empfangsconnector, akzeptierte Domäne, erster Test — steht in POP3- und IMAP-Postfächer in Exchange abholen.

Häufige Fragen

Mehr in den Exchange-Ratgebern, auf der Produktseite POPcon, der POPcon-Download-Seite oder in der Knowledge Base. In English: POP3/IMAP over TLS for mail retrieval.