Email service provider and SMTP relay
Overlapping names for how mail gets out: campaign platforms, delivery providers, SMTP relays, and HTTP sending APIs, often from one vendor.
See it
What it is
These are overlapping categories, not two tidy boxes, and the industry uses the words loosely. Email service provider covers both the campaign platforms (Mailchimp, Klaviyo, Beehiiv: audiences, a drag and drop editor, scheduling, unsubscribe handling, reporting) and the delivery vendors behind transactional mail (Postmark, Resend, Amazon SES, SendGrid, Mailgun), which plenty of people also call ESPs. Underneath, the distinction that actually matters is the interface: an SMTP relay takes your mail over SMTP with credentials, while an HTTP sending API takes a JSON POST and hands back a message ID. Most delivery vendors offer both interfaces, several campaign platforms sell a delivery product too, and either way the vendor owns the IPs, the retries, and the bounce handling.
Rule of thumb: humans picking recipients and writing copy points to a campaign platform. Code picking recipients (receipts, password resets, alerts) points to a delivery provider, over SMTP or its HTTP API. Run both if you need both, but split the streams onto separate subdomains so a marketing complaint spike never takes your login codes down with it.
Gotcha: do not send from your own server on port 25. Cloud and consumer IP ranges are blocked or distrusted by default, and you would be building reputation, feedback loops, and bounce processing from scratch. Second gotcha: shared IP pools mean you inherit whatever the neighbors did last week, and new SES accounts sit in a sandbox that only mails verified addresses until you request production access.
Ask AI for it
Set up transactional email sending in my app through a delivery provider's HTTP sending API (use Resend, or swap in the provider I name). Put the API key in an environment variable, wrap sending in a single service module with a typed sendEmail function, send from a dedicated subdomain, and include a plain text alternative alongside every HTML body. Keep the two failure vocabularies apart. For the HTTP API, retry timeouts, 429 responses, and retryable server-side 5xx responses with exponential backoff and an idempotency key so a retried job cannot double-send, and never retry a 4xx that means the request was wrong. For the SMTP outcomes the provider reports back, retry 4xx deferrals but do not automatically retry a 5xx transaction, and classify permanent recipient failures separately from policy and content rejections. Add a signed webhook endpoint that records delivered, bounced, and complained events and auto-suppresses hard bounces and complaints.