What is the SMTP Protocol?
The Simple Mail Transfer Protocol (SMTP) is the standard application-layer protocol for sending and relaying email across the Internet. Defined in RFC 5321 (which obsoletes RFC 821, RFC 974, RFC 1869, and RFC 2821), SMTP governs how email clients (Mail User Agents or MUAs) communicate with mail servers (Mail Transfer Agents or MTAs) and how those servers relay messages to each other until the email reaches its destination. SMTP is a text-based, command-response protocol that operates over TCP, typically on port 25 for server-to-server relay and port 587 for client submission. Unlike POP3 or IMAP, which retrieve email, SMTP only handles outgoing mail delivery.
How SMTP Works: The Client-Server Model
SMTP follows a simple client-server architecture. The client (your email application or an outgoing mail server) opens a TCP connection to the server, sends commands, and receives numeric response codes. Every SMTP transaction follows the same basic sequence: establish a TCP connection, identify the sender, specify the recipient, transmit the message content, and close the connection.
The SMTP model involves several distinct roles. The Mail User Agent (MUA) is the email client you use to compose and send messages. The Mail Submission Agent (MSA) receives outgoing mail from the MUA, typically on port 587. The Mail Transfer Agent (MTA) routes the message through the Internet, hopping from server to server. Finally, the Mail Delivery Agent (MDA) places the message into the recipient’s mailbox.
The SMTP Transaction in Three Steps
Every SMTP mail transaction consists of exactly three mandatory commands, executed in strict order:
1. MAIL FROM – Identifies the sender (the reverse-path or envelope sender).
2. RCPT TO – Identifies the recipient (the forward-path). This command can be repeated for multiple recipients.
3. DATA – Signals that the message content (headers and body) follows, terminated by a line containing only a period (`.`).
These three commands form the core of every SMTP transaction. Before and after the transaction, the client uses EHLO/HELO to identify itself and QUIT to end the session.
SMTP Protocol Example: A Complete Telnet Session
The best way to understand SMTP is to watch a real session. Below is a complete SMTP transaction using telnet, with server responses annotated. This is the definitive smtp protocol example you can run yourself.
$ telnet mail.example.com 25
Trying 192.0.2.10...
Connected to mail.example.com.
Escape character is '^]'.
S: 220 mail.example.com ESMTP Postfix
C: EHLO client.example.com
S: 250-mail.example.com
S: 250-PIPELINING
S: 250-SIZE 10240000
S: 250-VRFY
S: 250-ETRN
S: 250-STARTTLS
S: 250-AUTH PLAIN LOGIN
S: 250-ENHANCEDSTATUSCODES
S: 250-8BITMIME
S: 250-DSN
S: 250 SMTPUTF8
C: MAIL FROM:<[email protected]>
S: 250 2.1.0 Ok
C: RCPT TO:<[email protected]>
S: 250 2.1.5 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: "Sender Name" <[email protected]>
C: To: "Recipient Name" <[email protected]>
C: Subject: SMTP Protocol Example Test
C: Date: Mon, 28 Jun 2026 10:00:00 +0000
C: Message-ID: <[email protected]>
C: MIME-Version: 1.0
C: Content-Type: text/plain; charset=UTF-8
C:
C: This is the email body content.
C: It can span multiple lines.
C: The message ends with a period on a line by itself.
C: .
S: 250 2.0.0 Ok: queued as ABC123DEF
C: QUIT
S: 221 2.0.0 Bye
Connection closed by foreign host.Breaking Down the SMTP Example
Each line in this smtp protocol example serves a specific purpose. The server greeting (220) confirms the connection is ready. The EHLO command identifies the client and requests extended SMTP capabilities. The server responds with a multiline reply listing supported extensions: PIPELINING, SIZE, VRFY, ETRN, STARTTLS, AUTH PLAIN LOGIN, ENHANCEDSTATUSCODES, 8BITMIME, DSN, and SMTPUTF8.
The MAIL FROM command sets the envelope sender. The server responds with 250 2.1.0 Ok, confirming acceptance. The RCPT TO command sets the recipient. The server responds with 250 2.1.5 Ok. The DATA command transitions the session into data-acceptance mode, and the server responds with 354 End data with ..
The client then transmits the message headers and body, ending with a period on a line by itself. The server queues the message and responds with 250 2.0.0 Ok: queued as ABC123DEF. Finally, QUIT terminates the session.
SMTP Commands: Complete Reference
SMTP commands are text-based instructions sent from the client to the server. Each command is a case-insensitive keyword followed by optional arguments, terminated by CRLF.
| Command | Syntax | Description | Required? |
|---|---|---|---|
| EHLO | `EHLO ` | Extended hello; initiates ESMTP session | Yes (preferred) |
| HELO | `HELO ` | Basic hello; fallback if EHLO fails | Yes (fallback) |
| MAIL FROM | `MAIL FROM:` | Identifies the envelope sender | Yes |
| RCPT TO | `RCPT TO:` | Identifies a recipient; repeatable | Yes |
| DATA | `DATA` | Begins message content transmission | Yes |
| RSET | `RSET` | Aborts current transaction without closing connection | No |
| VRFY | `VRFY ` | Verifies a user or mailbox exists | No |
| EXPN | `EXPN ` | Expands a mailing list | No |
| HELP | `HELP []` | Returns helpful information | No |
| NOOP | `NOOP` | No operation; returns 250 OK | No |
| QUIT | `QUIT` | Terminates the session | Yes (to close) |
| AUTH | `AUTH []` | Authenticates the client | Conditional |
| STARTTLS | `STARTTLS` | Upgrades connection to TLS | No |
EHLO vs HELO: Why EHLO Matters
The EHLO command replaced HELO as the standard session initiation command. When a client sends EHLO, the server responds with a list of supported extensions. This allows the client to negotiate capabilities like STARTTLS, AUTH, PIPELINING, 8BITMIME, and DSN. If the server does not support EHLO, the client falls back to HELO. Modern SMTP servers must support both, but EHLO is always preferred.
SMTP Response Codes: The Complete Reference
SMTP servers respond to every command with a three-digit numeric code followed by a human-readable text message. The first digit indicates the general category of the response.
| Code Range | Category | Meaning |
|---|---|---|
| 2xx | Positive Completion | The requested action succeeded. A new request may be initiated. |
| 3xx | Positive Intermediate | The command was accepted, but the server awaits further information. |
| 4xx | Transient Negative | The command failed temporarily. The client should retry later. |
| 5xx | Permanent Negative | The command failed permanently. The client should not retry without correction. |
Common SMTP Response Codes
| Code | Meaning | Typical Context |
|---|---|---|
| 220 | Service ready | Server greeting on connection |
| 221 | Service closing channel | Response to QUIT |
| 235 | Authentication successful | Response to successful AUTH |
| 250 | Requested action completed | Success response for most commands |
| 251 | User not local; forwarding | Server will forward the message |
| 252 | Cannot VRFY user; will accept | Server cannot verify but will attempt delivery |
| 334 | Server challenge | Response during AUTH exchange |
| 354 | Start mail input | Response to DATA command |
| 421 | Service not available | Server shutting down or overloaded |
| 450 | Mailbox unavailable | Temporary failure; retry later |
| 451 | Local error in processing | Server encountered an error |
| 452 | Insufficient system storage | Server storage full |
| 455 | Server unable to accommodate parameters | Parameter temporarily not supported |
| 500 | Syntax error, command unrecognized | Command not understood |
| 501 | Syntax error in parameters or arguments | Invalid command arguments |
| 502 | Command not implemented | Command not supported |
| 503 | Bad sequence of commands | Commands sent in wrong order |
| 504 | Command parameter not implemented | Parameter not supported |
| 550 | Mailbox unavailable | Mailbox does not exist or access denied |
| 551 | User not local | Server not accepting mail for this user |
| 552 | Exceeded storage allocation | Mailbox exceeds quota |
| 553 | Mailbox name not allowed | Invalid mailbox syntax |
| 554 | Transaction failed | General failure; message rejected |
| 555 | MAIL FROM/RCPT TO parameters not recognized | Unrecognized parameter |
SMTP Envelope vs Headers vs Body
One of the most frequently misunderstood aspects of SMTP is the distinction between the envelope, the headers, and the body. These three layers serve different purposes and are processed at different stages of delivery.
[IMAGE 2: Comparison diagram showing three layers of an email: SMTP envelope with MAIL FROM and RCPT TO, email headers with From/To/Subject/Date, and email body with message content]
The SMTP Envelope
The envelope is the routing information transmitted via SMTP commands. It consists of the MAIL FROM address (the return path for bounces) and the RCPT TO addresses (the actual recipients). The envelope is not visible to the end user in the delivered message. It is analogous to the outer wrapper on a physical letter that the postal service uses for routing.
The Email Headers
The headers are the structured metadata at the top of the message content, transmitted after the DATA command. Headers include From, To, Subject, Date, Message-ID, Received, DKIM-Signature, and others. The recipient sees these headers in their email client. Critically, the header From address can differ from the envelope MAIL FROM address. This is how legitimate forwarding and mailing lists work, and also how email spoofing occurs.
The Email Body
The body is the actual message content, transmitted after the headers and separated by a blank line. The body can be plain text, HTML, or multipart content (MIME) with attachments.
Why the Distinction Matters
Email authentication protocols like SPF, DKIM, and DMARC validate different parts of this layered structure. SPF checks the envelope MAIL FROM domain against authorized sending servers. DKIM signs the headers and body with a cryptographic signature. DMARC aligns the header From domain with either SPF or DKIM. Understanding the SMTP envelope is essential for diagnosing deliverability issues and configuring authentication correctly.
SMTP Relay Chain: How Email Travels Across the Internet
Email does not travel directly from sender to recipient. Instead, it hops through a chain of SMTP servers, each acting as a relay. Understanding this relay chain is critical for troubleshooting delivery delays, bounce messages, and authentication failures.
[IMAGE 3: SMTP relay chain diagram showing email traveling from sender through multiple Mail Transfer Agents with DNS MX record lookup at each hop to reach the recipient inbox]
Step-by-Step Relay Process
1. Submission: The sender’s MUA connects to its configured SMTP submission server (typically port 587 with authentication). The MSA accepts the message and performs initial validation.
2. DNS MX Lookup: The first MTA extracts the recipient’s domain from the RCPT TO address and performs a DNS lookup for MX (Mail Exchange) records. The MX record returns the hostname(s) of mail servers authorized to receive mail for that domain.
3. Relay Hop: The MTA opens an SMTP connection to the highest-priority MX host (lowest preference number) and relays the message. If that server is unreachable, it tries the next priority MX.
4. Intermediate Relays: The message may pass through multiple MTAs. Each MTA adds a Received header to the message, creating a trace of the delivery path.
5. Delivery: The final MTA in the chain (the destination mail server) accepts the message and passes it to the MDA, which places it in the recipient’s mailbox.
DNS MX Records and SMTP Routing
When an SMTP server needs to deliver a message, it queries DNS for MX records of the recipient’s domain. The MX record format is:
destination.com. IN MX 10 mail.destination.com.
destination.com. IN MX 20 backup.destination.com.The number before the hostname is the preference value. Lower values are preferred. If the primary server (preference 10) is unavailable, the sending server tries the backup (preference 20). If no MX records exist, the sending server falls back to querying the A or AAAA record for the domain.
SMTP Authentication: AUTH LOGIN and AUTH PLAIN
SMTP authentication ensures that only authorized users can send mail through a server. Without authentication, any client could use any SMTP server to send mail, enabling spam and forgery. Modern SMTP submission requires authentication before accepting messages.
AUTH LOGIN Example
C: AUTH LOGIN
S: 334 VXNlcm5hbWU6
C: c2VuZGVyQGV4YW1wbGUuY29t
S: 334 UGFzc3dvcmQ6
C: bXlwYXNzd29yZA==
S: 235 2.7.0 Authentication successfulThe server sends base64-encoded prompts. “VXNlcm5hbWU6” decodes to “Username:” and “UGFzc3dvcmQ6” decodes to “Password:”. The client responds with base64-encoded credentials.
AUTH PLAIN Example
C: AUTH PLAIN AHNlbmRlckBleGFtcGxlLmNvbQBteXBhc3N3b3Jk
S: 235 2.7.0 Authentication successfulAUTH PLAIN sends the credentials in a single base64-encoded string formatted as `usernamepassword`. The leading “ is a null character acting as an authorization identity placeholder.
Security Considerations for SMTP Authentication
AUTH LOGIN and AUTH PLAIN transmit credentials in base64 encoding, which is not encryption. Anyone who captures the network traffic can decode the credentials. For this reason, authentication should only occur over a TLS-encrypted connection. The STARTTLS command upgrades a plaintext SMTP connection to TLS before authentication begins.
SMTP Security: STARTTLS and Encryption
SMTP was originally designed without security in mind. The protocol transmits all data, including commands, headers, body, and authentication credentials, in plaintext. STARTTLS addresses this by upgrading the connection to TLS encryption.
How STARTTLS Works
C: EHLO client.example.com
S: 250-STARTTLS
C: STARTTLS
S: 220 2.0.0 Ready to start TLS
--- TLS handshake occurs ---
C: EHLO client.example.com (new encrypted session)
S: 250-AUTH PLAIN LOGIN
C: AUTH LOGIN
...After the STARTTLS command and the server’s 220 response, the client and server perform a TLS handshake. Once the encrypted channel is established, the client sends EHLO again to renegotiate capabilities within the secure session. Authentication and data transmission then occur over the encrypted connection.
Port 465 vs Port 587 vs Port 25
The relationship between SMTP ports and encryption is a common source of confusion.
| Port | Protocol | Encryption | Primary Use |
|---|---|---|---|
| 25 | SMTP | Usually none (but STARTTLS available) | Server-to-server relay |
| 587 | SMTP Submission | STARTTLS (explicit TLS) | Client-to-server submission |
| 465 | SMTP Submission | Implicit TLS (SMTPS) | Legacy submission (deprecated but still used) |
| 2525 | SMTP Submission | STARTTLS or implicit TLS | Alternative submission port |
Port 25 is the original SMTP port. Internet service providers and cloud platforms frequently block outbound port 25 to prevent spam. Port 587 is the IANA-registered port for email message submission and is the recommended port for client configuration. Port 465 was briefly registered for SMTPS (SMTP over SSL) but was later revoked. Despite this, many providers still support port 465 with implicit TLS. Port 2525 is an unofficial alternative used when ports 25, 587, and 465 are all blocked.
Decision Matrix: Which SMTP Port Should You Use?
| Your Situation | Recommended Port | Reason |
|---|---|---|
| Configuring an email client (Outlook, Thunderbird, etc.) | 587 with STARTTLS | Standard submission port, widely supported |
| Sending from a web application | 587 with STARTTLS | Works through most firewalls, requires authentication |
| Server-to-server relay | 25 | Standard relay port, required for MX delivery |
| Port 587 is blocked by your ISP | 465 with implicit TLS | Falls back to SMTPS if STARTTLS port is blocked |
| All standard ports blocked | 2525 | Unofficial but supported by many providers |
| Legacy system requiring SSL | 465 | Only if the system does not support STARTTLS |
SMTP Extensions: ESMTP and Modern Capabilities
Extended SMTP (ESMTP) is the modern version of the protocol. When a client sends EHLO instead of HELO, the server responds with a list of supported extensions. Each extension adds specific capabilities.
Common ESMTP Extensions
| Extension Keyword | Capability | RFC |
|---|---|---|
| PIPELINING | Send multiple commands without waiting for responses | RFC 2920 |
| SIZE | Declare message size; server can reject oversized messages | RFC 1870 |
| STARTTLS | Upgrade to encrypted TLS connection | RFC 3207 |
| AUTH | SMTP authentication mechanisms | RFC 4954 |
| 8BITMIME | Support for 8-bit character data in message body | RFC 6152 |
| BINARYMIME | Support for binary data without encoding | RFC 3030 |
| CHUNKING | Stream large messages in chunks (BDAT command) | RFC 3030 |
| DSN | Delivery Status Notification support | RFC 3461 |
| SMTPUTF8 | Support for UTF-8 in email addresses and headers | RFC 6531 |
| ENHANCEDSTATUSCODES | Enhanced response codes with structured status | RFC 2034 |
| VRFY | Verify mailbox existence | RFC 5321 |
| ETRN | Remote queue processing | RFC 1985 |
PIPELINING: Faster SMTP Transactions
PIPELINING allows the client to send multiple commands without waiting for individual responses. Without pipelining, the client must wait for a response after each command before sending the next. With pipelining, the client can send MAIL FROM, RCPT TO, and DATA in rapid succession, reducing round-trip latency.
CHUNKING and BDAT: Handling Large Messages
The CHUNKING extension introduces the BDAT (Binary Data) command as an alternative to DATA. Instead of terminating the message with a period on a line by itself, BDAT declares the chunk length in advance. This enables streaming of large messages without scanning for the end-of-data marker. Multiple BDAT chunks can be sent, with a final zero-length chunk signaling completion.
SMTP Timeouts and Retry Strategies
SMTP defines specific timeout values that clients and servers must observe. These timeouts prevent hung connections from consuming resources indefinitely.
| Timeout Point | Duration | Description |
|---|---|---|
| Initial 220 greeting | 5 minutes | Server must send greeting within 5 minutes of connection |
| MAIL command | 5 minutes | Client must send MAIL FROM within 5 minutes of EHLO |
| RCPT command | 5 minutes | Client must send RCPT TO within 5 minutes of MAIL FROM |
| DATA initiation | 2 minutes | Client must send DATA within 2 minutes of last RCPT TO |
| Data block transfer | 3 minutes | Client must send each data block within 3 minutes |
| DATA termination | 10 minutes | Client must complete data and send termination within 10 minutes |
| Server idle timeout | 5 minutes | Server may close connection after 5 minutes of inactivity |
SMTP Retry Strategies
When a server returns a 4xx transient error, the sending MTA must retry delivery. RFC 5321 recommends a minimum retry period of 30 minutes, with exponential backoff. A typical retry schedule is:
1. First retry: 30 minutes
2. Second retry: 1 hour
3. Third retry: 2 hours
4. Fourth retry: 4 hours
5. Subsequent retries: every 4 hours
Most MTAs continue retrying for 48 to 72 hours before generating a bounce notification. The specific retry schedule varies by MTA implementation (Postfix, Sendmail, Exim, Exchange).
SMTP Bounce Handling and Delivery Status Notifications
When an SMTP server cannot deliver a message, it generates a bounce notification (also called a Delivery Status Notification or DSN). Bounces fall into two categories.
Hard Bounces (5xx Errors)
Hard bounces indicate permanent delivery failures. The sending server should not retry. Common causes include:
- 550 5.1.1 Mailbox does not exist: The recipient address is invalid.
- 550 5.1.2 Host not found: The recipient domain does not exist.
- 550 5.7.1 Relay denied: The server refuses to relay for the sender.
- 553 5.3.0 Mailbox name not allowed: The mailbox syntax is invalid.
Soft Bounces (4xx Errors)
Soft bounces indicate temporary delivery failures. The sending server should retry later. Common causes include:
- 450 4.1.1 Mailbox busy: The recipient mailbox is temporarily unavailable.
- 451 4.3.0 Internal server error: The destination server encountered an error.
- 452 4.2.2 Mailbox full: The recipient mailbox exceeds its quota.
- 421 4.4.0 Connection timed out: The destination server is unreachable.
DSN Extension
The DSN extension (RFC 3461) allows the sender to request specific notification types. The client includes parameters in the RCPT TO command:
RCPT TO:<[email protected]> NOTIFY=SUCCESS,FAILURE,DELAYThe server then sends DSN messages for the requested events. This is how senders receive bounce notifications with specific error codes rather than generic undeliverable messages.
SMTP and Email Authentication: SPF, DKIM, and DMARC
SMTP itself provides no mechanism for verifying the authenticity of the sender. Any client can claim any MAIL FROM address. Email authentication protocols were developed to fill this gap.
SPF (Sender Policy Framework)
SPF publishes a DNS record listing the IP addresses authorized to send mail for a domain. When a receiving MTA processes an SMTP session, it checks the envelope MAIL FROM domain against the SPF record. If the sending IP is not authorized, the server may reject or flag the message.
DKIM (DomainKeys Identified Mail)
DKIM adds a digital signature to the email headers. The sending MTA signs the message with a private key and publishes the public key in DNS. The receiving MTA retrieves the public key and verifies the signature. DKIM survives forwarding because it signs the body and specific headers, not the envelope.
DMARC (Domain-based Message Authentication, Reporting, and Conformance)
DMARC builds on SPF and DKIM by specifying how the receiving server should handle messages that fail authentication. It also provides reporting so domain owners can monitor authentication results. DMARC alignment requires that the header From domain matches either the SPF-authenticated domain or the DKIM-signing domain.
How Authentication Relates to SMTP
Authentication happens after the SMTP delivery is complete. The receiving MTA extracts the envelope information from the SMTP session, retrieves the message headers and body, and then performs SPF, DKIM, and DMARC validation. The results influence spam filtering and delivery decisions but are not part of the SMTP protocol itself.
SMTP Header Injection: Security Risks and Prevention
SMTP header injection is a security vulnerability that occurs when user input is included in email headers without proper sanitization. An attacker can inject additional headers or even modify the message content by inserting CRLF sequences into input fields.
How Header Injection Works
If an application constructs email headers by concatenating user input:
Subject: = user_inputAn attacker could submit:
Hello
Bcc: [email protected]The resulting SMTP DATA section would include a Bcc header, causing the server to send copies to thousands of recipients.
Prevention
- Validate and sanitize all user input before including it in email headers.
- Reject input containing CR (`r`) or LF (`n`) characters.
- Use email libraries that handle header encoding safely.
- Never construct raw SMTP commands from user input.
SMTP Performance Optimization
For high-volume senders, SMTP performance directly affects delivery throughput. Several factors influence how many messages an SMTP server can deliver per second.
Connection Reuse
Opening a new TCP connection for each message adds significant latency. Modern MTAs reuse connections for multiple messages. After delivering one message, the client can send another MAIL FROM command without closing and reopening the connection.
Pipelining
The PIPELINING extension reduces round trips by allowing the client to send MAIL FROM, RCPT TO, and DATA without waiting for intermediate responses. For multi-recipient messages, the savings are substantial.
Multiple Concurrent Connections
Most MTAs support multiple concurrent SMTP connections to the same destination. The optimal number depends on the destination server’s capacity. Too many concurrent connections can trigger rate limiting or blacklisting. A typical starting point is 5 to 10 concurrent connections per destination domain.
Message Size Optimization
Large messages consume more bandwidth and processing time. For bulk sending, keep message sizes under 100 KB when possible. Use MIME compression for attachments and avoid unnecessary base64 encoding overhead.
DNS Resolution Caching
Each SMTP relay requires a DNS MX lookup. Caching DNS results reduces latency. Most MTAs cache MX records according to the TTL specified in the DNS response.
SMTP Troubleshooting: Common Problems and Solutions
Connection Refused or Timeout
If telnet to port 25, 587, or 465 fails with “Connection refused” or “Connection timed out,” the destination server may be blocking the connection. Check whether the port is firewalled. Many residential ISPs and cloud providers block outbound port 25. Use port 587 or 2525 as alternatives.
Authentication Failed
If AUTH returns 535 Authentication failed, verify the username and password. Some servers require the full email address as the username. Check whether the account has sending privileges. If using port 25, note that many servers do not allow authenticated submission on port 25.
Relay Denied
A 550 Relay denied error means the server does not recognize the sender domain or the client IP is not authorized to relay. This typically occurs when using an SMTP server without proper authentication or when the server is configured to relay only for specific domains.
Mailbox Unavailable
A 550 Mailbox unavailable error means the recipient address does not exist. Remove the address from your mailing list immediately. Repeated attempts to send to invalid addresses damage sender reputation.
Greylisting
Some servers return a 451 4.7.1 Greylisted error as a spam mitigation technique. The server temporarily rejects the message and expects a legitimate MTA to retry later. Ensure your sending system retries with proper backoff.
SMTP Troubleshooting Checklist
- [ ] Verify the SMTP server hostname and port are correct
- [ ] Confirm the port is not blocked by a firewall or ISP
- [ ] Test connectivity with telnet or openssl s_client
- [ ] Verify authentication credentials (username, password, mechanism)
- [ ] Check that the sender domain has valid DNS MX records
- [ ] Confirm SPF, DKIM, and DMARC records are configured correctly
- [ ] Verify the recipient address exists and is valid
- [ ] Check the server’s error log for rejection reasons
- [ ] Ensure the sending IP is not on any blocklists
- [ ] Test with a single small message before sending bulk mail
SMTP and Cold Email Deliverability
For cold email campaigns, SMTP configuration directly affects deliverability. The way you send messages through SMTP influences whether they land in the inbox, spam folder, or are rejected entirely.
SMTP Reputation Factors
Every SMTP server has a reputation based on sending patterns. Receiving servers track the volume, frequency, and quality of messages from each sending IP. Key reputation factors include:
- Sending volume: Gradual volume increases build reputation. Sudden spikes trigger rate limiting.
- Bounce rate: High hard bounce rates indicate poor list hygiene and damage reputation.
- Spam complaint rate: Complaints above 0.1% can trigger blocklisting.
- Authentication compliance: Missing or misconfigured SPF, DKIM, and DMARC reduce deliverability.
- Recipient engagement: Low open and click rates signal poor list quality.
SMTP Warmup
When using a new SMTP server or IP address, a warmup process gradually increases sending volume to build reputation. A typical warmup schedule starts with 10 to 20 messages per day and doubles every few days over two to four weeks. This gradual increase signals to receiving servers that the IP is legitimate.
For cold email senders, using a dedicated warmup tool that automates this process can significantly improve deliverability. Tools like Mystrika provide automated warmup sequences that simulate natural sending patterns, helping new SMTP servers establish positive reputation before full-scale campaigns begin.
SMTP Sending Limits
Most SMTP providers enforce sending limits to prevent abuse. Common limits include:
- Daily message cap: Maximum messages per 24-hour period.
- Hourly rate limit: Maximum messages per hour.
- Recipients per message: Maximum recipients in a single RCPT TO sequence.
- Concurrent connection limit: Maximum simultaneous SMTP connections.
Exceeding these limits results in 4xx or 5xx errors. For high-volume sending, choose an SMTP provider that aligns with your volume requirements and supports gradual scaling.
SMTP Protocol Example: Python Implementation
For developers who want to send email programmatically, here is a minimal Python implementation using the built-in smtplib library. This example demonstrates the same SMTP transaction shown in the telnet session above.
import smtplib
from email.mime.text import MIMEText
# SMTP server configuration
smtp_host = "mail.example.com"
smtp_port = 587
username = "[email protected]"
password = "your_password"
# Create the message
msg = MIMEText("This is the email body content.")
msg["Subject"] = "SMTP Protocol Example Test"
msg["From"] = "Sender Name <[email protected]>"
msg["To"] = "Recipient Name <[email protected]>"
# Send via SMTP
with smtplib.SMTP(smtp_host, smtp_port) as server:
server.ehlo() # Identify with EHLO
server.starttls() # Upgrade to TLS
server.ehlo() # Re-identify over encrypted connection
server.login(username, password) # Authenticate
server.sendmail(
"[email protected]", # Envelope MAIL FROM
["[email protected]"], # Envelope RCPT TO
msg.as_string() # Message content (headers + body)
)The smtplib library handles the SMTP command sequence internally. The `ehlo()` method sends EHLO and parses the server’s extension list. The `starttls()` method sends STARTTLS and performs the TLS handshake. The `login()` method handles AUTH LOGIN or AUTH PLAIN negotiation. The `sendmail()` method sends MAIL FROM, RCPT TO, and DATA with the message content.
SMTP Protocol Example: Common Pitfalls
Pitfall 1: Confusing Envelope and Header Addresses
The MAIL FROM address in the SMTP envelope is not necessarily the same as the From header in the message. Bounces go to the envelope address, not the header From address. If you configure your SMTP client with a different envelope sender than the header From, bounces will go to the envelope address.
Pitfall 2: Missing the Trailing Period
The DATA command requires the message to end with CRLF.CRLF (a period on a line by itself). If the message body contains a line with a single period, the client must apply dot-stuffing: prepend an extra period to that line. The receiving server removes the extra period during processing.
Pitfall 3: Incorrect Command Order
SMTP commands must follow a strict sequence. Sending RCPT TO before MAIL FROM, or DATA before RCPT TO, results in a 503 Bad sequence of commands error. The correct order is always EHLO, MAIL FROM, RCPT TO (one or more), DATA, message content, period, QUIT.
Pitfall 4: Ignoring Response Codes
Every SMTP command generates a response. Ignoring response codes and proceeding as if every command succeeded leads to undetected failures. Always check the response code after each command. A 250 response means success. Anything else requires investigation.
Pitfall 5: Sending Without Authentication on Port 25
Many SMTP servers reject unauthenticated submission on port 25. Always use port 587 with STARTTLS and authentication for client submission. Reserve port 25 for server-to-server relay.
SMTP Protocol Example: Comparison with Other Email Protocols
| Feature | SMTP | POP3 | IMAP |
|---|---|---|---|
| Primary function | Send outgoing mail | Retrieve and delete mail | Synchronize mail across devices |
| Direction | Push (client to server) | Pull (server to client) | Pull (server to client) |
| Port (standard) | 25, 587 | 110 | 143 |
| Port (secure) | 465, 587 (STARTTLS) | 995 | 993 |
| Message storage | Server queues for delivery | Downloaded and deleted from server | Retained on server |
| Multi-device support | N/A | Limited | Full |
| State management | Stateless per transaction | Stateless | Stateful (folders, flags) |
| RFC | 5321 | 1939 | 3501 |
SMTP handles outgoing mail delivery. POP3 and IMAP handle incoming mail retrieval. A complete email system uses all three: SMTP to send, and either POP3 or IMAP to receive.
Key Takeaways
- SMTP is the standard protocol for sending and relaying email, defined in RFC 5321. It uses a text-based command-response model over TCP.
- A complete SMTP transaction consists of EHLO, MAIL FROM, RCPT TO, DATA (with message content ending in CRLF.CRLF), and QUIT.
- SMTP response codes are grouped into 2xx (success), 3xx (intermediate), 4xx (temporary failure), and 5xx (permanent failure). Understanding these codes is essential for troubleshooting.
- The SMTP envelope (MAIL FROM and RCPT TO) is distinct from the email headers and body. Email authentication protocols like SPF, DKIM, and DMARC validate different layers of this structure.
- Port 587 with STARTTLS is the recommended configuration for email submission. Port 25 is reserved for server-to-server relay. Port 465 provides implicit TLS for legacy systems.
- ESMTP extensions including PIPELINING, STARTTLS, AUTH, 8BITMIME, CHUNKING, DSN, and SMTPUTF8 add critical capabilities beyond the original SMTP specification.
- SMTP performance optimization involves connection reuse, pipelining, concurrent connections, message size management, and DNS caching.
- For cold email campaigns, SMTP configuration directly affects deliverability. Proper authentication, gradual warmup, bounce management, and reputation monitoring are essential.
- Tools like Mystrika can help manage SMTP warmup and sending infrastructure, while Filter Bounce provides budget-friendly email verification to reduce bounce rates. DoYouMail offers additional deliverability infrastructure for high-volume senders.
Frequently Asked Questions
What is an SMTP protocol example?
An SMTP protocol example is a step-by-step demonstration of the commands and responses exchanged between an email client and server during message delivery. The classic example uses telnet to connect to an SMTP server on port 25 or 587, then sends EHLO, MAIL FROM, RCPT TO, DATA, and QUIT commands while observing the server’s numeric response codes. This hands-on approach reveals exactly how SMTP works at the protocol level, making it the most effective way to learn the protocol.
What is the difference between SMTP and ESMTP?
SMTP (Simple Mail Transfer Protocol) is the original protocol defined in RFC 821, using the HELO command for session initiation. ESMTP (Extended SMTP) is the modern version defined in RFC 5321, using the EHLO command. ESMTP adds capability negotiation, allowing the server to advertise supported extensions like STARTTLS, AUTH, PIPELINING, 8BITMIME, and DSN. Virtually all modern email systems use ESMTP, falling back to basic SMTP only when the server does not support EHLO.
What are the most common SMTP commands?
The most common SMTP commands are EHLO (extended hello, initiates session), MAIL FROM (identifies the envelope sender), RCPT TO (identifies a recipient, repeatable for multiple recipients), DATA (begins message content transmission), RSET (aborts the current transaction), and QUIT (ends the session). The AUTH command is also common for authenticated submission, and STARTTLS upgrades the connection to encrypted TLS.
What do SMTP response codes mean?
SMTP response codes are three-digit numbers that indicate the result of each command. Codes starting with 2 mean success (250 OK, 221 closing), 3 means intermediate (354 start mail input), 4 means temporary failure (450 mailbox unavailable, 451 server error), and 5 means permanent failure (550 mailbox not found, 554 transaction failed). The second digit provides more specific categorization: x0x indicates syntax errors, x1x indicates informational responses, x2x indicates connection-related responses, x3x indicates authentication responses, x5x indicates mail system status.
What port does SMTP use?
SMTP uses multiple ports depending on the use case. Port 25 is the standard port for server-to-server relay. Port 587 is the standard port for client-to-server submission with STARTTLS encryption. Port 465 provides implicit TLS for legacy systems. Port 2525 is an unofficial alternative used when other ports are blocked. For most email client configurations, port 587 with STARTTLS is the recommended choice.
How does SMTP authentication work?
SMTP authentication uses the AUTH command with mechanisms like LOGIN and PLAIN. In AUTH LOGIN, the server sends base64-encoded prompts for username and password, and the client responds with base64-encoded credentials. In AUTH PLAIN, the client sends credentials in a single base64-encoded string. Authentication should always occur over a TLS-encrypted connection (after STARTTLS) to prevent credential interception.
What is the SMTP envelope?
The SMTP envelope is the routing information transmitted via the MAIL FROM and RCPT TO commands during the SMTP transaction. It contains the return path for bounces (MAIL FROM) and the actual recipient addresses (RCPT TO). The envelope is separate from the email headers and body and is not visible to the end recipient. Understanding the envelope is critical for configuring SPF, DKIM, and DMARC correctly.
How do I test an SMTP server with telnet?
To test an SMTP server with telnet, open a terminal and type `telnet mail.example.com 25` (replace with your server and port). After the server responds with 220, send `EHLO test.com` to initiate the session. Then send `MAIL FROM:`, `RCPT TO:`, and `DATA`. Type your message content, end with a period on a line by itself, and send `QUIT` to close the connection. This manual test is invaluable for diagnosing SMTP issues.
What is the difference between SMTP, IMAP, and POP3?
SMTP is a push protocol used to send outgoing mail from a client to a server and between servers. IMAP and POP3 are pull protocols used to retrieve incoming mail from a server to a client. SMTP cannot retrieve mail, and IMAP/POP3 cannot send mail. A complete email setup requires SMTP for sending and either IMAP or POP3 for receiving. IMAP is preferred for multi-device access because it keeps messages on the server, while POP3 downloads and typically deletes them.
How does SMTP relate to email deliverability?
SMTP configuration directly affects email deliverability in several ways. The SMTP server’s IP reputation determines whether receiving servers accept or reject messages. Proper SMTP authentication (AUTH) ensures the server trusts the sender. The SMTP envelope addresses must align with SPF and DKIM configurations for DMARC compliance. SMTP sending patterns, including volume, frequency, and retry behavior, influence spam filtering decisions. For cold email campaigns, using a dedicated SMTP warmup process and monitoring bounce rates through SMTP response codes are essential practices for maintaining inbox placement.