How to Integrate an Email System

Many people treat email as a tool for sending verification codes. Send one for signup, one for password reset, and the job seems done. After launch, they discover that email affects login, notifications, billing, delivery, marketing, reactivation, and user trust.

Email is not a minor feature. It is one of the most stable asynchronous communication channels between your product and users. When users are not online, email can still handle reminders, confirmations, recovery, delivery, and conversion.

Early products do not need a complex email platform, but the first version should clarify email types, provider, templates, unsubscribe behavior, logs, and deliverability. Otherwise, you can quickly run into missing emails, spam placement, failed verification codes, and messy marketing sends.

Separate Transactional and Marketing Email

Before integrating email, divide messages into two types: transactional email and marketing email.

Transactional email is triggered by user action or required system events: verification codes, magic links, password reset, payment success, invoices, task completion, exception alerts, and security notifications. These emails need to be timely, reliable, and traceable.

Marketing email is proactively sent by you: product updates, tutorials, campaigns, promotions, reactivation, and newsletters. These need segmentation, unsubscribe, frequency control, and high-quality content.

Do not mix the two. Transactional email must still be delivered even if users unsubscribe from marketing. Marketing email must include unsubscribe and should not hide advertisements under “system notification.”

The first version can use the same provider, but code and configuration should separate the types clearly.

Do Not Choose Providers by Price Alone

Your email provider directly affects deliverability and maintenance cost. Common options include Resend, Postmark, SendGrid, Mailgun, Amazon SES, and Brevo. They differ in price, developer experience, deliverability, template management, logs, and compliance support.

Early products can prioritize good developer experience, clear logs, and stable transactional delivery. Price is not the only metric. If emails fail, land in spam, or cannot be debugged, saving a little money becomes expensive.

For transactional email, check whether the API is simple, event webhooks are complete, logs are retained long enough, and failure reasons are clear. For newsletters, also check segmentation, unsubscribe, campaign analytics, and bulk sending.

Indie builders should not chase the cheapest provider first. Start with a solution that can reliably reach inboxes.

Domain Setup Is the Deliverability Baseline

Email integration does not end with an API key. You must configure the sending domain and set up SPF, DKIM, and DMARC correctly.

SPF tells receivers which servers can send on behalf of your domain. DKIM signs email so receivers can verify that content was not modified. DMARC tells receivers how to handle forged mail and helps you monitor domain abuse.

If these settings are incomplete, emails are more likely to land in spam or be rejected. For verification codes, login links, and payment notices, unreliable delivery directly breaks product usage.

The first version can use a subdomain such as mail.example.com or notify.example.com. Do not send product email from a personal address or unverified domain.

Design Templates by Scenario

Email templates are not just text inside HTML. Different emails have different goals.

Verification code emails should highlight the code, expiration time, and security note. Magic link emails should highlight the button and expiration. Password reset emails should explain that users can ignore the email if they did not request it. Task completion emails should link to the result. Payment success emails should include amount, plan, time, and support path.

Keep templates simple. Avoid heavy images and complex CSS. Many email clients support CSS inconsistently, and over-designed emails can render poorly. Key content must be readable in simple HTML or plain text.

Every email should include sender, subject, core action, necessary explanation, and support contact. Marketing emails must also include unsubscribe.

Save Sending Logs and Status

Sent does not mean received. You need to record email sending status.

At minimum, save email type, recipient, triggering user, send time, provider message ID, status, and failure reason. If the provider supports webhooks, record events such as delivered, bounced, opened, and clicked.

Transactional email especially needs logs. When a user says “I did not receive the code,” you should quickly know whether the email was sent, bounced, rejected, or delivered. Without logs, you can only guess.

A simple email_logs table is enough for the first version. Do not store full email bodies forever if privacy is a concern, but keep the key metadata searchable.

Add Retry and Rate Limits

Email will fail: provider timeout, invalid mailbox, domain configuration error, full inbox, or temporary bounce. You need failure handling.

For real-time emails such as verification codes, magic links, and password resets, show a clear error if sending fails and allow retry later. For task completion and notification emails, retry through a queue. For permanent bounces, do not send forever.

Also add rate limits. Verification emails should not be triggered infinitely, or they create cost and abuse risk. Common limits include per-email per-minute, per-hour, and per-day caps.

Email delivery should be reliable, but also resistant to abuse.

When You Need an Email Queue

The first version can call the email API directly. But once email volume grows, or sending should not block user actions, you should consider a queue.

Task-completion emails after generation, invoice emails after payment, bulk newsletter sending, and delayed retries all fit queues.

Queues make the main flow more stable. User actions do not need to wait for the provider response. Email failure also does not break core business state.

Early products can use a simple job queue, database queue table, framework queue, or cloud service. Do not introduce heavy architecture only for email, but do not let email sending block core requests either.

A Minimal Email System Structure

A first version can look like this:

Email types:
- Login verification code
- Password reset
- Payment success
- Task completion
- Important exception alert
- Product update or newsletter

Base modules:
- Email provider API
- Domain SPF / DKIM / DMARC
- Template management
- email_logs table
- Failure retry
- Rate limiting
- Marketing unsubscribe

This is not complex, but it covers the most important early email scenarios. Make transactional email reliable first, then gradually add marketing and automation.

Summary

Email is not only for verification codes. It supports login, password recovery, payment confirmation, task delivery, notifications, and user reactivation. Early integration should separate transactional and marketing email, configure domain authentication, design scenario-based templates, record sending logs, and handle failures and rate limits.

A good email system does not make the product flashy, but it makes it trustworthy. Users receiving the right email at a critical moment is part of product reliability.

Homework

• List the transactional emails your product must send.
• List which emails are marketing emails and design unsubscribe.
• Check whether the sending domain has SPF, DKIM, and DMARC.
• Design an email_logs table for key sending status.
• Create rate limits for verification codes or magic links.

Next Lesson

Message Notification Design: more notifications are not better. Good notifications remind users to take the next step at the right time.