SMTP (Simple Mail Transfer Protocol) is the foundational text-based, client-server, push-only protocol for transferring email between systems. Defined in RFC 5321 (October 2008), it specifies a strict command sequence — TCP connection, server greeting, EHLO, optional STARTTLS upgrade, optional AUTH, MAIL FROM, RCPT TO, DATA, QUIT — with three-digit numeric response codes. Modern ESMTP layers extensions (8BITMIME, PIPELINING, SIZE, AUTH, STARTTLS) on top of the base protocol. SMTP is the wire over which all the authentication standards (SPF, DKIM, DMARC, MTA-STS, DANE, TLS-RPT) operate; understanding it clarifies how every other email infrastructure concept fits together.
SMTP is the protocol nearly every email infrastructure entry in this glossary depends on. SPF validates the envelope sender SMTP exposes in MAIL FROM. DKIM signs message headers added before SMTP transmits DATA. DMARC aligns SMTP-level identifiers with header identifiers. MTA-STS enforces TLS on SMTP connections. DANE validates the certificate SMTP presents at STARTTLS. TLS-RPT reports back about SMTP TLS results. Spamhaus queries happen at SMTP connection time before EHLO. MTAs are the software implementing SMTP. PowerMTA is one specific MTA implementation. Every node in the cluster connects through SMTP — this entry maps the protocol itself.
Most published SMTP material falls into two camps: dense RFC documentation aimed at protocol implementers, or marketing-grade summaries that gloss over the operational details. This entry is written for operators who need to debug a real SMTP transaction at 3 AM — what each command does, what each response code means, why the four ports exist, what extensions matter, where the security pitfalls are, and how SMTP connects to every other piece of the email puzzle.
Historical context: 44 years of SMTP
SMTP's design predates HTTPS, predates Linux, predates the World Wide Web. Understanding the historical layers explains why the protocol looks the way it does — and why some of its security weaknesses persist:
SMTP transaction anatomy: full client/server exchange
The fundamental SMTP transaction has remained essentially unchanged since 1982. Here's a complete real exchange between a sending client and a receiving server delivering a message — annotated with what each line does:
# TCP connection established to port 25, server speaks first 220 mx.example.com ESMTP Postfix (Ubuntu) ; server greeting, ready EHLO sender.example.org ; client identifies (modern: EHLO not HELO) 250-mx.example.com ; multi-line response begins 250-PIPELINING ; supports command pipelining 250-SIZE 52428800 ; max message size: 50MB 250-VRFY ; (typically disabled in production) 250-ETRN 250-STARTTLS ; supports TLS upgrade 250-ENHANCEDSTATUSCODES ; supports 3-part X.X.X codes 250-8BITMIME ; supports 8-bit message bodies 250-DSN ; supports delivery status notifications 250 SMTPUTF8 ; supports international addresses STARTTLS ; upgrade to TLS (port 25 case) 220 2.0.0 Ready to start TLS # --- TLS handshake happens here; subsequent traffic is encrypted --- EHLO sender.example.org ; re-issue EHLO inside TLS 250-mx.example.com 250-PIPELINING 250-SIZE 52428800 250 ENHANCEDSTATUSCODES MAIL FROM:<sender@example.org> ; envelope sender (used by SPF) 250 2.1.0 Ok RCPT TO:<recipient@example.com> ; envelope recipient 250 2.1.5 Ok RCPT TO:<another@example.com> ; can repeat for multiple recipients 250 2.1.5 Ok DATA ; begin message body transfer 354 End data with <CR><LF>.<CR><LF> ; server ready, terminate with . From: "Sender Name" <sender@example.org> ; HEADER From: (used by DMARC) To: recipient@example.com Subject: Hello Date: Wed, 7 May 2026 14:00:00 +0000 Message-ID: <abc123@sender.example.org> DKIM-Signature: v=1; a=rsa-sha256; d=example.org; ... ; signed pre-DATA Body of the message goes here. . ; lone period terminates DATA 250 2.0.0 Ok: queued as 8BC1F2342 ; message accepted, has queue ID QUIT 221 2.0.0 Bye # TCP connection closes
example.org above), queries DNS for that domain's SPF record, and checks whether the sender's IP is authorized. DKIM validation happens after DATA — the server reads the DKIM-Signature header, validates the cryptographic signature, and notes the d= signature domain. DMARC alignment compares the From: header domain (the displayed sender) against the SPF-authenticated MAIL FROM domain or the DKIM d= domain. If neither aligns with the From: header, DMARC fails. This is why the envelope-vs-headers distinction (covered next) is foundational.
Envelope vs headers: the distinction that breaks DMARC
The single most consequential SMTP concept for production deliverability is the distinction between the SMTP envelope (exchanged in MAIL FROM and RCPT TO commands) and the message headers (transmitted inside DATA). They serve different purposes, can deliberately differ, and they're conflated in nearly every introductory SMTP guide.
Envelope
- MAIL FROM: the envelope sender — where bounces go (also called Return-Path, RFC5321.From, "envelope from"). Used by SPF.
- RCPT TO: the envelope recipients — actual delivery addresses, can be multiple, may not appear in the visible message at all (Bcc).
- Determines actual delivery routing.
- Not displayed to the recipient by default.
- Often called
RFC5321.Fromin DMARC literature to distinguish from the header From:.
Headers
- From: the displayed sender — what the recipient sees in their email client. Used by DMARC alignment.
- To: the displayed recipients (NOT necessarily the actual delivery list — that's RCPT TO).
- Reply-To: if set, where replies go (overrides From: for replies).
- Displayed to the recipient.
- Often called
RFC5322.Fromin DMARC literature.
A bulk-email vendor commonly sends with envelope MAIL FROM: bounce-handler@vendor.com (so bounces flow to the vendor's bounce processor) but header From: marketing@yourcompany.com (so the recipient sees your brand). This is legitimate — but it means the SPF check (run on the envelope MAIL FROM domain vendor.com) is checking the vendor's SPF, not yours. For DMARC to pass, either SPF needs to align (envelope MAIL FROM vendor.com ≠ header From: yourcompany.com = misalignment, DMARC SPF fails) or DKIM needs to align (DKIM d= signature domain matches header From: domain). Most ESP-sent mail relies on DKIM alignment for DMARC, since SPF alignment is structurally hard with vendor-handled bounces.
SMTP commands: complete reference
The SMTP command vocabulary has remained small and stable across 44 years. The complete reference per RFC 5321 + ESMTP extensions:
| Command | Purpose | Required? | Notes |
|---|---|---|---|
HELO | Legacy client identification (pre-ESMTP) | Legacy | Modern clients use EHLO. HELO still accepted for compatibility. |
EHLO | ESMTP client identification, lists server capabilities | Required | The first real command after the 220 greeting. Server responds with multi-line 250. |
STARTTLS | Upgrade plaintext connection to TLS | Conditional | Only if server advertised STARTTLS in EHLO. After STARTTLS + handshake, re-issue EHLO. |
AUTH | SMTP authentication (PLAIN, LOGIN, CRAM-MD5, etc.) | Submission | Required on port 587/465 submission. Mechanisms advertised in EHLO 250-AUTH response. |
MAIL FROM:<addr> | Specifies envelope sender (Return-Path) | Required | The address SPF validates. Used as bounce-back destination. |
RCPT TO:<addr> | Specifies envelope recipient | Required | Repeatable for multiple recipients in one transaction. |
DATA | Begin message body transmission | Required | Server replies 354. Client sends headers + body, terminates with lone period. |
BDAT | Binary chunked message transfer (CHUNKING ext.) | Optional | Replaces DATA for chunked binary transfers. Performance benefit for large messages. |
RSET | Reset current transaction | Optional | Useful in pipelined sessions to abort one transaction without closing connection. |
VRFY | Verify a username | Usually disabled | Information leak — typically disabled in production. RFC 5321 §7.3 acknowledges risk. |
EXPN | Expand a mailing list | Usually disabled | Information leak — typically disabled. Reveals list members. |
NOOP | No operation (keep-alive) | Optional | Server replies 250. Useful for connection liveness checks. |
HELP | Server help text | Optional | Returns implementation-specific help. Often vague. |
QUIT | Close the SMTP session | Required | Server replies 221. Connection closes after this. |
SMTP response codes: 2yz/3yz/4yz/5yz
Every SMTP command receives a three-digit numeric response. The first digit categorizes the result and is the most important for operator decision-making:
The second digit details the category: x0z = syntax/general, x1z = informational, x2z = connection, x3z/x4z = unspecified, x5z = mail system. Operators don't usually parse the second digit — the first-digit category drives operational decisions.
250 2.1.0 Ok where 2.1.0 is the enhanced code. RFC 3463 grumbled about SMTP's "scars from history" caused by uncontrolled use of basic reply codes — the Enhanced system is the cleanup attempt. The class identifier (first digit) of the Enhanced code MUST match the first digit of the basic code it accompanies.
For a complete list of common error codes operators encounter, with diagnostic guidance per code, see our PowerMTA 452/550 bounce code analysis and 421 deferral codes for Gmail/Microsoft.
The four SMTP ports decoded
SMTP's port story is the most-asked operator question and the most poorly answered in published guides. The actual reality:
Original SMTP port (1982). Used for server-to-server relay between MTAs. Commonly blocked outbound by ISPs and cloud providers (AWS, Azure, GCP) for client traffic — preventing customer machines from sending direct-to-MX spam.
Implicit TLS submission — TLS handshake happens before any SMTP traffic. No plaintext window. Originally registered 1997 for SMTPS, briefly deprecated 1998, formally reinstated by RFC 8314 (2018).
STARTTLS submission — connection starts plaintext, upgrades to TLS via STARTTLS command. Defined by RFC 6409. Most universally supported port for client submission across all major ESPs.
Not registered with IANA, not in any RFC. Emerged as practical alternative when ISPs or firewalls block standard ports. Behaves like 587 — STARTTLS encryption, SMTP AUTH, same protocol on different port number.
ESMTP extensions reference
The EHLO response advertises which extensions the server supports. Modern operations rely on these extensions extensively — understanding what they enable shapes what's possible:
STARTTLS
Upgrade plaintext connection to TLS. Foundational for transport security. Vulnerability: STRIPTLS strip attack — mitigated by MTA-STS and DANE.
AUTH
SMTP authentication. Mechanisms include PLAIN, LOGIN, CRAM-MD5, DIGEST-MD5, GSSAPI, XOAUTH2. Required for submission ports.
SIZE
Server declares max message size in EHLO response. Clients can fail-fast before transmitting oversize messages. Common values: 10MB, 25MB, 50MB.
PIPELINING
Client sends multiple commands without waiting for individual responses. Significant performance win — collapses 5-10 round-trips into 1-2.
8BITMIME
Allows 8-bit message bodies. Essential for non-ASCII content (UTF-8 text). Without it, content must be Quoted-Printable or Base64 encoded.
SMTPUTF8
Internationalized email addresses with non-ASCII characters in local part or domain. Required for IDN domains and non-Latin-script local parts.
CHUNKING
BDAT command replaces DATA for chunked binary transfers. Performance benefit for very large messages. Less universally supported than DATA.
DSN
Delivery Status Notifications. Sender requests notifications for success/failure/delay events. Maps to bounce-handler infrastructure.
ENHANCEDSTATUSCODES
Server includes 3-part X.X.X enhanced status codes alongside basic 3-digit codes. Finer-grained error categorization for diagnostic purposes.
The STRIPTLS attack and how the cluster mitigates it
SMTP's STARTTLS implementation has a fundamental vulnerability: the announcement of TLS capability happens in plaintext, before encryption begins. A network-positioned attacker can strip the announcement, causing the connection to silently downgrade to plaintext. The attack flow:
STRIPTLS man-in-the-middle attack on port 25/587
connect mx.example.com:25220 mx.example.com ESMTP readyEHLO sender.example.org250-PIPELINING / 250-SIZE / 250-STARTTLS / 250 8BITMIMEMAIL FROM, RCPT TO, DATA... all plaintext, all visible to the attacker.The mitigation chain involves three layers from this glossary:
- MTA-STS — out-of-band policy fetched over HTTPS that says "this domain requires TLS." Sender knows TLS is required even before connecting; if STARTTLS fails or is stripped, the sender refuses to send.
- DANE — DNSSEC-signed TLSA record that simultaneously signals "TLS required" and provides the certificate fingerprint. Anchored in DNSSEC root keys, immune to network-level stripping.
- Implicit TLS on port 465 — eliminates the STARTTLS step entirely. TLS handshake before any SMTP traffic, no plaintext window to strip.
For server-to-server relay (port 25), MTA-STS and DANE are the only practical mitigations. For client submission, port 465 with implicit TLS is structurally immune.
Testing SMTP manually with telnet and openssl
SMTP's text-based design makes manual testing essential and accessible. Standard operator commands:
# Test plaintext SMTP on port 25 (server-to-server) telnet smtp.example.com 25 # Type: EHLO test.example.org # MAIL FROM:<test@example.org> # RCPT TO:<recipient@example.com> # (server should respond 250 or reject) # QUIT # Test STARTTLS on port 587 (submission) openssl s_client -connect smtp.example.com:587 -crlf -starttls smtp -quiet # s_client opens plain, issues STARTTLS, upgrades to TLS # Then accepts SMTP commands inside the encrypted stream # Test implicit TLS on port 465 openssl s_client -connect smtp.example.com:465 -crlf -quiet # Direct TLS handshake, then SMTP commands in encrypted stream # Inspect server certificate during handshake openssl s_client -connect smtp.example.com:465 -showcerts < /dev/null # Test for SMTP AUTH support echo -e "EHLO test.com\r\nQUIT" | openssl s_client -connect smtp.example.com:587 \ -starttls smtp -quiet 2>/dev/null | grep AUTH
For systematic SMTP testing including connectivity, STARTTLS support, and certificate validation, dedicated tools like CheckTLS and internet.nl automate the full audit.
SMTP in Cloud Server for Email infrastructure
Our managed email infrastructure operates SMTP across all three roles (submission, relay, receiving) with these specific configurations:
- Inbound submission on port 587 (STARTTLS required) and port 465 (implicit TLS) for client applications submitting to our infrastructure. Port 25 outbound from client networks is structurally not used — we run dedicated relay infrastructure that owns reputation per client.
- Outbound relay on port 25 through PowerMTA virtual MTA pools per client, with STARTTLS opportunistic for delivery to recipients that don't publish MTA-STS or DANE policies, and STARTTLS strict for recipients with MTA-STS enforce policies. DANE TLSA validation for recipients with DNSSEC-signed MX zones.
- Receiving MTA on port 25 for inbound mail (bounce processing, FBL ingestion). Postfix-based with Spamhaus ZEN queries at connection time, SPF/DKIM/DMARC validation per DMARC policy.
- Continuous testing infrastructure via openssl s_client and automated TLS/STARTTLS audits per customer endpoint, with periodic connectivity verification across all client-facing submission endpoints.
- Enhanced status code handling — our PowerMTA accounting log captures both basic 3-digit codes and Enhanced 3-part codes per delivery attempt, feeding into deliverability dashboards. PowerMTA bounce code analysis documents the operational interpretations.
For customers running their own SMTP infrastructure, we provide consultation on port strategy (465 vs 587 vs 25), TLS hardening (STARTTLS strict, MTA-STS, DANE), and authentication layer (AUTH mechanisms, SMTP AUTH vs OAuth2 for application clients).
Related glossary concepts
- MTA — the umbrella concept; SMTP is the protocol MTAs implement.
- PowerMTA — specific high-volume MTA implementation.
- SPF — validates the SMTP envelope MAIL FROM domain.
- DKIM — message-level signature added before SMTP DATA transmission.
- DMARC — alignment policy across SMTP envelope and headers.
- MTA-STS — TLS enforcement policy for SMTP downgrade resistance.
- DANE — DNS-based TLS validation at SMTP STARTTLS handshake.
- TLS-RPT — daily reporting on SMTP transport TLS results.
- Spamhaus — DNSBL queries at SMTP connection time before EHLO.
- Sender Reputation — reputation tied to the IPs running SMTP outbound.
- IP Warming — gradual ramp on new SMTP-sending IPs.
Frequently asked questions
Why is SMTP push-only? Why can't I use SMTP to read my mail?
SMTP was designed in 1982 specifically for transmitting messages outbound — pushing them from sender to recipient mail servers. Reading mail (retrieving messages from a mailbox) is a completely different problem solved by IMAP (RFC 3501, port 143/993) and POP3 (RFC 1939, port 110/995). The split makes architectural sense: mail servers in the 1980s couldn't be assumed always-online or always-reachable, so messages needed to be pushed when the sender was online and stored on the recipient's server until the recipient retrieved them at their convenience. This push/pull split persists today — your email client uses IMAP or POP3 to read your inbox and SMTP only to send. Microsoft Exchange uses MAPI/EWS as alternatives to IMAP/POP3 but still uses SMTP for sending.
What's the maximum message size SMTP can transfer?
There is no hard limit in the SMTP protocol itself, but every server enforces a SIZE extension limit declared in EHLO. Common values: Gmail accepts up to 25MB, Microsoft 365 accepts up to 150MB (was 25MB until 2023), Yahoo accepts up to 25MB. Most enterprise mail servers enforce 10-50MB. The SIZE limit applies to the encoded message — Base64 encoding adds ~33% overhead, so a 25MB SIZE limit accommodates roughly 18MB of original content. For larger transfers, modern practice is to upload the file to cloud storage (Google Drive, OneDrive, Dropbox) and email a link instead. SMTP was not designed for bulk file transfer.
Why does SMTP use a lone period to terminate DATA? What if my message has a line that's just a period?
SMTP terminates the message body with a line containing only a period (CRLF.CRLF). This dates from 1982 when the protocol needed an in-band termination signal. The edge case of a legitimate line with only a period in the message body is handled by "transparency" or "dot-stuffing" per RFC 5321 §4.5.2: the sending client doubles any line that begins with a period (so a single "." becomes ".."), and the receiving server removes the duplication. This is invisible to humans and to message body content, but every SMTP implementation handles it. If you're writing SMTP code from scratch, this is one of the things you have to remember; if you're using a library (Python smtplib, JavaMail, Nodemailer), it's handled for you.
Is SMTP secure? Can I trust SMTP traffic to be private?
SMTP itself is not secure — it was designed in 1982 when the internet was a small, trusted network. Security has been bolted on through layered standards: STARTTLS (RFC 3207, 2002) for opportunistic TLS encryption; MTA-STS (RFC 8461, 2018) for TLS enforcement policy; DANE (RFC 7672, 2015) for DNSSEC-anchored certificate validation; SMTPS via implicit TLS on port 465 (RFC 8314, 2018). For server-to-server transport, modern best practice is STARTTLS opportunistic + MTA-STS or DANE for downgrade resistance. For client submission, implicit TLS on port 465 is structurally most secure. Even with all these layers, SMTP is hop-by-hop encrypted (each MTA decrypts and re-encrypts) — it's not end-to-end encrypted. For true end-to-end encryption, message-level standards like S/MIME (RFC 5751) and PGP/GPG (RFC 4880) operate above SMTP.
What's the relationship between SMTP and DNS?
SMTP delivery requires DNS at every step. To deliver mail to recipient@example.com, the sending MTA queries DNS for example.com's MX (Mail Exchanger) records, gets back a prioritized list of receiving server hostnames, queries DNS again for the A/AAAA records of those hostnames to get IP addresses, then opens a TCP connection to one of those IPs on port 25. SPF validation is a DNS TXT query during MAIL FROM. DKIM verification is a DNS TXT query for the public key after DATA. DMARC policy lookup is a DNS TXT query at delivery time. MTA-STS policy fetch starts with a DNS TXT query, then HTTPS. DANE validation is a DNS TLSA query at STARTTLS time. DNSBL queries (Spamhaus) are reverse-IP DNS queries at connection time. SMTP without functioning DNS is essentially non-operational — DNS issues frequently surface as "unable to deliver" errors that are actually DNS problems disguised as SMTP problems.
Can SMTP be replaced by something better in the future?
In theory, yes; in practice, no foreseeable replacement is on the horizon. SMTP's value isn't its protocol design — by modern standards, it's awkward, has historical baggage, and lacks built-in security. Its value is universal interoperability across 4+ billion email accounts, 44 years of accumulated infrastructure, and an enormous ecosystem of clients, servers, anti-spam, anti-virus, archival, and compliance tooling. Replacing SMTP would require coordinated migration across every email-handling system on the internet — practically impossible. The actual evolution path has been incremental: layer security on top (STARTTLS, MTA-STS, DANE), add authentication (SPF, DKIM, DMARC, ARC), extend capabilities (ESMTP, SMTPUTF8, internationalized addresses) — without breaking the underlying protocol. SMTP's mortar dries with each new RFC; replacement gets less likely, not more, with every layered standard.
What's the difference between SMTP and HTTP for email APIs (SendGrid, Mailgun)?
Modern transactional email services like SendGrid, Mailgun, and Amazon SES offer two interfaces: a traditional SMTP submission endpoint (port 587/465) and an HTTP REST API. They produce identical results — both submit a message to the ESP's infrastructure for delivery. The differences are operational. SMTP is universal (works with any email client, any backend language with an SMTP library) but inherits SMTP's quirks (port issues, AUTH mechanisms, protocol-level errors). HTTP APIs are easier to integrate from modern application code (JSON in/out, standard HTTP error semantics, easier authentication via API keys), often offer richer feedback (delivery webhooks, real-time status), and avoid port-blocking issues entirely. For new application development in 2026, HTTP APIs are typically simpler. For email-client-style submission or environments without HTTP-API integration, SMTP submission remains essential. ESPs continue to support both because their customers need both.
Last updated: May 2026 · Sources: RFC 5321, RFC 3207 STARTTLS, RFC 6409 Mail Submission, RFC 8314 Implicit TLS, Wikipedia: SMTP, SMTP return codes Wikipedia.