SMTP, or Simple Mail Transfer Protocol, is the standard protocol that moves email across the internet. It handles how messages are sent from a client to a server and relayed between mail servers until they reach the recipient's mailbox.
Key Takeaways
- SMTP is a push protocol that sends and relays email, while separate protocols handle retrieval and mailbox access.
- In practice, email delivery depends on distinct ports and agent roles that determine how a message moves from sender to recipient.
- By design, the protocol did not include built-in sender authentication or mandatory encryption, which left lasting security gaps.
- To close those gaps, modern email systems layer SPF, DKIM, and DMARC on top of SMTP.
How SMTP Works
SMTP works by moving a message through a defined chain of agents that exchange text-based commands over TCP.
Envelope vs. Message Headers
Every SMTP transaction involves two distinct layers of addressing. The SMTP envelope, created by the MAIL FROM and RCPT TO commands, tells servers where to route the message. The message headers, including the From, To, and Subject fields a recipient sees, are part of the message body and travel inside the envelope.
These two layers are independent. This separation is the architectural root of email spoofing: attackers can set any address in the visible From header while using a different envelope sender, and the receiving server has no built-in way to detect the mismatch. The authentication protocols Sender Policy Framework, DKIM, and DMARC policy were created specifically to bridge this gap.
The Four Agents in an SMTP Transaction
Email delivery involves four functional roles working in sequence. The Mail User Agent (MUA) is the email client, such as Outlook or Thunderbird, where a user composes and reads messages. When the user clicks send, the MUA passes the message to the Mail Submission Agent (MSA), which accepts outbound mail on port 587 or 465. The MSA requires the sender to authenticate before accepting any message.
On the delivery side, the MSA hands the message to the Mail Transfer Agent (MTA), which performs a DNS MX lookup to identify the recipient's mail server. Multiple MTAs may relay the message along the way. Each relay adds a Received header that traces the path. Once the message arrives at its destination, the Mail Delivery Agent (MDA) deposits it into the recipient's mailbox, where it waits to be retrieved via IMAP or POP3.
Session Flow from Sender to Recipient
An SMTP session follows a predictable sequence. The sending server opens a TCP connection and receives a 220 greeting from the receiving server. It then issues an EHLO command to identify itself and request a list of supported extensions. If both sides support TLS, a STARTTLS exchange encrypts the connection before any credentials are transmitted.
The sender then specifies the envelope sender with MAIL FROM, lists one or more recipients with RCPT TO, and transmits the message body after the DATA command. The server responds with a 250 confirmation, and the session closes with QUIT. This entire exchange happens in plain ASCII text, which makes it easy to debug but also easy to intercept if TLS is not in place.
SMTP Ports and Their Security Tradeoffs
SMTP ports differ by role: port 25 handles server relay, while ports 587 and 465 handle authenticated client submission.
Port 25 for Server-to-Server Relay
Port 25 is the original SMTP port, designated for MTA-to-MTA relay traffic. When one mail server forwards a message to another, the connection typically runs over port 25. Authentication is not required on this port because the servers are relaying mail on behalf of users who already authenticated during submission to their own MSA. Encryption is available through an opportunistic STARTTLS upgrade, but it is not guaranteed. Encryption depends on both sides cooperating, and a single misconfigured or outdated server breaks the chain.
MTA-STS and DANE allow receiving domains to publish policies requiring TLS on port 25 relay connections, closing the opportunistic gap. Email clients should never use port 25 for submission.
Ports 587 and 465 for Client Submission
Ports 587 and 465 both handle client-to-server submission, the link between an email client and its outgoing server, but they differ in how they establish encryption. Port 587 starts the connection in plaintext and upgrades to TLS via the STARTTLS command. This upgrade model introduces a brief plaintext negotiation phase where a man-in-the-middle attacker could strip the STARTTLS command and force the session to remain unencrypted.
Port 465 uses implicit TLS: the connection is encrypted from the very first byte, so no plaintext negotiation phase exists and the STARTTLS stripping attack becomes architecturally impossible. Both ports require SMTP AUTH. The user must supply valid credentials before the server accepts any mail. SMTP AUTH typically uses PLAIN or LOGIN mechanisms, which transmit credentials in base64 encoding that is trivially reversible, so credentials are only safe if TLS is already active. For new deployments, implicit TLS on port 465 is the preferred submission method.
SMTP Commands Reference
SMTP commands define the core session steps used to open a connection, transfer a message, and close the exchange.
Common SMTP commands include session initiation, sender and recipient declaration, message transfer, encryption upgrade, authentication, and connection closure.
| Command | Purpose | Classification |
|---|---|---|
| EHLO | Initiates an ESMTP session and requests the server's list of supported extensions. | Mandatory (modern) |
| HELO | Legacy session initiation with no extension negotiation. | Legacy |
| MAIL FROM | Sets the envelope sender address and begins the mail transaction. | Mandatory |
| RCPT TO | Specifies an envelope recipient; can be issued multiple times for multiple recipients. | Mandatory |
| DATA | Begins message body transfer; the message ends with a single period on its own line. | Mandatory |
| QUIT | Closes the SMTP connection. | Mandatory |
| RSET | Aborts the current transaction and resets the session to its initial state. | Highly recommended |
| VRFY | Requests verification of an email address; often disabled to prevent address harvesting. | Seldom used |
| STARTTLS | Requests a TLS upgrade on the current plaintext connection (RFC 3207). | ESMTP extension |
| AUTH | Authenticates the client with credentials before submission is allowed (RFC 4954). | ESMTP extension |
SMTP vs. IMAP and POP3
SMTP handles sending and relaying email, while IMAP and POP3 handle mailbox access and message retrieval.
SMTP handles only the outbound side of email: sending messages from a client to a server and relaying them between servers. Retrieving email from a mailbox requires a separate protocol. IMAP keeps messages on the server and synchronizes state across multiple devices. POP3 downloads messages to a single device and, by default, removes them from the server.
SMTP Security Risks
SMTP security risks stem from the protocol's original design, which lacked built-in sender authentication and mandatory encryption.
SMTP was designed for a small, cooperative internet, and its original specification included no sender authentication, no mandatory encryption, and no mechanism to verify that each hop in the delivery chain is secure. One direct consequence is the open relay problem: an SMTP server configured to accept and forward mail from any sender to any recipient without requiring authentication. Attackers exploit open relays to route spam and phishing through servers with established reputations. Those reputations can help the messages bypass filters that would block unknown sources. Requiring SMTP AUTH on all submission ports and restricting port 25 to relay traffic between authenticated domains are the standard mitigations.
Sender Address Spoofing
Because the SMTP envelope sender and the visible From header are independent fields, an attacker can set any value in the From header without modifying the envelope. A spoofed message might display the CEO's name and email address while originating from an entirely unrelated domain. Display name abuse amplifies the effect: an attacker sets the From header to show "CEO Name" as the display name but pairs it with an address like ceo@attacker-domain.com.
Business email compromise (BEC) attacks exploit this gap directly by impersonating executives and targeting finance departments with urgent wire transfer requests or demands for sensitive data. Spoofing is particularly effective in targeted attacks because the attacker can research and mimic specific internal communication patterns. The fraudulent message can become nearly indistinguishable from legitimate correspondence. According to the FBI IC3 2025 Internet Crime Report, BEC losses reached $3.05 billion in 2025 alone. Without SPF, DKIM, and DMARC enforcement in place, the receiving server cannot flag the mismatch between envelope and header identities.
STARTTLS Downgrade Attacks
When a client connects on port 587 and issues a STARTTLS command, the initial negotiation happens in plaintext. A man-in-the-middle attacker positioned between the client and server can intercept the EHLO response and strip the "250-STARTTLS" line from the server's capability list. The client, seeing no TLS option advertised, falls back to an unencrypted session. All subsequent traffic, including authentication credentials, then travels in cleartext. Executing this attack requires an active network position between the client and the mail server.
This vulnerability is specific to the STARTTLS upgrade model and does not apply to implicit TLS connections on port 465, where encryption begins before any SMTP commands are exchanged. MTA-STS addresses this gap on the server-to-server side by allowing receiving domains to publish a policy requiring TLS, so sending servers can refuse to deliver if encryption fails. DANE provides an alternative enforcement mechanism by publishing TLSA records in DNSSEC-signed DNS. Those records bind specific TLS certificates to mail server hostnames without relying on the web PKI trust model.
SMTP Smuggling
SMTP smuggling exploits inconsistencies in how different mail servers parse the end-of-data indicator that terminates a DATA command. RFC 5321 defines this indicator as a line containing only a period (CRLF.CRLF), but some servers accept variations of this sequence. Attackers craft messages containing alternate end-of-data sequences that one server interprets as a message boundary while the other treats as ordinary content.
When a sending server and a receiving server disagree on where one message ends and another begins, an attacker can inject a second, forged message inside a single SMTP transaction. The injected message inherits the authentication context of the legitimate outer message, which means it can pass SPF and DMARC checks even though its content is entirely fabricated. Server administrators can mitigate smuggling by configuring strict RFC 5321 compliance for end-of-data parsing. They should reject any non-standard termination sequences. Peer-reviewed research presented at USENIX Security 2025 found that 19 public email services and 1,577 private email services remained vulnerable to SMTP smuggling, with shared infrastructure like common SPF records amplifying the attack surface.
How SPF, DKIM, and DMARC Protect SMTP
SPF, DKIM, and DMARC protect SMTP by adding the identity checks the protocol itself was never built to provide.
SPF, DKIM, and DMARC form a layered authentication chain that addresses the identity verification gaps SMTP was never designed to fill. CISA's Binding Operational Directive 18-01 mandates their deployment for U.S. federal agencies.
SPF for Envelope Sender Verification
SPF authenticates the envelope sender, the address specified in the MAIL FROM command, by checking whether the sending server's IP address is authorized by the domain's DNS TXT record. The domain owner publishes this TXT record listing authorized IP addresses and ranges. When a receiving server gets a message, it extracts the domain from MAIL FROM, queries DNS for the SPF record, and checks whether the sending IP matches. If the IP matches, SPF passes; if not, the result is a fail or softfail depending on the domain's policy. SPF's core limitation is that it only validates the envelope sender. It says nothing about the visible From header, so a message can pass SPF while displaying a spoofed From address.
DKIM for Message Integrity
DKIM addresses content authenticity rather than IP authorization. The sending server signs selected message headers and the body with a private key, then attaches a DKIM-Signature header to the message. The signature header includes fields identifying the signing domain (d=) and specifying the selector (s=) used to locate the public key in DNS.
The receiving server uses the selector to query DNS for the public key at [selector]._domainkey.[domain] and verifies the signature against the message content. If the content has been altered in transit, the signature fails. DKIM authenticates the signing domain through its d= tag, but it does not define what action to take when verification fails. That enforcement role belongs to DMARC.
DMARC for Alignment and Enforcement
DMARC ties SPF and DKIM together by introducing identifier alignment: the domain authenticated by SPF or DKIM must match the domain in the visible From header. A message passes DMARC if at least one of the two underlying protocols passes and aligns. DMARC supports two alignment modes: relaxed alignment requires only that the organizational domains match, while strict alignment requires an exact domain match.
Domain owners publish a DMARC policy in DNS specifying what receiving servers should do with messages that fail: p=none monitors without action, p=quarantine routes failures to spam, and p=reject blocks them outright. The recommended deployment path is to progress gradually from p=none through p=quarantine to p=reject. Reporting data at each stage helps identify legitimate senders that need to be authorized before policy tightens. DMARC records support the rua= tag for aggregate reports, which give domain owners summaries of authentication results across all mail claiming to be from their domain.
Why Email Trust Still Depends on SMTP
SMTP still carries email between clients and servers, and modern protections compensate for limits in its original design. Organizations should focus on the controls around SMTP: authenticated submission, TLS enforcement where possible, and SPF, DKIM, and DMARC deployment.
Frequently Asked Questions
Does SMTP Send or Receive Email?
SMTP only sends and relays email. Receiving and reading email requires a separate protocol: IMAP retrieves messages while keeping them synchronized on the server, and POP3 downloads messages to a single device.
Why Doesn't SMTP Encrypt Email by Default?
SMTP was designed in the early 1980s for a small, trusted network where security was not a priority. Encryption and authentication were added later as extensions: STARTTLS and SMTP AUTH.
What Is the Difference Between SMTP Port 25 and Port 587?
Port 25 is reserved for server-to-server relay traffic and does not require authentication. Port 587 is designated for client-to-server mail submission, requires SMTP AUTH credentials, and supports a STARTTLS upgrade to encrypt the connection.
What Is SMTP Smuggling?
SMTP smuggling exploits parsing differences between mail servers in how they interpret the end-of-data sequence in the DATA command. When two servers disagree on where a message ends, an attacker can inject a hidden second message inside a single transaction.
