← RFC Reference

RFC 5321 – Simple Mail Transfer Protocol

Why This RFC Exists

SMTP is the oldest and most fundamental protocol powering email. Its lineage stretches back to RFC 821, published in 1982 by Jon Postel. RFC 5321, published in 2008, is the current definitive specification. It consolidated decades of extensions, clarifications, and operational experience into a single authoritative document.

The key evolution from RFC 821 to 5321 includes: formalization of ESMTP (Extended SMTP), clarification of relay vs. submission behavior, stricter requirements around DNS MX lookups, updated rules for address literals and IPv6, and requirements for bounce handling. This RFC is the bedrock that every other email RFC builds upon.

How It Works

An SMTP transaction is a structured conversation between two servers over a TCP connection (traditionally port 25). The protocol is text-based and line-oriented — every command and response is human-readable ASCII.

The SMTP Model

SMTP defines three roles:

• SMTP Client (Sender-SMTP): The system initiating the connection to transfer a message.
• SMTP Server (Receiver-SMTP): The system accepting the connection and receiving the message.
• SMTP Relay: A server that receives a message and forwards it toward its final destination, acting as both client and server.

The client connects, identifies itself with EHLO, specifies the envelope sender (MAIL FROM), one or more recipients (RCPT TO), then transmits the message data (DATA). The server responds to each command with a three-digit status code.

The SMTP Commands

Reply Codes

Every server response starts with a three-digit code. The first digit tells the client what happened:

• 2xx — Success. The requested action was completed.
• 3xx — Intermediate. The server needs more input (used after DATA).
• 4xx — Temporary failure. The client should retry later. Examples: mailbox full (452), server busy (421).
• 5xx — Permanent failure. Do not retry. Examples: user unknown (550), syntax error (500), relay denied (553).

The second digit narrows the category: x0x = syntax, x1x = information, x2x = connection, x5x = mail system. RFC 3463 further extends these with enhanced status codes like 5.1.1 (bad destination mailbox).

Key Technical Details

Envelope vs. Headers

A critical distinction in SMTP is between the envelope and the message headers. The envelope (MAIL FROM and RCPT TO) controls routing — it tells servers where to deliver the message. The message headers (From:, To:, Subject:) are part of the message body transmitted during DATA and are what the recipient sees. These can differ, and legitimately do in cases like mailing lists, BCC, and forwarding.

MX Lookup Process

When a client needs to deliver to user@example.com, it queries DNS for MX records for example.com. The process defined by RFC 5321:

1. Look up MX records for the domain. Sort by preference (lower number = higher priority).
2. If no MX records exist, fall back to an A or AAAA record for the domain itself.
3. If an MX record points to . (a "null MX" per RFC 7505), the domain does not accept mail.
4. Try each MX host in priority order. If a server returns a 4xx error, try the next host.

Line Length and Data Transparency

SMTP requires that lines in the message be no longer than 998 characters (excluding CRLF), with a recommended limit of 78 characters. The end-of-data marker is a line containing only a period (.). If a line in the message body starts with a period, the client must "dot-stuff" it by prepending an extra period, and the server must strip it.

Timeouts

RFC 5321 specifies minimum timeouts that clients MUST observe:

• Initial greeting: 5 minutes
• MAIL command: 5 minutes
• RCPT command: 5 minutes
• DATA initiation: 2 minutes
• Data block: 3 minutes
• DATA termination (final .): 10 minutes

These generous timeouts exist because receiving servers may perform expensive checks (spam filtering, virus scanning) before responding to the final dot.

SMTP Example

A complete SMTP transaction delivering a message:

Common Mistakes

• Confusing envelope and header addresses. The MAIL FROM envelope address is not the same as the From: header. SPF checks the envelope sender; DKIM signs the header. Getting this wrong causes authentication failures.
• Ignoring 4xx vs. 5xx distinction. A 450 means "try again later" — you should queue and retry with exponential backoff. A 550 means "never going to work" — continuing to retry generates unnecessary traffic and can harm your sender reputation.
• Not handling multi-line responses. A response like 250- (with a hyphen) means more lines follow. Only 250 (with a space) signals the final line.
• Sending without EHLO. Using the old HELO command instead of EHLO means you won't discover server extensions like STARTTLS, SIZE, or PIPELINING. Always use EHLO.
• Exceeding line length limits. Lines over 998 characters violate the spec and can cause message corruption. Use MIME encoding for long content.
• Ignoring the null sender. Bounce messages (DSNs) use an empty MAIL FROM:<>. Rejecting the null sender breaks the bounce loop prevention mechanism.
• Not implementing dot-stuffing. If your message body has a line starting with ., the server will interpret it as end-of-data unless you double the dot.

Deliverability Impact

RFC 5321 compliance directly affects whether your email reaches the inbox:

• Proper EHLO hostname. Your EHLO hostname should resolve in DNS (forward and reverse). Many receiving servers check that the EHLO name has a valid A/AAAA record and that reverse DNS for your IP matches. Mismatches are a spam signal.
• Bounce handling. RFC 5321 requires senders to process bounces. If you ignore DSNs, you'll keep sending to invalid addresses, which destroys your sender reputation. Mailbox providers track your bounce rate closely.
• Retry behavior. Proper retry logic with exponential backoff for 4xx errors shows you're a well-behaved sender. Aggressive retry behavior can trigger rate limiting or blocklisting.
• Connection behavior. Opening too many simultaneous connections to a single MX, or reconnecting too rapidly after being rejected, are patterns associated with spam. Respect connection limits and throttle appropriately.
• Envelope alignment. SPF and DMARC rely on the MAIL FROM domain. Ensuring your envelope sender domain aligns with your From: header domain is essential for passing authentication checks.

Related RFCs