term · mail protocol smtp

What is mail protocol SMTP, and how does it affect application email?

SMTP, or Simple Mail Transfer Protocol, is the standards-based protocol mail systems use to submit, relay, and hand off outgoing email. An application usually gives a finished message to an authenticated submission service; mail servers then use SMTP commands and DNS routing to move it toward each recipient. SMTP responses reveal whether a specific hop accepted or rejected a recipient, but acceptance is not the same as inbox placement. Applications still need durable queues, safe retries, message identifiers, authentication, and bounce processing.

SMTP transfers mail between responsible systems

SMTP is a store-and-forward transfer protocol. A client opens a session with a server, identifies itself, presents an envelope sender, proposes one or more envelope recipients, and transmits message content after the server agrees to receive it. The server can accept some recipients and reject others, so status belongs to a recipient and transaction rather than only to the message as a whole. Once a server accepts responsibility, it may deliver locally or relay the message toward another system selected through DNS Mail Exchanger records. This hop-by-hop design is why an application should not reduce email state to one sent boolean. The application, submission service, relay, receiving server, and mailbox filtering system each know different parts of the outcome. SMTP moves the message between systems, while product-level records and provider events make that movement understandable to users and operators.

Submission and relay are different protocol roles

RFC 6409 separates message submission from message relay. Submission is the first handoff from an authorized user or application to a Message Submission Agent, normally using port 587. Relay is transfer between Message Transfer Agents and conventionally uses port 25. Submission services can require authentication, validate or complete message fields, and enforce sender policy because they know who is introducing new mail. Public relay servers must interoperate with other domains and follow different trust rules. Application code should therefore connect to a provider's documented submission endpoint or use its HTTP API, not open arbitrary port 25 connections to destination servers. This division also clarifies credentials: an SMTP username or token authorizes submission to a particular service; it does not grant authority over the destination domain. Keep submission credentials server-side, scope them to the sending workload when the provider supports it, and rotate them without embedding them in message content or client software.

The SMTP envelope differs from visible message headers

An SMTP transaction carries an envelope with `MAIL FROM` and one or more `RCPT TO` commands. The transferred content separately follows the Internet Message Format defined by RFC 5322, with fields such as From, To, Date, Subject, and Message-ID plus a body. MIME standards extend that content for HTML, alternative parts, attachments, and non-ASCII data. The envelope sender is the address used for transport failures and can differ from the visible From author. Envelope recipients can also differ from visible To and Cc fields, as with Bcc. Do not build these structures by concatenating untrusted strings. Use a maintained message library, validate addresses, block newline injection into header fields, and preserve a stable Message-ID. When troubleshooting, inspect both layers: a correct visible From field cannot repair an unauthorized envelope identity, and a valid envelope does not make malformed MIME display correctly.

Read the transaction as a state machine

A basic Extended SMTP session starts with a server greeting, then `EHLO` so the server can advertise extensions. The client may negotiate TLS and authentication for submission. A mail transaction then uses `MAIL FROM`, one `RCPT TO` per destination, `DATA`, the complete message terminated according to SMTP framing, and `QUIT`. Do not treat the example as a reason to implement the wire protocol manually; mature SMTP libraries handle line endings, dot transparency, capability negotiation, authentication, and TLS state more safely. Instrument the library at command category and response-code level without logging credentials or full message bodies. Capture which recipient failed at which stage and whether the server had accepted responsibility after message data. That boundary determines whether a retry is appropriate, whether a duplicate is possible, and whether a later delivery-status notification rather than an immediate response will carry the failure.

Classify reply codes before deciding to retry

SMTP reply classes convey action. A 2xx response indicates successful completion of that command. A 4xx response is a transient negative completion, so a queued sender may retry after a delay. A 5xx response is a permanent negative completion for the attempted command and normally requires correction, suppression, or human investigation instead of repeated retries. Enhanced status codes add a structured `X.Y.Z` diagnosis for address, mailbox, system, routing, protocol, content, or security and policy conditions. Preserve both the numeric code and server text because either can add diagnostic value, but do not expose raw responses containing recipient data broadly. Apply exponential backoff with jitter and a maximum queue lifetime to transient failures. Never retry so aggressively that a temporary destination problem becomes abusive traffic. For permanent address failure, stop automatic sends to that destination and update suppression state. For policy or authentication failure, fix identity, DNS, credentials, or content before another attempt.

Use encrypted, authenticated submission

SMTP began as a transport protocol across networks with different trust assumptions, so secure submission depends on extensions and deployment policy. STARTTLS upgrades an SMTP connection to TLS, after which the client must discard capabilities learned before the handshake and issue `EHLO` again. RFC 8314 updates submission guidance by treating cleartext access and submission as obsolete and describing implicit TLS for submission. SMTP AUTH, standardized in RFC 4954, lets a submission server authenticate a client through advertised mechanisms. Use the provider's current hostname, port, TLS mode, and authentication instructions rather than guessing a combination. Validate the server certificate and do not fall back silently to cleartext when the workload requires protected submission. Keep passwords or tokens in a secret manager, use separate credentials by environment, and disable obsolete authentication mechanisms. TLS protects a connection hop; it does not authenticate the message author to every downstream receiver or replace SPF, DKIM, and DMARC identity alignment.

Diagnose an application email failure hop by hop

Begin with the application's durable outbound record: was the product event authorized, and did only one queued job claim it? Next inspect submission: DNS resolution, TCP connection, TLS negotiation, certificate validation, authentication, envelope sender authorization, per-recipient responses, and final DATA response. If the submission service accepted the message, stop blindly replaying the request and follow its message identifier and event stream. Distinguish a provider-processed state from receiving-server acceptance. A later bounce can still report a permanent failure after initial acceptance. If the receiving server accepted the message, investigate authentication results, reputation, recipient policy, content, and mailbox classification rather than calling it an SMTP transport failure. Check both envelope and header identities, and retain timestamps, response codes, queue attempt count, and provider identifiers. Use controlled recipients for tests. Never paste production SMTP credentials or full customer messages into tickets, prompts, terminal history, or public diagnostic tools.

Separate acceptance, delivery, and inbox placement

Protocol precision matters in product interfaces. Application acceptance means the local system recorded a request. Submission acceptance means the first mail service accepted responsibility for processing it. Receiving-server delivery means the destination SMTP server returned success for the handoff. Inbox placement is a later policy and classification decision inside the receiving environment. A message can pass one state and fail or be categorized differently at the next. SMTP gives direct evidence about the current transaction and may produce later delivery-status notifications, but it does not expose the recipient's final folder. Store these states independently instead of labeling every 250 response as inbox delivery. A provider event that includes the destination's SMTP success response can support a delivered-to-server state. A bounce supports failure or suppression handling. Neither supports a promise about visibility, reading, or engagement. This model keeps status truthful and prevents unsafe retries after responsibility has already transferred.

Use SendHQ's documented API

An application can speak SMTP through a provider library, or call an HTTP email API whose provider handles Internet mail transport beneath that interface. SendHQ provides a workspace-scoped email API with verified domain checks, outbound and inbound message resources, events, suppressions, inboxes, and workspace resource boundaries. Its HTTP API can provide structured requests, identifiers, and events alongside direct SMTP submission. It does not change destination-server behavior or establish SMTP acceptance, inbox placement, or recipient engagement.

Frequently asked questions

What does SMTP stand for?

SMTP stands for Simple Mail Transfer Protocol. It defines how mail clients and servers submit and transfer outgoing messages through commands, replies, envelopes, message data, and extensions for capabilities such as authentication and TLS.

Is SMTP used to read email from an inbox?

No. SMTP is primarily for submitting and transferring outgoing mail. Inbox access uses other interfaces such as IMAP, POP, a provider-specific mailbox API, or an application email API that exposes stored inbound messages.

What is the difference between ports 25, 587, and 465?

Port 25 is conventionally used for server-to-server relay. Port 587 is the standard message-submission service and commonly negotiates TLS. Port 465 is registered for submission over implicit TLS. Follow the provider's documented endpoint and security mode rather than switching ports experimentally.

Does SMTP success prove an email reached the inbox?

No. A successful reply proves only that the responding SMTP server accepted the relevant command or message responsibility. The receiving system can still apply later policy, generate a delayed failure, or classify accepted mail outside the primary inbox.

Should an application retry every 4xx SMTP response?

A 4xx code indicates a transient negative result, but retries should use a durable queue, exponential backoff with jitter, a finite lifetime, and recipient-aware attempt limits. Investigate repeated temporary failures instead of retrying indefinitely.

Is an HTTP email API a replacement for SMTP?

It can replace SMTP in application code, but the provider still normally uses SMTP to communicate with recipient mail systems. An API adds structured authentication, payloads, resource scoping, identifiers, and event handling above the transport layer.

Sources

Continue learning

Email API Implementation Guide for Product TeamsDesign a safe email API integration with verified domains, queued sends, stable identifiers, controlled retries, delivery events, suppression, and tenant isolation.