SMTP vs API is the first choice most teams make when they connect an application to a sending platform. Both methods hand a message to the platform, which then delivers it. The difference lies in how much work it takes, what features you can reach and how you find out what happened. This guide compares the two, gives a rule of thumb for choosing and explains how to combine them.
How each method works
SMTP
The Simple Mail Transfer Protocol is the standard way mail moves between servers, and a part of it, message submission, lets an application hand mail to a server. Your application opens a connection to the platform host, upgrades it to TLS, authenticates with a username and password, then sends commands: who the message is from, who it is for, and finally the message itself with its headers and body. The server replies with a numeric code after each step. A reply starting with 2 means success, 4 means a temporary problem and 5 means a permanent one.
EHLO app.example.com
STARTTLS
AUTH LOGIN ...
MAIL FROM:<bounce@mail.example.com>
RCPT TO:<user@example.net>
DATA
...headers and body...
.
QUITHTTP API
An API accepts a single HTTPS request that contains the message as structured data, usually JSON, along with an API key in a header. The platform builds the email, validates the fields and returns a response with a status code and, normally, a message identifier. You rarely see the SMTP conversation, because the platform handles it.
POST /v1/messages
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json
{"from":"orders@mail.example.com","to":["user@example.net"],
"subject":"Your receipt","html":"<p>Thanks for your order.</p>"}The request above is illustrative. Field names and endpoints differ between platforms, so use the reference in your own account.
Side-by-side comparison
| Aspect | SMTP | HTTP API |
|---|---|---|
| Compatibility | Works with almost anything that can send mail | Needs code or a specific integration |
| Setup effort | Enter host, port, username and password | Write or install code that calls the API |
| Features | Mostly the message itself, plus custom headers | Templates, tags, metadata, scheduling and batch sending where offered |
| Feedback at send time | Numeric reply codes from the server | Structured status and error body |
| Throughput from your own code | Good with persistent connections | Often better, because one request can carry many recipients |
| Firewall issues | Some networks block SMTP ports | HTTPS on port 443 is rarely blocked |
| Credentials | SMTP username and password | API key, ideally scoped to specific permissions |
| Best for | Plugins, CMS, CRM, printers and legacy apps | Applications you build and control |
When SMTP is the right choice
- Off-the-shelf software. WordPress, shop platforms, helpdesks and billing tools almost all support SMTP settings and nothing else.
- Moving from another provider. Changing the host and credentials is often all you need, so migration is quick.
- Devices and scripts. Scanners, monitoring tools and shell scripts can usually send by SMTP but not by custom API calls.
- A single standard. If you may switch providers later, SMTP keeps your application portable.
When the API is the right choice
- Your own application. You control the code, so a clear JSON request is simpler than building MIME messages.
- Rich features. Template variables, tags for reporting, scheduled sends and per-recipient data are easier to express in structured form.
- High volume. Sending many messages in one request reduces overhead.
- Restricted networks. If outbound SMTP ports are blocked, HTTPS usually still works.
- Better errors. A structured response tells you which field was wrong without parsing a server reply.
A message is not delivered when it is accepted. Whether you use SMTP or an API, a success response means the platform accepted the message for delivery. It does not mean the recipient received it. Use delivery events and bounce data to learn the outcome. See our guide to SMTP bounce codes.
Security considerations
| Area | SMTP | API |
|---|---|---|
| Encryption | Use STARTTLS on 587 or implicit TLS on 465, and never send credentials in clear text | Always HTTPS |
| Credential type | Shared username and password | Key, ideally with limited permissions |
| Storage | Keep out of code repositories; use environment variables or a secrets store | The same |
| Rotation | Change the password and update every system that uses it | Create a new key, switch over, delete the old one |
| Scope | Usually all-or-nothing for sending | Can often be limited to sending only |
Whichever method you choose, give every system its own credential. A leaked shared password forces you to change it everywhere at once. Our guide to API key security and rotation covers how to do this safely, and SMTP settings, ports and TLS explains the connection settings.
Error handling is the same in spirit
The two methods report problems differently, but the logic is identical. Temporary failures, such as a busy server or a rate limit, should be retried later with growing delays. Permanent failures, such as an invalid address or a rejected sender, should not be retried and should be recorded so that the address is not tried again. In SMTP the reply code class decides which case applies. In an API the HTTP status and error body do. Build the distinction into your application from the start.
| Situation | SMTP signal | API signal | What to do |
|---|---|---|---|
| Success | 250 | 2xx with message ID | Store the ID; wait for delivery events |
| Temporary problem | 421, 450, 451 | 429 or 5xx | Retry later with backoff |
| Rejected content or sender | 550, 554 | 4xx with an error body | Fix the cause; do not retry blindly |
| Bad credentials | 535 | 401 or 403 | Check the key or login; do not loop |
Running both in one setup
Using both methods is common and sensible. Your application sends receipts and password resets through the API, while a WordPress site and a helpdesk send through SMTP. Everything shares one verified domain, so authentication is the same, and you can still keep streams apart by giving each system its own credential and, where useful, its own sending subdomain, as described in our guide to separating transactional and marketing streams.
A short decision guide
- Can the system only do SMTP? Use SMTP.
- Do you write the code and need templates, tags or batch sending? Use the API.
- Are SMTP ports blocked on your network? Use the API over HTTPS.
- Do you want to stay portable between providers? Prefer SMTP, and isolate provider-specific code behind a small wrapper if you use the API.
- Still unsure? Start with SMTP to get mail flowing, and move your own code to the API when you need its features.
A worked example: a small online shop
Consider a shop with a custom checkout, a WordPress blog, a helpdesk and a monthly newsletter. Four systems need to send mail, and each has different constraints. The checkout is code the team owns, and it sends order confirmations, shipping notices and password resets. The blog only sends comment notifications and sign-up confirmations through a plugin. The helpdesk sends replies to customers from a support address. The newsletter tool sends bulk campaigns.
| System | Method | Why | Credential |
|---|---|---|---|
| Checkout code | API | Needs templates, tags such as order-confirmation, and a message ID stored against each order | One key limited to sending |
| WordPress plugin | SMTP | The plugin only offers host, port, username and password | Its own SMTP login |
| Helpdesk | SMTP | Built-in SMTP settings, no custom code possible | Its own SMTP login |
| Newsletter tool | Its own integration or SMTP | Follows whatever the tool supports | Separate login, ideally on a marketing subdomain |
With this layout, a leaked WordPress password affects only the blog and can be replaced in minutes. If the checkout key must be rotated, the helpdesk keeps working. Every message still comes from the same verified domain family, so authentication needs to be set up only once per sending domain. The team also decides that order mail uses a transactional subdomain and the newsletter uses a marketing subdomain, so that a campaign with a high complaint rate cannot hurt receipts.
The checkout team stores the message identifier returned by the API next to each order. When a customer says a receipt never arrived, support can search for that identifier, see whether the platform recorded a delivery, a bounce or a deferral, and answer in a minute instead of guessing. The plugin and helpdesk, which sit behind SMTP, do not return an identifier to the application, so the team relies on the platform event log and on searching by recipient address and time. This is a real difference in day-to-day support, and it is one reason to prefer the API for the mail that matters most to customers.
Testing either path
After setup, send a test message through each path to an inbox you control. Open the headers and confirm that SPF, DKIM and DMARC pass and that the domains align, using our guide to reading email headers. If you have not yet verified your domain, start with verifying your sending domain.
Not sure which method suits your app? Tell us what you are connecting and we will recommend a setup.
Further reading and sources
Frequently asked questions
Is SMTP or an API better for sending email?
Neither is better in every case. SMTP is the universal standard and works with almost any application, plugin or device. An HTTP API is usually easier to use from your own code and often gives access to extra features such as templates, tags and batch sending. Many teams use both.
Is an email API faster than SMTP?
Often, for high volume from your own code. An API request can carry many recipients and returns a clear response, while SMTP uses a longer conversation of commands for each message unless connections are reused. For low volume the difference is small, and delivery time after acceptance is the same.
Which method is more secure?
Both can be secure when used correctly. SMTP should use TLS on a submission port and authenticated credentials. An API should use HTTPS and a key with the narrowest permissions that work. The bigger risks are leaked credentials and over-broad keys, not the protocol.
Can I use both SMTP and an API in the same application?
Yes. A common pattern is to send system messages from application code through the API, while a CMS, CRM or shipping tool sends through SMTP. Use separate credentials for each so that you can rotate or revoke one without affecting the other.
Which port should I use for SMTP?
Use the submission port your provider documents. Port 587 with STARTTLS and port 465 with implicit TLS are the usual choices for applications. Port 25 is for server-to-server delivery and is often blocked by hosting providers and internet providers.
How do I know if an email was accepted?
With SMTP, a 250 response to the end of the message means the server accepted it for delivery, not that it reached the inbox. An API typically returns a success status and a message identifier. For the outcome, use delivery events or webhooks in both cases.
Why do some features only exist in the API?
APIs can accept structured data such as template variables, tags, scheduling and metadata in one request, which does not fit neatly into an email message. SMTP can carry some of these through custom headers, but support varies between platforms.
What should I use for WordPress or a shop plugin?
Use SMTP, because most plugins support it and need only a host, port, username and password. If a plugin offers a dedicated integration that uses the platform API, that may give richer reporting, but check that it is maintained.
Do I need to change my authentication setup when switching method?
No. Domain authentication with SPF, DKIM and DMARC is a property of your sending domain, not of the method. Verify the domain once, and it applies to mail sent over SMTP or the API.