All posts
2 min readPigeonify

SMTP or API: which should you use to send email?

Both end up in the same inbox. They differ in latency, error handling and how much they tell you when something goes wrong.

EngineeringAPI

Every sending provider offers both. The choice matters more than it first appears.

SMTP: the universal option

SMTP is the protocol email actually runs on. Every language has a client, every framework has an integration, and every legacy system already speaks it.

That is its real advantage: you probably do not have to change any code. Point your existing configuration at a new host, update the credentials, done. Migrating providers takes minutes.

The cost is chattiness. A single send is a TCP connection, a TLS handshake, then EHLO, AUTH, MAIL FROM, RCPT TO, DATA and QUIT — several round trips before a message moves. Over a long-haul connection that is real latency.

Error reporting is also thin. You get a three-digit code and a line of text, and it arrives for the whole message rather than per recipient.

HTTP APIs: better feedback

An API send is one HTTPS request with a JSON body. One round trip, and the response is structured:

{
  "id": "0101...",
  "rejected": ["invalid@example"],
  "suppressed": ["unsubscribed@example.com"]
}

That per-recipient detail is the real argument. SMTP gives you one status for the message; an API can tell you which addresses were dropped and why, which is the difference between logging "failed" and knowing what to fix.

APIs also expose things SMTP has no vocabulary for — scheduling, tagging, idempotency keys, batch sends with per-recipient variables.

Choosing

Use SMTP when you are migrating an existing system, working in an environment with an entrenched mail layer, or your framework's mailer already does what you need.

Use an API when you are building new, you need per-recipient results, or latency inside a request matters.

The mistake either way

Do not send email inside a web request.

If your signup handler calls the mail provider synchronously, then your signup endpoint fails whenever their API is slow. You have coupled your availability to theirs for no benefit — the user does not need the email to exist before the page loads.

Queue it. Return the response. Send in a worker with retries. This matters more than the protocol.

On credentials

SMTP credentials are a username and password with no scope: anything holding them can send as you. API keys can be scoped, rotated and revoked individually, and a good provider shows you when each was last used.

If you are on SMTP, treat those credentials with the same care as a database password, and use a separate set per application.

Send email that actually arrives

Authentication, suppression and bounce handling built in. Start free, no card required.

Start free