Email port issues usually look like broken mail, but they are often configuration mismatches. SMTP, IMAP, and POP3 all use different ports because they solve different jobs:

- SMTP submits and relays outbound email.
- IMAP reads and synchronizes mailbox state on the server.
- POP3 downloads messages from a mailbox to a client.

Use this guide to choose secure defaults, understand where MailSlurp ports fit, and test the full send-and-receive workflow instead of checking a socket in isolation.

## Quick answer

For most modern setups:

- use SMTP submission on `587` with STARTTLS when the provider supports it
- use SMTP implicit TLS on `465` when the provider documents that mode
- use IMAP over TLS on `993` for synchronized mailbox access
- use POP3 over TLS on `995` only when a download-first workflow is required

MailSlurp also exposes mailbox-compatible SMTP and IMAP access for supported inbox workflows, while the MailSlurp API remains the most deterministic option for automated tests.

## MailSlurp SMTP and IMAP ports

The following ports and hosts are available for [MailSlurp](/api/) [SMTP inboxes](/guides/smtp-vs-http-email-inboxes/) and mailbox-compatible access.

| Protocol | Encryption | Port | Host             |
| -------- | ---------- | ---- | ---------------- |
| SMTP     | None       | 25   | mx.mailslurp.com |
| SMTP     | None       | 2525 | mx.mailslurp.com |
| IMAP     | None       | 1143 | mailslurp.click  |
| SMTP     | TLS        | 587  | mailslurp.mx     |
| SMTP     | TLS        | 2587 | mailslurp.mx     |
| SMTP     | TLS        | 465  | mailslurp.mx     |
| SMTP     | TLS        | 2465 | mailslurp.mx     |

## Common email ports

| Protocol | Port   | Security model                       | Common use                                              |
| -------- | ------ | ------------------------------------ | ------------------------------------------------------- |
| SMTP     | `25`   | server-to-server or restricted relay | mail transfer, not normal app submission                |
| SMTP     | `587`  | STARTTLS                             | recommended app submission default                      |
| SMTP     | `465`  | implicit TLS                         | supported by many providers for secure submission       |
| SMTP     | `2525` | provider-specific fallback           | fallback when `587` is blocked and provider supports it |
| IMAP     | `143`  | plain or STARTTLS                    | legacy or explicit TLS upgrade access                   |
| IMAP     | `993`  | implicit TLS                         | secure IMAP mailbox access                              |
| POP3     | `110`  | plain or STARTTLS                    | legacy POP3 access                                      |
| POP3     | `995`  | implicit TLS                         | secure POP3 mailbox access                              |

## How to test port configuration

Port checks should answer three questions:

1. Can the client reach the host and port?
2. Does the server expect plain, STARTTLS, or implicit TLS?
3. Does a real message arrive and expose the expected headers and body?

Use [SMTP tester](/tools/smtp-tester/) for transport diagnostics, then capture the resulting message in [Email Sandbox](/product/email-sandbox/) or assert it with [Email integration testing](/product/email-integration-testing/). When sender identity matters, inspect the received copy with the [Email header analyzer](/tools/email-header-analyzer/).

## SMTP port testing workflow

1. Confirm whether the provider expects `587` with STARTTLS or `465` with implicit TLS.
2. Send a controlled test message through the application or SMTP client.
3. Capture the message in a MailSlurp inbox.
4. Check `From`, `Return-Path`, `Received`, and `Authentication-Results` headers.
5. Assert the subject, body, links, OTP codes, and attachments in CI.

If the SMTP server accepts the message but the inbox never receives it, keep the SMTP transcript, message ID, and received-message search evidence together. That keeps debugging focused on relay, DNS, authentication, content, or recipient policy instead of guessing.

## IMAP and POP3 port testing workflow

For IMAP:

- connect on the expected host and port
- verify folders, flags, and read state sync across clients
- confirm the message remains available on the server
- check the same message through MailSlurp API when test determinism matters

For POP3:

- connect on the expected host and port
- verify messages download in the expected order
- confirm whether the client deletes or leaves messages on the server
- avoid using POP3 as the main test fixture for parallel CI runs unless the workflow is intentionally download-first

Use [IMAP vs POP3](/guides/imap-vs-pop3-smtp/) when the team is deciding between synchronized mailbox access and local download behavior.

## Common mistakes

### Using SMTP settings for IMAP or POP3

SMTP sends mail. IMAP and POP3 retrieve mail. A correct SMTP host does not prove incoming mailbox access is configured correctly.

### Mixing STARTTLS and implicit TLS

Port `587` usually starts plain and upgrades with STARTTLS. Port `465` usually expects TLS immediately. Swapping those modes is a common reason a client cannot connect.

### Treating port reachability as delivery proof

A successful connection is not the same as a completed email workflow. For release checks, prove the received message, headers, links, and events.

## Related pages

- [IMAP vs POP3](/guides/imap-vs-pop3-smtp/)
- [SMTP and IMAP guide](/guides/smtp-imap/)
- [SMTP tester](/tools/smtp-tester/)
- [Email Sandbox](/product/email-sandbox/)
- [Email integration testing](/product/email-integration-testing/)