SMTP
SMTP is the protocol mail servers use to hand messages to one another. It is a conversation of short commands and numeric replies: who the message is from, who it is for, then the message itself. Almost everything else in email — authentication, encryption, bounce handling — is either an extension to it or a reaction to what it does not do.
At a glance
- Category
- Protocols
- Full name
- Simple Mail Transfer Protocol
- Conversation
- EHLO, MAIL FROM, RCPT TO, DATA, then a reply code
- Reply codes
- 2xx accepted, 4xx try again later, 5xx permanent refusal
- Ports
- 25 between servers; 587 for authenticated submission
- Specified in
- RFC 5321
How it works
A sending server connects and greets the receiver, which answers with the extensions it supports. The sender announces the envelope sender, then each recipient, each of which is accepted or refused individually. It then sends the message itself and ends with a full stop on a line of its own. The receiver answers with a numeric code: accepted, try again later, or refused permanently. That code is the origin of every delivery event and every bounce you will later read.
Why it matters
SMTP was designed for a network where every host was trusted, so it has no native notion of who is allowed to claim an address. Every authentication mechanism in email exists to patch that gap from the outside, which is why SPF, DKIM and DMARC are separate layers rather than features of the protocol. Knowing the conversation also demystifies the reporting: a temporary code is a deferral, a permanent code is a bounce, and there is no third thing.
Example
A message for someone at example.com is offered to the receiving server named in the domain's MX record. The envelope sender is accepted, the recipient is accepted, and after the message body the server answers with a code in the 200 range and an identifier of its own. That acceptance becomes a delivery event. Had it answered in the 500 range, the same exchange would have produced a hard bounce with the server's reason attached.
Common mistakes
- 01Reading a 250 acceptance as proof the message reached an inbox, when it only means the next server took responsibility for it.
- 02Treating a 4xx code as a failure, when it is an instruction to try again and usually succeeds on the retry.
- 03Sending authenticated submission traffic to port 25, which many networks block outright for anything but server-to-server relay.
- 04Assuming the protocol authenticates the sender, when nothing in the conversation itself proves who anybody is.
In Rasket
Rasket sends over an HTTPS API rather than asking you to open an SMTP connection, and the reply the receiving server gave still reaches you as a delivery or bounce event. Email API
Related terms
Frequently asked questions
Should I use SMTP or an HTTP email API?
An HTTP API fits the tooling most applications already have, with ordinary status codes and no connection handling. SMTP remains useful when an existing system or appliance can only speak it.
Why are there two ports?
Port 25 is for servers relaying to one another, and port 587 is for an authenticated client submitting a new message. Many networks block outbound port 25 to limit compromised machines sending spam.
Does SMTP encrypt anything by itself?
No. Encryption comes from the STARTTLS extension, which upgrades an existing plain connection. That upgrade is optional by default, which is the gap MTA-STS exists to close.
Sources
Last updated 16 September 2026.
Start sending this morning
Verify a domain and send your first email in minutes.