What Is an SMTP Server?
An SMTP server is a computer or service that sends and relays outgoing email using the Simple Mail Transfer Protocol. When you hit send, your mail client hands the message to an SMTP server, which authenticates you, then routes the message toward the recipient's mail server across the internet. SMTP handles outbound delivery; separate protocols like IMAP and POP handle retrieving mail into an inbox.
- Protocol
- Simple Mail Transfer Protocol, defined in RFC 5321 (IETF)
- Common ports
- 587 (submission with STARTTLS), 465 (implicit TLS), 25 (server-to-server)
- Job
- Sending and relaying outbound mail, not storing inboxes
- Paired protocols
- IMAP and POP3 retrieve mail; SMTP only sends (industry-typical)
What does an SMTP server actually do? #
An SMTP server is the piece of email infrastructure responsible for moving a message from the sender toward the recipient. SMTP stands for Simple Mail Transfer Protocol, the standardized set of commands mail systems use to hand off messages. When you compose an email and click send, your mail app opens a connection to your outgoing SMTP server, authenticates, and transfers the message along with its envelope: who it is from, who it is to, and the content. The SMTP server then looks up where the recipient's domain accepts mail and relays the message onward, server to server, until it reaches the mailbox provider that hosts the recipient. Crucially, SMTP only sends and relays; it does not store your inbox or let you read incoming mail. That job belongs to IMAP or POP3. Think of the SMTP server as the post office that accepts and routes outgoing letters, while your inbox is the mailbox where delivered letters wait. For local businesses, a reliable SMTP path is what turns a website form into an email that actually arrives.
How does SMTP move a message step by step? #
The process is a short conversation of plain-text commands. Your client connects to the SMTP server on a submission port and greets it with EHLO. The server offers its capabilities, and the client starts an encrypted session with STARTTLS. The client then authenticates with a username and password. Next it declares the envelope: MAIL FROM sets the return path, and one or more RCPT TO commands name the recipients. The client sends DATA, followed by the headers and body, and ends with a single dot on its own line. The server accepts the message with a 250 OK response and takes responsibility for it. If the recipient is on another domain, the server performs a DNS lookup for that domain's MX records to find the receiving mail server, then repeats a similar SMTP conversation to relay the message onward. Each hop can accept, defer, or reject. The DNS piece that makes this routing possible is explained in /wiki/what-is-dns, and it is why correct DNS records are essential for mail to flow.
What is the difference between SMTP, IMAP, and POP3? #
These three protocols split email into distinct jobs, and confusing them causes most setup mistakes. SMTP is the sending protocol: it pushes outbound mail from your client to a server and relays it between servers. IMAP and POP3 are retrieval protocols: they pull delivered mail from your provider into your app so you can read it. IMAP keeps messages on the server and syncs across all your devices, so an email read on your phone shows as read on your laptop; it is the modern default. POP3 downloads messages to one device and traditionally removes them from the server, which suits a single-machine setup but does not sync well. In a typical account you configure both an SMTP server for outgoing and an IMAP server for incoming, often on the same provider. When email breaks, it helps to know which direction failed: cannot send points to SMTP or authentication, cannot receive points to IMAP, POP, or DNS. We sort out these settings for clients as part of /services/domains-dns-email so both directions work reliably.
Which ports and encryption does SMTP use? #
Port choice signals how the connection is secured. Port 587 is the modern standard for mail submission from a client to a server; the connection starts unencrypted and upgrades to TLS with the STARTTLS command, and authentication is required. Port 465 provides implicit TLS, meaning the connection is encrypted from the first byte; it was deprecated, then re-standardized, and remains widely supported. Port 25 is reserved for server-to-server relay, the hops between mail servers, and most residential and cloud networks block outbound port 25 to curb spam, which is why you should never use it for client submission. Always use 587 or 465 with TLS and authentication for sending from an app or website. Using an encrypted, authenticated submission port protects credentials and message contents in transit and is expected by every reputable provider. Misconfigured ports are a frequent cause of send failures we diagnose during migrations and rescues; getting them right is part of a clean setup on /services/managed-hosting.
Do I need my own SMTP server? #
Almost never. Running your own SMTP server means managing IP reputation, blocklist monitoring, authentication, feedback loops, and security patches, a serious ongoing job. For nearly every US local business, the better path is to use a managed sending service or the SMTP relay bundled with your email or hosting provider. These services maintain warm, reputable IPs and handle the operational burden, so your mail is far more likely to land in the inbox. You simply point your website, app, or mail client at their SMTP host, port, and credentials. Self-hosting only makes sense for large senders with dedicated deliverability teams, and even they usually outsource. A common trap for small businesses is relying on a shared web host's built-in mail() function, which sends from a poorly reputed shared IP and frequently lands in spam. We steer clients toward a proper authenticated relay instead, configured through /services/domains-dns-email, and connect it to the site so forms and confirmations deliver reliably rather than vanishing.
How do I configure SMTP for a website or app? #
You need five things from your provider: the SMTP host, the port, whether to use TLS, and a username and password (or an API key acting as credentials). In your website platform, form plugin, or application, enter these where it asks for outgoing mail settings, choosing port 587 with STARTTLS or 465 with TLS. Set the from address to a mailbox on a domain you control and have authenticated, not a free consumer address, because sending as gmail.com from your server fails DMARC. Test by triggering a real message, a form submission or password reset, and confirm it arrives and passes authentication. Keep credentials in environment variables or a secrets store, never hard-coded in public files. Below is a minimal example of the SMTP conversation for reference. When we build sites and apps on /services/web-app-development, we wire this in and verify placement with our /tools/email-deliverability-checker so the connection is proven before launch.
S: 220 mail.example.com ESMTP ready
C: EHLO app.mybusiness.com
S: 250-mail.example.com
S: 250 STARTTLS
C: STARTTLS
S: 220 Ready to start TLS
C: AUTH LOGIN (username + password, base64)
S: 235 Authentication successful
C: MAIL FROM:<[email protected]>
S: 250 OK
C: RCPT TO:<[email protected]>
S: 250 OK
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: Subject: Your appointment is confirmed
C: (headers + message body)
C: .
S: 250 OK: queued as 7F3A2
C: QUIT
S: 221 ByeHow does SMTP relate to email deliverability? #
The SMTP server is the on-ramp, but authentication and reputation decide whether the message reaches the inbox. When your SMTP server relays a message, the receiving server checks SPF to confirm the sending IP is allowed for your domain, validates the DKIM signature to ensure the message was not altered, and applies your DMARC policy. It also weighs the sending IP's reputation and any blocklist entries. So a technically working SMTP connection can still deliver straight to spam if the sending domain is not authenticated or the IP is poorly reputed. This is why the choice of SMTP provider matters: reputable relays keep their IPs clean and support easy DKIM signing. It is also why using a shared host's mail function so often fails. Correct DNS records tie your domain to your chosen SMTP path, which is why /wiki/what-is-dns and SMTP setup go hand in hand. We configure both together and confirm real inbox placement rather than assuming a green connection means delivery, all covered under /services/domains-dns-email.
What are common SMTP problems and fixes? #
The most frequent error is authentication failure, usually a wrong username, password, or an app-specific password requirement; fix the credentials and confirm the provider does not need a separate app password. Connection timeouts often mean the wrong port or a blocked port 25; switch to 587 or 465. Messages that send but land in spam point to missing SPF, DKIM, or DMARC rather than an SMTP fault, so audit DNS. A relay access denied error means you are trying to send through a server that does not trust you, common when a site's from address does not match an authenticated domain. Rate-limit or throttling responses appear when you send too fast on a new setup and are best solved by warming up gradually, as covered in /wiki/what-is-email-warmup. TLS negotiation errors usually come from outdated software or a mismatched encryption setting. We diagnose these during website migrations and rescues through /services/website-migrations and /services/website-rescue, restoring reliable sending so forms, confirmations, and resets stop disappearing.
FAQ
What is an SMTP server in simple terms?
It is the outgoing mail server that accepts your message when you hit send and relays it toward the recipient using the Simple Mail Transfer Protocol. Think of it as the post office for outbound email. It only sends and routes mail; reading your inbox is handled by IMAP or POP instead.
What port should I use for SMTP?
Use port 587 with STARTTLS for modern client submission, or port 465 with implicit TLS, both with authentication. Avoid port 25 for sending from apps or clients, since it is meant for server-to-server relay and is usually blocked on residential and cloud networks to reduce spam.
Is SMTP the same as email?
No. SMTP is only the protocol for sending and relaying outbound messages. Retrieving and reading mail uses IMAP or POP3. A full email setup combines an outgoing SMTP server with an incoming IMAP or POP server, plus DNS records that route and authenticate the mail correctly.
Do I need my own SMTP server for my business?
Almost never. Running one means managing IP reputation, blocklists, and security yourself. For a local business, use a managed sending service or your provider's authenticated relay, which keeps IPs clean and mail in the inbox. We set this up as part of /services/domains-dns-email so you avoid the operational burden.
Why does my website email go to spam even though SMTP works?
A working connection only means the message was accepted for sending. Placement depends on authentication and reputation. Missing SPF, DKIM, or DMARC records, or sending from a shared host's poorly reputed IP, sends legitimate mail to spam. Authenticate a proper domain and use a reputable relay to fix it.
What is the difference between SMTP and IMAP?
SMTP sends and relays outgoing mail from your client to a server and between servers. IMAP pulls delivered mail from your provider into your app and syncs read status across devices. You configure SMTP for outgoing and IMAP for incoming, usually with the same provider, to make an account fully work.
Was this helpful?