Table of Contents
- Which IMAP Port to Use and When to Switch
- Which settings belong together?
- When should an administrator switch?
- How to verify it
- IMAP Ports Compared With POP3 and SMTP
- What does a wrong-protocol setting look like?
- How to verify it
- IMAP Hosts and Ports by Provider
- What does Google require beyond the server setting?
- What should an Exchange administrator confirm?
- How to verify it
- How Encryption Works on 993 and 143
- What happens during implicit TLS?
- What happens during STARTTLS?
- What makes the encrypted session trustworthy?
- How to verify it
- Port and Encryption Mismatches That Break Login
- Which common mistakes fail before authentication?
- Can antivirus or a firewall cause the same symptoms?
- How to verify it
- Blocked Ports Versus Rejected Credentials
- What does a reachability failure prove?
- What does a TLS failure prove?
- What does an authentication rejection prove?
- How to verify it
- How to Verify the IMAP Connection
- What is the verification procedure?
- How should an AI agent handle the check?
- How to verify it
- IMAP Port Questions and the Check to Run
- Is 993 always better than 143?
- Should I use an app password or OAuth?
- What should an AI agent call?
Do not index
Do not index
Use TCP port 993 with SSL/TLS (implicit TLS) for IMAP. Use TCP port 143 only with STARTTLS, and never send the password before encryption is established.
A correct hostname and password can still produce a connection failure. The overlooked setting is often when encryption starts, because an IMAP server and client must agree on the handshake before either can attempt a login.
Table of Contents
Which IMAP Port to Use and When to SwitchWhich settings belong together?When should an administrator switch?How to verify itIMAP Ports Compared With POP3 and SMTPWhat does a wrong-protocol setting look like?How to verify itIMAP Hosts and Ports by ProviderWhat does Google require beyond the server setting?What should an Exchange administrator confirm?How to verify itHow Encryption Works on 993 and 143What happens during implicit TLS?What happens during STARTTLS?What makes the encrypted session trustworthy?How to verify itPort and Encryption Mismatches That Break LoginWhich common mistakes fail before authentication?Can antivirus or a firewall cause the same symptoms?How to verify itBlocked Ports Versus Rejected CredentialsWhat does a reachability failure prove?What does a TLS failure prove?What does an authentication rejection prove?How to verify itHow to Verify the IMAP ConnectionWhat is the verification procedure?How should an AI agent handle the check?How to verify itIMAP Port Questions and the Check to RunIs 993 always better than 143?Should I use an app password or OAuth?What should an AI agent call?
Which IMAP Port to Use and When to Switch
Port 993 with implicit TLS is the default for a new IMAP configuration, unless the mailbox provider documents another requirement. The port and encryption mode form a pair, not separate preferences.
IMAP stands for Internet Message Access Protocol. An email client uses IMAP to access messages stored on a server and synchronize mailbox folders and message state. IMAP isn't the outgoing mail protocol, and it isn't interchangeable with a download-oriented POP3 connection.
Which settings belong together?
The standard service names distinguish ordinary IMAP from IMAP over TLS. The practical difference is the first exchange after the network connection opens.
An application's SSL option usually means implicit TLS, not permission to use an obsolete SSL protocol. The provider's documentation should identify the intended connection mode, even when the application's label is shortened.
A setting labeled automatic needs particular attention. An administrator should confirm the actual mode selected rather than assume the client requires encryption.
When should an administrator switch?
- A new client has no provider-specific exception. Select implicit TLS and the secure IMAP endpoint. This avoids a separate plaintext protocol exchange before encryption starts.
- The provider documents STARTTLS rather than implicit TLS. Select the documented STARTTLS endpoint explicitly. An implicit-TLS setting won't perform that upgrade.
- The implicit-TLS endpoint is blocked, but the STARTTLS endpoint answers. A switch is acceptable only when the provider supports it and the server advertises STARTTLS in its capabilities. An open TCP connection alone isn't sufficient.
- The server offers only an unencrypted listener. Don't configure a password-based connection that can proceed without encryption. The administrator must enable a secure service or require STARTTLS before allowing LOGIN.
The same hostname might expose separate listeners for different connection modes. Switching a port without switching the mode can therefore turn a working configuration into a handshake error without changing anything about the mailbox.
An unknown hostname shouldn't be guessed from the email address. A custom-domain mailbox can use a server operated under the hosting provider's domain rather than the organization's domain.
Hostnames and supported connection modes can also differ by provider region, plan, or a recent service change. The account's current official setup documentation takes precedence over an old configuration saved in an application.
How to verify it
The mailX IMAP checker can test whether the selected endpoint connects, negotiates encryption, and accepts an authorized login. A good result confirms the complete pair; an open port followed by a failed TLS negotiation means the configuration isn't ready for credentials.
The host-discovery step belongs before repeated login attempts. It prevents an administrator from debugging a password against the wrong server.
IMAP Ports Compared With POP3 and SMTP
An incoming-mail field needs an incoming protocol, not merely an encrypted port. Two mail connections can both use TLS and still perform completely different jobs.
IMAP synchronizes a server mailbox. POP3 retrieves messages through a different protocol, while SMTP submits outgoing messages. A client needs separate incoming and outgoing settings even when the provider uses the same hostname for both services.
What does a wrong-protocol setting look like?
A POP3 endpoint can't become an IMAP endpoint because an application requests IMAP folders. Even after encryption succeeds, the client and server won't understand the same mailbox commands.
An SMTP endpoint presents a similar problem. A successful connection to an outgoing server doesn't prove that incoming synchronization works.
- Sending works, synchronization fails. Inspect the incoming account type, hostname, and security pair. The outgoing configuration may be correct while the incoming field contains SMTP settings.
- Reading works, sending fails. Inspect the outgoing configuration separately. Adding another IMAP connection won't repair SMTP submission.
- Encryption succeeds, protocol negotiation fails. Confirm that the selected service speaks IMAP. A valid certificate doesn't identify the application protocol by itself.
A provider's setup page may place incoming and outgoing settings next to each other. Copying an entire row is safer than copying a port in isolation.
How to verify it
After the incoming connection is settled, an SMTP connection test checks the outgoing side independently. A successful outgoing result doesn't clear an IMAP failure, and a rejected SMTP login shouldn't trigger changes to a working incoming connection.
If the hostname doesn't resolve at all, the mailX DNS guide provides the relevant hostname-resolution context. Protocol troubleshooting starts only after the intended server can be located.
IMAP Hosts and Ports by Provider
The provider's documented hostname comes before any port experiment. The settings below distinguish a confirmed public hostname from an administrator-configured endpoint.
The Microsoft 365 and Exchange Online hostname entry is deliberately not a copyable server value. The account's current Microsoft documentation must confirm the endpoint before configuration.
What does Google require beyond the server setting?
Google's incoming-mail setup instructions specify
imap.gmail.com, port 993, and SSL enabled, while separately listing SMTP port 587 with TLS. Those settings serve different directions of mail traffic.The username should be the complete mailbox address where Google requires it. Authentication must also follow the account's permitted method, which may involve OAuth through SASL XOAUTH2 or an app password where the account allows one.
A Google Workspace administrator may need to permit IMAP access. Transport settings don't override an administrative access policy, and a successful encrypted connection doesn't prove that a particular application is authorized.
The distinction matters for integrations. An application that supports only a mailbox-password login may remain incompatible with an account that requires token-based authorization.
What should an Exchange administrator confirm?
A self-hosted Exchange IMAP service uses the administrator's configured public fully qualified domain name, or FQDN. The external hostname must resolve publicly, and the certificate must cover that hostname.
The SSL listener and the plain-or-STARTTLS listener are separate bindings. Publishing one doesn't automatically publish the other, and opening a firewall rule doesn't create a missing listener.
For Yahoo, iCloud, Zoho, or another mailbox provider, the current setup guide should supply the host and security pair. A remembered hostname isn't a substitute for account-specific documentation, particularly when a provider has regional endpoints or plan restrictions.
How to verify it
Administrators can find your IMAP server with mailX before configuring the client. The IMAP finder returns the host, ports with encryption, and the provider's setup guide without asking for mailbox credentials.
The discovered endpoint should agree with the provider's account instructions. If the endpoint connects securely but login fails, the next checks concern username format, permitted authentication, and IMAP access, not a guessed replacement hostname.
How Encryption Works on 993 and 143
Implicit TLS encrypts the connection before the client starts the IMAP conversation. STARTTLS begins with an IMAP conversation and then upgrades that same connection to TLS.
Implicit TLS on TCP 993: TLS begins immediately after TCP connect. STARTTLS on TCP 143: encryption starts after the IMAP session begins.
What happens during implicit TLS?
The client opens a TCP connection and sends a TLS ClientHello. The server participates in TLS negotiation and presents its certificate before the client proceeds with IMAP commands.
Once the TLS handshake succeeds, the server's IMAP greeting and the client's mailbox commands travel inside the encrypted connection. Authentication doesn't precede certificate validation.
The client must therefore speak TLS first. Waiting for a plaintext IMAP greeting on this listener leaves the client and server expecting different opening exchanges.
What happens during STARTTLS?
The server first sends an unencrypted IMAP greeting. The client discovers the server's capabilities and requests STARTTLS; after the server accepts, the client begins TLS negotiation.
The client must not treat the initial greeting as permission to send a password. After a successful upgrade, the client obtains the capabilities appropriate to the protected session before continuing with authentication.
The IMAP4rev2 specification, RFC 9051, published in 2021, retains TCP 143 for cleartext or STARTTLS and TCP 993 for implicit TLS, requires support for TLS 1.2 or newer, and recommends TLS 1.3. It also requires STARTTLS support on a cleartext listener and TLS negotiation on an implicit-TLS listener.
The standard recommends that clients try both connection patterns concurrently, including IPv4 and IPv6, unless configuration or DNS service-discovery records override that behavior. Consequently, a failed attempt against one endpoint doesn't establish that every supported route to the mailbox is unavailable.
What makes the encrypted session trustworthy?
Encryption must connect the client to the intended server, not to any server willing to negotiate TLS. Certificate validation needs to cover:
- Trust chain. The certificate must lead to a trusted certificate authority.
- Validity period. An expired or not-yet-valid certificate must not be accepted.
- Hostname identity. The certificate must cover the hostname the client intended to reach.
- Negotiated protocol. The connection must meet the client's TLS security requirements.
A client should fail closed on certificate errors rather than offer an automatic plaintext retry. Disabling validation can hide a hostname mistake or interception instead of solving it.
How to verify it
The mailX IMAP checker should confirm the expected encryption mode before authentication is interpreted. A successful TCP connection without successful TLS is a transport-only result, not a secure mailbox connection.
Port and Encryption Mismatches That Break Login
The port and encryption mode must match the server's listener. Port 993 typically uses implicit TLS, while port 143 typically uses IMAP with STARTTLS or, where permitted, no encryption. Microsoft's Set-ImapSettings reference documents these port assignments for Exchange.
Which common mistakes fail before authentication?
Error wording varies by application. A generic connection error may conceal a protocol mismatch, so check the configured port-and-mode pair against the provider's settings.
Connecting without encryption can make a client appear to work, while leaving the session unprotected. Use the mode required by the provider.
Can antivirus or a firewall cause the same symptoms?
Endpoint security software and gateways may inspect or intercept mail traffic. If inspection interrupts TLS, the connection can fail even when the remote listener is configured correctly.
Compare results from an approved alternate network or device to isolate local interference. Security administrators can review interception certificates and mail-inspection policies without disabling encryption.
For authentication failures after a connection and encryption succeed, see Blocked Ports Versus Rejected Credentials.
How to verify it
The mailX IMAP checker reports whether the connection, encryption, and authentication succeed. Its results help identify whether the configured port-and-mode pair works through the authentication stage.
Blocked Ports Versus Rejected Credentials
A timeout, a TLS error, and a rejected login point to different stages of an IMAP connection. The earliest failed stage narrows what to check next.
The diagnostic order is reachability, TLS, then authentication. Each successful stage allows the next one to be assessed, but does not guarantee it will succeed.
What does a reachability failure prove?
A timeout means the connection did not complete within the allowed interval. Possible causes include dropped traffic, an unavailable server, incorrect routing, or a security device blocking the request.
A connection refusal means the destination or an intervening device actively rejected the attempt. A missing listener is one possible cause. Neither result provides evidence about the mailbox password, because the client has not reached an authentication exchange.
- Check the destination. Confirm the hostname and selected service.
- Check the listener. The server must offer the intended connection mode.
- Check the path. Local firewall, gateway, and hosting-network rules must permit the traffic.
What does a TLS failure prove?
If TCP connects but TLS fails, basic reachability has succeeded and the connection has stopped before mailbox authentication. Possible causes include a port and encryption-mode mismatch, an expired certificate, an untrusted certificate chain, or a certificate issued for a different hostname.
Keep certificate validation enabled. Accepting an unexpected certificate does not confirm that the client reached the intended mailbox server.
Test location matters. A server-side diagnostic uses a different network path from a desktop client, so its success does not rule out a local firewall or inspection problem.
What does an authentication rejection prove?
Once DNS resolution, TCP connection, and TLS validation succeed, a rejected login points to the authentication layer. Check the credentials, mailbox access, application authorization, and provider policy.
If the application uses the wrong authentication method, repeated password resets will not address the cause. Keep the successful transport settings in place while correcting the authorization method.
The mailX guide to IMAP server issues explains possible causes when an IMAP server does not respond as expected. Use the earliest failed exchange to interpret an error, since a client's final message may be too general.
How to verify it
The mailX IMAP checker reports whether connection, encryption, and authentication succeed. Use it only to test an IMAP login for a mailbox you control, with its credentials. A successful result confirms that the server accepted the tested connection and login.
How to Verify the IMAP Connection
A repeatable check keeps the destination, security mode, and account identity fixed while testing a single change. Otherwise, a successful retry won't reveal which correction mattered.
The process should begin without credentials when the server is unknown. Authentication testing comes only after the intended host and secure connection mode have been established.
What is the verification procedure?
- Identify the incoming server. Open the mailX IMAP finder and enter the mailbox domain. Read the returned host, ports with encryption, and provider setup guide rather than substituting the domain's website hostname.
- Configure the documented pair. Set the incoming account type to IMAP and use the provider's hostname with its supported encryption mode. If the application changes the port automatically when security is selected, inspect both fields again before saving.
- Test an authorized mailbox. Run an IMAP connection test only for a mailbox the tester controls. Supply the permitted password or app password when that is the supported test method.
- Read the result in connection order. Resolve a reachability failure before interpreting encryption, and resolve encryption before interpreting authentication. A later stage can't supply useful evidence when the earlier stage never completed.
- Change only the failed layer. Correct the relevant hostname, network rule, mode, certificate, or login method, then repeat the same test. Keep successful settings unchanged unless new evidence shows they are incorrect.
An account that requires OAuth may need its application authorization repaired rather than a password-based diagnostic repeated. The provider's supported login mechanism remains the authority.
How should an AI agent handle the check?
The mailX MCP documentation identifies the available agent interface and tools. An agent should use host discovery without requesting credentials, then ask for explicit user confirmation before any test that logs in.
The
imap_check tool should only be invoked when the user explicitly requests an IMAP login test for a mailbox they control and provides its credentials. An agent shouldn't infer permission from a general request to investigate email settings.The website, API, and MCP connection tests use the submitted password only to run the test. The password is redacted before the request is saved, and credentials aren't stored.
How to verify it
A good result confirms connection, encryption, and authentication, not just an open socket. A timeout or refusal points to reachability; a handshake error points to the mode or TLS configuration; a rejection after TLS points to the account or authorization method.
The final check should repeat the intended production hostname and security pair. If the diagnostic passes but the application still fails, compare the application's actual configuration and local network path rather than changing the working server endpoint.
IMAP Port Questions and the Check to Run
Is 993 always better than 143?
Choose the port and encryption mode listed for your provider and mail client. If you are configuring a new connection, compare the provider's setup instructions with the client's available security options.
Should I use an app password or OAuth?
Use the sign-in method your provider supports for the specific mailbox and application. An app password may be required when the app cannot use OAuth and the provider allows app passwords. If the account requires OAuth, use that authorization method instead of repeating password-based login attempts.
What should an AI agent call?
An agent can use
imap_finder to look up the host, encrypted port options, and provider setup guide without credentials. It should call imap_check only when the user explicitly asks to test an IMAP login for a mailbox they control and provides the credentials. The user should confirm before the login test.mailX provides free IMAP diagnostics with no signup, separating connection, encryption, and authentication results so an administrator can identify the layer that failed. Visit mailX to run the IMAP check, or use its MCP access from ChatGPT, Claude, or Cursor when an authorized AI agent is handling the investigation.