Transactional Email for Builders
A marketing newsletter landing in spam is a missed opportunity. A password reset email landing in spam is a support ticket and a furious user. This course teaches you how transactional email actually works — deliverability fundamentals, sending your first real email through an API, choosing between providers, building templates that render correctly everywhere, and handling bounces, webhooks, and retries safely. By the end you will have a real transactional email flow wired into a real app, with bounce handling that does not silently break.
What you'll learn
Course outline
Free — no account needed
Why Transactional Email Is Different From Marketing Email
A password reset that lands in spam is not an inconvenience — it is a broken product
How Deliverability Actually Works
SPF, DKIM, DMARC, and why a perfectly written email can still land in spam
Your First Transactional Email
Verify a domain, send a real email through an API, and confirm it arrives
Full course — $59 one-time
Choosing a Transactional Email Provider
Resend, Postmark, SES, and SendGrid solve the same problem at very different price points
Templates & Dynamic Content
Why email HTML breaks differently than web HTML, and how to avoid the worst of it
Webhooks, Bounces & Suppression Lists
A bounced email you ignore today becomes a deliverability problem for everyone tomorrow
Retries, Idempotency & Duplicate Sends
A user who gets the same receipt three times trusts your product a little less each time
The Production Transactional Email Checklist
DNS, suppression, idempotency, and the details that separate a demo from a trusted sender
Get the full course
8 lessons — from your first verified send to production-grade deliverability, templates, and bounce handling.
About this course
Transactional email — password resets, receipts, order confirmations, login codes — is triggered by a single user action and expected to arrive within seconds, which makes it a fundamentally different problem from bulk marketing email. Learning transactional email means understanding SPF, DKIM, and DMARC (the DNS records that establish sender trust), why sending domain reputation matters more than email content, how to build templates that survive being rendered by email clients with decades-old rendering engines, and how to handle bounces, spam complaints, and retries without silently losing emails or duplicating sends.
This course is for developers building anything that emails a user as part of a core flow — signup, checkout, password recovery. After completing it you will be able to verify a sending domain and send a real transactional email through an API, choose between Resend, Postmark, SES, and SendGrid, build a template that renders correctly across Gmail and Outlook, wire up bounce and complaint webhooks with a suppression list, and apply idempotency keys so a network retry never sends the same receipt twice.
Frequently asked questions
Why did my password reset email land in spam even though the content looks fine?
Deliverability is determined almost entirely by domain and sender reputation, not email content. If your sending domain is missing SPF, DKIM, or DMARC DNS records, receiving mail servers have no strong way to verify the email actually came from you, and will often route it to spam regardless of how well it is written. Check your domain's records with a free tool like mxtoolbox.com before troubleshooting anything else.
Should I use the same email provider for transactional and marketing email?
Not on the same sending domain by default. A spam complaint or high bounce rate on a marketing newsletter can damage the sending reputation shared with your password reset and receipt emails, turning a marketing problem into a core product outage. Use a dedicated subdomain (e.g. mail.yourapp.com) for transactional sending, isolated from your marketing tool's domain and reputation.
What is an idempotency key and why does it matter for sending email?
An idempotency key is a unique identifier you attach to a send request — if the same key is sent twice (e.g. due to a network timeout and retry), the provider deduplicates it and only sends the email once. Without one, a timed-out API call that actually succeeded on the provider's end can result in a user receiving the same receipt or reset code two or three times when your code retries the failed-looking request.
How do I handle bounced emails — do I need to do anything manually?
Set up a webhook endpoint for your provider's bounce and complaint events, and write the affected address to a suppression list in your own database. Before every future send, check that list and skip suppressed addresses. This is not optional housekeeping — receiving servers track how often you send to addresses that previously hard-bounced or complained, and continuing to do so actively damages your sending reputation for every email you send afterward.
Why does my email template look fine in Gmail but broken in Outlook?
Email clients use rendering engines with wildly varying levels of modern CSS support — Outlook desktop in particular lags far behind a modern browser, with unreliable support for flexbox and grid layouts. Table-based layouts remain the most consistently compatible approach across clients. Tools like react-email or MJML let you write templates in a more modern syntax while compiling down to email-safe HTML, so you do not have to hand-write table markup.