An SMTP server is the mail transport system your app, device, or mail client connects to when it needs to send email. It accepts a message, checks the sender and recipient, queues the message, and relays it toward the recipient's mail infrastructure using the SMTP protocol.

If you searched for `smtp server`, `what is an smtp server`, or `smtp server example`, use this guide to understand the model first. Then move into configuration and testing with the MailSlurp workflows linked below.

## Quick answer: what does an SMTP server do?

An SMTP server handles outbound email transfer. It receives a message from a trusted client, validates the envelope, negotiates security and authentication, queues the message, and relays it to the next mail server on the delivery path.

That means a successful SMTP response only proves the server accepted the message. Product teams still need to verify that the message reached the right inbox, carried the right headers, and contained the right link, OTP, attachment, or template content.

## Which SMTP server page do you need?

| Goal                                                             | Start here                                                                        |
| ---------------------------------------------------------------- | --------------------------------------------------------------------------------- |
| Understand what an SMTP server is                                | This guide                                                                        |
| Configure host, port, TLS, auth, and sender details              | [SMTP server configuration checklist](/blog/smtp-server-configuration-checklist/) |
| Test host, port, TLS, auth, and transcript behavior              | [SMTP tester](/tools/smtp-tester/)                                                |
| Understand relay setup and closed relay policy                   | [SMTP relay guide](/guides/smtp-relay/)                                           |
| Prove that app email reaches a safe test inbox                   | [Email Sandbox](/product/email-sandbox/)                                          |
| Add automated assertions for password resets, OTPs, and receipts | [Email integration testing](/product/email-integration-testing/)                  |

## SMTP server examples

Common SMTP server examples include:

- `smtp.gmail.com` for Gmail mailbox-authenticated submission
- `smtp-relay.gmail.com` for Google Workspace relay use cases
- `smtp.office365.com` or Microsoft 365 SMTP submission endpoints
- a managed transactional email provider's SMTP relay host
- an internal mail transfer agent such as Postfix, Exim, or Sendmail
- a local or sandbox SMTP server used only for testing

The host name alone is not enough. A working SMTP setup also needs the correct port, TLS mode, authentication method, sender identity, and DNS posture for the domain sending the message.

## SMTP server settings you usually need

Most applications ask for a similar group of SMTP settings:

| Setting           | What it controls                                                                                  |
| ----------------- | ------------------------------------------------------------------------------------------------- |
| SMTP host         | The server your app connects to for mail submission                                               |
| SMTP port         | The submission path and transport mode, usually `587`, `465`, or provider-specific fallback ports |
| TLS mode          | STARTTLS, implicit TLS, or another provider-documented mode                                       |
| Username          | The account, mailbox, or token identity used for SMTP AUTH                                        |
| Password or token | The credential used by the SMTP client                                                            |
| From address      | The visible sender identity customers see                                                         |
| Sender domain DNS | SPF, DKIM, DMARC, MX, and related authentication posture                                          |

For the implementation checklist, use [SMTP server configuration checklist](/blog/smtp-server-configuration-checklist/). For provider-specific examples, use [Gmail SMTP server](/guides/gmail-smtp-server/), [Outlook SMTP settings](/guides/outlook-smtp-settings/), or [Office 365 SMTP settings](/guides/office-365-smtp-settings/).

## SMTP server example: command flow

```text
S: 220 smtp.example.com ESMTP ready
C: EHLO app.example.com
S: 250-STARTTLS
S: 250-AUTH LOGIN PLAIN
C: MAIL FROM:<sender@example.com>
S: 250 2.1.0 OK
C: RCPT TO:<recipient@example.com>
S: 250 2.1.5 OK
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: Subject: SMTP test
C:
C: Hello world
C: .
S: 250 2.0.0 Queued
```

This is the core SMTP server interaction model. The client identifies itself, the server advertises capabilities, the client authenticates if required, and the message is transferred after the server accepts the envelope.

## How SMTP server delivery works step by step

1. Your app opens a connection to the configured SMTP host and port.
2. The server announces its capabilities.
3. The client upgrades to TLS when the server and port require STARTTLS.
4. The client authenticates when submission policy requires it.
5. The client sends the envelope sender and recipient list.
6. The server accepts the message body and queues the message.
7. The server relays the message toward the recipient domain or hands it to another relay.
8. Delivery, deferral, bounce, and complaint signals appear later through logs, events, or headers.

This is why "SMTP accepted the email" and "the user received the email" are different checks.

## SMTP server vs SMTP relay vs email API

| Term        | Meaning                                                       | Typical use                                                     |
| ----------- | ------------------------------------------------------------- | --------------------------------------------------------------- |
| SMTP server | Mail transport endpoint that accepts and relays outbound mail | App, device, or mailbox submission                              |
| SMTP relay  | A trusted server-to-server or app-to-provider forwarding path | Centralized policy, delivery, and sender controls               |
| Email API   | HTTP API for creating and sending messages                    | App-native automation, richer metadata, easier workflow testing |

If your team is choosing the send model, read [SMTP API](/email/smtp-api/) and [SMTP relay services](/guides/smtp-relay-services/). If you already use SMTP and need to validate delivery, keep reading.

## SMTP vs IMAP vs POP3

- SMTP sends and relays outbound email.
- IMAP reads and syncs mailbox state.
- POP3 downloads mailbox messages.

A typical app uses SMTP for sending and uses inbox APIs, IMAP, or POP3-style retrieval only when it needs to inspect received messages. For the broader protocol split, read [IMAP vs POP3 vs SMTP](/guides/imap-vs-pop3-smtp/).

## SMTP server roles in email infrastructure

You will often hear these terms:

- MUA (Mail User Agent): client or app creating the message
- MTA (Mail Transfer Agent): server software relaying mail
- MDA (Mail Delivery Agent): final delivery into mailbox storage

SMTP servers run MTA behavior during transfer. If you want the direct relationship between protocol and relay software, read [MTA and SMTP](/guides/mta-smtp/).

## Common SMTP server failure patterns

### Connection and network errors

Likely causes:

- blocked egress from the app host
- wrong hostname or port
- DNS resolution failures
- firewall or provider restrictions

### Auth and policy failures (`535`, `550`)

Likely causes:

- wrong credentials
- wrong username format
- sender identity mismatch
- relay restrictions
- domain policy failures

### Accepted but not delivered to inbox

Likely causes:

- sender reputation or authentication gaps
- spam-folder placement
- downstream recipient filtering
- broken message templates, links, or attachments
- queue delays after the SMTP server returns `250 queued`

## Test SMTP server behavior with MailSlurp

A good SMTP server test has two layers: transport checks and inbox proof.

1. Use [SMTP tester](/tools/smtp-tester/) to validate host, port, TLS, authentication, and response behavior.
2. Send a controlled message to a MailSlurp test inbox through the same app workflow.
3. Capture the message in [Email Sandbox](/product/email-sandbox/) instead of sending repeated tests to real users.
4. Inspect headers with [Email header analyzer](/tools/email-header-analyzer/) so SPF, DKIM, DMARC, routing, and received-path details are visible.
5. Assert the subject, body, links, OTP codes, and attachments with [Email integration testing](/product/email-integration-testing/) or the [Email testing API](/product/email-testing-api/).
6. Run [email deliverability testing](/testing/email-deliverability-test/) when sender trust, inbox placement, or spam risk matters.

That workflow turns an SMTP server check into a release gate for the real customer journey.

## SMTP security and authentication checklist

1. Use authenticated submission on port `587` with STARTTLS when available.
2. Use port `465` only when your provider requires implicit TLS.
3. Avoid port `25` for ordinary app submission unless you are testing a documented server-to-server relay path.
4. Enforce SPF, DKIM, and DMARC alignment for sender domains.
5. Separate transactional, marketing, staging, and test sender identities when needed.
6. Track bounce, deferral, complaint, and delivery events through webhook or queue pipelines.
7. Re-validate after DNS, provider, credential, or infrastructure changes.

References:

- [SMTP authentication](/blog/smtp-authentication/)
- [STARTTLS vs SSL/TLS](/blog/starttls-ssl-tls/)
- [SMTP ports guide](/guides/what-are-smtp-ports/)
- [SMTP relay guide](/guides/smtp-relay/)

## FAQ

### Is an SMTP server the same as an email server?

Not exactly. SMTP servers handle mail submission and transfer. A full email system may also include mailbox storage, IMAP/POP retrieval, spam filtering, webmail, and administration tooling.

### What is my SMTP server?

It is the SMTP host your mail provider, workspace admin, or relay provider tells your app to use. For example, Gmail uses `smtp.gmail.com` for mailbox-authenticated submission, while Google Workspace relay use cases can use `smtp-relay.gmail.com`.

### Can SMTP servers receive email?

SMTP servers can accept inbound SMTP transfers from other servers, but mailbox retrieval is handled by mailbox storage and retrieval services such as IMAP, POP3, or an inbox API.

### What port should I use for SMTP submission?

Usually port `587` with STARTTLS. Use provider-recommended settings and verify them in each environment before release.

### How do I know if an SMTP server is working?

Check that the server is reachable, TLS negotiates correctly, authentication succeeds, the server accepts the envelope, and the resulting message is actually received in the expected inbox with correct headers and content.

### Can I use Gmail's SMTP server for application email?

You can use Gmail SMTP for small, controlled sending scenarios that fit Gmail's account and security rules. For product workflows, combine provider guidance with MailSlurp tests so password resets, OTPs, receipts, and alerts are verified before customers depend on them.

## Next steps

- [SMTP protocol guide](/blog/smtp/)
- [SMTP server configuration checklist](/blog/smtp-server-configuration-checklist/)
- [SMTP tester](/tools/smtp-tester/)
- [Test SMTP servers with Telnet](/blog/test-smtp-servers-with-telnet/)
- [Email deliverability testing](/testing/email-deliverability-test/)