LiveChat 
Support 
What Is SMTP? The Mail Protocol That Sends Your Email, Explained
Every time you press send, a protocol you have probably never thought about springs into action and carries your message across the internet. That protocol is SMTP, and understanding what it is and what it does removes a surprising amount of the mystery around how email works.
This article is a plain-language explainer of the mail protocol SMTP: what it stands for, the precise job it does, how a message actually travels from your device to someone else’s mailbox, and why SMTP is only one half of the email story. If you have already configured an email client and wondered why it asks for both an “outgoing server” and an “incoming server,” the answer is here. We will keep the focus on the protocol itself. The numbered ports SMTP uses are covered in a dedicated companion article, which we link to rather than repeat.
Key Takeaways
• SMTP stands for Simple Mail Transfer Protocol. It is the internet standard for sending and relaying email between mail systems.
• SMTP does exactly one half of the email job: pushing mail outward. A separate protocol, IMAP or POP3, retrieves mail so you can read it.
• A message travels: your client to your SMTP server, your server relays it to the recipient’s mail server, where it waits until they retrieve it via IMAP or POP3.
• SMTP works through a short conversation of commands: `HELO`/`EHLO`, `MAIL FROM`, `RCPT TO`, and `DATA`.
• SMTP AUTH requires you to log in before your server will send mail, which stops abuse.
• Deliverability records (SPF, DKIM, DMARC) ride alongside SMTP to prove your mail is legitimate.
What is SMTP?
SMTP stands for Simple Mail Transfer Protocol. It is the standard set of rules, first defined in the early internet RFCs and refined steadily since, that governs how email is sent and moved between servers. When two mail systems need to hand a message from one to another, SMTP is the language they speak to do it.
The word *transfer* in the name is the important one. SMTP is concerned entirely with moving mail from a sender toward a recipient. It is the postal carrier of the internet: it picks up your outgoing message and delivers it to the right destination server. What it does *not* do is let you read mail that has arrived for you. That is a separate job, handled by a separate protocol, and conflating the two is the single most common source of email confusion.
Because SMTP is a published, open standard rather than any one company’s product, every mail server, email client, and application on the internet can use it to exchange mail with every other. That universality is exactly why email works between providers at all.
What does SMTP actually do, and what does it not do?
It helps to state the boundary precisely. SMTP sends and relays outgoing mail. It does not retrieve, store, or display the mail already sitting in your mailbox.
This division is built into how email was designed. Sending a message and reading a message are genuinely different operations with different requirements, so the internet uses two different families of protocol for them:
- Sending and relaying (outbound): handled by SMTP.
- Retrieving and reading (inbound): handled by IMAP or POP3.
This is why every email app you have ever configured asks for two servers. The outgoing (SMTP) server is the one your messages leave through. The incoming (IMAP or POP3) server is the one your messages arrive into and are read from. They are configured separately because they are doing opposite jobs.
| SMTP | IMAP / POP3 | |
|---|---|---|
| Direction | Outbound (sending) | Inbound (retrieving) |
| Job | Send and relay mail toward the recipient | Fetch mail from your mailbox so you can read it |
| When it runs | When you press send | When you open or refresh your inbox |
| Server role in your app | The “outgoing server” | The “incoming server” |
| Authentication purpose | Proves you may send mail | Proves you may read this mailbox |
The companion explainer on incoming protocols covers the retrieval side in full, including why you would choose IMAP over POP3.
How does email actually travel from sender to recipient?
The clearest way to understand SMTP is to follow a single message on its journey. Suppose you send a message from your laptop to a colleague at another company. Here is the path it takes.
Step one: submission. Your email client (Outlook, Apple Mail, a phone, or an application) hands your outgoing message to *your own* mail server using SMTP. This first hop is called submission. Your server checks that you are allowed to send, accepts the message, and takes responsibility for it.
Step two: relay. Your mail server looks up where the recipient’s domain receives mail and opens an SMTP connection to the recipient’s mail server. It relays your message across the internet, server to server. This is the classic server-to-server SMTP hop, and it may pass through one or more intermediate servers along the way.
Step three: delivery to the mailbox. The recipient’s mail server accepts the message and files it into your colleague’s mailbox, where it sits and waits.
Step four: retrieval. When your colleague opens their email, their client connects to *their* mail server using IMAP or POP3 and pulls the message down to read. Notice that SMTP plays no part in this final step. SMTP’s job ended the moment your message was delivered into the recipient’s mail system.
So the full journey is: your client to your SMTP server, to the recipient’s mail server (all SMTP), then from that mailbox to the recipient’s screen via IMAP or POP3. SMTP carries the message most of the way, but a different protocol completes the last leg.
What does the SMTP conversation look like?
Under the surface, SMTP is a remarkably readable text conversation. When one mail system connects to another, they exchange a short series of commands and numeric reply codes. You do not need to memorise these, but seeing them demystifies what is happening on the wire.
The core commands, in the order they typically occur, are:
- `HELO` or `EHLO` — the opening greeting. The connecting system introduces itself and asks who it is talking to. `EHLO` is the modern, extended version that also asks the receiving server which optional features it supports, such as authentication and encryption.
- `MAIL FROM` — declares the envelope sender: who the message is from for delivery purposes.
- `RCPT TO` — declares the envelope recipient: who the message is for. This command can be repeated for multiple recipients.
- `DATA` — signals that the actual message content (headers and body) follows. The sender transmits the message, then ends it with a single dot on its own line.
After `DATA`, the receiving server replies with a status code indicating whether it accepted the message for delivery. Throughout, the receiving server answers each command with a three-digit reply code: codes in the 200s mean success, 400s mean a temporary problem to retry later, and 500s mean a permanent failure. If you have ever seen a bounce message quoting a code like `550`, that number came straight out of this SMTP exchange.
This simple, legible conversation is the whole protocol in action. Everything else, including security and deliverability, is layered on top of these basic steps.
The single clearest way to understand email is to accept that it takes two different protocols doing opposite jobs, and SMTP only does half of it. SMTP is exclusively about sending and relaying mail outward — getting your message off your device, through the servers, and onto the recipient’s mail server. A completely separate protocol, IMAP or POP3, handles retrieving mail so you can actually read it. People conflate “email” with one single system, but it is really a postal *sending* service (SMTP) bolted onto a mailbox *retrieval* service (IMAP/POP3). This split quietly explains a great deal of real-world confusion: it is why every mail app makes you configure both an “outgoing (SMTP) server” *and* an “incoming (IMAP/POP3) server”; it is why you can sometimes receive mail perfectly but fail to send (an SMTP problem) or send fine but never receive (a retrieval problem); and it is why every deliverability tool you will ever read about — SPF, DKIM, DMARC — concerns the *sending* side. SMTP is the mail carrier heading out the door. It never brings the mail back in.
How does SMTP authentication work, and why is it required?
In the early internet, a mail server would relay mail for almost anyone who asked. That openness was promptly abused: spammers used any willing server as a free megaphone. The fix is SMTP AUTH, an extension that requires a sender to log in before the server will accept their mail for sending.
This is why your email client asks for a username and password for the *outgoing* server, not just the incoming one. When you submit a message, your client authenticates with your mailbox credentials, and only then does your server agree to send on your behalf. An unauthenticated stranger gets refused.
SMTP AUTH is the reason “outgoing server requires authentication” must be enabled in your mail client. If it is switched off, your own server will reject your messages, because it cannot tell you apart from an abuser. Authentication is what makes outgoing mail accountable: every message your server relays is tied to a known, logged-in user.
How do SMTP and email deliverability relate?
Sending a message successfully and having it land in the recipient’s inbox are two different achievements. SMTP gets your message *delivered to* the recipient’s server. Whether that server trusts it enough to place it in the inbox rather than the spam folder depends on a set of domain authentication records that travel alongside the SMTP transaction.
The three that matter are:
- SPF (Sender Policy Framework): a published list of which servers are allowed to send mail for your domain.
- DKIM (DomainKeys Identified Mail): a cryptographic signature that proves a message genuinely came from your domain and was not altered in transit.
- DMARC (Domain-based Message Authentication, Reporting and Conformance): a policy tying SPF and DKIM together and telling receiving servers what to do if a message fails the checks.
These are not part of SMTP itself, but they ride alongside every SMTP send to prove the mail is legitimate. A perfectly executed SMTP transaction will still land in spam if these records are missing or wrong. The dedicated deliverability guide explains how to set them up correctly.
What is SMTP relay and a smarthost?
Two related terms come up constantly once you start sending mail at any scale, and both are just specific uses of SMTP.
SMTP relay is the act of one mail server passing a message on to another server for onward delivery, rather than delivering it directly to a final mailbox. The server-to-server hop in our journey above is a relay. Applications that send transactional email, such as receipts or password resets, typically relay their mail through a mail server rather than trying to deliver it themselves.
A smarthost is a designated mail server that an application or another server sends all of its outgoing mail through, instead of contacting each recipient’s server directly. Configuring a smarthost means your application authenticates to one trusted, well-configured SMTP server and lets it handle the relaying, the encryption, and the deliverability records. This is the standard, reliable way to send application email, because the smarthost has the proper authentication and reputation that a random server would lack.
Which ports does SMTP use?
SMTP conversations happen over numbered network ports, and the choice of port determines whether you are submitting mail from a client or relaying it between servers, and how the connection is encrypted. In short: client submission uses port 587 (with STARTTLS) or port 465 (with implicit TLS), while server-to-server relay uses port 25, which is why networks block port 25 for ordinary clients.
The ports are a topic in their own right, with several common numbers and a few important gotchas about encryption and which one to configure. Rather than duplicate that detail here, the companion article covers it precisely.
DarazHost business email and the full mail journey
Because email genuinely takes two protocols doing opposite jobs, getting it right means configuring both halves correctly, and that is exactly what DarazHost business email does for you. On the sending side, it provides properly configured, authenticated SMTP with SPF, DKIM, and DMARC set up for your domain, so your mail not only sends reliably but is trusted enough to reach the inbox. On the receiving side, it supports IMAP and POP3 so you can retrieve and read your mail on any device, desktop or mobile.
The result is email that handles the complete journey: messages that send correctly *and* arrive correctly, on a setup that is secure by default. DarazHost provides the exact outgoing and incoming server settings for whatever client or application you use, and 24/7 support stands behind it. For the wider picture of running email on your own domain, see our complete guide to professional business email hosting.
Frequently asked questions
What is SMTP in simple terms? SMTP, or Simple Mail Transfer Protocol, is the internet standard for sending and relaying email. It is the protocol that carries your message from your device, through mail servers, to the recipient’s mail server. It handles sending mail outward, not reading mail that has arrived.
What is the difference between SMTP and IMAP or POP3? SMTP sends and relays outgoing mail; IMAP and POP3 retrieve incoming mail so you can read it. They do opposite jobs, which is why your email app asks you to configure a separate outgoing (SMTP) server and incoming (IMAP/POP3) server.
Does SMTP receive email? Not in the sense of letting you read it. SMTP delivers a message into the recipient’s mail server, but retrieving that message from the mailbox to read it is done by IMAP or POP3. SMTP’s role ends once the message reaches the destination mail server.
Why does sending email require a password? Because of SMTP AUTH. To stop spammers from abusing mail servers, modern servers require you to authenticate with your mailbox credentials before they will send mail on your behalf. This is why the outgoing server in your client needs a username and password.
Is SMTP secure? SMTP can and should be secured. Modern mail submission uses encryption (STARTTLS or implicit TLS) and requires authentication, so credentials and content are protected in transit. Deliverability records like SPF, DKIM, and DMARC add a further layer that proves your mail is legitimate.
