SMTP Explained: What It Is, How It Works, Ports, and Setup

SMTP is the protocol every email on the internet travels over. It has been around since 1982 in roughly its current form, which makes it one of the oldest pieces of internet infrastructure still in daily use. Understand SMTP and most of email's strange edge cases stop being mysterious.

The harder lesson, especially for anyone using SMTP for cold outreach: knowing how SMTP works does not mean SMTP relays are the right tool for every job. They are not. The right answer for cold email is dedicated provider inboxes, not a different SMTP server. Here is the protocol explained, the ports demystified, and the practical guidance on when to use SMTP and when to use something else.

What SMTP Actually Is

SMTP stands for Simple Mail Transfer Protocol. It is the set of rules two computers follow when one wants to hand off email to the other. The "simple" part of the name was earnest in 1982 and is mostly accurate today. The core protocol is straightforward enough that you can read an SMTP transaction with the naked eye and understand what is happening.

An SMTP transaction looks like a structured conversation:

S: 220 mail.example.com ESMTP ready
C: EHLO sender.com
S: 250-mail.example.com Hello sender.com
S: 250-AUTH LOGIN PLAIN
S: 250 STARTTLS
C: STARTTLS
S: 220 Ready to start TLS
C: EHLO sender.com
S: 250-mail.example.com Hello sender.com
C: AUTH LOGIN
S: 334 VXNlcm5hbWU6
C: dXNlcm5hbWU=
S: 334 UGFzc3dvcmQ6
C: cGFzc3dvcmQ=
S: 235 Authentication successful
C: MAIL FROM:<sarah@sender.com>
S: 250 Sender OK
C: RCPT TO:<mike@example.com>
S: 250 Recipient OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Subject: Hello
C: From: sarah@sender.com
C: To: mike@example.com
C:
C: Hi Mike, this is the email body.
C: .
S: 250 Message accepted
C: QUIT
S: 221 Goodbye

The client (sending server) introduces itself with EHLO. The receiving server lists what it supports. They negotiate TLS for encryption. The client authenticates. They exchange the sender, recipient, and message. The server returns a status code (250 means accepted, 4xx means temporary failure, 5xx means permanent failure). The connection closes.

That is the entire protocol. Modern complications (DKIM signing, SPF checks, DMARC alignment, content filtering) sit on top of it but do not change the underlying conversation.

SMTP Ports: 25, 465, 587, and 2525

Email's port assignments are messy because they evolved over decades. Each port has a specific purpose and most "SMTP not working" problems trace back to using the wrong one.

• Port 25, the original SMTP port. Used for server-to-server mail relay. ISPs and cloud providers commonly block outbound port 25 from residential and shared infrastructure to prevent abuse. Do not use port 25 for sending mail from an application. Use 587.
• Port 465, implicit TLS (SMTPS). Encryption is established before any SMTP commands are sent. Originally deprecated, then re-standardized as SMTPS. Many providers support it for backward compatibility. Functional but not the modern default.
• Port 587, submission with STARTTLS. The modern standard for client-to-server mail submission (an application or email client sending mail to its provider). Authentication is required. Encryption is negotiated via STARTTLS. This is the port you should be using to send mail from any application.
• Port 2525, unofficial alternative to 587. Some hosts (Heroku, certain cloud providers) block 587 outbound. Many SMTP services offer 2525 as a fallback. Functionally identical to 587.

The short rule: use 587 with STARTTLS unless your provider tells you otherwise.

SMTP Authentication: How Sending Servers Prove Identity

An open SMTP relay (one that lets anyone send mail through it) is a spam factory. Modern SMTP requires the client to authenticate before sending mail.

The common authentication mechanisms:

• AUTH LOGIN, username and password sent base64-encoded. Most common, must be paired with TLS.
• AUTH PLAIN, similar to LOGIN but slightly different framing. Also requires TLS.
• AUTH CRAM-MD5, challenge-response authentication. More secure when TLS is unavailable. Largely legacy now.
• OAuth 2.0 / XOAUTH2, token-based authentication. Used by Google Workspace and Microsoft 365 for application access. Replaces password auth for "less secure app" scenarios.

For most application-level SMTP setups in 2026, OAuth 2.0 is the secure path for Workspace/M365 and SMTP AUTH LOGIN over TLS is the path for third-party SMTP services.

What SMTP Does Not Do

SMTP is just the transport layer. It does not solve any of the problems that determine whether email actually lands in the inbox:

• SMTP does not verify the sender's identity (SPF, DKIM, DMARC do that)
• SMTP does not assess message reputation (the receiving mail server does that)
• SMTP does not handle bounces (the receiving server returns codes; the sender has to interpret them)
• SMTP does not warm up sending domains (sending history builds reputation, the protocol just transports the mail)
• SMTP does not affect spam filtering (content, behavior, and reputation determine that)

This is the part that catches teams using "SMTP" as shorthand for "email sending solved." A working SMTP connection means the protocol can deliver the message. Whether the message lands in the inbox depends on a dozen factors above the protocol layer.

SMTP Server Setup: The Common Configurations

Three setups cover most real-world SMTP needs:

1. SMTP through your provider's mail server (Workspace, M365, ISP). Use the provider's SMTP host (smtp.gmail.com:587, smtp.office365.com:587), authenticate with your account credentials or OAuth token. Send rate-limited per account (Workspace: 2,000/day for paid, lower for free; M365: 10,000/day for licensed). Right answer for transactional sending from small applications and personal use.

2. SMTP through a dedicated transactional service. Postmark, Mailgun, AWS SES, SendGrid all expose SMTP endpoints. Better deliverability than self-hosting, built-in suppression list management, transparent reputation reporting. Right answer for application transactional email at any meaningful volume.

3. Self-hosted SMTP server. Postfix, Exim, or OpenSMTPD on your own infrastructure. Full control, lowest per-email cost, highest operational overhead. You handle authentication, DKIM signing, bounce processing, IP warmup, blocklist monitoring, abuse handling. Right answer for very high volume or specific compliance requirements; wrong answer for almost everyone else.

The thing missing from this list: SMTP for cold email outreach.

Why SMTP Is the Wrong Tool for Cold Email

Cold outreach has different deliverability dynamics than transactional or marketing email. Recipients did not opt in. Engagement is lower by definition. Spam complaint rates are higher. The signals receiving servers profile look more like spam, even when the email is legitimate B2B prospecting.

SMTP relays, including the major transactional ESPs, perform poorly on cold email for specific reasons:

• Receiving servers profile the source. Mail from established Google Workspace or Microsoft 365 inboxes is treated more favorably than mail from generic SMTP infrastructure. The trust differential is built into Gmail's and Microsoft's spam filtering.
• Shared IPs work against cold senders. Most SMTP services share IPs across thousands of customers. One bad actor's complaints damage the IP reputation, and you inherit the consequences.
• ESP terms of service prohibit cold sending. SendGrid, Mailgun, Postmark all prohibit non-opted-in sending. Accounts caught running cold campaigns get throttled or terminated.
• Authentication is not enough. Even with perfect SPF/DKIM/DMARC, an SMTP relay sends from infrastructure that receiving servers know is built for bulk. Cold mail from there underperforms compared to the same mail from a real provider inbox.

The right setup for cold email is multiple secondary sending domains, real Google Workspace or Microsoft 365 inboxes (not SMTP relays), and authentication configured correctly, with proper warmup run from the sequencer before any campaign starts. This is the cold email infrastructure stack, a different category from SMTP entirely. The sequencer (Instantly, Smartlead, Apollo) connects to those provider inboxes via SMTP/IMAP or API and runs the campaigns. The infrastructure underneath determines deliverability.

Reading SMTP Error Codes

SMTP responses follow a three-digit code format. The first digit signals the category:

• 2xx, success. The most common is 250 ("Requested mail action okay, completed").
• 3xx, intermediate. The server needs more information to continue (e.g., 354 "Start mail input").
• 4xx, temporary failure. Retry later. Common: 421 (service not available), 450 (mailbox unavailable, try later), 451 (local error).
• 5xx, permanent failure. Do not retry. Common: 550 (mailbox does not exist), 553 (rejected for policy reasons), 554 (transaction failed, often spam).

The full list of codes runs over 30 entries and most are rarely seen. The ones worth knowing for deliverability work: 421 (rate limited), 450/451 (try later), 550 (recipient does not exist or rejected), 552 (mail too large), 554 (refused, often content or reputation). For comprehensive coverage, see the email error codes guide.

The Practical Summary

SMTP is the protocol email travels over. Port 587 with STARTTLS is the modern default. Authentication is required, OAuth 2.0 for Workspace/M365 and AUTH LOGIN over TLS for everything else.

The choice that matters more than the SMTP setup itself is the choice of what is sending the mail:

• Transactional email (low volume): SMTP through Workspace, M365, or your ISP works fine
• Transactional email (production app): SMTP through a dedicated transactional ESP. Postmark, Mailgun, AWS SES
• Marketing email: SMTP through a marketing ESP. Mailchimp, Klaviyo, Customer.io
• Cold outreach: Not SMTP relays at all. Real Workspace or M365 inboxes on secondary sending domains, with proper warmup and authentication, connected to a sequencer for campaign management

SMTP is fine. SMTP relays for the wrong job are not. The teams that struggle with cold email deliverability while running through SMTP services are running into a category problem, not a protocol problem.

At ScaledMail, we provision and manage the infrastructure layer end to end: secondary sending domains, real Google Workspace and Microsoft 365 inboxes, SPF/DKIM/DMARC configured correctly on every domain, IP rotation, continuous monitoring of domain reputation and IP reputation. The sequencer of your choice (Instantly, Smartlead, Apollo) connects via SMTP/IMAP, runs the campaigns, and handles warmup. The infrastructure layer is what makes the difference between cold email that lands and cold email that doesn't. Book a call or see the setup.