SMTP vs API for Sending Email from Applications
SMTP interface or HTTPS API for application email: how each works on Amazon SES, a side by side comparison of effort, portability, features, and errors, and when to use which.
Every transactional email service offers two ways to hand it a message: an SMTP endpoint that behaves like a mail server, and an HTTPS API that accepts a request describing the message. Both end in the same delivery pipeline, so the choice is about integration effort, control, and how failures surface in your application. This guide compares the two on Amazon SES, where both interfaces are first class, and gives a rule of thumb for which to use.
How SMTP sending works
With the SMTP interface, your application or a local mail transfer agent opens a TCP connection to the service’s SMTP endpoint on port 587 with STARTTLS or port 465 with implicit TLS, authenticates with a username and password, and transmits the message in the SMTP dialogue: envelope sender, envelope recipients, and then the full MIME message with headers and body. The service accepts the message, returns a queue identifier, and takes over delivery.
Amazon SES exposes a regional SMTP endpoint and generates SMTP credentials from an IAM user’s access key with a documented conversion, so the credentials are IAM identities under the hood and can be rotated or revoked like any other. The endpoint does not accept port 25 from most cloud networks, and outbound port 25 is restricted on most providers in any case, so use the submission ports. SES imposes the same sending quota and maximum send rate on the SMTP interface as on the API.
The strength of SMTP is universality. Every language has a mail library, every framework has a mail configuration block, every CMS and helpdesk can be pointed at an SMTP host, and Postfix or another MTA on a VPS can relay through it with a relayhost setting and SASL credentials. Nothing about the application needs to know which service is behind the endpoint, which makes switching providers a configuration change.
How API sending works
With the API, the application makes an authenticated HTTPS request that describes the message as structured data: sender, recipients, subject, text and HTML bodies, attachments, headers, and service specific options such as a configuration set or template name. The service builds the MIME message itself, returns a message identifier synchronously, and delivers it. Amazon SES offers this through the SES API v2, with SDKs for the languages AWS supports, and authenticates with IAM credentials or a role, which means an EC2 instance, Lambda function, or container can send without any stored secret.
The API exposes features that SMTP cannot express. On SES that includes stored templates with substitution data, sending a single templated message to many recipients in one call, list and subscription management, and direct control over configuration sets and tags for event tracking. Errors come back as typed responses rather than SMTP status codes, so a rejected recipient, a quota exceeded condition, or an unverified identity is a distinct exception the application can handle.
The cost is coupling. The integration is specific to the provider, so moving services means changing code rather than configuration, and any component that only speaks SMTP still needs the SMTP interface alongside.
Comparing the two
| Consideration | SMTP interface | API |
|---|---|---|
| Integration effort | Configuration only in most frameworks and tools | SDK or HTTP client code, provider specific |
| Authentication | Username and password over TLS (SES derives them from IAM) | IAM credentials, roles, or API keys depending on the service |
| Portability | High, any SMTP capable service is a drop-in replacement | Low, tied to the provider’s request format |
| Connection model | Persistent sessions, several messages per connection possible | One HTTPS request per send or per batch |
| Features | Standard headers only, service options via special headers | Templates, batch sending, tags, list management |
| Error handling | Numeric SMTP reply codes and text | Structured error types per request |
| Firewall needs | Outbound 587 or 465 | Outbound 443, usually already open |
| Best suited to | Existing software, MTAs, low code tools | Applications you write, serverless, high volume |
Throughput is often assumed to favour the API, but on SES both interfaces are bound by the same account quotas, and a well implemented SMTP client reusing connections can send at the account’s maximum rate. The practical difference is latency and observability: an HTTPS call returns a message identifier you can log and correlate with events, while SMTP gives you a queue identifier in the reply text that takes more parsing.
Choosing for your situation
Use the SMTP interface when the sender is software you did not write. WordPress, a self hosted helpdesk, a CI system, a monitoring tool, and a Postfix instance collecting cron output all speak SMTP natively. It is also the right choice when you want to keep the option of changing providers without a code change, and for small applications where a mail library and three configuration lines are all the integration you need.
Use the API when the sender is your own application and you want templates managed by the service, batch sends, per message tags for analytics, or credential free authentication through an instance role. Serverless functions in particular suit the API, since holding an SMTP session inside a short lived function is awkward and an HTTPS call is not. Applications that need to react to a rejected send at the point of sending also benefit from typed errors.
Many teams run both: the application sends through the API, and everything else in the company relays through the SMTP endpoint with a separate set of credentials, ideally under a separate IAM user so that revoking one does not touch the other. On SES the two paths share identities, configuration sets, and quotas, so the operational picture stays unified.
What both interfaces require
The transport does not change the rules of sending. The From domain must be a verified identity on SES with SPF, DKIM, and DMARC in place, which the guide to email authentication setup walks through. A new account starts in the SES sandbox, which restricts recipients to verified addresses until production access is granted after AWS reviews the use case. Bounce and complaint events must be consumed and acted on, and the sending quota and maximum send rate apply to the combined traffic of both interfaces. All mail must be permission based and comply with anti-spam law, and credentials for either interface should be stored in a secrets manager rather than in source code, as described in API keys and secrets management.
Where to go next
The Amazon SES accounts page lists options labeled SMTP 50K Limits and SMTP 100K Limits. The labels state a sending limit level and nothing beyond that; the SMTP interface and the API share whatever quota applies, and use of any account is subject to the AWS service terms and the SES acceptable use policy.
For the sandbox, production access, and how quotas grow, read Amazon SES explained. For the reputation side of sending at volume, continue with email deliverability basics. The full email infrastructure series is in the Cloud Library.