SMTP stands for Simple Mail Transfer Protocol. It is the protocol mail systems use to submit and relay outbound email. If you are searching for `mail protocol smtp` or `simple mail transfer protocol`, the practical answer is this: SMTP is the send-side transport layer of email. It moves messages between clients and servers, and between servers themselves. It does not handle reading mail from a mailbox. ## Quick answer SMTP is responsible for: - authenticated message submission from apps and clients - relay between outbound mail servers - handoff to destination mail infrastructure SMTP is not responsible for: - mailbox synchronization - reading mail from the server - folder or read-state management Those jobs belong to IMAP, POP3, or webmail interfaces. ## Where SMTP fits in the mail pipeline A typical path looks like this: 1. an app or client creates a message 2. the message is submitted over SMTP to an outbound server 3. that server relays the message toward the destination domain 4. the receiving domain accepts or rejects the message 5. the recipient reads mail through IMAP, POP3, or webmail SMTP is the transport contract in that sequence. ## SMTP submission vs SMTP relay These are related but not identical use cases. | Mode | What it means | Typical port | | ---------- | ------------------------------------------------ | -------------- | | Submission | client or app sends mail to an outbound provider | `587` or `465` | | Relay | one server transfers mail to another server | often `25` | Teams get into trouble when they design application sending as if it were raw relay. Most apps should use authenticated submission, not open relay behavior. ## Core SMTP transaction A simplified SMTP session looks like this: ```smtp EHLO app.example.com MAIL FROM: RCPT TO: DATA Subject: Hello ... . QUIT ``` Common commands: - `EHLO` for capability negotiation - `MAIL FROM` for the envelope sender - `RCPT TO` for recipients - `DATA` for headers and body - `QUIT` to close the session If TLS is required, the session often includes `STARTTLS` before authentication or message submission continues. ## SMTP response classes SMTP response codes are part of how you debug transport issues quickly. | Class | Meaning | Typical action | | ----- | ----------------- | -------------------------------------- | | `2xx` | success | continue | | `4xx` | temporary failure | retry according to policy | | `5xx` | permanent failure | fix config, recipient, or policy issue | Understanding this split is essential for retry logic. Retrying a permanent failure indefinitely turns one message problem into a queue problem. ## SMTP vs IMAP vs POP3 These protocols solve different stages of the email lifecycle. | Protocol | Main job | | -------- | --------------------------------- | | SMTP | send and relay mail | | IMAP | sync and manage stored mail | | POP3 | download and retrieve stored mail | If you need a message to leave your system, SMTP is in the path. If you need to read or manage a mailbox, you are in IMAP or POP3 territory. ## SMTP ports and security Common SMTP-related ports: - `587` for authenticated submission - `465` for implicit TLS submission - `25` for relay and some legacy submission cases Security around SMTP usually depends on: - TLS for transport - authenticated submission - SPF, DKIM, and DMARC for sender trust - bounce and complaint handling after send SMTP alone does not guarantee inbox placement or sender credibility. ## SMTP vs email API Many providers expose an HTTP API while still operating SMTP infrastructure behind the scenes. Use SMTP when you want: - portability across vendors - direct protocol compatibility - existing client or library support Use an email API when you want: - richer application-level telemetry - simpler auth patterns - provider-specific workflow abstractions The right choice is about operational fit, not protocol purity. ## What SMTP does not solve by itself SMTP transport success does not prove: - the message reached the inbox - the content rendered well - the sender identity passed downstream trust checks - the right mailbox workflow happened after delivery That is why SMTP testing should include message capture, header review, and inbox validation instead of stopping at "accepted by server." ## Use MailSlurp to test SMTP workflows end to end MailSlurp lets teams validate the workflow around SMTP, not just the socket connection. Use it to: - check send setup with [SMTP tester](/tools/smtp-tester/) - capture and assert messages in [Email sandbox](/product/email-sandbox/) - validate full release paths in [Email integration testing](/product/email-integration-testing/) - confirm real inbox outcomes with [Email deliverability test](/testing/email-deliverability-test/) For the shorter protocol intro, see [What is SMTP?](/blog/what-is-smtp/). {{LANDING_SHORTCODE:POST_CTA_BANNER:%7B%22title%22%3A%22Preview%20emails%20after%20SMTP%20protocol%20changes%22%2C%22content%22%3A%22Once%20SMTP%20submission%20works%2C%20use%20%5BFree%20Email%20Render%5D(%2Ftools%2Ffree-email-render%2F)%20or%20device%20previews%20to%20check%20the%20delivered%20message%20content%2C%20links%2C%20responsive%20layout%2C%20and%20dark-mode%20contrast.%22%2C%22buttonHref%22%3A%22%2Fproduct%2Fdevice-previews%2F%22%2C%22buttonText%22%3A%22Explore%20device%20previews%22%2C%22buttonTheme%22%3A%22blue%22%2C%22image%22%3A%22%2Fassets%2Fhome%2Fdevice-render-devices.png%22%2C%22imageAlt%22%3A%22Email%20preview%20workflow%20after%20SMTP%20protocol%20changes%22%2C%22imageWidth%22%3A%22800%22%2C%22imageHeight%22%3A%22415%22%2C%22imagePosition%22%3A%22%22%7D}} ## FAQ ### What is SMTP in simple terms? SMTP is the protocol mail systems use to submit and relay outbound email. ### Does SMTP receive email? Not in the mailbox-access sense. SMTP handles transport and handoff. IMAP and POP3 handle retrieval. ### Which port should I use for SMTP? Usually `587` for authenticated submission, `465` when implicit TLS is required, and `25` for relay scenarios. ### Is SMTP enough for application testing? No. You also need to capture, inspect, and verify the resulting message behavior after send. ## Final take SMTP is the send-side transport layer of email. Teams that understand submission, relay, response codes, and testing boundaries can ship more reliable email workflows and debug incidents much faster.