SendStreak logo

What is SMTP?

Simple Mail Transfer Protocol (SMTP) is the standard application-layer protocol for transmitting electronic mail. Defined in RFC 5321, its primary role is to facilitate the relay of outgoing mail from an email client to a mail server and subsequently from that sending server to the recipient’s mail server.

When an application sends an email, it connects to an SMTP server, often authenticating with credentials. The server then processes the message, determining the recipient’s domain and routing it through a series of Mail Transfer Agents (MTAs) until it reaches its final destination.

It is important to distinguish SMTP’s function from retrieval protocols. SMTP is a push protocol used exclusively for sending messages. The corresponding pull protocols, such as IMAP and POP3, are used by clients to retrieve messages from a mail server.

How an SMTP conversation works

SMTP follows a simple command-response pattern. When a client connects to a server, they exchange a series of text commands:

  1. Connection - The client opens a TCP connection to the server. The server responds with a 220 greeting.
  2. EHLO - The client identifies itself with EHLO client.example.com. The server responds with a list of supported extensions (e.g., STARTTLS, AUTH).
  3. STARTTLS - If supported, the client upgrades the connection to TLS encryption before sending any credentials or message content.
  4. AUTH - The client authenticates, typically with AUTH LOGIN or AUTH PLAIN, providing a username and password (Base64-encoded).
  5. MAIL FROM - The client declares the sender’s address: MAIL FROM:<[email protected]>.
  6. RCPT TO - The client specifies the recipient: RCPT TO:<[email protected]>. This command is repeated for multiple recipients.
  7. DATA - The client sends the message content (headers and body), terminated by a line containing only a period (.).
  8. QUIT - The client ends the session.

Each command receives a numeric status code. Codes starting with 2xx indicate success, 4xx indicate a temporary failure (retry later), and 5xx indicate a permanent failure (do not retry).

SMTP ports and encryption

Three ports are commonly used for SMTP, each with different security characteristics:

Port Name Encryption Typical use
25 SMTP None (or STARTTLS upgrade) Server-to-server relay. Usually blocked by ISPs for end users.
465 SMTPS Implicit TLS (connection starts encrypted) Legacy submission port, reintroduced in RFC 8314.
587 Submission STARTTLS (plaintext, then upgrades) Standard port for client-to-server submission. Most recommended for applications.

For applications sending transactional email, port 587 with STARTTLS is the most widely supported option. Port 465 with implicit TLS is also acceptable and avoids the STARTTLS upgrade step.

Common SMTP errors

When integrating SMTP into an application, these are the status codes developers encounter most frequently:

  • 250 - Success. The server accepted the command.
  • 354 - Start mail input (after DATA command).
  • 421 - Service not available. The server is temporarily refusing connections. Retry with backoff.
  • 450 - Mailbox unavailable (temporary). Often caused by rate limiting or a full mailbox. Retry later.
  • 501 - Syntax error in command parameters. Check the MAIL FROM or RCPT TO format.
  • 535 - Authentication failed. Verify credentials.
  • 550 - Mailbox not found or delivery rejected. This is a permanent failure - do not retry.
  • 554 - Transaction failed. Often indicates the message was rejected as spam.

Understanding these codes is essential for building proper retry logic: temporary failures (4xx) should be retried with exponential backoff, while permanent failures (5xx) should be logged and the recipient flagged.

SMTP authentication and deliverability

Sending an email via SMTP is only half the challenge. For the message to reach the recipient’s inbox, the sending domain must be properly authenticated using DNS records:

  • SPF verifies that the sending IP is authorized to send on behalf of the domain.
  • DKIM attaches a cryptographic signature to the message, proving it was not tampered with in transit.
  • DMARC ties SPF and DKIM together with a policy that tells receiving servers what to do when authentication fails.

These mechanisms are evaluated by receiving mail servers and recorded in the Authentication-Results header. Without them, messages are significantly more likely to be filtered as spam.

Try SendStreak for Free now!