SMTP vs API: which should your app send email with?

The short answer

SMTP and a REST API are two doors into the same sending service. SMTP, the Simple Mail Transfer Protocol defined in RFC 5321, is how mail servers pass messages to each other. An SMTP relay accepts finished messages from your software and delivers them onward. An email API accepts an HTTP request that describes the email, then builds and sends it for you.

So the real question is where the email comes from. If a framework mailer, CMS, server or off-the-shelf app already sends it, SMTP is the shortest path: you change settings, not code. If your own code decides who gets what, the API gives you more control in each request.

What an SMTP relay means for your app

Almost every language and framework ships with an SMTP client. You give it a host, a port and a username and password, and it hands each message to the relay. The relay takes care of delivery from there.

With tinyRelay, SMTP credentials are issued when your account is set up. Any software that can send over SMTP can use them, from a framework mailer to a background worker to a server process. What you configure:

• Host and port: shared during onboarding.
• Username and password: issued by our team at onboarding.
• From address: on a sending domain we have set up with you.

Read more on the SMTP relay service page.

What a REST email API means

With an API, your code makes one HTTPS request. tinyRelay's send endpoint is POST /email/campaign, authenticated with an API key in the X-RELAY-ACCESS-TOKEN header from IP addresses we have allowlisted for you. A successful call returns 202 with a requestId.

One request can address many recipients. Each recipient can carry attributes, which are rendered into the body as merge tags such as [FIRST_NAME], and metadata, your own IDs that come back on every webhook event for that recipient. There are no packages to install: the API works with any language that can make HTTP requests. See the transactional email API page for the full request shape.

SMTP vs REST API for email, side by side

When SMTP is the better fit

• The email comes from software you don't want to change. A CMS, helpdesk, monitoring tool or server process that already speaks SMTP.
• Your framework has a mailer. Laravel, Django and Rails all send over SMTP out of the box. See the Laravel SMTP guide, the Django email guide and the Rails Action Mailer guide.
• A platform asks for custom SMTP. Auth providers often do, for sign-up and reset emails. See Supabase custom SMTP.
• You want to switch providers by changing settings. New host, port and credentials; the rest of your code stays as it is.

When the REST API is the better fit

• One request, many people. Send the same email to a batch, each with their own [FIRST_NAME] and their own IDs.
• You need your IDs back. Metadata such as an order_id or user_id is echoed on every webhook event, so your app can match events to its own records. See email webhooks.
• You want control per request. Turn open and click tracking off with disableTrackingLinks, or hide tracked destinations with X-Link-Wrapping: true.
• You'd rather not run an SMTP client. Serverless functions and small services often find one HTTPS call simpler. Start with send email with cURL.

Can you use SMTP and the API together?

Yes. Both run on the same infrastructure, with the same sending domains and the same DKIM record. A common split is to keep an existing framework mailer on SMTP for password resets while new services send through the API.

Whichever you choose, some things don't change:

• Authentication: one CNAME, tec1._domainkey.yourdomain pointing to tec1.dkim.tinyemail.com, signs your mail with DKIM. PUT /domain/dns/check validates DKIM and SPF. See SPF, DKIM and DMARC explained.
• Events: SEND, DELIVERED, BOUNCED, OPEN, CLICK, UNSUBSCRIBE and SPAM arrive as signed webhooks.
• Bounces: every BOUNCED event carries one of 19 documented bounce categories.

What each looks like

Over SMTP you only change settings. Over the API you make one request.

# .env for any framework mailer
MAIL_HOST=[SMTP host]
MAIL_PORT=[port]
MAIL_USERNAME=issued-at-onboarding
MAIL_PASSWORD=issued-at-onboarding
MAIL_FROM=no-reply@acme.com

curl -X POST https://api.tinyemail.com/v1/relay/email/campaign \
  -H "X-RELAY-ACCESS-TOKEN: $TINYRELAY_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "subject": "Reset your password",
  "body": "<p>Hi [FIRST_NAME], use this link to reset…</p>",
  "sender": { "from": { "name": "Acme", "email": "no-reply@acme.com" } },
  "recipients": { "to": [
    { "email": "ann@example.com", "attributes": { "FIRST_NAME": "Ann" },
      "metadata": { "user_id": "u_1042" } }
  ] }
}'

# 202 {"requestId": "833c5151-…", "message": "SUCCESS"}

SMTP host and port are shared at onboarding. Base URL from current site samples; confirm in the docs.

Sources

• RFC 5321, Simple Mail Transfer Protocol: datatracker.ietf.org/doc/html/rfc5321
• tinyRelay docs, Send Email: docs.tinyrelay.com/docs/tiny-relay/send-email
• tinyRelay docs, Validate DKIM and SPF: docs.tinyrelay.com/docs/tiny-relay/validate-dns
• tinyRelay docs, Webhook Responses: docs.tinyrelay.com/docs/tiny-relay/webhook-response