SMTP relay or email API — which should you use?
The practical differences between sending over SMTP and sending over an HTTP API, when each one wins, and why most teams end up using both.
Infrastructure · 3 min read · updated
What each one actually is
An SMTP relay is a server your application talks to using the same protocol mail servers have spoken since the 1980s. You point your app at a host, a port and a username, and it works — because everything that sends email already knows how to do this.
An email API is an HTTPS endpoint you POST JSON to. There is no connection to hold open, no protocol negotiation, and the errors come back as structured data instead of three-digit codes.
When SMTP is the right answer
- Software you did not write. WordPress, a CRM, an ERP, a monitoring system, a Django or Rails app with mail already wired up, a scanner in an office. All of them take SMTP credentials and none of them will ever take your API client.
- Migrating in an afternoon. Changing four settings is a smaller change than rewriting a sending layer. It is the fastest way off a provider that has become expensive or unreliable.
- No code at all. Plugins, scripts and platform mail settings are configuration, not development work.
When the API is the right answer
- Volume and batching. One request carrying many personalised messages beats one SMTP conversation per recipient, by a wide margin.
- Metadata you want back later. Tags, custom fields and idempotency keys travel cleanly in JSON and come back attached to every event.
- Errors you can act on. A structured error naming the invalid field is a different experience from parsing a 550 and guessing.
- Hosts that block SMTP ports. Some platforms block outbound 25 and 587 entirely. HTTPS always works — though a relay on 2525 usually gets you around it too.
The honest answer: you will use both
Your application sends receipts over the API. Your billing system sends invoices over SMTP because that is all it knows. Your marketing team sends campaigns from a UI. That is the normal end state, and it is fine.
What is not fine is those three paths running through three different vendors. Then you have three reputations, three suppression lists, and three dashboards that disagree — and the day someone unsubscribes from a campaign, the invoice system happily keeps mailing them.
The questions to ask a provider
- Does one suppression list cover SMTP, API and campaigns?
- Do opens, clicks, bounces and complaints land in one place?
- Do webhooks fire for every path, or only the API?
- Can transactional and marketing mail use separate subdomains and reputations?
- Who owns the sending IP, and what happens to it if you leave?
Common questions
Is SMTP slower than an API?
Per message, yes — each send involves a protocol conversation rather than one request. For most applications the difference is irrelevant. At high volume with per-recipient personalisation, the API's batching wins clearly.
Which port should I use for SMTP?
587 with STARTTLS is the standard submission port. 465 with implicit TLS also works. 2525 is the common fallback when a host blocks the others. Port 25 is for server-to-server relay, not for your application.
Can I use both without splitting my reputation?
Yes, provided both paths run through the same platform, the same sending domains and the same suppression list. Splitting across vendors is what splits reputation.
Check your addresses now
The free InkPigeon checker runs syntax, DNS, disposable, typo and role-account analysis on any address — instantly, no signup.