Resend — Overview
What Resend is, why apps need a dedicated email service, and how transactional email fits into every production application.
Every professional application sends email. When a parent pays a school fee, they receive a confirmation. When a teacher is added to the system, they receive a welcome message. When a fee record is updated, the parent is notified. When a payment is processed, a receipt arrives within seconds.
These emails are not optional. They are how users trust your application.
Resend is the service that makes sending them possible — reliably, without spam filters blocking you, and without complicated configuration.
The "Why First" Scenario
You have built a school management app. It works. A parent pays their child's school fee and the payment goes into your database. Now what?
The parent has no confirmation. They have no receipt number. No record of what was paid. They start wondering: "Did that actually go through? Should I try again? Do I call the school?"
You know the obvious fix: send them an email confirmation.
So you write code to send an email using your Gmail account.
Google blocks it within 24 hours.
Google's spam prevention systems detect that your application — running on a server — is trying to send transactional email through a personal Gmail account. This violates Gmail's terms of service. Your account gets flagged, your emails start going to spam, and eventually Gmail disables API access for your account entirely.
This is not a technicality. It is how every email provider works. Yahoo, Outlook, iCloud — all of them block automated sending through personal accounts. They have to. Otherwise every spammer in the world would use them.
The solution is a dedicated email sending service.
These services — called Email Service Providers (ESPs) — are built specifically for application-generated email. They have:
- Direct relationships with inbox providers (Gmail, Outlook, Yahoo) to ensure delivery
- Reputation management so your emails reach inboxes, not spam folders
- APIs designed for code integration
- Dashboards to see every email sent, delivered, bounced, or opened
We use Resend.
Transactional vs Marketing Email
Understanding this distinction will save you from problems later.
| Transactional Email | Marketing Email |
|---|---|
| Triggered by a user action | Sent on a schedule or campaign |
| One email per event | Sent to a list of many people |
| Fee payment confirmation | Monthly newsletter |
| Password reset | Promotional offers |
| Payment receipt | Announcement of a new feature |
| Result published notice | "We miss you" re-engagement |
| Welcome email after signup | Weekly digest |
Transactional email is what we use in training and in EduTrack. It is covered by Resend's free tier. Marketing email requires a paid plan. Keep this distinction clear — if someone asks you to "send a newsletter to all our users," that is a different tool and a different cost conversation.
Why Resend Specifically
There are several email sending services — SendGrid, Mailgun, Postmark, AWS SES. We use Resend for the following reasons:
1. The simplest API of any email service
Sending an email with Resend is five lines of TypeScript. No configuration files, no SDK initialization rituals, no 15-page quickstart guide. The API is designed for developers who want to send emails without the overhead.
2. React email templates
Resend supports writing email HTML as React components using the @react-email/components library. This means the same skill you use to build web interfaces — React, TypeScript, props — you use to build email templates. There is no separate templating language to learn.
3. Excellent deliverability
Resend was founded by people who previously built email infrastructure at large-scale companies. Their relationships with inbox providers (Google, Microsoft, Apple) mean emails sent through Resend reach inboxes rather than spam folders.
4. Free tier is sufficient for training
3,000 emails per month, 100 per day, 1 custom domain. Every training project and small client site stays well within this. You only pay when you have real scale.
5. A dashboard that shows everything
Every email you send appears in Resend's dashboard — recipient, subject, sent time, delivery status. When a client says "I didn't get my confirmation email," you open the Resend dashboard, search their email address, and see exactly what happened: delivered, bounced, or never sent.
How Resend Fits in the EduTrack Architecture
Resend never touches your frontend. It is always called from a Supabase Edge Function — a server-side function that runs in a secure environment where your Resend API key is stored safely. The customer's browser never sees your API key.
Emails EduTrack Sends
When you look at what EduTrack needs to communicate, you quickly get a list of 6–8 email types:
| Recipient | Trigger | |
|---|---|---|
| Fee payment confirmation | Parent | Fee payment recorded as paid |
| Fee overdue notice | Parent | Due date passed, status still pending |
| Result published | Parent | Results entered by teacher |
| Attendance alert | Parent | Student marked absent |
| Teacher welcome | Teacher | Account activated by branch admin |
| Announcement | Parent + Teacher | Admin posts school announcement |
| Password reset | All users | User requests password reset |
Each of these is a separate edge function or a single function with a type parameter that selects the right template.
What You Will Have After This Section
By the end of this section, you will have:
- A Resend account connected to your GitHub login
- An API key created, saved to VaultMate, and added as a Supabase secret
- A sending domain verified (or the development workaround configured)
- A test email sent and visible in the Resend dashboard
This section is a tool setup guide, not an edge function writing guide. You are learning to configure and understand Resend here. Writing the actual edge functions that call Resend is covered in the Backend module, where Supabase Edge Functions are introduced with Resend as a practical example.
Time Required
| Page | Estimated time |
|---|---|
| Overview (this page) | 10 minutes reading |
| Account Setup | 10 minutes |
| Domain Setup | 15–30 minutes (DNS propagation can take up to 2 hours) |
| API Key | 5 minutes |
| Email Templates | 20 minutes reading |
| Verification | 10 minutes |
Total active work: approximately 60 minutes. DNS propagation is waiting time, not work time — start the domain verification step, then continue to the API key and template pages while you wait.