SMTP stands for Simple Mail Transfer Protocol. Here is what that means in practice, how a message actually travels, and why the details matter when you start sending at volume.
SMTP stands for Simple Mail Transfer Protocol.
It's the standard protocol computers use to send email across the internet. Every email you've ever sent, whether from Gmail, Outlook, a company server, or an application, moved over SMTP at some point in its journey.
The name is literal. Simple, because the original design was deliberately minimal. Mail, because it carries email. Transfer, for its job of moving messages between servers. Protocol, because two machines need agreed rules to understand each other.
SMTP was defined in 1982 in RFC 821, written by Jonathan Postel. The modern version most servers use today lives in RFC 5321, published in 2008. A protocol designed in the early 80s still carries essentially all the world's email. That says something about how well it was designed.
In a networking syllabus, SMTP shows up as an application layer protocol in the TCP/IP model. That placement matters for understanding what it does and doesn't do.
| Layer | Protocol examples | Job |
|---|---|---|
| Application | SMTP, HTTP, FTP, DNS | Defines what the message means |
| Transport | TCP, UDP | Ensures the data arrives intact |
| Internet | IP | Routes packets between networks |
| Link | Ethernet, Wi-Fi | Moves bits over physical media |
SMTP sits at the top. It defines the conversation: the commands, the responses, the order things happen in. TCP underneath handles reliable delivery. DNS handles routing.
One thing worth remembering. SMTP is a push protocol. It pushes mail from a client to a server, and from one server to another. It doesn't pull mail into your inbox. That's a different job, and POP3 or IMAP does it.
Say you send an email from you@yourcompany.com to customer@example.com. This is the sequence.
Step 1. Your client connects to your outgoing server. Your email client or application opens a TCP connection to your SMTP server. In business setups, that's usually port 587.
Step 2. The handshake. The client announces itself with EHLO. The server replies with a list of what it supports: encryption, authentication methods, maximum message size.
Step 3. Encryption. The client issues STARTTLS and the connection upgrades to an encrypted channel. Everything after this point is protected in transit. Any modern server insists on this. If yours doesn't, replace it.
Step 4. Authentication. The client proves who it is with AUTH LOGIN and credentials. This is what stops the rest of the internet from sending mail through your server.
Step 5. The envelope. The client tells the server who the message is from and where it's going:
MAIL FROM:<you@yourcompany.com>
RCPT TO:<customer@example.com>These are the envelope addresses. They're separate from the From and To headers a recipient sees. The distinction matters for authentication and bounce handling.
Step 6. The message. The client sends DATA, then the headers and body, ending with a single dot on its own line.
Step 7. DNS lookup. Your server queries the MX (Mail Exchange) records for example.com in DNS. Those records say which servers accept mail for that domain, and in what priority order.
Step 8. Server-to-server transfer. Your server opens a new SMTP session to the recipient's mail server on port 25 and runs a similar conversation. Mail may pass through intermediate relays before it lands.
Step 9. Delivery to the mailbox. The receiving server accepts the message and files it. In an inbox. In a spam folder. Sometimes in the bin.
Step 10. Retrieval. The recipient's client fetches the message using IMAP or POP3. SMTP's job ended at step 9.
The whole sequence usually finishes in under a second when nothing's broken.
The protocol is readable text. Part of why it has lasted this long is that you can hold an SMTP conversation by hand over a terminal.
| Command | What it does |
|---|---|
HELO / EHLO | Client introduces itself. EHLO is the extended version and returns server capabilities |
STARTTLS | Upgrades the connection to TLS encryption |
AUTH | Authenticates the client with credentials |
MAIL FROM | Sets the envelope sender |
RCPT TO | Sets an envelope recipient (repeated for multiple recipients) |
DATA | Begins the message headers and body |
RSET | Aborts the current transaction |
VRFY | Asks the server to verify an address (usually disabled — spammers abused it) |
QUIT | Ends the session |
Server responses are three-digit codes. 250 is success. Codes starting with 4 are temporary failures. Retry them. That's a soft bounce. Codes starting with 5 are permanent. Don't retry them. That's a hard bounce. A well-behaved sending system retries soft bounces and permanently suppresses hard ones. Getting this backwards ruins your sending reputation faster than almost anything else.
SMTP uses different ports for different purposes. Picking the wrong one is the most common configuration mistake we see.
| Port | Use | Encryption |
|---|---|---|
| 25 | Server-to-server relay | Opportunistic STARTTLS |
| 587 | Client submission — use this one | STARTTLS required |
| 465 | Implicit TLS submission | TLS from connection start |
| 2525 | Unofficial alternative | STARTTLS |
Port 587 is the correct choice for an application or client sending mail. Port 25 is for servers relaying to each other, and most Indian ISPs and cloud providers block outbound port 25 on ordinary connections to limit spam.
We get support tickets almost every week that read “connection refused on port 25.” The cause is always the ISP. The fix is always 587, never a request to unblock 25.
Port 2525 is a fallback for networks that block the standard ports. It isn't an official standard, but most relays support it. There's a fuller breakdown in our guide to SMTP port numbers.
These three get confused constantly, and the difference is simply direction.
| SMTP | POP3 | IMAP | |
|---|---|---|---|
| Direction | Sending | Receiving | Receiving |
| Full form | Simple Mail Transfer Protocol | Post Office Protocol v3 | Internet Message Access Protocol |
| Default port | 587 / 25 | 110 (995 with TLS) | 143 (993 with TLS) |
| Where mail lives | In transit | Downloaded to one device | Stays on server |
| Multi-device | N/A | Poor | Designed for it |
SMTP sends. POP3 and IMAP receive. They're complementary, not alternatives. Your mail client uses SMTP to send and IMAP to read at the same time, over separate connections.
POP3 downloads messages and traditionally deletes them from the server. That suited the single-device era. IMAP keeps everything on the server and syncs state (read, unread, folders) across every device you own. For almost any modern use, POP3 belongs in a museum. Use IMAP.
Most email problems people run into come from misreading the protocol's limits.
SMTP doesn't guarantee delivery to the inbox. It guarantees the message was handed to the receiving server. What that server does with it, whether it files it in the inbox, drops it in spam, or discards it, is entirely its own call, based on your sending reputation.
SMTP has no built-in sender verification either. The protocol will happily let any server claim to be sending from any address. SPF, DKIM and DMARC were bolted on afterwards to fix that. They're separate DNS-based mechanisms that let a receiver check whether a sender is authorised.
There's no built-in encryption. STARTTLS is an extension, not part of the original design. Without it, mail moves in plain text.
And SMTP doesn't scale by itself. Sending one message is trivial. Sending fifty thousand, while managing IP reputation, honouring per-provider rate limits, retrying soft bounces correctly and suppressing hard ones, is an operational problem the protocol never tried to solve.
You can run your own SMTP server. Most organisations that try eventually stop. It isn't because the software is hard to install.
IP reputation is the hard part. A brand-new IP has no sending history. Mailbox providers treat unknown IPs with suspicion and will throttle or reject mail until the IP builds a track record of well-received sends. Warming it properly takes weeks of gradual sending.
Port 25 is blocked on most networks. Cloud providers and Indian ISPs routinely block it, so a self-hosted server often can't deliver at all without a specific arrangement with the upstream.
Deliverability itself demands constant attention. Blocklist monitoring. Feedback loop processing from providers. Bounce handling. Reverse DNS. IP rotation under load.
An SMTP relay is a hosted service that handles all of this for you. Your application connects to the relay over standard SMTP with credentials, and the relay takes care of reputation, retries, authentication and delivery. Your code doesn't change. It's still SMTP.
At neuMails, that SMTP relay runs on dedicated IPs in AWS Mumbai, with SPF, DKIM and DMARC alignment configured for your domain, and per-message logs so you can see what happened to every send. Because the infrastructure is in India, delivery to Indian recipients skips an unnecessary international round trip. Billing is in INR with a GST invoice, and the free tier includes 5,000 emails every month.
| Error | Meaning | Fix |
|---|---|---|
550 5.7.1 Relay access denied | Server won't relay for you | Authenticate before sending |
421 Too many connections | Rate limited | Reduce concurrency, retry with backoff |
535 Authentication failed | Wrong credentials | Check username and password or API key |
Connection timed out on port 25 | Port blocked by network | Switch to port 587 |
454 TLS not available | STARTTLS failed | Check TLS settings and certificate |
550 5.1.1 User unknown | Address doesn't exist | Hard bounce — suppress permanently |
Simple Mail Transfer Protocol. It's the internet standard for sending email between clients and servers.
Sending. POP3 and IMAP handle receiving.
Port 587 for applications and clients. Port 25 is for server-to-server relay and is blocked on most consumer and cloud networks.
Not on its own. SMTP with STARTTLS encrypts the connection in transit, which every modern server should do. Sender authenticity needs SPF, DKIM and DMARC layered on top.
SMTP is the protocol. An SMTP relay is a hosted service that speaks the protocol on your behalf and manages IP reputation, retries and deliverability. Under the hood, it's still SMTP, and any application that already speaks SMTP can point at a relay without code changes.
Yes, but volume introduces problems the protocol doesn't solve: rate limits, reputation, bounce handling. A relay built for volume handles them.
The same thing. In coursework, it's classified as an application layer protocol in the TCP/IP model, running over TCP.
Dedicated IPs, India-hosted infrastructure, per-message logs. 5,000 emails free every month.
Start Free — No Card Needed