What Is an Email Service?
Why apps send email through a service, the two kinds of email, and how to choose a provider

Sprout presents
Sending an email takes one line of code. Getting it into the inbox takes considerably more. Four services, compared carefully, because I could not resist.Sending an email takes one line of code. Getting it into the inbox takes considerably more. Four services, compared carefully, because I could not resist.

Pretty much every app sends email. Welcome messages, password resets, receipts and alerts all have to go out somehow. This lesson covers why apps hand that job off to an email service, the lingo you'll see on every provider's website and how to pick between the four services in this module.
Why Not Just Send It Yourself?#
Technically, any server can send an email. The hard part is getting it into the inbox instead of the spam folder.
Inbox providers like Gmail and Outlook are suspicious of mail by default. They check where it came from, whether the sender proved who they are and how that sender has behaved in the past. A brand new server sending mail from your app has ZERO track record, so a lot of its mail just never shows up.
An email service fixes that. It runs sending servers with a good reputation, handles the technical checks and tells you what happened to every single message.
And here's the sneaky part... "delivered" doesn't always mean somebody saw it. I had a client whose Outlook got hit by a Microsoft update, and it quietly swallowed 49 form-fill notifications. The deliverability side said "delivered" every time. Nothing ever hit the inbox. So yeah, knowing what happened to each message matters a LOT.
Two Kinds of Email#
Email services talk about two kinds of mail, and the difference shapes pretty much everything else.
| Kind | What It Is | Examples |
|---|---|---|
| Transactional | Sent to one person because of something they did | Password reset, receipt, login link, "someone replied to you" |
| Marketing (or broadcast) | Sent to many people at once, by your choice | Newsletter, product announcement, sale |
Transactional email is expected and urgent. Marketing email is optional, and people can unsubscribe from it. Lots of providers keep the two apart, because a marketing email that gets marked as spam shouldn't drag your password resets down into spam with it.
Where an Email Service Sits in Your App#
User clicks "Forgot password"
|
v
Your app --- API call with your API key ---> Email service
|
v
User's inbox
|
Your app <--- webhook: delivered, bounced, opened -------+Your app never talks to Gmail directly. It makes an API call to the email service using an API key you keep in an environment variable, and the service handles the rest. Lots of services can also call your app back with a webhook to tell you what happened.
Proving You Own Your Domain#

Before a service will send mail from [email protected], you have to prove you own yourdomain.com. You do that by adding a few DNS records the service hands you. Three names show up over and over.
- SPF lists which servers are allowed to send mail for your domain.
- DKIM adds a digital signature to each email, so inboxes can check that it wasn't changed and really came from you.
- DMARC tells inboxes what to do with mail that fails those checks, and where to send reports.
Every provider in this module walks you through these records. The exact records are different for each one, so always copy them from the provider's own dashboard.
What to Look For#
When you're comparing email services, run through these questions.
- Transactional, marketing or both? Some focus on one, and some do both.
- How easy is the API? Look for a Node.js example you can get running in a few minutes.
- How does domain setup work? Clear SPF, DKIM and DMARC instructions save you hours.
- What do you learn after sending? Think bounces, spam complaints, delivery logs and webhooks.
- How is it priced? Usually by how many emails you send per month.
The Services in This Module#
Each of these gets its own chapter.
| Service | What Makes It Different |
|---|---|
| Resend | A developer-friendly API with a simple setup, built for sending from code |
| SendGrid | A big platform from Twilio that covers both transactional email and marketing campaigns |
| Amazon SES | A raw building block inside AWS. New accounts start in a sandbox and must request production access |
| Postmark | Focused on transactional deliverability, with separate message streams for transactional and broadcast mail |
How to Choose#
There's no single best service. Here's a simple way to think it through.
- Just starting out and sending from code? Resend is the gentlest first step, which is why it kicks off this module.
- Need marketing campaigns and transactional email in one place? SendGrid covers both.
- Already on AWS, or sending a ton and happy to do more setup yourself? Amazon SES is worth a look.
- Password resets and receipts HAVE to arrive, every time? Postmark is built around exactly that.
You can also switch later (it's not a marriage). Your app only talks to the service through one small piece of code, so changing providers mostly means swapping that piece and your DNS records.
TL;DR#
- Email services exist mainly for deliverability, which means getting mail into the inbox
- Transactional email goes to one person because of something they did, and marketing email goes to lots of people
- Your app sends through the service's API, using an API key kept in an environment variable
- SPF, DKIM and DMARC records prove you own your sending domain
- This module covers Resend, SendGrid, Amazon SES and Postmark
What's Next?#
The Resend chapter is up first. You'll see why email is harder than it looks and send your first message with just a few lines of code...
This lesson ends with 2 short activities.
