Quick email protocols reference
Email uses three protocols with different jobs: SMTP sends mail between servers, IMAP and POP3 fetch mail from a server to a client. Ports, encryption, and authentication have all shifted in the last 3 years and legacy defaults are being sunset.
The port numbers below are near universal, but hostnames are not: some ISPs publish a single server name used for both submission and retrieval, and key it to the domain in your address rather than to the protocol. Spectrum does exactly this on its rr.com estate, which is why a protocol prefixed guess such as smtp.example.net fails there.
| Protocol | Job | Modern port | 2026 status |
|---|---|---|---|
| SMTP | Server-to-server relay, client submission | 587 (STARTTLS) or 465 (implicit TLS) | Standard. Basic auth being sunset in favor of OAuth2. |
| IMAP | Client reads mail from server (kept on server) | 993 (implicit TLS) | Standard. OAuth2 required on Gmail, M365, Yahoo. |
| POP3 | Client downloads and deletes from server | 995 (implicit TLS) | Deprecated. Gmail sunset for new accounts Jan 2025. Yahoo following. |
| Port 25 | Legacy SMTP relay | Blocked by most ISPs on residential connections | Server-to-server only, never for client submission. |
| Standards | RFC 5321 (SMTP), RFC 9051 (IMAP4rev2), RFC 1939 (POP3), RFC 6749 (OAuth2) | ||
How one message travels, port by port
A message does not take one connection, it takes three, and each hop uses a different port with different rules. Most failed mail client setups come from applying the rules of one hop to another: asking a client to submit on port 25, or expecting a retrieval port to send anything.
- Submission is the client handing its own outgoing message to its own provider, authenticated, on port 587 (STARTTLS) or 465 (implicit TLS). This hop is governed by RFC 6409, not by the plain SMTP relay rules.
- Relay is one server talking to another on port 25, with no user account involved. This is the only hop where port 25 is correct, and it is the hop a residential connection is not allowed to perform.
- Access is the recipient reading the message back with IMAP on port 993 or POP3 on port 995. Neither protocol can send anything, which is why every client asks for an incoming and an outgoing server separately.
What SMTP, IMAP, and POP3 actually do
The three email protocols split responsibilities cleanly. SMTP is transport: it moves mail from a sender’s client to the sender’s server, and from server to server across the internet until it reaches the recipient’s inbox server. IMAP and POP3 are access: they let a mail client (Apple Mail, Outlook, Thunderbird) fetch and manage mail already sitting on the inbox server.
- SMTP (Simple Mail Transfer Protocol) handles submission (client to server) and relay (server to server). Defined in RFC 5321 with submission-specific rules in RFC 6409.
- IMAP (Internet Message Access Protocol) keeps mail on the server and synchronizes state (read/unread, folders, flags) across multiple devices. Latest revision is RFC 9051 (IMAP4rev2, 2021).
- POP3 (Post Office Protocol) downloads mail to a single client and typically deletes from the server. Defined in RFC 1939, unchanged since 1996. Being sunset by major providers.
Port reference: 2026 canonical values
| Port | Protocol | Encryption | Purpose | Status |
|---|---|---|---|---|
| 25 | SMTP | Optional STARTTLS | Server-to-server relay | Standard for MTAs. Blocked by residential ISPs. |
| 465 | SMTP | Implicit TLS | Client submission with immediate TLS | Preferred for modern submission (RFC 8314). |
| 587 | SMTP | STARTTLS | Client submission with STARTTLS upgrade | Standard submission port. Still widely supported. |
| 110 | POP3 | Optional STARTTLS | Plaintext or STARTTLS POP3 | Deprecated. Use 995. |
| 995 | POP3 | Implicit TLS | Encrypted POP3 | Only acceptable POP3 port in 2026. Provider POP3 access itself being sunset. |
| 143 | IMAP | Optional STARTTLS | Plaintext or STARTTLS IMAP | Deprecated. Use 993. |
| 993 | IMAP | Implicit TLS | Encrypted IMAP | Standard. Widely supported. |
| 2525 | SMTP | STARTTLS | Alternative submission port | Used by ESPs (SendGrid, Mailgun) when 25/465/587 are blocked. |
Which guide to open next
This page is the map: one table, three protocols, the canonical port for each. The step-by-step configuration of each protocol, including provider quirks, error messages and the exact fields a client asks for, lives in its own guide.
| You want to | Open | Ports covered there |
|---|---|---|
| Send mail from a client or an app | SMTP setup guide | 587, 465, 25, 2525 |
| Read mail and keep it on the server | IMAP configuration | 993, 143 |
| Download mail to one machine | POP3 configuration | 995, 110 |
| Find the hostnames for one provider | Provider directory, 218 providers | all of the above, per provider |
| Route bulk or transactional mail through a relay | SMTP relay services | 587, 465, 2525 |
Port numbers are close to universal. Hostnames are not, and neither are the authentication rules: that is where the per-provider pages earn their keep.
STARTTLS vs implicit TLS: the difference
Two ways to encrypt: explicit (STARTTLS) or implicit.
- STARTTLS (explicit): the client connects in plaintext, issues a
STARTTLScommand, then upgrades the same TCP connection to TLS. Used on ports 587 (SMTP submission), 143 (IMAP), 110 (POP3). Risk: if an attacker strips the STARTTLS response, the connection stays plaintext. - Implicit TLS: the client connects with TLS from byte one, before any SMTP or IMAP command exchanges. Used on ports 465 (SMTP), 993 (IMAP), 995 (POP3). Safer against downgrade attacks.
RFC 8314 (2018) recommends implicit TLS on 465/993/995 for all new deployments and explicit STARTTLS on 587 for backward compatibility. In 2026, implicit TLS is the safer default.
Port 25 is for server-to-server relay only. Ports 110 and 143 without STARTTLS transmit credentials in plaintext. Any client documentation still recommending plaintext IMAP or POP3 in 2026 is a security bug.
POP3 sunset: what is happening
POP3 is being retired by major mailbox providers. The reasons: POP3 downloads and deletes mail from the server, which breaks multi-device sync. It has no built-in modern authentication (no OAuth2 support), which forces basic auth on providers who want to eliminate password-based access.
- Gmail: POP3 disabled by default for new accounts as of January 2025. Existing accounts can still enable it but Google now shows a deprecation warning.
- Yahoo: POP3 access sunset announced for 2026, no exact date confirmed.
- Microsoft 365: POP3 still supported but requires modern authentication (OAuth2) since October 2022. Basic auth POP3 is dead.
- Apple iCloud: POP3 disabled since 2023.
New client integrations should use IMAP, not POP3. If your product still recommends POP3 setup, plan migration.
OAuth2 requirements by provider
Basic authentication (username + app password) is being phased out. OAuth2 is required for API and IMAP/SMTP access on the major providers.
| Provider | Basic auth SMTP/IMAP | OAuth2 required? | Notes |
|---|---|---|---|
| Gmail (personal) | App passwords still work if 2FA enabled | Preferred for apps, mandatory for Workspace | Less secure app access removed in 2022. |
| Google Workspace | Blocked by default since 2024 | Mandatory | Admin can enable password app access but discouraged. |
| Microsoft 365 | Disabled since October 2022 | Mandatory | Basic auth exceptions expire on individual tenants. |
| Outlook.com (personal) | App passwords with 2FA | Preferred for apps | Similar to personal Gmail. |
| Yahoo Mail | App passwords with 2FA required | Optional | OAuth2 available via Yahoo Developer. |
| Apple iCloud | App-specific passwords with 2FA | Optional | No public OAuth2 for iCloud IMAP. |
| ProtonMail | Bridge password (Bridge app only) | N/A | Local IMAP/SMTP through the Bridge desktop app. |
App passwords are 16-character strings the user generates in provider settings, then pastes into your app for IMAP/SMTP login. They work everywhere but are a security compromise. OAuth2 uses browser-based consent, refreshable tokens, and per-scope permissions. If you build a product accessing user mail via IMAP or SMTP in 2026, ship OAuth2 for Gmail, Google Workspace, and Microsoft 365, and app passwords as fallback for other providers.
Common provider settings
Reference table for the top providers (always verify against provider documentation, values can change):
| Provider | SMTP server | SMTP port | IMAP server | IMAP port |
|---|---|---|---|---|
| Gmail | smtp.gmail.com | 465 (SSL) or 587 (TLS) | imap.gmail.com | 993 |
| Microsoft 365 | smtp.office365.com | 587 (STARTTLS) | outlook.office365.com | 993 |
| Outlook.com | smtp-mail.outlook.com | 587 (STARTTLS) | outlook.office365.com | 993 |
| Yahoo Mail | smtp.mail.yahoo.com | 465 (SSL) or 587 (TLS) | imap.mail.yahoo.com | 993 |
| iCloud Mail | smtp.mail.me.com | 587 (STARTTLS) | imap.mail.me.com | 993 |
For 218 more providers, see the SMTPedia provider settings directory.
Common configuration errors
- Using port 25 for client submission. ISPs block it. Use 587 (STARTTLS) or 465 (implicit TLS).
- Setting SSL/TLS to “None” or “Auto” in old clients. Force TLS explicitly. Some clients silently fall back to plaintext if TLS handshake fails.
- Trying to use POP3 for shared inboxes. POP3 downloads and deletes. Use IMAP.
- Using an outdated app password after enabling 2FA. App passwords must be regenerated after security changes.
- Configuring IMAP for a Gmail Workspace account without enabling IMAP in Workspace admin. Workspace admins can disable IMAP tenant-wide.
- Mismatching SMTP AUTH mechanism. Gmail requires PLAIN with TLS or OAuth2. Some clients default to LOGIN or CRAM-MD5 which Gmail rejects.
- Ignoring server certificate validation. Some legacy clients let you disable cert checking. This defeats TLS entirely.
- Using STARTTLS on a port that expects implicit TLS. On port 465, the client must open with TLS immediately, not send
STARTTLS.
The standards behind these numbers
Every port on this page is fixed by a document, not by convention, and the documents disagree less than vendor help pages do. When a provider’s instructions contradict the table above, the specification is the tiebreaker.
- RFC 5321 defines SMTP itself, including the relay behaviour that belongs on port 25.
- RFC 6409 separates message submission from relay, which is why 587 exists as its own port.
- RFC 8314 is the document that made implicit TLS on 465, 993 and 995 the recommended default and declared cleartext obsolete.
- RFC 9051 is the current IMAP revision, IMAP4rev2, replacing the 2003 text.
- RFC 1939 is POP3, unchanged since 1996, which is most of the story of its retirement.
- RFC 2595 added TLS to IMAP and POP3 and first argued against the plaintext ports.
- The full set, 68 standards with what each one actually changed, is in the email RFC directory.
A correct port with a correct certificate still leaves room for the server to refuse the message on its own terms. When the connection succeeds and the transaction fails, the reply code is the next thing to read: the SMTP error code reference maps the 4xx and 5xx families to what to do about them. And when outbound port 25 is the blocker rather than a setting, the constraint is the network, not the client: hosts that leave port 25 open are a small and specific list.
Email protocols FAQ
Should I use POP3 or IMAP in 2026?
IMAP for anything modern. POP3 is being sunset by Gmail and Yahoo. IMAP keeps mail on the server and syncs across devices, which matches how people use mail today.
What is the difference between port 465 and port 587?
Both are for SMTP client submission with TLS. Port 465 uses implicit TLS (encryption starts immediately). Port 587 uses STARTTLS (connection starts plaintext, then upgrades). In 2026, RFC 8314 recommends port 465 for new deployments because implicit TLS is more resistant to downgrade attacks.
Why is port 25 blocked on my home internet?
Residential ISPs block outbound port 25 to prevent malware and spam. Use your ISP’s or provider’s submission port (587 or 465) with authentication instead.
Do I need OAuth2 to send mail through Gmail SMTP?
For a personal Gmail account with 2FA, an app password on port 587 or 465 still works. For Google Workspace, admins increasingly require OAuth2 and disable basic auth. For any commercial product accessing user mail, ship OAuth2.
What replaces POP3 after sunset?
IMAP4rev2 (RFC 9051). It offers the same fetch-mail-to-client behavior with server-side sync, folder support, and OAuth2 authentication. Migrate POP3 configurations to IMAP with the same credentials (or OAuth2 tokens).
Is STARTTLS still safe?
Yes, if implemented correctly. Modern MTAs and clients treat STARTTLS as mandatory (they refuse to fall back to plaintext if the server offers STARTTLS). The historical concern was downgrade attacks where an attacker stripped STARTTLS from the server response; RFC 8314 addresses this with MTA-STS and DANE for MTA-to-MTA and implicit TLS for client submission.
What is port 2525?
An alternative SMTP submission port used by some ESPs (SendGrid, Mailgun) when ports 25, 465, or 587 are blocked by the client’s network. Not standardized, no RFC. Works but is a fallback, not a default.
Final words
Three protocols, three jobs. SMTP moves mail, IMAP reads it from the server, POP3 downloads and deletes. In 2026 the shift is clear: POP3 is dying, OAuth2 is mandatory for Gmail Workspace and Microsoft 365, implicit TLS on 465/993/995 is the new default, and plaintext ports 25/110/143 have no place in modern client configuration.
If you build a product that accesses user mail: ship IMAP not POP3, ship OAuth2 for the top three providers, and ship implicit TLS as the default connection mode. If you configure your own mail client: port 587 or 465 for sending, port 993 for reading, TLS always, credentials never in plaintext.
Verify addresses before you send.
SMTPing catches disposables, role addresses, catch-alls, syntax errors, dead mailboxes and known spam traps. 13 validation types, 25 free checks daily, no card required.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
