IMAP Connection Broken Server Response

The full message is usually [CLOSED] IMAP connection broken (server response). Despite the wording, this is not an RFC 3501 IMAP server status or an SMTP reply code. It is an error string emitted by PHP's imap extension, which is built on the legacy UW-IMAP c-client library. You will see the identical text from anything that wraps that extension — ddeboer/imap, Kayako Classic's email parser, Faveo Helpdesk, and similar PHP mail tooling.

PHP 8.4+: the imap extension was unbundled from PHP core and moved to PECL — it's no longer built in or enabled by default. Install it separately with pecl install imap, or migrate to a maintained library such as webklex/php-imap.

[CLOSED] is the c-client mailbox state: the stream was opened but then closed. connection broken (server response) means the client got far enough to start talking to the server, but the session ended (the socket was reset, the TLS handshake failed, or the server rejected/aborted the session) before imap_open() could return a usable mailbox handle. So this is a connection-or-login failure, not a "mailbox not found" or "bad command" failure.

What causes "IMAP connection broken (server response)"?

The connection reaches the server but does not survive to an authenticated session. The documented triggers are:

• Port / encryption mismatch. Trying implicit SSL on the STARTTLS port (143), or plaintext on the implicit-SSL port (993). Per RFC 3501, plaintext/STARTTLS IMAP uses port 143 (STARTTLS added by RFC 2595); per RFC 8314, implicit-TLS IMAP uses port 993, and cleartext access should be deprecated in favor of it.
• TLS handshake / certificate failure. A self-signed or hostname-mismatched certificate makes c-client tear the stream down. Note: the /novalidate-cert flag only skips certificate validation — it does not fix a handshake that never completes.
• Authentication rejected, then the server drops the stream. This is the most common modern cause and is easy to misread as a "connection" problem:
• Gmail / Google Workspace require an App Password (with 2-Step Verification enabled) or OAuth2. Google removed "Less Secure Apps" for personal Gmail accounts on May 30, 2022. Google Workspace accounts kept LSA access longer — the admin toggle was removed June 15, 2024, and IMAP/POP access via LSA was fully cut off September 30, 2024. Either way, a plain account password is now refused.
• Microsoft 365 / Exchange Online disabled Basic authentication for IMAP (October 2022; 21Vianet March 2023). outlook.office365.com:993 now requires OAuth 2.0; username + password will fail.
• Firewall, antivirus, or network appliance silently closing the connection mid-session.
• Non-ASCII characters in the password (reported against Exchange Online), or an idle/oversized session the server times out.

How do I fix "IMAP connection broken (server response)"?

1. Confirm what the server actually speaks. From a shell, test both modes:

# implicit TLS on 993
openssl s_client -connect imap.example.com:993
# STARTTLS on 143
openssl s_client -starttls imap -connect imap.example.com:143

If 993 returns a TLS handshake and an * OK banner, use implicit SSL. If only 143 + STARTTLS works, use that. This also surfaces certificate errors directly.

2. Match the PHP connection flags to the result. For implicit TLS:

$mbox = imap_open('{imap.example.com:993/imap/ssl}', $user, $pass);

For STARTTLS on 143, use /imap/tls. Only add /novalidate-cert for a known self-signed cert in testing — never as a blind fix in production.

3. Use modern authentication.

• Gmail: enable 2-Step Verification, generate a 16-character App Password, and pass it (no spaces) as the password to imap.gmail.com:993 with /imap/ssl.
• Exchange Online: switch to OAuth 2.0; Basic auth over IMAP is permanently disabled. The PHP imap extension supports XOAUTH2 only with a c-client built for it, so most teams move to an OAuth-capable IMAP client/library here.

4. Rule out the network. Temporarily disable local firewall/antivirus or test from a different network to confirm a middlebox isn't closing the session.

5. Reconnect on transient drops. If the failure is intermittent (idle timeout, large mailbox), close the broken handle and re-open a fresh one rather than reusing it.

If none of these resolve it, the session is being terminated server-side — ask the mail-server admin to check the IMAP logs for the disconnect reason, which will name the real cause (auth failure, TLS error, or rate limit).