Exchange mail flow guides › Inbound: POP3 and IMAP retrieval into Exchange

POP3/IMAP over TLS for mail retrieval: ports 995 and 993, STARTTLS vs implicit TLS, and “-ERR Command is not valid in this state”

POP3 and IMAP each have two ways to encrypt a connection: implicit TLS on a dedicated port — 995 for POP3, 993 for IMAP — where the connection is encrypted before the first command is sent, and STARTTLS (the POP3 command is spelled STLS) on the plain port — 110 for POP3, 143 for IMAP — where the client connects in clear text and then asks the server to switch to encryption. The two must not be mixed: sending STLS on port 995 fails because the server expects TLS to be in place already, and a TLS handshake on port 110 meets a server that is waiting for plain text.

Updated on 2026-10-06

The port and encryption facts on this page are taken from Microsoft Learn, where they are documented for Exchange Server 2016, 2019 and Subscription Edition and for Exchange Online; the connector side is taken from the POPcon help and knowledge base. Nothing here depends on a particular provider except where the provider’s documented settings are quoted.

Two ways to encrypt the same protocol

Microsoft describes the pair for Exchange Server in one sentence each: for POP3, “995 for always SSL/TLS encrypted connections, and 110 for unencrypted connections, or for opportunistic TLS (STARTTLS) that results in an encrypted connection after the initial plain text protocol handshake”; for IMAP4 the same with 993 and 143 (POP3 and IMAP4 in Exchange Server). “Always SSL/TLS” is what this page calls implicit TLS; “opportunistic TLS” is STARTTLS. The SMTP side that a connector or relay uses to submit mail has the same two shapes, which is why it is in the table.

Protocol	Plain port	Implicit TLS port (encrypted before the first command)	Upgrade command on the plain port	Documented by Microsoft
POP3	110	995	STLS	Exchange Server: 995 always encrypted, 110 plain or STARTTLS; Exchange Online: outlook.office365.com 995, SSL/TLS
IMAP	143	993	STARTTLS	Exchange Server: 993 always encrypted, 143 plain or STARTTLS; Exchange Online: outlook.office365.com 993, SSL/TLS
SMTP submission (the sending side of a mail program or relay)	25 / 587	465	STARTTLS	Exchange Online: smtp.office365.com 587, STARTTLS

The Exchange Online values are Microsoft’s table of settings in POP3 and IMAP4 in Exchange Online, where the encryption method is given as “SSL/TLS” for 995 and 993 and as “STARTTLS” for 587. The same page notes that security defaults disable POP3 and IMAP4 in a tenant and that disabling Basic authentication blocks both protocols — which is why a Microsoft 365 mailbox is fetched with OAuth 2.0, described in Basic authentication is gone: fetching a Microsoft 365 mailbox with OAuth2.

What the common servers expect

Mailbox at	POP3	IMAP	Source
Microsoft 365 / Exchange Online	outlook.office365.com, 995, SSL/TLS (implicit)	outlook.office365.com, 993, SSL/TLS (implicit); the POPcon walkthrough uses IMAP, 993, OAuth2 Microsoft	Microsoft Learn (above); knowledge base
Gmail / Google Workspace	pop.gmail.com, 995, server type POP3-SSL	imap.gmail.com, 993, OAuth2 Google	Knowledge base: Gmail by POP3, Gmail with OAuth2; guide Gmail into Exchange with OAuth2
Another Exchange Server 2016, 2019 or SE (when you pull from a mailbox on a second Exchange)	995 always encrypted; 110 plain or with STARTTLS	993 always encrypted; 143 plain or with STARTTLS	Microsoft Learn, POP3 and IMAP4 in Exchange Server
Other providers	Whatever the provider’s settings page lists for mail programs. “SSL/TLS” or “SSL” next to 995/993 means implicit TLS; “STARTTLS” next to 110/143 means the upgrade. The German knowledge base notes that 1&1, for example, only allows encrypted POP3 connections.		Knowledge base (German)

Two things follow for a connector. First, the TLS question is settled by the provider, not by the administrator: use the port the provider documents and the encryption mode that belongs to it. Second, for the two providers most mailboxes are at today, the documented combination is IMAP on 993 with implicit TLS and OAuth 2.0 — the choice between POP3 and IMAP itself is the subject of POP3 or IMAP for retrieving provider mailboxes into Exchange?.

The classic misconfiguration: STLS on port 995

A thread on Microsoft Q&A shows the error exactly as it happens (Unable to connect to POP email, a community question, not Microsoft documentation). The client’s log reads, in sequence: it opens a TLS connection to outlook.office365.com:995; the server answers +OK Microsoft Exchange POP3 server ready; the client then writes STLS; the server replies -ERR Command is not valid in this state.; the client gives up with “Could not connect to POP3 server outlook.office365.com on port 995”.

Everything up to the STLS line was correct. On port 995 the TLS handshake happens before the first POP3 command — that is what Microsoft means by “always SSL/TLS encrypted” — so by the time the client could send STLS, the session is already encrypted. There is nothing left to upgrade, and the server refuses the command as out of place; “not valid in this state” is the POP3 way of saying “not now”. The server is not broken and the password was never checked. The fix is on the client: select implicit TLS for port 995 (or 993), or, if the client is meant to use STLS, point it at port 110 (or 143) where the provider offers STARTTLS.

The reverse mistake looks different. A client set to implicit TLS that connects to port 110 starts with a TLS handshake; the server is waiting for plain-text POP3 and does not answer in a way the client understands. There is no readable error line — the login fails or the connection times out before any mail is read. The symptom “timeout on a correct password” therefore points at the port and encryption pairing before it points at the provider.

Setting it in the connector

In POPcon the pairing is two fields on the account. The server type carries the default port — POP3 110, POP3-SSL 995, IMAP 143, IMAP-SSL 993 (POP3/IMAP settings) — and the encryption field has four values (Account details):

Encryption value	What it does	Belongs with
TLS	Transport Layer Security, implicit — connects on the SSL port and encrypts before the first command	POP3-SSL / 995, IMAP-SSL / 993
SSL	Secure Sockets Layer, the legacy predecessor, also on the SSL port	995 / 993 (legacy)
STLS	StartTLS — connects in plain text on the standard port and upgrades to encrypted	POP3 / 110, IMAP / 143
SPA	Secure Password Authentication — an authentication option, not transport encryption	No port pairing of its own

The working combinations are TLS with 995 or 993 and STLS with 110 or 143. The Test access button checks the server connection, the authentication and the mailbox access in one go and is the quickest way to confirm the pairing; the timeout for a server response defaults to 180 seconds, so a wrong pairing can show up as a long wait rather than an instant error. POPcon supports TLS 1.2 and 1.3 and both variants, STARTTLS and implicit TLS, on POP3 (995) and IMAP (993).

TLS versions

The second thing that can be wrong with an encrypted connection is the protocol version. The POPcon version history lists TLS 1.2 support with version 4.0 (April 2021), and the product page states TLS 1.2 and 1.3 for the current version. The German knowledge base article on timeouts with Strato accounts describes the symptom of the old state: the 3.9x versions used an SSL/TLS library that had not been developed further for years and did not support TLS 1.2, and the article attributes the message “timeout while waiting for a response from the host” with Strato accounts to the slow TLS decryption of those versions. If a connector older than 4.0 suddenly cannot reach a provider on 995 or 993, the TLS version is the first suspect and the update is the fix.

The SMTP side, for completeness

A connector only retrieves over POP3 or IMAP; it hands mail to Exchange over SMTP, and a relay such as MultiSendcon sends outbound mail over SMTP to a provider. SMTP has the same two shapes: STARTTLS on port 587 (and 25) and implicit TLS on port 465. MultiSendcon supports both for every configured route; Microsoft documents smtp.office365.com on 587 with STARTTLS, and the SMTP account help notes that SSL is activated automatically when port 465 is used. Two knowledge-base articles are this page’s SMTP twins: “504 5.7.4 Unrecognized authentication type” appears when a server requires explicit TLS and the account’s SSL setting is not set to explicit SSL/TLS, and “530 5.7.0 Must issue a STARTTLS command first” is Exchange’s own SMTP side insisting on TLS before it accepts mail from the connector. The complete list of replies is in Exchange SMTP error codes explained.

Symptoms and what each one means

Symptom	Cause	Fix
Log shows STLS followed by -ERR Command is not valid in this state	STLS sent on an implicit-TLS port (995/993); the session was already encrypted	Set the encryption to TLS (implicit) for 995/993, or move STLS to 110/143
Login on 995 or 993 fails or times out although the password is correct; no readable server reply	Plain-text or STLS client on an implicit-TLS port, or implicit TLS selected on a plain port	Pair TLS with 995/993 and STLS with 110/143; run Test access
Connection on 110 or 143 fails with TLS selected	The server expects plain text first	Select STLS, or switch to the SSL port with TLS
Microsoft 365 mailbox refuses a correct password	Basic authentication for POP and IMAP is off in Exchange Online; not a TLS problem	IMAP, outlook.office365.com, 993, OAuth2 Microsoft — guide
Google Workspace mailbox refuses a correct password	Google no longer accepts a username and password from a third-party app	IMAP, imap.gmail.com, 993, OAuth2 Google — guide
Timeouts on an encrypted port with a POPcon 3.9x version	Old TLS library without TLS 1.2	Update to the current version (download)
504 5.7.4 Unrecognized authentication type when MultiSendcon sends to Microsoft 365	The server requires explicit TLS and the account is not set to it	Set the account’s SSL option to explicit SSL/TLS (knowledge base)
530 5.7.0 Must issue a STARTTLS command first from Exchange when the connector delivers	Exchange’s SMTP side is configured to require TLS before accepting mail	Knowledge base article; the row in the SMTP error code table

The connection log that shows the exchange of commands is, for POPcon, the file POPconSrv.log in the program directory. How the retrieved mail then reaches Exchange — receive connector, accepted domain, first test — is in How to download POP3 and IMAP mailboxes into Exchange.

Frequently asked questions

More in the Exchange mail flow guides, on the POPcon product page, the POPcon download page or in the knowledge base. Auf Deutsch: POP3/IMAP über TLS bei der Mailabholung.