EMAIL / LESSON 01
What Is an Email Service?
Why apps send email through a service, the two kinds of email, and how to choose a provider
Loading the lesson…
Loading activities…
Browse lessons
EMAIL / LESSON 01
Why apps send email through a service, the two kinds of email, and how to choose a provider
Loading the lesson…
Loading activities…
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.
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.
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.
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.
Before a service will send mail from hello@yourdomain.com, 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.
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.
When you're comparing email services, run through these questions.
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 |
There's no single best service. Here's a simple way to think it through.
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.
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...