Email delivery sounds like a solved problem. You sign up for a provider, add an API key, call send(), and the email arrives. For the first hundred users, that's mostly true. But somewhere between a hundred users and a hundred thousand, email becomes one of the most operationally complex parts of your product. Password reset emails that don't arrive. Onboarding sequences that land in spam. Billing alerts that never get seen. When email breaks, churn spikes, support tickets flood in, and trust erodes in ways that are hard to rebuild.
The developer email tooling landscape has improved dramatically in the last two years. A new generation of developer-first email platforms has replaced the legacy providers with APIs that feel modern, templates that are built like UI components, and monitoring dashboards that actually help you debug deliverability problems. This guide covers the choices, the trade-offs, and the fundamentals that every developer should understand before their email pipeline becomes a problem.
Why email is harder than it looks
The core complexity in email isn't sending — it's deliverability. Whether your email lands in the inbox, the promotions tab, or the spam folder is determined by dozens of signals that inbox providers (Gmail, Outlook, Yahoo) use to assess reputation: your sender domain's age, your SPF and DKIM configuration, your DMARC policy, your historical bounce rate, your unsubscribe rate, and how recipients interact with your emails. A new domain with no sending history starts with no reputation — and reputation builds slowly, over weeks of consistent, low-complaint sending.
The second layer of complexity is infrastructure management. If you self-host an SMTP server (which almost nobody should do), you're responsible for IP warming, bounce handling, feedback loop setup with major inbox providers, and monitoring IP blacklists. If you use a shared IP pool from a provider, your deliverability is partially dependent on the behavior of other senders on those same IPs. Dedicated IPs improve isolation but require warming periods before they're trusted. None of this is hard to understand, but it requires ongoing attention that most development teams would rather not provide.
The developer's deliverability reality
The single best thing you can do for deliverability: configure SPF, DKIM, and DMARC on your sending domain before your first production send. These are DNS records that take 15 minutes to set up and prevent spoofing — inbox providers heavily penalize domains that don't have them.
Transactional vs. marketing email
Before choosing a tool, it's worth distinguishing between the two fundamentally different types of email your product will send. Transactional email is triggered by user actions: welcome emails, password resets, purchase confirmations, subscription notifications, two-factor authentication codes. These emails are expected by the recipient, have high open rates (often 60-80%), and must arrive immediately and reliably. Missing a password reset email is a support ticket. Missing a 2FA code is a blocked login.
Marketing email is broadcast-style: newsletters, product announcements, feature launches, re-engagement campaigns. These go to opted-in audiences on a schedule. They have lower open rates (typically 20-40%), and a delayed or failed send is annoying but not critical. Marketing email has different compliance requirements (CAN-SPAM, GDPR require unsubscribe links and physical address), different deliverability dynamics, and benefits from A/B testing and segmentation features that transactional tools don't need.
The operational recommendation: use separate tools for transactional and marketing email, and ideally separate sending domains (e.g., [email protected] for transactional, [email protected] for marketing). Mixing them on the same domain means a spam complaint on a marketing campaign can degrade the deliverability of your password reset emails — a very bad outcome.
Resend: email for modern developers
Resend was founded by the team behind React Email, and that integration is the platform's primary differentiator. Instead of managing HTML string templates in a separate system or using a drag-and-drop editor that generates unreadable markup, you write email templates as React components. They're strongly-typed, composable, and live in your repository alongside your application code. A change to your brand's button style updates every template that uses it.
The API ergonomics are excellent. A minimal send is five lines of code: import the client, instantiate with your API key, call send() with from, to, subject, and react (your template component with props). The response is typed. Errors are typed. The Node.js SDK handles retries and timeout configuration. Compared to the previous generation of email APIs, which returned opaque status codes and required consulting documentation for every edge case, Resend's API is a genuine improvement.
The free tier is 3,000 emails per month and 100 per day — sufficient for development, staging, and early production usage. The pricing scales predictably for higher volumes, and dedicated IPs are available on higher plans for teams that need deliverability isolation.
Deliverability fundamentals
Whether you use Resend or any other provider, these DNS configurations are non-negotiable for production email. SPF (Sender Policy Framework) is a DNS TXT record that lists which mail servers are authorized to send email on behalf of your domain. DKIM (DomainKeys Identified Mail) adds a cryptographic signature to your outgoing emails that receiving servers can verify against a public key in your DNS. DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receiving servers what to do when an email fails SPF or DKIM checks, and provides reporting so you can monitor for spoofing attempts.
- SPF: Add a TXT record to your DNS that includes your email provider's sending servers — Resend provides the exact record to copy
- DKIM: Add a CNAME or TXT record with the public key your provider generates for your domain — usually one record per sending domain
- DMARC: Start with p=none (monitor only) to collect data, then tighten to p=quarantine or p=reject once you've validated all legitimate sending paths
- Custom domain: Send from your own domain ([email protected]), never from a shared subdomain of your provider
- Bounce handling: Configure your provider to automatically suppress bounced addresses — high bounce rates are one of the fastest ways to damage sender reputation
Building templates with React Email
React Email is an open-source library (maintained by the Resend team) for building email templates as React components. The library provides a set of email-safe components — Html, Head, Body, Container, Section, Row, Column, Text, Button, Link, Image, Hr, Preview — that render to email-client-safe HTML. This is important because email HTML is a different world from browser HTML: tables still work better than flexbox in many clients, certain CSS properties are ignored, and Gmail strips style tags from the head.
A basic welcome email in React Email is about 30 lines of TSX. The component receives typed props (userName, productName, loginUrl), renders a styled layout using the library primitives, and exports a default function. You can preview it in a browser with the React Email dev server (npm run email), which renders a live preview with toggling between different email clients' rendering behaviors. This preview capability alone prevents the cycle of send → check inbox → spot rendering issue → edit template → send again.
Testing and previewing before you send
Email testing deserves its own strategy because email clients render HTML very differently. Outlook 2016+ uses the Word rendering engine, which supports almost none of modern CSS. Gmail strips certain styles. Apple Mail is generally the most modern renderer. What looks great in your browser can look broken in Outlook. The React Email dev server handles basic cross-client preview, but for production confidence, you'll want to test in actual email clients — either manually via seed addresses or using a tool like Email on Acid or Litmus.
For functional testing (not just rendering), always maintain a list of seed email addresses across major providers — Gmail, Outlook, Yahoo, and iCloud — that you send to before every significant template change. Deliverability tools like Mail Tester (free) score your email against common spam filter criteria and report which DNS records are missing or misconfigured. Running your outgoing email through Mail Tester before your first production send is a 10-minute investment that can prevent significant deliverability problems.
Monitoring deliverability in production
Resend's dashboard shows delivery status (queued, sent, delivered, bounced, complained) for every email. The key metrics to monitor: delivery rate (should be 98%+), bounce rate (hard bounces above 2% will cause most providers to flag your account), and spam complaint rate (above 0.1% is a warning sign, above 0.3% triggers automatic sending restrictions with most major inbox providers). Set up webhook alerts for high bounce rates and complaints so you're notified before reputation damage compounds.
Google Postmaster Tools is a free service from Google that provides domain-level reputation data for email sent to Gmail accounts — which is typically 40-60% of your user base. It shows your IP reputation, domain reputation, and spam rate as measured by Gmail. If your emails are landing in spam for Gmail users, Postmaster Tools will tell you why. Set it up on your sending domain before you hit production scale — it requires DNS verification and takes a few days to start showing data.
Scaling from 100 to 1 million sends
The main operational concern when scaling email volume is IP warming — the practice of gradually increasing send volume from new IPs so that inbox providers can observe consistent, low-complaint behavior before trusting them with high volumes. If you suddenly send 500,000 emails from an IP that has no sending history, a significant percentage will land in spam regardless of content quality. Resend handles IP warming automatically on shared IP pools; dedicated IP warming requires following a specific ramp-up schedule (typically 1,000 → 5,000 → 25,000 → 100,000 over several weeks).
At scale, list hygiene becomes critical. Remove unsubscribers immediately. Suppress hard bounces permanently. Run re-engagement campaigns before emailing contacts who haven't opened in six months, and remove those who don't re-engage. Sending to disengaged contacts is one of the primary drivers of spam complaints, which damage the deliverability of all your other emails. A smaller, engaged list consistently outperforms a large, unengaged one in both deliverability and conversion.
Pre-launch email checklist
- 1Configure SPF, DKIM, and DMARC records on your sending domain — verify with Mail Tester
- 2Set up a custom sending domain (not a provider subdomain) — this is free with Resend
- 3Test all transactional emails across Gmail, Outlook, and Apple Mail before launch
- 4Configure bounce and complaint webhooks to alert your team immediately
- 5Set up Google Postmaster Tools on your sending domain for ongoing Gmail reputation monitoring
- 6Implement unsubscribe handling for any marketing emails — required by CAN-SPAM and GDPR
- 7Separate your transactional and marketing sends to different domains or subdomains
- 8Document your email sending flows so the team knows which emails send when and why
“Email is the one communication channel your users actually own. Treat it with the same engineering care you'd give your API — because when it breaks, they notice immediately.”
— Tama
