All About 25, 465, 587, 143, 993, 110 & 995 in One Table

All Seven Email Ports at a Glance: 25, 465, 587, 143, 993, 110, and 995

These seven ports are not competing trivia. They divide one mail workflow into different ports for relay, message submission, and mailbox access, which is why all about port 25 465 587 143 993 110 and 995 becomes easier to read once each number is tied to a job. The table below turns port 25 and the rest of the different ports into one reference map by protocol family, traffic direction, encryption posture, and practical current status.

What Each Email Port Handles: Protocol, Direction, Encryption, and Current Status

The useful distinction is functional, not numerical: an email port tells whether traffic is for SMTP sending, IMAP access, or POP3 retrieval, and whether security starts immediately or upgrades after connection. In the table, Direction means the port's main role in submission, relay, or receiving, and access. Encryption model means implicit TLS from the first packet or a plain-start session that can upgrade with STARTTLS or STLS.

That status map matters because the same protocol can split across modern defaults, alternatives, and compatibility paths. The next step is to stop reading these as isolated port number entries and group them by protocol role instead.

Which Protocol Uses Which Default Port for Sending and Receiving

The first real split is not between seven port numbers. It is between sending and receiving. In computer networking, SMTP handles outbound mail movement, while IMAP and POP3 handle mailbox access after delivery. That is why a default port only makes sense inside a protocol family, and why different ports can serve one protocol without meaning the same thing. A standard port marks the job first, then the connection style attached to that job.

SMTP Ports 25, 465, and 587: Relay, Submission, and Legacy Use

SMTP is the sending family, but the three SMTP port numbers do not describe the same path. Inside the simple mail transfer protocol, port 25 belongs to relay traffic between mail systems, while 587 and port 465 are submission choices for mail that begins with a user or application. Read that split correctly, and SMTP communication stops looking arbitrary. Misread it, and a relay path gets treated like a client path.

So the real distinction is not old versus new alone. It is relay versus submission. The simple mail transfer protocol uses port 25 when systems pass mail onward, but a user-facing SMTP port is usually about authenticated submission, which is why 587 and port 465 sit together conceptually even though their encryption models differ. That internal split is what later security guidance builds on.

IMAP Protocol: Ports 143 and 993 for Mail Access

IMAP is a receiving family built for mailbox access, not for sending. The internet message access protocol appears on two ports because the protocol job stays the same while the connection posture changes. In practice, 143 and 993 are not competing IMAP protocols. They are two entry points into the same mailbox-access model, which matters even more when mail is checked from multiple devices.

• Port 143: IMAP access that begins in a plain state and can upgrade later.
• Port 993: IMAP access that begins with encryption already in place.
• Shared Role: both ports serve the internet message access protocol and preserve mailbox access rather than one-time retrieval.

POP3 Ports 110 and 995: Legacy Retrieval vs Secure Retrieval

POP3 is narrower than IMAP. The post office protocol is about retrieval of email messages, not a synchronized mailbox view. That is why ports 110 and 995 look like a smaller fork: the protocol role stays fixed, and the main change is connection security. For a simple download model tied to only the sender and one endpoint, that distinction can be enough.

• Port 110: POP3 retrieval that begins without encryption already established.
• Port 995: POP3 retrieval with encryption in place from the start.
• Shared Role: both ports use the post office protocol to retrieve stored email messages rather than maintain ongoing mailbox access.

Email Security Across the Seven Ports: STARTTLS vs Implicit TLS

Email settings often fail not because the port number is wrong, but because the email security model behind it is. The core split is simple: STARTTLS means a connection begins in the clear and upgrades inside the session, while implicit TLS means the channel is protected from the first exchange. That timing decides how transport layer security appears on the wire, how much early network data is exposed before TLS encryption begins, and why otherwise correct settings still break when client and server expect different secure connections under different encryption protocol assumptions.

Why Port 587 and Port 143 Start Plain and Upgrade With STARTTLS

Port 587 and port 143 do not begin as encrypted channels, and that is the point rather than a defect. On these ports, the client connects first, learns that the server supports TLS encryption, and then sends a STARTTLS command to convert the session into a protected one. The protocol stays the same, but the security state changes midstream.

• On port 587, SMTP submission starts with ordinary SMTP commands, then shifts to encryption after the STARTTLS step.
• On port 143, IMAP follows the same plain-start upgrade pattern rather than assuming encryption from the first packet.
• A client configured for implicit TLS will fail here because it expects encryption immediately, while these ports expect negotiation first.
• A server that does not offer the upgrade when the client expects it creates the same mismatch in reverse.

Encrypted IMAP on Port 993 and Secure POP3 on Port 995

Port 993 and port 995 remove the upgrade step entirely. With encrypted IMAP on 993 and secure POP3 on 995, the TLS encrypted connection is expected from the moment the client connects, so mailbox access begins only after that protected channel is in place. That changes the opening terms of the session: the server does not begin with a plain conversation and then negotiate safety later. Port 995, in other words, is POP3's encrypted-from-connect counterpart to port 110, the plain-start retrieval alternative.

• Port 993 keeps IMAP mail access but requires encryption from the opening exchange.
• Port 995 does the same for POP3 retrieval, with no mid-session switch from plain-text to encrypted traffic.
• Because encryption is immediate, a client set to STARTTLS instead of implicit TLS can fail even when the hostname and protocol family are otherwise correct.

Why Port 465 Still Uses Implicit TLS for SMTP Submission

Port 465 completes the map by putting SMTP submission on the implicit TLS side rather than the STARTTLS side. The connection is expected to arrive encrypted from the first packet, which makes port 465 behave more like 993 or 995 than like 587, even though both 465 and 587 are used for submission. Older secure sockets layer SSL language still shadows this port, and SSL TLS labels can blur the distinction, but the operational point is straightforward: this is a dedicated port for submission that starts protected immediately. Once that behavior is clear, the next question is no longer how the connection begins, but which of these ports should be the default choice now.

The Modern Defaults: Which Ports to Use Now for SMTP, IMAP, and POP3

The baseline is tighter than the seven-port list suggests: for sending, prefer port 465 where the provider offers implicit TLS submission; use port 587 when the client or provider expects STARTTLS.

⚠︎ Current-first recommendation set:

Port 25 still matters, but for relay between mail servers, not normal client or app submission..

There is no single universal SMTP answer: 465 is preferred where implicit TLS is offered, while 587 remains the common submission setting in STARTTLS-oriented environments.

For receiving, use 993 for IMAP and 995 for POP3; treat 143 and 110 as exceptions, not defaults.

The Default SMTP Port for Modern Sending Is 587

In environments built around STARTTLS, port 587 remains the common practical answer for outgoing mail because it separates user and app submission from server relay. RFC 6409 defines it as the message submission port, and that institutional split matters: it keeps normal sending tied to SMTP authentication instead of treating every sending client like a mail server.

That recommendation still needs context. Port 587 is not the only secure choice, and it is not the best fit in every environment, but it is still the SMTP submission port many providers document for clients and apps because STARTTLS plus SMTP authentication is broadly supported.

• Use port 587 when the provider documents it as the default SMTP port for client or application setup.
• Choose it when the expected flow is SMTP submission with STARTTLS rather than immediate implicit TLS.
• Treat it as the standard SMTP port only in the submission context, not as a universal answer for every SMTP port role.
• Expect SMTP auth, usually with an SMTP username, because secure email submission on 587 is built around authenticated sending rather than inherited trust.

Common SMTP Ports Compared: When 465 Still Makes Sense and When 25 Does Not

These three common SMTP ports do not belong in the same decision bucket. For modern submission, port 465 and port 587 are real choices with different security behavior, while port 25 belongs to a different class of work altogether: relay between servers, not ordinary authenticated client sending.

That table is the real boundary line across the most common SMTP ports. A secure SMTP port can mean 465 or 587 depending on what email service providers support, but the right SMTP port for a user or application is almost never port 25. The fallback is not the default, and relay is not submission.

For Receiving Mail, 993 Is the Modern Default and 995 Is the Secure POP3 Option

Receiving ports are not the hard part once the access model is clear. Use 993 when the mailbox is accessed over IMAP, because it keeps secure mailbox synchronization on implicit TLS. Use 995 when POP3 is still required and the job is secure retrieval rather than synchronized mailbox state across sessions.

• Choose 993 for IMAP as the modern default for secure mailbox access.
• Choose 995 as the secure POP3 option when POP3 is still the required retrieval model.
• Treat 143 and 110 as legacy plain-start alternatives, not as first-choice modern defaults.

Once that baseline is settled, the older ports stop looking like equal choices and start looking like exceptions that need a reason.

Which Legacy or Alternative Ports Still Deserve a Place

Old ports persist because infrastructure remembers longer than best practice does. The Internet Engineering Task Force can clarify current practice, and the Internet Assigned Numbers Authority can preserve registration history, but neither turns familiarity into a sane default. Legacy visibility earns a place only when it serves a live role: relay, temporary compatibility, or a tightly scoped migration window.

• Keep an older port only when the modern default still cannot cover a specific job.
• Treat inherited settings as inertia, not proof that the old path deserves baseline status.
• Reduce plain-start access ports over time, or compatibility quietly hardens into policy.

Port 25: Still Needed for Server-to-Server Relay, Rarely for Client Submission

Port 25 survives for infrastructure, not convenience. The SMTP port still matters when a mail transfer agent passes mail to another system, because that traffic is SMTP relay rather than ordinary user sending. In that role, port 25 remains a message relay port on an SMTP relay server, which is why the original SMTP port still keeps its narrow place.

What it should not keep is cultural authority. Once users or applications are submitting mail, treating port 25 as normal blurs a clean role boundary and keeps old habits in charge. Move that traffic to authenticated submission on 465 or 587.

• Legitimate Use: server-to-server transfer handled by a mail transfer agent or comparable relay function.
• Discouraged Use: end-user devices or applications treating port 25 as the default submission channel.
• Practical Correction: move remaining client submission off port 25 and onto authenticated submission on 465 or 587.

Ports 110 and 143: Why Unencrypted Retrieval Ports Still Exist

Ports 110 and 143 persist mostly because migrations move slower than best practice. Older clients, inherited mailbox settings, and devices that were never rebuilt can keep these access paths visible even after 993 and 995 became the cleaner modern choices. That legacy visibility reflects compatibility debt, not equal standing. Their remaining role is transitional: a compatibility-driven alternative that may still need to exist for a time, but one that should steadily give way to implicit TLS access.

How Legacy Clients and Blocked Networks Change the Alternative Port Decision

Workarounds are where exception logic most easily turns into policy drift. An alternative port may be justified, but only when it is tied to a named constraint, a narrow owner, and an exit plan.

A legacy client cannot do implicit TLS

Keep the needed alternative port temporarily.

Restrict who or what can reach it.

Plan replacement before the exception becomes normal.

A network or provider blocks the preferred path

Use an alternate port only as a controlled exception.

Port 2525 belongs to workaround territory, not a new default.

Document why the path exists and review whether the constraint still applies.

A managed or embedded device has fixed settings

Isolate the exception to that device or segment.

Keep the scope narrow so one fragile dependency does not widen exposure policy.

Migrate when firmware or vendor support finally allows it.

The next operational question is the one that matters: which ports the server and firewall should expose by default, and which they should open only by explicit exception.

Which Ports to Open on an Email Server and Firewall

Opening ports on an email server is a control decision, not routine housekeeping. The practical question for network administrators is narrower: which services does the SMTP server actually need to expose, and to whom? A modern baseline is usually smaller than legacy checklists suggest. Each familiar port left open by habit becomes another public promise to defend.

• ✓Open only the ports tied to an active service role.
• ✓Keep 110 and 143 outside the baseline unless a documented legacy need still exists.
• ✓Treat 25 as a relay decision, not a client-compatibility shortcut.
• ✓Match each opening to a distinct firewall scope for relay, submission, or mailbox access.

Minimum Open Ports for a Modern Email Server

Most teams running their own mail servers need fewer exposed services than old setup lists imply. The minimum open ports for a modern email server should follow the role, not habit: relay only where server-to-server delivery is required, use submission only where authenticated users or applications need it, and provide mailbox access only for the protocols you actually offer. Remove the rest. In practice, ports typically stay open only where they map to an active service.

• ✓Open TCP 25 for the inbound MX or server-relay role only on the host that must receive Internet mail.
• ✓Permit outbound TCP 25 only from authorized internal MTAs or mail gateways, not from every host.
• ✓Open 465 or 587 only if the service provides authenticated client or application submission.
• ✓Open 993 if the service provides IMAP access.
• ✓Open 995 only if secure POP3 is actually offered.
• ✓Keep 110 and 143 closed in the baseline, and require TLS-capable service where submission or mailbox access is exposed.

Which Extra Ports to Open Only for POP3 Support or Legacy Compatibility

Compatibility has a way of turning exceptions into infrastructure. Extra openings should be named, documented, and temporary, especially when they preserve older access patterns rather than a current baseline. The point is containment: allow only the legacy path that still has a real user population, limit its scope, and plan to retire it.

• Port 110 is a compatibility-only exception for legacy POP3 clients that cannot move yet. Restrict it tightly and put it on a retirement path.
• Port 143 is a compatibility-only exception for legacy IMAP clients that still depend on plain-start or STARTTLS access. Restrict it tightly and plan retirement.
• Port 995 belongs only where POP3 is still an intentional service, not as a default add-on.
• Port 465 and port 587 may both appear during a submission transition, but some environments expose only one of them by design.
• Port 25 does not belong in the client-compatibility bucket. Keep it for relay roles, not as a normal submission fallback.

When Inbound Relay, Submission, and Client Access Need Different Firewall Rules

A single blanket rule for mail traffic makes the system less legible than it looks. Relay, submission, and mailbox access serve different peers, carry different trust assumptions, and should not inherit the same exposure policy by accident. In practice, that means port 25 may need Internet-facing delivery on designated gateway hosts, while submission and mailbox access can be limited to the users, applications, networks, or policies that actually need them. Separate trust boundaries keep a necessary public interface from expanding into a convenience opening for everything else.

Why the Right Port Still Fails in Practice

Correct choices still fail when the network, the security mode, or the software is enforcing a different rule. Sort the problem first: outbound port 25 blocking, a security-mode mismatch, or a legacy client limitation.

Condition: Port 25 fails while 587 or 465 still connects.

Outcome: Suspect upstream blocking before bad credentials.

Action: Check provider policy, then move to 587, to 465 where supported, or to a relay service.

Condition: The same hostname behaves differently across common mail ports.

Outcome: The likely problem is a security-mode mismatch.

Action: Match the port and encryption mode before retrying credentials.

Condition: Only one older application fails while newer clients work.

Outcome: Treat it as a compatibility case, not a new standard.

Action: Allow a controlled legacy accommodation with a migration target.

When ISPs or Cloud Providers Block Outbound Port 25

Outbound port 25 is often blocked by policy, not broken by configuration. Many internet service providers and cloud providers do this to limit abuse, though the pattern varies by environment. If port 25 fails while 587 or 465 works, suspect the upstream network first.

Scenario: A host on Google Cloud cannot send externally on port 25.

Scenario Context: Google Cloud allows 465 or 587 for submission while blocking external egress to TCP 25.

Scenario Implication: The failure points to provider policy, not necessarily to broken SMTP authentication or a dead server.

Scenario Action: Move first to authenticated submission on 587, then to 465 where supported.

Scenario: A VM on AWS or in many Azure cases cannot deliver mail directly on port 25.

Scenario Context: Cloud hosting providers often restrict outbound SMTP on 25 even when the server is configured correctly.

Scenario Implication: Direct relay theory stops at the platform boundary.

Scenario Action: If 587 or 465 is unavailable, route mail through a managed relay path.

Scenario: A residential connection from many internet service providers will not transmit mail on port 25.

Scenario Context: Some internet service providers block direct SMTP transmission on 25 for anti-abuse reasons.

Scenario Implication: Local settings can look correct while the connection still fails upstream.

Scenario Action: Use 587 first, use 465 where supported, or move mail through a third party SMTP service.

The pattern matters more than any single platform. Some cloud hosting providers and residential networks restrict more than just port 25, so the safe order is still 587 first, then 465 where supported, then a third party SMTP service or other managed relay path.

When STARTTLS Fails Because the Client and Server Expect Different Security Modes

A failed login is often a mode mismatch in disguise. If the same hostname works on one port number but fails on another, check the security mode before blaming the server or the password.

Condition: The service is set to 587 or 143.

Outcome: The client should use STARTTLS, not implicit SSL/TLS from connect.

Action: Review the SMTP settings and switch to upgrade-based encryption.

Condition: The service is set to 465, 993, or 995.

Outcome: The client should use SSL/TLS from connect, not STARTTLS after the session begins.

Action: Match the security mode to the port number before testing credentials again.

Condition: The same account succeeds under one mode and fails under another.

Outcome: Treat the problem as a security-mode mismatch first.

Explanation: The port and encryption model have to agree before authentication can work.

Match the port and mode first, then retry.

When Older Mail Clients Still Push You Toward 110, 143, or 465

An old client can turn a settled standard into a support exception. If a mail client fails while newer tools connect normally, pressure to use 110, 143, or 465 should stay a controlled legacy accommodation, not a new default.

Scenario: Microsoft Outlook or Apple Mail on an older setup only supports older connection assumptions.

Scenario Context: The account may work only with 110, 143, or 465-era settings even though better defaults exist elsewhere.

Scenario Implication: The failure is about compatibility pressure, not a change in the recommended standard.

Scenario Action: Allow a temporary exception while narrowing who can use it and how long it remains in place.

Scenario: A legacy mail client must stay in service for a short migration period.

Scenario Context: The need is continuity, not proof that the older port remains preferable.

Scenario Implication: Limit the exception with source restrictions, a VPN or tunnel, or a short migration window.

Scenario Action: Document the replacement target so the temporary path does not become permanent.

Verify provider policy first, verify security mode second, and justify any legacy exception explicitly.