SMTP

SMTP (Simple Mail Transfer Protocol) is the Internet standard for transferring email from a sender’s system to the mail server responsible for the recipient’s domain. Defined today in RFC 5321, with the message format covered separately by RFC 5322, it is the push protocol of email infrastructure: every message that crosses the Internet travels at least one SMTP hop between servers.

SMTP only moves messages toward a mailbox; it does not let users read them. Retrieval is the job of IMAP and POP3, while SPF, DKIM and DMARC add the sender authentication that the original protocol never had. Understanding SMTP therefore means understanding the transport layer on which all of these mechanisms depend.

How an SMTP session transfers a message

An SMTP transfer is a text-based command and reply dialogue over a TCP connection, in which the client issues commands and the server answers each one with a three-digit reply code. The client is either a mail program submitting a new message or a Mail Transfer Agent relaying one; the server is the next Mail Transfer Agent on the path.

Before connecting, a relaying server looks up the MX records of the recipient domain in DNS and tries the hosts in order of preference, lowest value first. If a domain has no MX record, the sender falls back to the domain’s A or AAAA address, a rule known as the implicit MX. A domain can publish a null MX record to state that it accepts no mail at all.

The table below shows the core commands of a typical session in the order they occur.

The message content ends with a line containing a single period, the sequence CRLF.CRLF. To keep a body line that begins with a period from ending the message early, the client adds an extra period, a technique called dot-stuffing, which the receiver removes. Each line, including the CRLF, may hold at most 1,000 characters.

Envelope, headers and reply codes

SMTP separates the envelope from the message content, and confusing the two is one of the most common sources of misunderstanding. The envelope sender and recipients from MAIL FROM and RCPT TO control routing and bounces, while the From and To header lines are only text inside the message that the mail client displays.

This separation explains why Bcc works (the recipient exists only in the envelope) and why a forged From header was historically easy. SPF checks the envelope sender domain, DKIM signs the content, and DMARC ties the authenticated domain back to the visible From domain.

Reply codes tell the client what to do next. The first digit carries the decision, which is why robust software reacts to the class of the code rather than to its wording.

The distinction between 4xx and 5xx drives queueing behavior. A sending server keeps a message after a transient failure and retries it; the standard recommends a retry interval of at least 30 minutes and a give-up time of at least 4 to 5 days before a non-delivery report is generated. Greylisting deliberately exploits this rule by answering unknown senders with a temporary 4xx code.

Ports, submission and relay roles

Modern email separates message submission by users from server-to-server relay, and each role uses its own port and security policy. Mixing them up is a frequent configuration error in applications that send mail.

Port 465 was briefly assigned, withdrawn and later standardized again for implicit TLS submission, so both 465 and 587 are legitimate today. Many residential and cloud networks block outbound port 25 to stop compromised machines from sending spam directly, which is why applications should submit through 587 or 465 to an authenticated relay.

A server that accepts mail from anyone for any destination is an open relay. Open relays are quickly abused for spam and placed on blocklists, so a correctly configured server relays only for authenticated users or trusted networks and accepts unauthenticated mail only for its own domains.

SMTP compared with retrieval protocols

SMTP delivers mail to a server, whereas IMAP and POP3 let a user read mail from a server. A complete email exchange therefore combines at least two protocols, and each has a distinct job.

Proprietary APIs such as HTTP-based sending services often replace SMTP at the submission step, but between independent organizations the transfer still happens over SMTP. No widely deployed alternative has displaced it for inter-domain delivery.

Security limits and protective extensions

The original protocol from 1982 had no encryption and no sender authentication, and later standards add these properties as optional layers. Each layer closes a specific gap, but none of them is enforced unless both sides support and require it.

• STARTTLS encrypts the hop, but on port 25 it is opportunistic, so an attacker who strips the STARTTLS offer can force a downgrade to plaintext.
• MTA-STS and DANE let a receiving domain publish a policy that requires TLS with a valid certificate, which defeats the downgrade attack.
• SPF, DKIM and DMARC authenticate the sending domain, but they do not encrypt anything and do not stop a lookalike domain.
• TLS protects only each hop separately; every server along the path sees the message in clear text unless end-to-end encryption such as S/MIME or OpenPGP is used.

A practical consequence is that deliverability now depends more on authentication and reputation than on SMTP itself. Large mailbox providers reject or quarantine bulk mail that lacks aligned SPF or DKIM and a published DMARC policy.

Understanding it simply

SMTP is the postal service between mail servers. When you press send, your mail program hands the message to an outgoing server, and that server finds out which server handles the recipient’s address and passes the message along.

It works like a short, polite conversation: one server says who it is, who the letter is from, who it is for, and then hands over the letter. The other side answers with numbers that mean accepted, try again later, or refused. SMTP only carries letters to the right mailbox; reading them is the job of other protocols.

Applied in practice

An online shop sends order confirmations from a web application. At first, the developers point the application at port 25 of an external mail server, and in production nothing arrives, because the hosting provider blocks outbound port 25.

The team switches to port 587 with STARTTLS and authenticated submission to a dedicated relay, publishes an SPF record that authorizes that relay, enables DKIM signing and adds a DMARC record that starts at monitoring. Logs then show 250 replies from recipient servers, and a temporary 451 reply from one provider resolves itself after the relay retries 30 minutes later.

Within two weeks the share of confirmations landing in spam folders drops sharply, and the shop moves its DMARC policy to quarantine. The fix was not in SMTP itself but in using the right submission port and authenticating the domain that SMTP carries.