SMTP is the most portable way to hand email to a sending service. HTTP APIs are usually better when a product needs idempotency, typed responses, event data, templates, and provider-specific controls. The right transport depends on the application surface, not on a generic claim that one protocol is newer.
last updated 2026-05-074 sections
section 01
Protocol mechanics
SMTP behaves like a mail relay. The client opens a connection, authenticates, and submits a message. An HTTP API behaves like a product endpoint. The client posts structured data and receives a structured response. Both can send the same email, but they expose different operational controls.
capability
SMTP relay
HTTP API
Compatibility
Works with legacy mail clients and frameworks.
Requires provider-specific integration.
Response shape
Protocol status plus provider relay response.
Structured JSON with message ID and errors.
Idempotency
Usually application-owned.
Provider support is possible.
Templates
Usually rendered before handoff.
Can use provider templates or rendered HTML.
Events
Separate webhooks or logs.
Often tied directly to message IDs.
section 02
When SMTP is the right choice
SMTP is useful for legacy apps, simple framework mailers, shared hosting, and vendor portability. It also works well when the application already renders complete MIME messages and only needs a relay.
okThe app already uses a framework mailer built around SMTP.
okVendor portability matters more than provider-specific features.
okMessages are low volume and low complexity.
okThe sender does not need provider-side templates, batch endpoints, or idempotency.
section 03
When an API is the right choice
An email API fits new product flows where delivery state, retries, and message metadata need to be first-class. Password resets, magic links, receipts, and agent sends benefit from stable message IDs and structured error handling.
need
why API helps
Stable message IDs
Connects send attempts to webhooks and support logs.
Retry control
Pairs with idempotency keys and queue state.
Batch or fan-out
Sends many related messages with less connection management.
Provider metadata
Stores stream, template, user, and tenant fields with the send.
section 04
Hybrid patterns
Many teams keep SMTP for old framework mailers and use an API for new product flows. That is fine if streams, sender domains, suppressions, and event handling are intentionally separated.
okUse separate streams for legacy SMTP and new API sends.
okKeep suppression sync consistent across both transports.
okLog provider message IDs in the same support surface.